Jim,
Thank you for your responses to my comments. My responses are included in
the message below. I snipped the text that we agree on.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
-----Original Message-----
From: Jim Schaad [mailto:jimsch5(_at_)home(_dot_)com]
Sent: Tuesday, July 03, 2001 5:47 PM
To: 'Pawling, John'; 'SMIME WG (E-mail)'
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Here are my comments on John. I have left the number the same as the
orginal message.
<snip>
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."
[Jim: As I have said before - and is a new topic - I disagree and feel the
entire
paragragh should be deleted.]
[John: The intent of my comment was simply to correct the grammar of the
sentence. I believe that this issue should be discussed in messages sent in
response to Russ' 28 June "Mandatory to Implement Algorithms in CMS" message
that addressed your original comment.]
<snip>
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.
[Jim: 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.]
[John: I agree that the PasswordRecipientInfo version value should not be
changed. I also agree that the Section 6.1, EnvelopedData version-setting
algorithm should be changed as you describe. I propose the following
replacement text (same as proposed in my 7/2 reply to Russ):
[*** 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) AND
(any version 2 attribute certificates are present)) OR
(any RecipientInfo structures are pwri CHOICE) OR
(any RecipientInfo structures are ori CHOICE)
THEN version is 3
ELSE
IF (originatorInfo is present) OR
(unprotectedAttrs is present) OR
(any RecipientInfo structures are a version other than 0)
THEN version is 2
ELSE version is 0]
[Jim: 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.]
[John: I agree that the EnvelopedData version-setting algorithm will not
need to be changed for new syntaxes defined for use within the RecipientInfo
ori CHOICE. The EnvelopedData version-setting algorithm should be changed
if new syntaxes are added directly to the RecipientInfo CHOICE in future
versions of the CMS spec. I believe that the text to which you are
referring was present in rfc2630bis-00, but deleted from rfc2630bis-01.
rfc2630bis-01 states: "all implementations MUST gracefully handle
unimplemented alternatives within the RecipientInfo CHOICE".]
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."
[Jim: 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.]
[John: I agree that a non-match is a critical security error. Propose that
the following sentence be added to Section 5.6 Message Signature
Verification Process as the last paragraph: "If the signedData signerInfo
includes signedAttributes and the content-type attribute value is different
from the signedData encapContentInfo eContentType value, then the CMS
implementation MUST report an error."
Propose that the following sentence be added to Section 9.3 MAC Verification
as the last paragraph: "If the authenticatedData includes
authenticatedAttributes and the content-type attribute value is different
from the authenticatedData encapContentInfo eContentType value, then the CMS
implementation MUST report an error."]
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."
[Jim: I agree that the AuthAttributes statement needs to be added. However,
I
think this should be a MUST not a MUST NOT as MUST NOT is not testable.]
[John: Agree. Propose the following new text: "The SignedAttributes syntax
and AuthAttributes syntax are each defined as a SET OF Attributes. The
SignedAttributes in a signerInfo MUST include a single instance of the
message-digest attribute. Similarly, the AuthAttributes in an
AuthenticatedData MUST include a single instance of the message-digest
attribute."
Also, we should make the following replacement in Section 11.1 Content Type:
OLD: 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 content-type attribute. Similarly,
the AuthAttributes in an AuthenticatedData MUST NOT include multiple
instances of the content-type attribute.
NEW: The SignedAttributes syntax and AuthAttributes syntax are each defined
as a SET OF Attributes. The SignedAttributes in a signerInfo MUST
include a single instance of the content-type attribute. Similarly,
the AuthAttributes in an AuthenticatedData MUST include a single
instance of the content-type attribute.]
== jim