Jim:
Thanks for spending so much time with the document. You have performed a
real service here. I think that the bulk of your comments are handled
here. There are a few that need further dialogue.
1. "The CMS ..." should be uniformly changed to "CMS ...".
I think that "The Cryptographic Message Syntax (CMS) ..." is correct. Are
there places that I omitted "the"?
2. I have a sever problem with the following text "However, implementations
of the CMS MUST support the mandatory to implement algorithms specified in
[CMSALG], or its successor." It is my believe that this statement should be
removed for the following reasons:
a) This violates the letter and spirit of the IETF process rules for
pushing documents to standards. In my opinion if this becomes a standard
then CMSALG must also be a standard. Also if CMSALG is reset to draft, so
must this draft. The words "MUST support" is extremely normative.
b) If I create a toolkit or other system and publish that I am STD [CMS]
conformant. It does not make sense that by updating the set of required
algorithms I loose conformance to that standard. I was compliant, I loose
compliance through no action of mine. This argues that a new standard
number should be applied.
c) The reasoning behind not having a MUST for certificates is even more
strongly appliciable here. While certificates and heirarchies can move
between different applications (thus making the arugment that application
spaces should mandate algorithms a somewhat odd argument), that is not the
case with CMS objects. If S/MIME and CMS/SET were to specificy that
different content encryption algorithms be required, there is no
interactions between the spaces. An S/MIME message would never be consumed
(successfully) by a CMS/SET application nor would one expect it to be used.
From this standpoint I think that not requiring a MUST on algorithms from
CMS makes sense.
I have asked Jeff and Marcus for guidance. So far, I have not received input.
3) Section 2, para 2: Remove "if desired" from the last sentence. That is
what MAY means.
Done.
4) Section 2, para 3: "within the authenticated-data content types require"
types should be singular.
Done.
5) Section 2, para 3: Revert to original language on DER encoding of signed
and authenticated attributes. The correct location for the MUST statement is
in the description of the attribute fields in the appropriate structures.
I thought that the rewording removed the "must." We agree that the MUST
statement belongs in the discussion of signed attributes and authenticated
attributes. How about this:
As a general design philosophy, each content type permits single pass
processing using indefinite-length Basic Encoding Rules (BER)
encoding. Single-pass operation is especially helpful if content is
large, stored on tapes, or is "piped" from another process. Single-
pass operation has one significant drawback: it is difficult to
perform encode operations using the Distinguished Encoding Rules
(DER) [X.509-88] encoding in a single pass since the lengths of the
various components may not be known in advance. However, signed
attributes within the signed-data content type and authenticated
attributes within the authenticated-data content type need to be
transmitted in DER form to ensure that recipients can verify a
content that contains one or more unrecognized attributes. Signed
attributes and authenticated attributes are the only CMS data types
that require DER encoding.
6) Section 5, para 8: The MAY should be lower case. This section is
descriptive in nature is not creating requirements on the implementor.
Agree. How about:
The signer's certificate can be included in the SignedData
certificates field.
7) Section 5.1, digestAlgorithms: One of the following statements should be
added to this paragraph:
a) Each digest algorithm used in a signture computation MUST be included in
this set, although unused algorithms may also be included. OR
b) Complient implementations MUST verify signatures for which the digest
algorithm is not in this set. OR
c) Complient implementations MAY fail signature verification if the digest
algorithm is not included in this set.
How about:
Implementations MAY fail to validate signatures that use a
digest algorithm that is not included in this set.
8) Section 5.1, certificates: The following items are missing from this
paragraph. 1) If version 2 attribute certificates are present the version
MUST be 4. 2) The MAY from section 5, para 8 if it is considered of
importance. I think it can be omitted.
How about:
certificates is a collection of certificates. It is intended that
the set of certificates be sufficient to contain chains from a
recognized "root" or "top-level certification authority" to all of
the signers in the signerInfos field. There may be more
certificates than necessary, and there may be certificates
sufficient to contain chains from two or more independent top-
level certification authorities. There may also be fewer
certificates than necessary, if it is expected that recipients
have an alternate means of obtaining necessary certificates (e.g.,
from a previous set of certificates). The signer's certificate
MAY be included. As discussed above, if version 2 attribute
certificates are present, then the value of version MUST be 4.
While the use of version 1 attribute certificates is discouraged,
if version 1 attribute certificates are present and no version 2
attribute certificates are present, then the value of version MUST
be 3.
9) Section 5.2, para 7: Change "the content type within ... should be
id-data" to "MUST be id-data" and "content field ... MUST be omitted".
Agree. Done. I changed "should" to "MUST" in two places.
10) Section 5.3, para "sid": What is the third alternative for specifying
the signer's public key?
Ooops. I changed "three" to "two".
11) Section 5.3, para "digestAlgorithm" See comment 7 above. Does the
should in the last sentence need to be SHOULD/MUST?
How about:
digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer. The message digest is
computed on either the content being signed or the content
together with the signed attributes using the process described in
section 5.4. The message digest algorithm SHOULD be among those
listed in the digestAlgorithms field of the associated SignerData.
Implementations MAY fail to validate signatures that use a digest
algorithm that is not included in the SignedData digestAlgorithms
set.
12) Section 5.3, para "signedAttributes": Should be "signedAttrs".
Agree. Done.
13) Section 5.3, para "signedAttributes": "Each SignedAttribute in the SET
MUST be DER encoded."
Agree. Done.
14) Section 5.3, para "signature": I don't understand the MUST in this
paragraph. The field is not optional how can it be omitted? The MUST is
redundant.
I agree that the ASN.1 definition and this must statement are
redundant. They are not contradictory. What do you not understand? What
change are you requesting?
15) Section 5.3, para "unsignedAttributes": should be "unsignedAttrs".
Agree. Done.
16) Section 5.3, para "attrValues": Append the following sentence.
"attrType may impose additional restrictions on the number of items in the
set."
How about:
attrValues is a set of values that comprise the attribute. The
type of each value in the set can be determined uniquely by
attrType. The attrType MAY impose restrictions on the number of
items in the set.
17) Section 5.6, para 1: Change "MAY" to "may".
Agree. Done.
18) Section 6.1, para "version": What is the correct value if v2 attribute
cert and unprotected attributes are present? Maybe should change this to an
if - then - else type of writing.
It is pretty confusing. How about:
[*** NEW ***] version is the syntax version number. The
appropriate value depends on originatorInfo, RecipientInfo, and
unprotectedAttrs. The version MUST be assigned as follows:
IF (originatorInfo is present) OR (unprotectedAttrs is present)
THEN
IF (any version 2 attribute certificates are present)
THEN version is 3
ELSE version is 2
ELSE
IF (any RecipientInfo structures are a version other than 0)
THEN version is 2
ELSE version is 0
19) Section 6.1, para "originatorInfo": Change MAY to may in last sentence.
No requirement is stated here.
Agree. Done.
20) Section 6.1, para "certs": ditto above for some. What is the "optional"
feature being discussed on the MAY.
How about:
certs is a collection of certificates. certs may contain
originator certificates associated with several different key
management algorithms. certs may also contain attribute
certificates associated with the originator. The certificates
contained in certs are intended to be sufficient for all
recipients to build certification paths from a recognized
"root" or "top-level certification authority." However, certs
may contain more certificates than necessary, and there may be
certificates sufficient to make certification paths from two or
more independent top-level certification authorities.
Alternatively, certs may contain fewer certificates than
necessary, if it is expected that recipients have an alternate
means of obtaining necessary certificates (e.g., from a
previous set of certificates).
21) Section 6.1, para "recipientInfos": Should change the ASN to
"RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo" to reflect the MUST
in the text?
We use "SET OF" many places. I do not think we want to add "SIZE (1..MAX)"
to them all. Therefore, I am not sure that there is any real value in
adding it to this one.
22) Section 6.1, para "encryptedContentInfo": Remove the [*** NEW ***]
text. The field is not optional.
Agree. Done.
23) Section 6.1, para "contentEncryptionAlgorithm": Please explain the
MUST. How could you NOT use the same algorithm for each recipient?
Agree. How about:
The same content-encryption algorithm and content-encryption
key are used for all recipients.
24) Section 6.1, para "encryptedContent": Please explain how the MUST in
this paragraph would be tested. I think this is a "must" not "MUST"
Agree. Done.
25) Section 6.2.1, para "rid": Two items
a) do we want to change to text to allow for SKI's to be non-certificate
based.
I see no reason to do this. Is there a constituency that needs it?
b) do we need a stronger definition of what a key transport public key is
if there is a MUST for it being in the certificate. [[[[ Think about this
comment ]]]]]
I did think about your comment, and I do not think so. [[ I am
anticipating an embarrassing reply. ]] This field is within the key
transport recipient information, therefore any recipient public key that is
used with this syntax (and is interoperable) must be a key transport key.
c) do we need to support both for specifying the certificate or just for
locating a certificate? (i.e. encode vs decode)
We need both (for send and receive). I prefer the subject key identifier;
it is smaller. However, S/MIME v2 requires issuer and serial number, which
is bigger than a subject key identifier. If you do not think that the MUST
statement is complete, please propose an alternative.
26) Section 6.2.2, para 1: "...one or more recipients that use..."
Agree. Done.
27) Section 6.2.2, para "ukm": I believe this is a MUST not a SHOULD
statement. I understand that we don't require it for the default algorithm
(ESDH), but it is premitted to occur. If UKM is not supported then all that
could be done would be to ignore the recipient. (Note: there is a MUST use
UKM in rfc2631 for one case.)
UKM is required for Static-Static Diffie-Hellman. I basically agree with
your point, and it is not a big burden on an implementation. However, I
would like to hear from more implementors before I make a change here.
28) Section 6.3. Lets seperate the discussion on how to pad from the
content encryption process. I believe this should be moved to the algorithm
section or a seperate section in this document. The CEK algorithm is what
determines the padding method not CMS.
Not true. CMS encryption always uses this padding. CMS also supports
algorithms that do not require any padding (for example, a stream cipher),
but if padding is needed, this is the padding technique that MUST be used.
29) Section 6.3, para 2: I don't like the section sentence in this
paragraph. The content begin encrypted has little or nothing to do with the
value of the encrypted data octet string. This is the post encryption
value.
I understand your point. These words have not changed in a very long
time. Perhaps you would like to propose some better ones.
30) Section 9.1: Do we want to change the name of
unauthencticatedAttributes to unauthencticatedAttrs to be consistant with
the naming in signed and encrypted data? (ditto with
autenticatedAttributes.)
Good idea. Done.
31) Section 10.1.5: Should we change HMAC to HMAC-SHA1 as HMAC by itself is
not a MAC algorithm?
Okay. Done. I called it "HMAC-SHA-1."
32) Section 10.2.1: Change MAY to may - not protocol requirement here.
Agree. Done.
33) Section 10.2.2: Why define another tag for v2 attribute certificates.
We have never bothered with this for v1/v2/v3 certificates.
Long story. The short version is that v2 ACs are not backward compatible
with v1 ACs. If you really want to hear the nasty, dirty details, I
suggest you talk to Hoyt or Sharron. This little jewel is the reason that
the PKIX AC Profile requires the use of v2 ACs.
34) Section 10.2.3: make MAY may, no protocol requirement imposed by CMS.
Agree. I changed "MAY" to "may" in three places.
35) Section 11: Update RFC 2459 text reference to "Son of 2459".
Agree. This is a place holder. I think I will know when son-of-RFC2459
finally makes it through the PKIX WG, IESG, and RFC Editor....
36) Section 11.1: Content-type MUST be omitted when building counter
signatures.
Elsewhere the document says: "The content-type attribute is not required
when used as part of a countersignature unsigned attribute as defined in
section 11.4." This does not say MUST NOT to me. It says MAY. Eh?
37) Section 11.1: There MUST be exactly one instance of AttributeValue
present. -- MUST NOT is not testable.
It says: "A content-type attribute MUST have a single attribute value, even
though the syntax is defined as a SET OF AttributeValue. There MUST NOT be
zero or multiple instances of AttributeValue present."
So, you agree with the first sentence. I think the second sentence is a
restatement of the first. Does the second sentence help anyone understand?
38) Section 11.2: See comment 37.
See response to comment 37. (I could not resist...)
39) Section 11.3: I think we should loosen up the locations allows for
signing-time. I would like to see it allowed as an autenticated attribute.
Okay. Done.
40) Section 11.3: See comment 37.
See response to comment 37.
41) Section 11.4: should be "MUST NOT" not "MUST not" in the description of
generalizedTime.
Agree. Done.
42) Section 11.4: See comment 37.
See response to comment 37.
43) Section 11.5: Item 1 in the values. Change to "... but MUST NOT contain
a content-type attribute. (No content type has been defined for a
counter-signature.)"
I assume that this is a comment about section 11.4, there is no section 11.5.
See response to comment 36. It seem to me that you are interpreting "need
not" as "MUST NOT." What have other implementors done?
44) Section 11.5, UnsignedAttribute syntax: I disagree with the MAY here. I
believe this should be lower case. If there is a procotol statement it
needs to be that implementations MUST be able to handle more than one
counter signature attribute.
I assume that this is a comment about section 11.4, there is no section 11.5.
Agree. Done.
OTHER:
1) should countersign say MUST omit content type?
See response to comments 36 and 43.
Russ