ietf-smime
[Top] [All Lists]

Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

2008-12-30 16:05:34

At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote:
This is a practical application of an approach that I remember being brought 
up during discussions about MD5 at a saag meeting some time ago.  I also 
recall someone mentioning at the time that many/most CA's were already issuing 
certificates with random rather than sequential serial numbers, which would 
have thwarted this particular attack.

Your recollection may be off. I believe I was the person who brought up the 
serial number hack at the mic, and I'm pretty sure I said "some", not "many" 
(and certainly not "most"!). When I looked at a handful of popular CAs earlier 
this week, I only found a few who are using randomization in their serial 
numbers.

Regardless of that, the authors of the MD5 paper are correct: trust anchors 
signed with MD5 are highly questionable as of today (well, actually, since they 
published their last paper). Hopefully, the maintainers of the popular trust 
anchor repositories (Microsoft, Mozilla, etc.) will yank out the trust anchors 
signed with MD5 (and MD2!) as soon as possible.

At 3:10 PM -0500 12/30/08, Russ Housley wrote:
RFC 5280 does not include this advice.  It is sound advice that was discussed 
in PKIX and other venues.  Perhaps a BCP is in order.

Man, that is really stretching the definition of "best".

For one, it is only needed in signatures that use known-attackable hash 
functions. A "best practice" in that case is to use a better hash function in 
the signature. Also, it relies on the ability of the software using the random 
number to be sure that the result is a positive integer in ASN.1, which seems 
overly optimistic.

If the IETF feels that adding randomization to signatures is important, we 
should define randomized signature functions. We could start with NIST Draft SP 
800-106 
(<http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>).
 However, I think that doing so is sending the wrong message: we should instead 
be encouraging the use of non-broken hash functions.

--Paul Hoffman, Director
--VPN Consortium