RE: CMC Comments?

[Brian LaMacchia <bal@xxxxxxxxxxxxx>]

Luke--

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

The basic idea is as follows (perhaps we should add a Conformance section to
the draft to explicitly call this out):

A minimally-compliant CMC server:
a) MUST accept a Full PKI Request message
	i) MUST accept CRMF Request Bodies within a Full PKI Request
	ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request
b) MUST accept a Simple Enrollment Request message
c) MUST be able to return a Full PKI Response.  (A Full PKI Response is
always a valid response, but for interoperability with downlevel clients a
compliant server SHOULD use the Simple Enrollment Response whenever
possible.)

A minimally-complaint CMC client:
a) MAY use either the Simple Enrollment Message or the Full PKI Request.
	i) clients MUST use PKCS#10 with the Simple Enrollment Message
	ii) clients MAY use either PKCS#10 or CRMF with the Full PKI Request
b) MUST understand the Simple Enrollment Response.
c) MUST understand the Full PKI Response.

So, it is possible to run CMC between minimally-compliant clients and
servers using only the Full PKI Request and Full PKI Response messages.  The
additional mandates (server-side support for Simple Enrollment Request and
client-side support for Simple Enrollment Response) are present to maximize
interoperability in situations where only one of the two parties in the
transaction are CMC-compliant and the other party is a "current" (PKCS#10/7
only) client or server.

	For clients
	- MUST be able to produce a simple PKCS#10 request.

As part of the Simple Enrollment Request, yes.  As mentioned above, clients
can use either Simple or Full, and within Full either PKCS#10 or CRMF.

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

This is only true if the client chooses to use the Simple Enrollment Request
message.  If the client chooses to use the Simple Enrollment Request and
there is an error, a CMC-compliant server may either return a Full PKI
Response or simply drop the transaction on the floor.  (This is what happens
today with some current clients and servers; there's no standard for what
happens today in the error case.)

	For servers
	- MUST not implement envelopedData according to PKCS#7 (use CMS
	specification of the same structure instead).

Correct, there's an ambiguity in the PKCS#7 definition.
	
	- MUST be able to return a simple enrollment response (or no
response in the
	case of a failure).

Correct, but the MUST only applies if the client chose to use the Simple
Enrollment Request.  (Section 4.1 needs to be cleaned up a bit to reflect
this; it should read "if the Simple Enrollment Request message is *used*"
not "is *supported*".)

	- MUST be able to process a CRMF message body.

Correct, as part of a Full PKI Request.  Support for PKCS#10 message bodies
is also a MUST in Full.

	- MUST support full enrollment request.

Correct.

	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.

This is one acceptable mode of operation between minimally-compliant clients
and servers.  Of course, you don't get all the benefits of Full if you
choose to run this way.  

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

No, they also need to understand the Full PKI Response message.  A current
client (that only speaks PKCS#10/7) is not CMC-compliant because it does not
support a standard mechanism for returning error information.

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

Obviously, the long-term goal is to use Full PKI Request and Response
messages throughout.  However, CMC also has a goal of supporting
industry-standard PKCS#10/7 as a subset of the protocol, so that current
clients and servers can also participate in the CMC world.

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

Agreed; I will suggest text to the authors for a Conformance section
(following the table at the top of this mail).

	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?

This comment is similar to the one Carlisle raised.  The intent is that
controls should appear in the CMC control section, and not in individual
request bodies.  Putting the controls in CMC allows individual controls to
reference/apply to multiple request bodies.  It also puts all the processing
information up front, which facilitates one-pass processing.

	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 }

(I assume you mean responseInfo, not respInfo...)

I don't see the need to extend the definition of regInfo or responseInfo
into a SEQUENCE of OID/ANY as you suggest.  If client and server choose to
define particular semantics for their specific information, and there's an
OID tagging a structure with those semantics, then that information can be
passed at top-level as just another CMC control attribute.  It is expected
that clients and servers that choose to define additional information
specific to their agreements will pass this information through additional
control attributes; there's no reason to bury it down inside a
regInfo/responseInfo/ExtraInfo structure.

