Subject: RE: CMC Comments?

From: Carlisle Adams <[email-masked]>
Date: Wed, 16 Dec 1998 19:12:02 -0500

-----Original Message-----
> From: Barb Fox (Exchange) [mailto:[email-masked]]
> Sent: Wednesday, December 16, 1998 2:17 PM
> To: [email-masked]'
> Cc: [email-masked]
> Subject: CMC Comments? 
> 
> Carlisle:
> 
> Could you please post your Orlando comments to the list? Thanks!
> 
> --Barbara Fox
> [email-masked]
-----------------------------

Barb, et al,

Apologies if the delay has kept you waiting.  As it turns out, getting
these comments posted was not the only thing on my plate this week...

I have two primary concerns with respect to the latest draft of the CMC
protocol (despite the fact that it is a vast improvement over previous
iterations).  The first is the security of the initialization procedure.
For signing key pairs, the reqSequence is a SEQUENCE OF taggedRequest,
each of which could be a PKCS #10 or a CRMF structure (i.e., each
element carries its own POP over the contents of the corresponding
request).  In the controlSequence, an identityProof is computed over the
full reqSequence.  The problem is that each individual request may carry
no identity information (the draft explicitly says that the subject MUST
be present, but may be NULL in order to accommodate environments in
which names are centrally assigned (which makes sense to ensure
uniqueness of DNs)).  Thus, the POP is computed over a structure without
identity information.  This allows me to take the request and
corresponding POP from someone else's message, put it in my own message,
compute my identityProof over the request, and submit the result to the
CA.  The CA then issues a certificate with my name and the "borrowed"
public key.

For encryption key pairs, the draft describes a mechanism for reducing
the amount of state kept on the CA.  This mechanism suffers from the
same problem as that described above.  The server computes the variable
y from a value x and the public key from a request (y = F(x,PK)).  The
value x is reused over multiple requests for some ("short") period of
time, but if I take the public key from someone else's request message
then I know that the same y will be used in the challenge during this
period of time, so I can send their decryptedPOP response as my response
and be assured that it will pass.  Thus, again, I can get my name and
someone else's public key put into a certificate.  I'm willing to be
convinced that there actually is a way to save CA state and do this
initialization securely, but I'm not convinced yet (I suspect that you
have to send a new y with every request).

As usual, if you can't trust the certificates (the binding between
identities and key pairs), you haven't got a PKI (at least for the
purposes of PKIX).  So, my feeling is that this needs to be addressed.

My second concern is the difficulty of interoperability.  A number of
parts of the draft are sufficiently underspecified that I don't see how
two independent implementations could hope to communicate.  Many
examples may be cited; here are some representative ones:

- the draft does not specify how to coordinate between CRMF controls and
CMC controls (when these overlap in functionality);
- the draft does not specify example uses of RegInfo and ResponseInfo
(is the appendix in CRMF still valid?);
- the draft does not specify how to do off-client generation of
encryption key pairs, while recognizing that some environments will
want/need this functionality (it suggests a method to implement the
response, but says that the details of the request "would be done on a
bilateral basis");
- the draft does not specify the structure of an unsigned,
shared-secret-based revocation request, while suggesting that there may
be circumstances under which such a request will be a necessity (it says
that the structure of such a request is "a matter of local
implementation");
- the draft actually assigns OIDs to controls (rather than leaving them
currently unassigned) and then notes that the numbers will change.

My feeling is that interoperability considerations will necessitate more
detailed specification than is currently included in the draft.

--------------------
Carlisle Adams
Senior Cryptographer
Entrust Technologies
--------------------

---

From: Juergen Walter <[email-masked]>
Date: Fri, 18 Dec 1998 14:59:27 +0100

> CA.  The CA then issues a certificate with my name and the "borrowed"

[CRMF] defines the following.

"POPOSigningKeyInput ::= SEQUENCE {
    authInfo            CHOICE {
        sender              [0] GeneralName,
        -- used only if an authenticated identity has been 
        -- established for the sender (e.g., a DN from a
        -- previously-issued and currently-valid certificate)
        publicKeyMAC        PKMACValue },
        -- used if no authenticated GeneralName currently exists for
        -- the sender; publicKeyMAC contains a password-based MAC
        -- on the DER-encoded value of publicKey
    publicKey           SubjectPublicKeyInfo }  -- from CertTemplate 
"[CRMF]

Provided that there isn`t any password shared between subscriber and CA,
I miss the identifier (e. g. of the subscriber too. I agree that an
identifier for the subscriber should be present. The POP should include
any identifier for the applicant. But, I dislike the [CRMF] solution. I
would like to share between subscriber`s identifier on the one hand, and
some authentication token (e. g. password-based MAC) on the other hand.

The PKCS#10 request hasn`t any field that may serve a subscriber`s
identifier. Is someone interested in an attribute that contains a
subscriber`s identifier? What`s about an additional attribute that
contains an authentication token for initial registration? I was writing
authentication token, why I would like to break the restriction to this
one. The range of all authentication token should be allowed. 

[snip]

> that the structure of such a request is "a matter of local
[snip]

This is a critical point. Revocation requests must be authenticated. One
way is that there are only signed revocation request are allowed. In
contrast, plain-text password authentication is bad. So, for
interoperability a secure mechanism is needed. 

Juergen Walter