[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 5:54 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?
Yes, a good question indeed.
Say that SHA-1 is completely broken in the sense that we can produce collisions
at will, of all sorts and forms.
Say also that we have a few valid TSA certificates issued for the same key
pair, signed using good hash algorithms (or else all bets are off anyway).
The randomness properties of SHA-1 will remain intact even if SHA-1 is broken.
This means that the risk/chance that two valid certificates, signed with safe
signature algorithms, will by chance produce collisions, is still totally
Where am I thinking wrong here?
On 3/14/09 8:00 PM, "Jim Schaad" <ietf@xxxxxxxxxxxxxxxxx>
The question you need to be asking is – Do you believe that SHA-1 will be
broken one day, and if it is broken do you want to have in place a solution to
deal with it.
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 7:06 AM
Subject: Do we need rfc 3161bis?
The more I
look into this the more I get to doubt that we actually need 3161bis.
The only substantial technical change I know of is to allow the updated ESS
certIDv2 to be used to identify the signer’s certificate IF the TSA for
some reason choose to hash its certificate with another hash then SHA-1.
The rationale for the certID identifier is given in section 5 of RFC 2634 and
describes attacks where one valid certificate is substituted by another valid
certificate (exceopt for some DoS case that I don’t think is relevant
Now I have to ask myself. How likely is it that a legitimate TSA has 2 or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 collision.
This is not the previously discussed certificate collision attack using weak
certificate signing hash, where I may prepare a certificate request in a way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to find a way
to prepare the TSA certificate requests, the TSA certificate hash need to be
weak in addition to the certID hash AND In addition to that the complete
certificates (not only the to be signed part) need to create a hash collision
when computing the certID.
So, my first question is if this change addresses any real security threat?
Can someone provide a reasonable threat analysis?
And consequently, if there are no real threats to solve, does this update
motivate the potential interoperability issues that might be the result of by
allowing ESS CertIDv2 in time stamp tokens?
If we do come to the conclusion that it is worth it, then why not just create an
update RFC updating RFC 3161 instead of replacing it?
This update does not change any bits on the wire for implementations of the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA’s certificate.
This seems like a perfect thing for an update RFC. Another argument is that the
old editors that rightfully should have the credit for RFC 3161 are not part of
this minor amendment but are completely erased from the update. That may be
reasonable if the changes are major but I’m not so sure in this case.