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

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

At Tue, 30 Dec 2008 12:53:06 -0800,
Paul Hoffman wrote:
> 
> 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.

So it's in my deck from SAAG at IETF 62.

http://www.ietf.org/proceedings/05mar/slides/saag-3.pdf

I don't know whether many or most do it. IMO everyone should.


> >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.

I certainly agree we should be encouraging the use of non-broken hash
functions. However, randomizing the SN seems like very cheap backward
compatible insurance against the fact that that's going to take a long time. 

-Ekr