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


Russ,

-----Original Message-----
From: Housley, Russ [mailto:rhousley(_at_)rsasecurity(_dot_)com]
Sent: Monday, July 09, 2001 2:00 PM
To: jimsch(_at_)exmsft(_dot_)com; 
John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01


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


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?


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.

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.


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


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

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.

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.


looks good


Russ

jim