I have no problems with any of John's comments.
jim
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Pawling,
John
Sent: Wednesday, June 27, 2001 12:50 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
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
===========================================