Re: [secdir] security review of draft-ietf-pkix-rfc3280bis-09

[Paul Hoffman <phoffman@xxxxxxx>]

[[ 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