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