All,
In my opinion, Russ did an outstanding job of updating this document. I
agree with the vast majority of the proposed changes. I have comments as
follows:
1) Section 5.1, SignedData version description: The existing text is
confusing and could lead to multiple interpretations. Recommend the
following:
[*** NEW ***] version is the syntax version number. The version
MUST be assigned as follows:
IF any v2 attribute certificates are present in certificates
THEN version MUST be 4
ELSE
IF any v1 attribute certificates are present in certificates
OR encapContentInfo eContentType is other than id-data
OR any version 3 SignerInfos are present
THEN version MUST be 3
ELSE version MUST be 1
2) Section 5.1, SignedData certificates description: Please delete: "As
discussed above, if attribute certificates are present, then the value of
version MUST be 3." I don't believe that we need to repeat the version
setting algorithm in this text.
3) Section 6.1, EnvelopedData version description: The existing text is
confusing and could lead to multiple interpretations. I believe that Russ'
recommended solution included in his reply to Jim Schaad's comments is
correct as follows:
"[*** 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"
4) Section 6.2, RecipientInfo description: Please delete "are" from the
following sentence: " [*** NEW ***] All implementations MUST support the
mandatory to implement key management algorithms are specified in [CMSALG],
or its successor."
5) Section 6.2: I strongly agree that the pwri and ori CHOICES should be
included in RecipientInfo.
6) Section 6.2.4, 1rst paragraph: Replace "posses" with "possess".
7) Section 6.2.4, recommend changing PasswordRecipientInfo version value to
1. This would cause the EnvelopedData version number to be set to 2 if the
PasswordRecipientInfo was present. This would assist with debugging and
error reporting.
8) Section 6.2.5, 1rst sentence: Replace with "Recipient information for
additional key management techniques are represented in the type
OtherRecipientInfo."
9) Section 6.4, last sentence: Please change to: "Any of the aforementioned
key management techniques can be used for each recipient of the same
encrypted content."
10) Section 10.2.2. I strongly agree that the v1AttrCert and v2AttrCert
CHOICES should be included in CertificateChoices.
11) Section 11.1 Content Type: Please add as last sentence of first
paragraph: "The content-type attribute value MUST match the encapContentInfo
eContentType value in the signed-data or authenticated-data."
12) Section 11.2 Message Digest: Please replace the last paragraph with the
following:
"The SignedAttributes and AuthAttributes syntaxes are each defined as
a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT
include multiple instances of the message-digest attribute. Similarly,
the AuthAttributes in an AuthenticatedData MUST NOT include multiple
instances of the message-digest attribute."
13) Section 11.3 Signing Time: Please replace MAY with MUST in the following
sentence: "[*** NEW ***] The signing-time attribute MAY be a signed
attribute; it MUST NOT be an unsigned atribute, authenticated attribute,
unauthenticated attribute, or unprotected attribute."
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================