(The regInfo and responseInfo controls themselves were defined for clients
and servers that have agreed on the semantics of that OCTET STRING through
some out-of-band mechanism.  For example, in a Web-based enrollment scenario
the server could construct the regInfo using form field values & script.) 

	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.

In what particular scenarios do you believe a confirmation message is
required?  In particular, could you expand on what it means for a client to
"accept the response?"  I know that CMP uses the client confirmation message
as means of doing after-the-fact POP on an encryption key (the "indirect
method" defined in section 2.3.2): the cert is issued to the encryption key
before POP, the cert is returned to the client encrypted, the client
demonstrates POP by decrypting the encrypted cert, and failure to respond
requires that the CA now revoke the cert it just issued.  CMC takes the
approach that the cert should not be issued in the first place unless CA
policy has been completely satisfied (e.g. POP for encryption keys
demonstrated before the request is granted); this avoids extraneous
revocations.

	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.

There were a few alternative proposals floated in Orlando, but I haven't
seen closure on this issue yet.  Most of the proposals have involved
interpreting the D-H key as a signature key for a discrete log-based
signature algorithm and using that algorithm to sign the request.

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

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

The term "bilateral agreement" is used in two places in the draft:
1) In Section 5.10.2, Key Recovery Request Control Attribute.  Clients and
servers that choose to implement Section 5.10 MUST implement the
subjectPublicKeyInfo method of shroudIdentification.  In addition, clients
and server MAY implement other mechanisms of shrouding, but reaching
agreement on those mechanisms is outside the scope of CMC.  CMC provide a
guaranteed method of interoperability in this control attribute should a
client choose to implement 5.10 in the first place.
2) In Section 5.14, Registration and Response Information Control
Attributes, where (as you point out above) clients and servers that choose
to use these attributes must otherwise agree on the semantics of the OCTET
STRING.

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

I respectfully disagree :-), as there is clearly a need within the community
to standardize current industry practice, as has long been identified within
the PKIX WG.

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

There are only two different request messages: Simple Enrollment Request and
Full PKI Request.  What is the third?

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

Yes, these were an unfortunate by-product of invalid section references when
converting from Word to text format.  They will be fixed in the next draft.

	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.

This has already been pointed out by Carlisle in his previous list comments;
the authors are currently evaluating a number of proposals to nullify
self-inflicted denial-of-service attacks, including this one.

	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?

See my comments above in 4) concerning confirmation messages.  The indirect
POP method *does* require that the CA revoke the certificate in the event
the POP fails.  This is sub-optimal because it means the CA has issued the
certificate, and assumed risk, before receiving the POP.  Then when the POP
fails the CA must revoke what should never have been issued in the first
place.  Better to satisfy the CA's POP policy up front.

	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.

This grammar will be fixed in the next draft.  As for the signature in a
PKCS#10, I'm not sure I understand your point.  PKCS#10 (as available at
ftp://ftp.rsa.com/pub/pkcs/doc/pkcs-10.doc, and as structurally included in
CMC) defines a CertificationRequest as a SEQUENCE of
CertificationRequestInfo, SignatureAlgorithm (an AlgorithmIdentifier) and a
Signature (BIT STRING), equivalent to the X.509 SIGNED macro.  All we need
to do is define the AlgorithmIdentifier and semantics of the Signature BIT
STRING for whatever DH-SIG ends up using.

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

PKIData is the correct identifier; any remaining instances of EnrollmentBody
will become PKIData in the next draft.

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

This grammar will be fixed in the next draft.

	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?

