[17016] in cryptography@c2.net mail archive
Re: MD5 collision in X509 certificates
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Sun Mar 6 14:35:50 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Sat, 05 Mar 2005 09:23:11 -0700
From: Anne & Lynn Wheeler <lynn@garlic.com>
To: Victor Duchovni <Victor.Duchovni@MorganStanley.com>
Cc: Cryptography <cryptography@metzdowd.com>
In-Reply-To: <20050304211830.GW7470@piias899.ms.com>
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?
the purpose of a certificate is analogous to the old letters of credit
in the sailing ship days .... it supposedly establishes the bonifides of
the individual in an offline, non-connected world where the relying
party has no other recourse regarding trust/integrity of the individual
that they are dealing with.
in the PKI/certificate world ... the relying party receives some sort of
digitally encrypted/signed information and validates it using the public
key presented in the attached certificate. a correctly validation then
implies some kind of 3-factor authentication (although the
PKI/certificate paradigm tends to totally gloss over this
characteristic, instead attempting to focus the communities attention on
the value of the certification as opposed to focusing the attention on
any possibility/value/trust that some part of 3-factor authentication
might have occured).
In any case, if the public key (from some source, possibly a
certificate) is able to validate the transmission, then the relying
party assumes that some portion of 3-factor authentication occured in
the access and use of the corresponding private key ... possibly
* something you have (private key exclusively in a hardware token)
* something you know (hardware token won't work appropriately w/o PIN)
* something you are (hardware token requires some biometric)
in any case, given that the relying party accepts the validation by the
public key as representing some implied 3-factor authentication involved
in access and use of the corresponding private key ... then the relying
party may be faced with just who the implied authentication corresponds
to. In the typical, long time accepted business process ... the relying
party will have prior relationship with the entity being authenticated
and it will be explicit and/or implicit in the communication itself. In
the more modern world, in the situations where the relying party has no
prior relationship with the authenticated entity ... they will have
access to online and/or real-time information to establish that fact.
However, certificates were targeted at the offline email world ... where
the email was created, digitally signed (presumably after some form of
3-factor authentication occuring to establish access/use of the private
key), and the email, digital signature, and certificate packaged up and
sent off to some party that there had been no previous communciation
(might be considered spam in this day and age). After some number of
intermediary store-and-forwards stops, the package arrives at the post
office of the relying party. the relying party eventually calls their
post office, exchanges emails and hangs up.
At this point the relying party is presented with a digital signed
message with whom that they had no prior communciation. The attached
certificate provides the public key for validating the digital signature
and the rest of the certificate contents is supposedly to attest to some
characteristic of the email sending party (that the relying party has no
other way of validating).
The implication is that if i can substitute a public key in some
certificate that attests to represent some other party .... then it may
be some form of identity theft (fraudulent messages can be created that
otherwise appear to have originated from you ... and validate with the
substituted public key). The other might be elevation of privileges ....
adding characteristics to a certificate that were otherwise not provided.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
