Russ,
I agree with your counter-proposals.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
-----Original Message-----
From: Housley, Russ [mailto:rhousley(_at_)rsasecurity(_dot_)com]
Sent: Tuesday, July 10, 2001 11:31 AM
To: Pawling, John
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
John:
Regarding Jim's comment 7: In previous messages, I proposed changes to the
Section 6.1, EnvelopedData version-setting algorithm that address your
comments. I repeated the proposal today in my reply to Peter Gutmann's
message sent to the S/MIME mail list.
Regarding Jim's comment 11: In a previous reply to Jim (which he concurred
with), I proposed the following:
[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."
How about an additional paragraph that says: "If the SignedData signerInfo
includes signedAttributes, then the content-type attribute value MUST match
the SignedData encapContentInfo eContentType value."
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."]
To be parrallel, I propose a new paragraph in section 9.3 that says: "If
the AuthenticatedData includes authenticatedAttributes, then the
content-type attribute value MUST match the AuthenticatedData
encapContentInfo eContentType value."
Russ