At 6:13 PM -0500 12/12/07, Ran Canetti wrote:
*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?)
These aspects of cert issuance criteria are represented via the CPS of the
issue and/or the policy under which the cert is issued. The issuer may choose
to include a policy OID in the cert policies extension, for the cert, and
even to include policy text (or a reference to the text) via the UserNotice
part of this extension. So, the bottom line is that PKIX already defines ways
for CAs to convey this info to relying parties, although we do not mandate
that CAs express this in the cert policies extension.
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.)
As you noted above, proof of possession is part of our standard cert request
protocols, (CMC and CMP, and is a mandatory feature of both. Wether the CA
demands PoP is another fact that can be expressed in the CP or CMS.
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.
We agree, and PKIX addresses this issue by requiring support for the cert
policies extension. we can't mandate what CAs put in their policies, or even
mandate that they use the extension, just that compliant implementations of
CA and client (RP) software know ho to process it.
Steve