-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Pawling,
John
Sent: Thursday, July 05, 2001 9:21 AM
To: 'jimsch(_at_)exmsft(_dot_)com'
Cc: 'SMIME WG (E-mail)'
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
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