Subject: AD Review of draft-ietf-pkix-rfc2510bis-07.txt

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Fri, 07 Feb 2003 23:26:11 -0500

I am in the process of reviewing draft-ietf-pkix-rfc2510bis-07.txt.
This review isn't yet complete, but far enough along to give you two key
pieces of feedback. I will also request a formal IETF Wide Last Call, so
that it can happen in parallel while you work on edits.

1. You need to split the References section into two sections. One
    labeled "Normative References" and the other "Informational
    References." The IESG has been asked by the RFC Editor to require
    this on all submissions.

    Normative references are those which describe some portion of feature
    of the protocol such that a protocol developer must read the
    normative reference in order to implement the protocol. A normative
    references is also one which directly influences the protocols in the
    referencing document such that a change in the document references
    would have an impact on the protocol being defined.

2. Section 2.2.2 states "and EE equipment MUST support the second scheme
    listed below." Can you more clearly define this, as in a references
    to a section number.

Note: Below is not a formal comment

Today one of the common ways of issuing certificates is via a user's web
browser. Both Netscape/Mozilla and Internet Explorer have a mechanism
for submitting a form that contains a public key (in some form of self
signed object, aka a PKCS10 object) to a server, presumably a CA, which
can then download either immediately or at some other time, a user's
certificate. Typically a secret value is also transmitted with form post
that is used to authenticate the user. Presumably this secret pass
phrase has been delivered in a secure fashion. If this transaction
occurs via an SSL connection, doesn't this provide sufficient strength
to initially authenticate the user. The transaction itself doesn't need
to be enciphered via a shared secret key, SSL provides the necessary
protection.

So my question is: "How does this fit in with this document?" (or did I
miss something because I haven't read the whole document in detail yet).

Thanks.

                         -Jeff

---

From: Carlisle Adams <[email-masked]>
Date: Fri, 14 Feb 2003 16:02:38 -0500

Hi Jeff,

Thanks for your preliminary feedback on rfc2510bis-07.txt.  We will split
the references into Normative and Informational, as you suggest, and will
add a more explicit reference in Section 2.2.2.

As for your comment regarding the PKCS #10 protocol exchange over SSL (the
model for certificate issuance employed by popular browsers), it is
generally accepted that this mechanism is common and workable.  It is also
too limited for some environments.

 - It is not always the case that certificate issuance takes place over
SSL-protected connections, and so total reliance upon the presence of an
underlying secure channel seems unwise.  It would be better to have
protection mechanisms built into the issuance request/response protocol
itself, if possible.

 - Passing a secret value along with the PKCS #10 in a form post, while
authenticating the sender to some degree, does not authenticate the content
of the PKCS #10:  there is no cryptographic binding between the secret value
and the data inside the PKCS #10 message.  Again, conveying these together
through a secure underlying transport such as SSL can help, but what if that
transport isn't there?  And, even if it is there, no binding exists once the
two pieces pop out the other end, so if the CA doesn't act on this issuance
request immediately, the value of the sender authentication is lost.  It
would be better to have a strong cryptographic binding between the shared
secret used for sender authentication and the issuance request.

 - This has been discussed many times over the PKIX list over the past
several years, but PKCS #10 does not readily accommodate key pairs that are
to be used for purposes other than signing.  If I have a key pair that can
only be used for encryption, how can I use the private key to sign the PKCS
#10 request?  If I want to certify my Diffie-Hellman public key, how can I
use my corresponding private key to sign the request (RFC 2875 provides a
couple of mechanisms, but these do stretch the "spirit" of PKCS #10
somewhat).  It would be better to have a protocol message (including
subsequent challenge/response messages, if necessary) that can easily handle
certificate issuance requests for different kinds of key pairs.

 - The syntax of PKCS #10 assumes that the requester already knows its own
DistinguishedName (DN), as well as the DN of the CA.  In many applications
this will not be the case:  as part of the issuance process, the CA will
assign a DN to the entity and include this DN in the response (i.e., in the
issued certificate).  It would be better to have flexibility in the request
message to allow the sender to be identified in some other way.

 - PKCS #10, even for environments in which it is a suitable technology,
does not do anything more than request certificate issuance.  Every other
aspect of certificate life cycle management (update/renewal, revocation,
recovery, etc.) needs protocol messages beyond PKCS #10.  It would be better
to have a single, comprehensive suite of protocols that encompasses the full
life cycle of certificate use.

For all the above reasons (and perhaps others that I couldn't remember off
the top of my head), CMP/CRMF was created.  In an attempt to accommodate the
current browser-based solution, a PKCS #10 message can be carried in a CMP
envelope, but this isn't really recommended.  CMP/CRMF is intended to
provide all the functionality of PKCS #10, while addressing every one of its
limitations.  Significant implementation and interoperability experience has
shown that it does this quite successfully in many different kinds of
environments.

Carlisle.