On 1/3/14, 12:19 PM, "Ralph Holz" <[email protected]> wrote:
>Hi, > >>> Tell me something new. ;-) Although in fact, the whole thing goes much >>> deeper. A broken hash algorithm means root cert-like compromise as it >>> means the capacity to imitate a correct signature by a root cert. There >>> is no fix for this but blacklisting. Not in any model with TTPs, by the >>> way. >> >> You mean blacklisting the algorithm, right? > >Ultimately, yes. That's what Moz etc. did, but you cannot force CAs to >switch to new algorithms at once. New root certs have to be added to the >root stores, new certs issued for existing customers, etc. Thus the >grace period until 2011. IMO, individuals ought to be able to turn off obsolete algorithms and suffer whatever peril comes as a result (none in many cases). Disabling algorithms on a per-CA basis may be good enough without requiring users to get involved. > >In the meantime, all you can do is blacklist known-rogue certs. Or whitelist certificates you require (which is more or less what you suggest below). >Alternatively, pull the root cert from which MD5 signatures were issued. >As the MD5 attack still had considerable cost (for the hobby blackhat, >not a 3-letter agency), it was deemed that this must suffice for a while. To make the discussion CT-compliant, having logs provide a list of algorithms that are used by each CA would be a nice feature to enable decisions like this. _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
