RE: CMC Comments?

[Luke Koops <luke.koops@xxxxxxxxxxx>]

Hello,

I have been reviewing the CMC document from a developers point of view.  As
such, my main concern is with interoperability.  I am not looking for
missing functionality, I assume the authors know what they need from this
standard.  I am not looking for security problems, I defer to more
experienced readers.

I have a few main issues which I will list first.  I have collected a number
of other problems with the document which are appended to the end of my
message.

1)

It is not clear what a minimally compliant implementation MUST support.  It
seems to be:

For clients
- MUST be able to produce a simple PKCS#10 request.
- MUST be able to accept a PKCS #7 response (using the CMS specification for
envelopedData) or no response in case of an error.

For servers
- MUST not implement envelopedData according to PKCS#7 (use CMS
specification of the same structure instead).
- MUST be able to return a simple enrollment response (or no response in the
case of a failure).
- MUST be able to process a CRMF message body.
- MUST support full enrollment request.

The interaction between a compliant client and server only requires a
PKCS#10 request and an envelopedData response (using definition in CMS
instead of PKCS#7 due to an ambiguity in PKCS#7), or no response in the case
of an error.

In order to be compliant with the protocol, clients just need to continue
operating as they already do.

Is there a need to lower the bar for PKIX compliance to this level?

PKIX-CMC needs to clearly state what MUST be supported by a minimally
compliant implementation of the client and server.

2)

There is duplicate information in CRMF and CMC messages.  CRMF includes the
following:
Registration Token control, Archive Options Control.
These controls are redundant with information in the CMC message.
Respectively:
Identity Proof Control, Key Archival Control.

To further complicate matters, in CRMF, each request has its own set of
controls.  In CMC some controls apply to a specific request (key archival
control) , and some apply to all requests (Identity Proof Control).  This
really complicates handling of the request when similar controls are
included in the CMC message and in one or more of the contained CRMF
messages.  What is the prescribed behaviour?

3)

The regInfo and respInfo controls are 'too open'.  The result is that a CA
or RA might not be able to interoperate with two different clients which use
regInfo differently.  A bit pattern could be a valid message from both types
of clients, but with different semantics.  It might not be possible to
specify a parser which can handle both requests.

It would be much better if regInfo and respInfo were not octet strings, but
were defined in the following manner.

  ExtraInfo ::= SEQUENCE {
    infoType OBJECT IDENTIFIER,
    info ANY DEFINED BY infoType }

4)

The absence of a client confirmation message means that there is no way to
be sure that a client recieved a response, or that a client accepts the
response.

5)

In section 3.3.3 "Production of Diffie-Hellman Public Key Certification
Requests" there is a statment that says:  "Clients and servers producing
self-signed D-H certification requests MUST support ephemeral D-H signature
method."  Since Jim Schaad has retracted the ephemeral scheme from his
draft, how will this be addressed in the PKIX-CMC document.

======================================================================
Other observations (collected from other readers here):

Several references to the term 'Bilateral Agreement'.  This does not promote
interoperability.

p.1, item 1 in Abstract:  "need" should be replaced with "desire".

p.2, section 2:  "The two different request messages" should be replaced
with "The three different request messages".

p.5, section 3.1:  "Error!  Reference source not found." messages need to be
fixed up.  [See also p.6, section 3.3.]

p.7, section 3.3.2 [see also p.6, section 3.3.1]:  MUST include both the
subject name and public key fields, although the subject may be NULL.  There
is an attack here on the initialization mechanism whereby I can copy
somebody else's request and then send in my own request, ending up with
their public key and my identity in a valid verification certificate.  In
other words, the initialization mechanism is not secure.

p.7, section 3.3.2:  "The indirect method of proving POP is not supported in
this protocol."  Why is this?  Isn't 3 messages better than 4 in terms of
network bandwidth?  Isn't it nice not to have to revoke the certificate if
the POP fails?

p.7, section 3.3.3:  "[DH-SIG] provides a way to product necessary
signature."  Change "product" to "produce the".  Also, note that this
mechanism is not strictly conformant with PKCS #10, which is very explicit
about how you sign the request.

