All,
I withdraw my proposal to eliminate support for "signedAndEnvelopedData" in
the future S/MIME v3 Message Specification. My proposal was premature since
the first draft S/MIME v3 set of specs have not yet been submitted to the
mail list (or future IETF S/MIME WG). If appropriate, I will re-submit the
proposal after the first draft set of S/MIME v3 specs have been submitted.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
At 08:30 AM 10/15/97, ietf-smime(_at_)imc(_dot_)org wrote:
All,
Based on Russ Housley's message and the minimal value added by
signedAndEnvelopedData, I re-submit my proposal as follows:
When the new S/MIME v3 Message Specification is written, I propose that
Section 2.4 should be replaced by the following: "The PKCS #7 v1.5
specification defines six distinct content types: "data", "signedData",
"envelopedData", "signedAndEnvelopedData", "digestedData", and
"encryptedData". The "signedAndEnvelopedData" content type is not
supported as part of the S/MIME 3 set of specifications. Sending agents
MUST NOT send the "signedAndEnvelopedData" content type, but may they may
send any of the other content types depending on the services that the agent
supports. Receiving agents MUST support the "data", "signedData" and
"envelopedData" content types. Receiving agents are not required to support
the "signedAndEnvelopedData" content type."
Does anybody disagree with this proposal to eliminate support for the
"signedAndEnvelopedData" content type?
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
At 02:24 PM 10/14/97 -0400, Russ Housley wrote:
signedandEnvelopedData has a flaw. An attacker can stip the signature from
the message, then by changing the OID, the recipient will think that the
message we encrypted.
This attack is mitigated by using signedData and envelopedData independently.
Russ