Comments on <draft-ietf-pkix-cmc-02.txt>

[Al Arsenault <aarsenault@xxxxxxxxxx>]

Folks,

	I finally made the time to look at CMC more fully.  I have a number of
comments.  I have divided them up into two categories, "Significant"  and
"Nits".  "Significant" comments are those I think the authors need to
address fully.  "Nits" are those things that should be cleaned up before
this document goes up to the Area Director, but it's not crucial.  (Most of
the "Nits" are grammatical/typographical and may go away in a rewrite of
the section.)

"Significant"

	1 - Terminology - this document refers to a CA as a "Certificate
Authority", and uses the term "Local Registration Agent" or "LRA" to
designate the other key role in a PKI.  I think all of the other PKIX
documents now say that CA expands to "Certification Authority", and the
assistant is the "Registration Authority" or "RA".  Please change terms to
be consistent with the other PKIX documents.

	2 - Central generation of keys - it's not supported.  I'm concerned about
that.  I recognize that some vendors (many, even) prefer local generation
for a variety of reasons, and it's okay to leave that as the default
behavior.  But I think that not even including a mechanism for supporting
central generation of keys is a mistake.

	3 - Specification of which certificate extensions to support:  Sections
3.3.1 and 3.3.2 both state that "Servers are not required to be able to
process every v3 X.509 extension transmitted using this protocol, nor are
they required to be able to process other, private extensions."  Okay,
that's true.  But I think that we can agree it would be sort of "bad form"
for a CMC-compliant server to not recognize the extensions identified in
PKIXCERT as "MUST" support extensions.  Recommend that both of these
sections be rewritten to mandate server support for those extensions
identified in Section 4.2 of PKIXCERT as "MUST", and identify the other
standard extensions and all private extensions as optional (unless their
are any you want to explicitly prohibit.)  This will help address the
problem of interoperability that Carlisle pointed out.

"Nits"

	1 - p. 5, paragraph under "PKIData" definition:  there are two reference
errors that need to be fixed in the explanation of reqSequence.

	2 - p. 6, section 3.3.1, second paragraph, last sentence:  insert "a
request is" between "If" and "rejected".

	3 - p. 7, last paragraph before section 3.3.3, second sentence:  change
"X.590" to "X.509".

	4 - p. 8, section 3.5.2, second line:  insert "information" (or some
similar word) between "sensitive" and "in".

	5 - Section 3.5.2, in general:  use consistency in capitals for
envelopedData.   In this section, there are two instances of
"EnvelopedData" (uppercase E) and three instances of "envelopedData"
(lowercase e).  Unless you really mean different things, make them all be
the same.

	6 - p. 9, Section 4.2, next-to-last paragraph, second sentence:  change
"the a signature" to "the signature"

	7 - p. 10, Section 4.2, item 2:  Insert "For example,"  at the beginning
of the second sentence.  There are other restrictions that CAs and RAs may
impose.

	8 - p. 16, fourth line from the bottom:  Change "it's" to "its".

	9 - p. 27, section 6.1, first line:  Change "end entities" to "end entity's"

	10 - p. 30, next-to-last paragraph, second sentence:  Change the third
occurrence of "archiving entity" in this sentence to "key owner".  It
should read something like, "Once a key is given to an archiving entity,
the archiving entity could use the keys in a way not conducive to the key
owner."


					Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.