p.8, section 3.5.1:  "EnrollmentBody" and "PKIData" appear to be the same
thing.  This terminology should be harmonized to minimize confusion.

p.8, section 3.5.1:  "placed on the signedData object." change to "placed in
the signedData object."

p.9, section 4.2:  it seems to me that digging into the bowels of a message
in order to verify the outer envelope is a violation of the intent of
CMS/PKCS7.  Is there really no way to avoid this layering mismatch?

p.10, section 4.2:  "identificationProof" and "identityProof" appear to be
the same thing.  This terminology should be harmonized to minimize
confusion.

p.11, section 4.5:  the first sentence seems to be incomplete.  Perhaps
"from being accessible to unintended entities" (or similar) should be
inserted just before the period.

p.13, section 5.2:  are there words missing in the text under the CMCStatus
"pending"?

p.14, section 5.4:  "a bilateral method of similar strength available".
Should replace "a bilateral" with "an alternative".

p.14, section 5.4:  replace "attribution" with "attribute".

p.15, section 5.4:  "identity field" and "identification control" appear to
be the same thing.  This terminology should be harmonized to minimize
confusion.

p.16, section 5.6, list item 1: "would be rejected with and error" change to
"would be rejected with an error".

p.18, list item 2b:  "The content begin the value y" should be "The content
being the value y".

p.18, second-last sentence:  "The value of y is used as the secret value in
the HMAC algorithm."  Add "and the request referenced in (4a) is used as the
data" just before the period.

p.19, section 5.9:  "If an out-of-band POP is required..."  This mechanism
is not necessarily restricted to out-of-band.  The EE and the RA can go
through the normal in-band POP process and then the RA can simply forward
the original request along with this witness control.

p.20, section 5.10:  "A control statement containing the required fields for
key generation..."  What is meant by this?

p.20, section 5.10.2:  "selectionCriterial OCTET STRING OPTIONAL" should be
"selectionCriteria OCTET STRING OPTIONAL".

p.22, section 5.10.4.1:  "DH-PrivateKey ::= INTEGER" should be
"DH-PrivateKey ::= INTEGER, re-encoded as an OCTET STRING" (written in valid
ASN.1).

p.22, section 5.10.4.2:  "RSAPrivateKey" should be "RSAPrivateKey,
re-encoded as an OCTET STRING" (written in valid ASN.1).

p.22, section 5.10.6:  "1. Client retrieves an encryption certificate for
the archiving server, so that key material to be archived may be encrypted
to it."  I cannot figure out what this sentence is supposed to mean.  I
cannot find support within the protocol for retrieval of an encryption
certificate.

p.26, section 5.13:  "in the instance when an end-entity has lost use..."
should be "in the instance when an LRA is not involved in the request and
when an end-entity has lost use...".

p.26, section 5.13:  "The RevRequest provides for the optional transmission
from the end-entity to the CA of a shared secret that may be used as an
alternative authenticator."  How is this shared secret established?

p.26, section 5.13:  "A full response message MUST be returned for a
revocation request."  Why?

p.26, section 5.13:  What does the full response to a revocation request
contain?

p.26, sections 5.13 and 5.14:  "a matter of local implementation",
"bilateral agreement".  Where is the interoperability?

p.26, section 5.14:  "registration".  Hasn't this been called "enrollment"
everywhere else in this document?

p.30, section 9:  IPSEC and TLS are not out-of-band and are not used as
trust initiation mechanisms (you need a certificate in order to use them).

p.31, section 9:  "Small Group Attack".  Is there an intent to add text
here?

Finally, two other shortcomings:

   - you can't make a request for an encryption certificate only (unless you
already have a verification certificate) because you need to create a
SignedData.

   - it is not possible to securely send the CA root key in the response
message.  This might be a serious limitation in some environments.

-----

I apologize if there is some overlap between these observations and those of
other readers.

Happy Holidays.


-Luke Koops
Software Developer
Entrust Technologies
Ottawa, Canada

luke.koops@entrust.com