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