Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00

From: "Pawling, John" <[email-masked]>
Date: Wed, 27 Jun 2001 15:49:35 -0400

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 28 Jun 2001 11:09:13 -0400

John:

This one comment was not addressed in my long reply to Jim Schaad's
note.  So, I am handling it separately.

>      instances of the signing-time attribute.

Good catch.  I did some minor edits on your proposed text:

    The SignedAttributes syntax and the AuthAttributes syntax 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.

Russ