Somehow you need to get a copy of the public component of the signature key
pair in order to verify the signature.  CMS provides two types of hints in
SignerInfo to help you try to find the right key: an Issuer&SerialNumber
pointer and a SubjectKeyIdentifier value (SKI was just added in Orlando).
In S/MIMEv3 use, the I&SN identifies a cert for the corresponding public
key, and typically a copy of that cert will be included in the
CertificateSet.  if you're signing your Full PKI Request with a
previously-certified key that works fine.  However, this approach doesn't
work in CMC if you're signing the Full PKI Request with one of the key for
which you are requesting certification.  That's why draft -02 overloaded
I&SN, putting the bodyPartID in the SN slot and NULL IssuerName.  In the
next draft CMC will take advantage of the SKI form to identify a particular
key contained within the message.

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

"identityProof" is the correct identifier; any remaining instances of
identificationProof will become identityProof in the next draft.

	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.

Will fix in the next draft.

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

What, the text in the ASN.1 comments?  We can clean that text up a bit, but
the real description of pending and the queryPending control attribute is in
Section 5.15.

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

It does require agreement between client and server, though.

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

Will fix in the next draft.

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

Will change "identity field" (only one appearance, in section 5.4) to
reference the identification control attribute in the next draft.

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

Will fix both of these in the next draft.

	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.

OK.

	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.

True, although the POP is out-of-band to the CA.  Will reword in the next
draft.

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

In other words, if I'm going to ask the server to generate a key for me, I
have to tell it some parameters defining the type of key I want generated.
Things like the group I'm operating in, or the key size, etc.

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

Will fix in next draft.

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

I don't understand this; are you asking for the INTEGER to be wrapped within
an OCTET STRING?  Why?  PKIX Part 1 uses INTEGER for the public components
of DSA an DH, and RSAprivate is pulled directly from PKCS#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.

How you get an encryption key you trust for the archival server is outside
the scope of CMC.  There is a control attributes called getCert that was
added to allow a client to request a particular cert by issuer name and
serial number from the server (no text yet documenting it, but completely
straightforward), which could be used to retrieve a cert.  In general,
though, the process of getting public keys for entities with which you wish
to communicate is outside the scope of CMC; I believe the PKIX operational
protocols provide some mechanisms that speak to this point.

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

The comment about LRAs in the preceeding paragraph is really a parenthetical
comment; the involvement of an LRA does not necessarily mean that all is OK
in the event of loss of use of the private.  For example, the LRA itself
might require a signed revocation statement.  This section will be reworded
in the next draft to make this clearer.

	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?

Again, this is a matter of local CA policy.  Some CAs allow you to set a
one-time-use password during the cert request process.

	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?

I believe the reason for the mandate was that a CMCStatus needed to be
returned.  Since no certificate is being issued a Simple Response is not
appropriate, and you need to get some information back from the server
stating that the revocation request either succeeded or failed.

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

These are areas properly part of CA policy and CMC, like PKIX Part 1, does
not attempt to standardize issues that are part of local CA policy.

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

This just refers to the regInfo control attributes.

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

But those certificates need not necessarily come from the same CA as you're
trying to contact.  That is, I may have secure machine-to-machine
communication built on top of IPSec certs coming from one CA hierarchy, and
I can use that connection to request certificates for individuals in another
hierarchy.  More generally, the trust policy used in the transport layer may
be orthogonal to that respected by the requesting and certifying
applications.

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

Yes, there should be a sentence added here pointing to the Security
Considerations section of draft-ietf-smime-x942-??.txt, which discusses the
small subgroup attack on static D-H keys.

	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.

Correct; you have to have a signing key to authentiate your request to the
CA.  With the change made in CMS's SignerInfo (including SKI), there's now
no requirement that the signing key be certified by anyone (you can produce
the SignerInfo without having any certs on the signing key pair).  I believe
it would be technically possible to enroll for only an encryption
certificate using just the out-of-band shared secret mechanisms, but I don't
see this as particularly useful.  (You'd define a null signature algorithm
OID (e.g. an signature algorithm that meant "this is unsigned") and mandate
use of the proper control attributes with it.)  If the list feels this
option should be explicitly permitted within CMC it's easy enough to add.  

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

What do you mean by "securely send the CA root key"?  Please expand on this
remark.

Hope this answers your questions,

					--Brian LaMacchia
					  bal@microsoft.com