All,
I agree with the majority of Jim's comments and Russ' responses. I have a
few comments regarding their statements. My comments are numbered
consistently with Jim's original message.
14) Section 5.3, SignerInfo signature description: Jim stated: "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 with Jim. Recommend the
following replacement:
OLD: [*** NEW ***] This field MUST be present; however, the details of the
signature
depend on the signature algorithm employed.
NEW: [*** NEW ***] The details of the signature depend on the signature
algorithm employed.
21) Section 6.1, EnvelopedData: I agree with Jim's recommendation as
follows: "Should change the ASN to "RecipientInfos ::= SET SIZE (1..MAX) OF
RecipientInfo" to reflect the MUST in the text?"
25) Section 6.2.1, KeyTransRecipientInfo rid description: Jim proposed:
"Alternative: "Implementations MUST support both alternatives for
specifying the recipient's certificate when decoding. Implementations MUST
support one of these alternatives for encoding." Recommend changing second
sentence to: "Implementations MUST support at least one of these
alternatives for encoding.".
27) Section 6.2.2, KeyAgreeRecipientInfo ukm description: Jim stated: "I
believe this is a MUST not a SHOULD statement." Recommend the following
replacement:
OLD: [*** NEW ***] Implementations SHOULD support UKM
processing. Implementations that do not process UKMs MUST
gracefully handle the presence of UKMs.
NEW: [*** NEW ***] Implementations MUST support ASN.1 decoding a
KeyAgreeRecipientInfo SEQUENCE that includes a ukm field.
Implementations that do not fully support the processing of
UKMs MUST gracefully handle the presence of UKMs.
29) Section 6.3 Content-encryption Process, paragraph 2: Jim Proposed: "The
input to the content-encryption process is the "value" of the content being
enveloped. The resulting value of the encryption process is then wrapped in
an OCTET string for transporting." I believe that this paragraph should be
deleted because it is redundant to the first paragraph in section 6.3.
36) Section 11.1 Content Type: Jim proposed: "Content-type MUST be omitted
when building counter signatures." I agree with Jim. Recommend the
following re-wording of his proposal be added as the last sentence of the
1rst paragraph: "The content-type attribute MUST be omitted when used as
part of a countersignature unsigned attribute as defined in section 11.4."
39) Section 11.3 Signing Time: Jim stated and Russ agreed: "I think we
should loosen up the locations allows for signing-time. I would like to see
it allowed as an autenticated attribute."
I don't object to this change. If the change is made, please make the
following replacement:
OLD: The SignedAttributes syntax is defined as a SET OF Attributes. The
SignedAttributes in a signerInfo MUST not include multiple instances
of the signing-time attribute.
NEW: 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 signing-time attribute. Similarly,
the AuthAttributes in an AuthenticatedData MUST NOT include multiple
instances of the signing-time attribute.
43) Section 11.4 Countersignature: Jim stated "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.)" Recommend the following
replacement:
OLD: 1. The signedAttributes field MUST contain a message-digest
attribute if it contains any other attributes, but need not
contain a content-type attribute, as there is no content type for
countersignatures.
NEW: 1. The signedAttributes field MUST contain a message-digest
attribute if it contains any other attributes.
2. The signedAttributes field MUST NOT contain a content-type
attribute, because there is no content type for countersignatures.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================