MD5 collision in X509 certificates

[Anne & Lynn Wheeler]

Victor Duchovni wrote:
> What is the significance of this? It seems I can get a certificate for
> two public keys (chosen, not given) while only proving posession of the
> first. Is there anything else? In what sense is the second public key
> useful to the attacker?

so three kinds of attacks on certificate contents ... the previously two 
mentioned

* identity theft
* privilege escalation

the other is possibly by the relying party against the key owner.

in the early '90s identity certificates were all the rage. some problems 
were at the time the certification took place ... it might not be 
possible for the certification authority to determine all possible kinds 
of identity information that a relying party (at any point in the 
future) might require ... so there was a trend to overloading an 
identity certificate with all possible types of identity information on 
the off chance that something might be useful to some relying party in 
the future. this led to increasing realization that such collection of 
identity information might represent various kinds of privacy violation 
and you saw some retrenching to relying-party-only certificates in the 
mid-90s ... misc. relying-party-only certificates only containing an 
account number to be used in online/real-time transaction (note however, 
in online/real-time relying-party-only scenario it is also trivial to 
show that certificates are redundant and superfluous)
http://www.garlic.com/~lynn/subpubkey.html#rpo

the other thing in the 90s was trying to project a value proposition for 
certificates. there was a lot of FUD and confusion generated about the 
value of certificates to the point that it was frequently obscured that 
it was even necessary to have security and safety around the protection 
and use of the private key ... and/or that any form of 3-factor 
authentication was even involved in the access and use of the private 
key. To this day, you have people writing about using a digital 
certificate to create a digital signature.

So another value representation for digital certificates was that of 
non-repudiation. basically if the non-repudiation flag in a digital 
certificate was checked/marked ... then the relying party could assume 
non-repudiation on the part of the originating party. Again this is a 
scenario trying to represent the value of a digital certificate in place 
of the safety and security around the access and use of the private key.

So the story given to merchants in the merchant/consumer market place 
.... was that the existed circumstances were that in any dispute the 
burden of proof is on the merchant .... but the proposal was that if a 
merchant could produce any certificate (for the originator's public key) 
that had the non-repudiation flag marked/checked, then the burden of 
proof (in a dispute) whould shift from the merchant to the consumer.

So if that effort had been succesful ... then it would be in the 
interest of merchants to be able to produce a consumer digital 
certificate that included the non-repudiation flag (regardless of 
whether that certificate had been used in the original transaction or 
not .... since by definition all burden of proof then is shifted to the 
consumer).

some of this is discussed in various postings regarding finread ... 
where the EU attempted to dictate some minimum hardware environment that 
  would provide some level of assurance around the access and use of the 
private key (which helps diffuse the confusion around whether the 
digital signature value proposition relies solely in the existance of a 
digital certificate .... or whether there is some value in controlling 
the access and use of private keys .... and it possibly isn't the case 
that digital signatures are generated by digital certificates):
http://www.garlic.com/~lynn/subpubkey.html#finread

other past postings on 3-factor authentication
http://www.garlic.com/~lynn/subpubkey.html#3factor

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com