ietf-smime
[Top] [All Lists]

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

2001-06-28 13:33:34

John:

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

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

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


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.

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.

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"

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

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."

Done.

5) Section 6.2: I strongly agree that the pwri and ori CHOICES should be
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.

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.

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....

8) Section 6.2.5, 1rst sentence: Replace with "Recipient information for
additional key management techniques are represented in the type
OtherRecipientInfo."

Done.

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."

Done.

10) Section 10.2.2. I strongly agree that the v1AttrCert and v2AttrCert
CHOICES should be included in CertificateChoices.

Okay.  No change is needed.

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."

Done.

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."

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.

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."

Done.

Russ

<Prev in Thread] Current Thread [Next in Thread>