RE: [saag] X.509 certificate collision, via MD5 collisions

[Paul Hoffman <paul.hoffman@xxxxxxxx>]

At 10:46 AM -0500 3/4/05, Robert Zuccherato wrote:
> However, I really wonder if we should be recommending that people 
> change their implementations at this point.  I don't think we know 
> enough yet about the potential attacks on MD5, SHA-1 to say with any 
> certainty that any particular counter-measures are worth 
> implementing.  This infrastructure was built assuming that people 
> will use strong hash functions.  I see no reason at this point to 
> change that assumption.  People should have stopped using MD5 a long 
> time ago.  Over the next couple of years they will likely have to 
> stop using SHA-1 as well.  I think that is the real advice that we 
> should be giving people at this time.

The first sentence fully contradicts the last one. To use a new hash 
algorithm is a *much* larger change than to have CAs change the 
method they issue serial numbers; one involves changing every 
validating client, the other doesn't.

> There are also some practical problems with overloading the serial number.

The term "overloading" is silly here. Before now, no one has accused 
VeriSign of "overloading" its serial numbers.

>   CRLs will, in most circumstances, increase in size.  Also, OCSP 
> responders that pre-compute responses may have trouble pre-computing 
> "good" responses if they cannot predict which serial numbers have 
> been used.  This issue would come up with responders that work from 
> CRLs and assume that a certificate is "good" if it's serial number 
> doesn't appear on a CRL.

Those are valid points. However, weigh them against asking every 
validating client to change its software (and not even assuring them 
that they won't have to again later when we discover that the 
"better" hash algorithm has some other flaws). Which is the better 
way to get the public to trust PKI more?

> I'd also like to point out that the serial number proposal would 
> only help X.509 certificates and not CRLs, RFC 3161 time stamp 
> tokens (there was already a message to the CFRG list today showing 
> how to extend the MD5 X.509 work to 3161 tokens), OCSP responses, 
> etc.

Please explain the attack scenario for these. What possible value is 
there for a CRL signature spoofing attack, for example? As for 
timestamps and OCSP responses, what Eric said yesterday still stands: 
if you are relying on a particular signed object for a valuable 
transaction, keep the object around.

--Paul Hoffman, Director
--VPN Consortium