RE: CMC Comments?

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

-----Original Message-----
> From: Barb Fox (Exchange) [mailto:bfox@Exchange.Microsoft.com]
> Sent: Wednesday, December 16, 1998 2:17 PM
> To: 'carlisle.adams@entrust.com'
> Cc: ietf-pkix@imc.org
> Subject: CMC Comments? 
> 
> Carlisle:
> 
> Could you please post your Orlando comments to the list? Thanks!
> 
> --Barbara Fox
> bfox@microsoft.com
-----------------------------

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