Mike,
Any protocol that uses public keys to identify participants, and
implicitly assumes that different participants will have
different/unrelated public keys would be susceptible to attack if the
CA does not verify posession of the secret key (or otherwise guarantees
that public keys are unrelated to each other).
For more concrete examples - the MQV and STS key exchange protocols break
if the CA allows parties to register public keys without proving posession
of the secret keys. (See examples in papers by Krawczyk from 2005 or
Kaliski from earlier on.)
In contrast, the signature mode of IKE and the ISO 9798-3 key exchange
protocols were proven to be secure even if the CA does not verify
posession of the secret key.
It is also possible to concoct protocols that would remain secure if it
is guaranteed that all public keys are chosen using good random sources,
but would break if parties are allowed to register public keys that were
chosen in funny ways --- even if a POP is performed. I'm not aware
though of any existing protocols out there that have this property.
Ran
On Fri, 14 Dec 2007, Mike Henry wrote:
> Paul,
>
> " While such behavior is harmless for the
> security of typical authentication protocols such as IPSEC,TLS etc, it
> can be disastrous in other situations."
>
> Could you give some examples of the disastrous situations.
>
> Mike Henry
>
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Paul Hoffman
> Sent: Thursday, December 13, 2007 7:57 PM
> To: ietf-pkix@xxxxxxx
> Cc: Ran Canetti
> Subject: Re: [secdir] security review of draft-ietf-pkix-rfc3280bis-09
>
>
> [[ Forwarded for Ran; not sure why it didn't get to the PKIX list. ]]
>
> *I have reviewed this document as part of the security directorate's
> *ongoing effort to review all IETF documents being processed by the
> *IESG. These comments were written primarily for the benefit of the
> *security area directors. Document editors and WG chairs should
> treat
> *these comments just like any other last call comments.
>
>
> While I have not read the document in full detail, my overall impression
> is that it is well thought out and nicely done.
>
> One aspect that I found a bit lacking though is in providing a language
> for certificates to contain inormation on what the certificate actually
> attests to. Salient options include:
>
> - Does the certificate attest that the certified owner has merely
> presented the public key to the CA?
>
> - Does the certificate attest that the certified owner of the
> public key actually has the corresponding secret key?
>
> - Does the certificate attest that the certified owner has chosen the
> key
> with a good/accredited/certified random number generator?
>
> There can of course be additional variants - e.g., has the CA explicitly
> seen the secret key, or was there only a "proof of ability to
> sign/decrypt"? in the latter case, what's the exact protocol used and
> what
> security guarantees does it carry? (e.g. was a POP out of those in RFC
> 2797 performed? another protocol?)
>
> Each of these attestations provides a different "cryptographic trust"
> guarantee. The differences can be critical to the security of protocols
> that rely on these certificates. (For instance, if a certificate only
> attests that the CA has seen the public key, then this leaves open the
> possiblity that a user has registered a public key that was copied from
> the certificate of another entity. While such behavior is harmless for
> the
> security of typical authentication protocols such as IPSEC,TLS etc, it
> can be disastrous in other situations.)
>
> It thus seems prudent that a certificate will be required to contain a
> field that describes the "semantics" of what's actually being certified
> regarding the registered public key, perhaps out of a number of standard
> options.
>
> Also, it seems that this issue and the associated perils should be
> discussed in the security considerations.
>
> [Having spent only few hours with this 140+ page document, I may have
> missed a discussion of this issue. In this case, my apologies... but
> still, this may mean that the discussion can be made more prominent.]
>
> Hope that I dont get the entire pkix wg running after me with axes due
> to
> this comment... :)
>
> Ran
>
>
> _______________________________________________
> secdir mailing list
> secdir@xxxxxxx
> https://mailman.mit.edu/mailman/listinfo/secdir
>
>
> Important Notice: This email message and any attachments may contain information and/or trade secrets that are private, and are meant to be delivered solely for the use of the intended recipient(s). If you are not the intended recipient, please do not read, copy, use, forward or disclose the contents of this communication to others. Interception of e-mail is a crime under the Electronic Communications Privacy Act, 18 U.S.C. 2510-2522 and 2701-2709. If you have received this email in error, please immediately notify us by return email or by telephone at [703-221-0200 Ext 51119] and promptly delete this message. Thank You.
>
>
Important Notice: This email message and any attachments may contain information and/or trade secrets that are private, and are meant to be delivered solely for the use of the intended recipient(s). If you are not the intended recipient, please do not read, copy, use, forward or disclose the contents of this communication to others. Interception of e-mail is a crime under the Electronic Communications Privacy Act, 18 U.S.C. 2510-2522 and 2701-2709. If you have received this email in error, please immediately notify us by return email or by telephone at [703-221-0200 Ext 51119] and promptly delete this message. Thank You.