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

From: "Jim Schaad" <[email-masked]>
Date: Tue, 3 Jul 2001 14:46:56 -0700

Here are my comments on John.  I have left the number the same as the
orginal message.

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

I very much agree with this.  Having a MUST requirement specified multiple
times is confusing in many ways.

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

As I have said before - and is a new topic - I disagree and feel the entire
paragragh should be deleted.

>
> 5) Section 6.2: I strongly agree that the pwri and ori
> CHOICES should be
> included in RecipientInfo.

I concur with this.

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

I disagree with this.  This is the version struture of the
PasswordRecipientInfo structure and is independent of the EnvelopedData
version number.

I think however that the version number of EnvelopedData needs to be 3 if
either PasswordRecipientInfo or OtherRecipient is present as these are "new"
structure and thus modify the behavior of the processing an EnvelopedData
object.  I don't think that this will necessaryly need to be changed in the
future as we now have an explicit statement that implemenations MUST handle
other choices in the RecipientInfo.  This was not imposed in the past
however.

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

Do we consider a non-match to be a signature failure?  This is not currently
stated anyplace.  I think that we should probably add this.

>
> 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 that the AuthAttributes stateemnt needs to be added.  However, I
think this should be a MUST not a MUST NOT as MUST NOT is not testable.

== jim

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 09 Jul 2001 17:00:00 -0400

Jim & John:

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

I cannot find anything in draft-ietf-smime-password-03 regarding the 
EnvelopedData version value when PasswordRecipientInfo is used.

RFC 2630 says: "If any of the RecipientInfo structures included have a 
version other than 0, then the version shall be 2."  However, this text was 
written before PasswordRecipientInfo was defined with a version of zero.

The proposed algorithm for version in RFC2630bis is:
    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

Based on this discussion, this algorithm is not acceptable.  It needs to be 
modified to set version to 3 if either PasswordRecipientInfo or 
OtherRecipientInfo is present.  Agree?

>stated anyplace.  I think that we should probably add this.

I have added the sentence suggested by John.  What more are you proposing.

>think this should be a MUST not a MUST NOT as MUST NOT is not testable.

Okay.  How about:

    The SignedAttributes syntax and AuthAttributes syntax are each
    defined as a SET OF Attributes.  The SignedAttributes in a signerInfo
    MUST include only one instance of the message-digest attribute.
    Similarly, the AuthAttributes in an AuthenticatedData MUST include
    only one instance of the message-digest attribute.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 9 Jul 2001 16:20:54 -0700

Russ,

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Monday, July 09, 2001 2:00 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
>
>
> Jim & John:
>

I do not think that the EnvelopedData version number field was ever
addressed in the Peter's document.  I agree that the algorithm needs to be
updated.

> I have added the sentence suggested by John.  What more are

I was thinking about putting it into section 5.6 as part of the signature
validation process.

>     only one instance of the message-digest attribute.

looks good

> Russ

jim