Subject: Comments to draft-ietf-smime-rfc2630bis-01

From: "Pawling, John" <[email-masked]>
Date: Wed, 27 Jun 2001 11:44:54 -0400

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

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 28 Jun 2001 16:15:02 -0400

John:

Thanks for you careful review.  I respond to each of your comments
below.  I think that all but one are resolved.

>            OR any version 3 SignerInfos are present

I agree that a bit of pseudocode is useful here.  Yet, I want the
formatting of the pseudocode to be the same as was done for the
enveloped-data version.

How about:

       [*** NEW ***] version is the syntax version number.  The
       appropriate value depends on certificates, eContentType, and
       SignerInfo.  The version MUST be assigned as follows:

          IF (certificates is present) AND
             (any version 2 attribute certificates are present)
          THEN version MUST be 4
          ELSE
             IF ((certificates is present) AND
                 (any version 1 attribute certificates are present)) OR
                (encapContentInfo eContentType is other than id-data) OR
                (any SignerInfo structures are version 3)
             THEN version MUST be 3
             ELSE version MUST be 1

>setting algorithm in this text.

Good point.  The paragraph now reads:

       certificates is a collection of certificates.  It is intended that
       the set of certificates be sufficient to contain chains from a
       recognized "root" or "top-level certification authority" to all of
       the signers in the signerInfos field.  There may be more
       certificates than necessary, and there may be certificates
       sufficient to contain chains from two or more independent top-
       level certification authorities.  There may also be fewer
       certificates than necessary, if it is expected that recipients
       have an alternate means of obtaining necessary certificates (e.g.,
       from a previous set of certificates).  The signer's certificate
       MAY be included.  The use of version 1 attribute certificates is
       discouraged.

>              IF (any RecipientInfo structures are a version other than 0)

I have already put this in the yet-to-be-published -02 draft that I am
working on.

>mandatory to implement key management algorithms are specified in [CMSALG],

Done.

>included in RecipientInfo.

I have put them into the yet-to-be-published -02 draft that I am working on.

>6) Section 6.2.4, 1rst paragraph: Replace "posses" with "possess".

Done.

>PasswordRecipientInfo was present.  This would assist with debugging and

Please raise this on a separate thread.  This is a comment on
draft-ietf-smime-password, not CMS.  Right now, draft-ietf-smime-password
says to use version 0.

We can change the version setting algorithm....

>additional key management techniques are represented in the type

Done.

>key management techniques can be used for each recipient of the same

Done.

>CHOICES should be included in CertificateChoices.

Okay.  No change is needed.

>eContentType value in the signed-data or authenticated-data."

Done.

>    instances of the message-digest attribute."

I agree, but I prefer a minor rewording to be parallel with the wording
that I proposed in the response to Jim Schaad's comments.  How about:

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

>unauthenticated attribute, or unprotected attribute."

Done.

Russ