Sorry about taking so long. Here is my first set of comments:
1. "The CMS ..." should be uniformly changed to "CMS ...".
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.
3) Section 2, para 2: Remove "if desired" from the last sentence. That is
what MAY means.
4) Section 2, para 3: "within the authenticated-data content types require"
types should be singular.
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.
6) Section 5, para 8: The MAY should be lower case. This section is
descriptive in nature is not creating requirements on the implementor.
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.
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.
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".
10) Section 5.3, para "sid": What is the third alternative for specifying
the signer's public key?
11) Section 5.3, para "digestAlgorithm" See comment 7 above. Does the
should in the last sentence need to be SHOULD/MUST?
12) Section 5.3, para "signedAttributes": Should be "signedAttrs".
13) Section 5.3, para "signedAttributes": "Each SignedAttribute in the SET
MUST be DER encoded."
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
15) Section 5.3, para "unsignedAttributes": should be "unsignedAttrs".
16) Section 5.3, para "attrValues": Append the following sentence.
"attrType may impose additional restrictions on the number of items in the
17) Section 5.6, para 1: Change "MAY" to "may".
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.
19) Section 6.1, para "originatorInfo": Change MAY to may in last sentence.
No requirement is stated here.
20) Section 6.1, para "certs": ditto above for some. What is the "optional"
feature being discussed on the MAY.
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?
22) Section 6.1, para "encryptedContentInfo": Remove the [*** NEW ***]
text. The field is not optional.
23) Section 6.1, para "contentEncryptionAlgorithm": Please explain the
MUST. How could you NOT use the same algorithm for each recipient?
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"
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
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
c) do we need to support both for specifying the certificate or just for
locating a certificate? (i.e. encode vs decode)
26) Section 6.2.2, para 1: "...one or more recipients that use..."
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.)
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.
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
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
31) Section 10.1.5: Should we change HMAC to HMAC-SHA1 as HMAC by itself is
not a MAC algorithm?
32) Section 10.2.1: Change MAY to may - not protocol requirement here.
33) Section 10.2.2: Why define another tag for v2 attribute certificates.
We have never bothered with this for v1/v2/v3 certificates.
34) Section 10.2.3: make MAY may, no protocol requirement imposed by CMS.
35) Section 11: Update RFC 2459 text reference to "Son of 2459".
36) Section 11.1: Content-type MUST be omitted when building counter
37) Section 11.1: There MUST be exactly one instance of AttributeValue
present. -- MUST NOT is not testable.
38) Section 11.2: See comment 37.
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.
40) Section 11.3: See comment 37.
41) Section 11.4: should be "MUST NOT" not "MUST not" in the description of
42) Section 11.4: See 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
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.
1) should countersign say MUST omit content type?