ietf-smime
[Top] [All Lists]

Re: Simplifying S/MIME v3

1997-10-14 06:48:11
Peter,

Thank you very much for your responses.  

I agree that digestedData and EncryptedData offer unique services that may
be required by some S/MIME-enabled applications, so they should not be
prohibited by the "S/MIME v3" set of specs.

I respectfully disagree that signedAndEnvelopedData should be supported in
the "S/MIME v3" set of specs.

You made the following point:
signedandEnvelopedData is very useful as it offers a service
not available otherwise - as only the intendedRecipient
is authorised to verify the signatures. The property is a function
of the integrated nature of the signing/encryption. This is a specialised
service.

There are two options provided by PKCS #7 v1.5 for signing and encrypting data:

1) sign the data using signedData and then encrypt the signedData using
EnvelopedData.

2) sign the data and encrypt the data using signedAndEnvelopedData.

In my opinion, signedAndEnvelopedData does not add any value over the
signedData/EnvelopedData option.  In both cases, only the intended
recipients can verify the signature.  In the signedAndEnvelopedData option,
the signature value is encrypted using the MEK, but (IMHO) that feature
doesn't add any value.  The recipient of the signedAndEnvelopedData object
can decrypt the content and signature value and then convert that
information into a signedData object which can then be forwarded to a third
party just as if the signedData were received encapsulated within an
EnvelopedData object.  Therefore, I don't see any benefit provided by the
signedAndEnvelopedData regarding the "integrated nature of the
signing/encryption".


You stated:
The current language is clear; no-one need implement the optional elements,

However, if one vendor chooses to send only signedAndEnvelopedData objects
(as allowed by the current S/MIME spec) and another vendor chooses not to
implement signedAndEnvelopedData at all (as also allowed by the current
S/MIME spec), then there is not going to be interoperability between the two
products.  Both vendors can claim compliance to the spec, but their products
are not interoperable.  In my opinion, that is a condition that is
unacceptable and needs to be rectified in the "S/MIME v3" set of specs.

In summary, I believe that the signedAndEnvelopedData option adds compexity
to the S/MIME v3 environment without adding any value and should be
prohibited in the S/MIME v3 set of specs.

================================
John Pawling   
jsp(_at_)jgvandyke(_dot_)com                             
J.G. Van Dyke & Associates, Inc.           
================================


At 10:08 AM 10/9/97 -0700, Peter Williams wrote:

-----Original Message-----
From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
Date: Thursday, October 09, 1997 5:49 AM
Subject: Simplifying S/MIME v3


All,

The draft charter for the proposed IETF S/MIME Working Group includes plans
for developing a new S/MIME v3 Message Specification as a separate document
from the 23 Sep 1997 Internet Draft S/MIME Message Specification (also
known
as S/MIME v2 Message Specification).  This message includes a proposal for
simplifying the future S/MIME v3 Message Specification.

The 23 Sep 97 S/MIME Message Specification, Section 2.4, General Syntax,
states:  "The PKCS #7 defines six distinct content types: "data",
"signedData", "envelopedData", "signedAndEnvelopedData", "digestedData",
and
"encryptedData". Receiving agents MUST support the "data", "signedData" and
"envelopedData" content types. Sending agents may or may not send out any
of
the content types, depending on the services that the agent supports."

This paragraph implies that an agent SHOULD support receiving the
"digestedData", "encryptedData" and "signedAndEnvelopedData" content types.
If a sending agent were to send one of these content types to a receiving
agent that did not support that type, then that receiving agent would
encounter an error condition.


When the new S/MIME v3 Message Specification is written, we 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".  Sending agents may send the "data", "signedData" and
"envelopedData" content types, depending on the services that the agent
supports.  Receiving agents MUST support the "data", "signedData" and
"envelopedData" content types.  The "digestedData", "encryptedData" and
"signedAndEnvelopedData" content types are not supported as part of the
S/MIME 3 set of specifications.  Sending agents MUST NOT send the
"digestedData", "encryptedData"  or "signedAndEnvelopedData" content types.
Receiving agents are not required to support the "digestedData",
"encryptedData"  or "signedAndEnvelopedData" content types."

Does anybody object to removing support for sending and receiving the
"digestedData", "encryptedData"  or "signedAndEnvelopedData" content types?
Please provide comments.


Yes.

Encrypted Data is a value-add option for S/MIME implementations: having
established pairwise keys, an encrypted msg may simply reuse keying
material without having the overhead of indicating/agreeing/transporting
keys.

signedandEnvelopedData is very useful as it offers a service
not available otherwise - as only the intendedRecipient
is authorised to verify the signatures. The property is a function
of the integrated nature of the signing/encryption. This is a specialised
service.

DigestedData is used heavily in SET to address linking attacks
in multi-phase, multi-party messenging protocols, and shows lots of
potential to be used much as Encrypted Data - where an integrity
key has been previously established, subsequent mails may
be sent using digestedData, rather than signedData.

These functions are not "current" in the sort of emailish privacy-centric
notion of S/MIME that we have around in the market at the current time.
Where
S/MIME is used in http or SSL however, it is more than likely that should a
party
define a custom SSL3 record-layer protocol (as they are entitlted) in which
the current keys of the state/connection are used, then the S/MIME
mechanisms
(including the above) may well be used as the message formats. Why invent a
new
one, one might ask.

The current language is clear; no-one need implement the optional elements,
particulary where there is yet little momentum for more refined
business-like
S/MIME applications dealing with secure relay-centric messenging, versus
merely secure inter-personal mail or end-end EDI. Denying
the use would seem harsh, and prevent S/MIME evolving to
satisfy other uses/enviornments  that personal or EDI mail services.


==============================================================
John Pawling                               (301) 953-3600
J.G. Van Dyke & Associates, Inc.           (410) 880-6095
141 National Business Pkwy, Suite 210      FAX: (301) 953-2901
Annapolis Junction, MD  20701              jsp(_at_)jgvandyke(_dot_)com






<Prev in Thread] Current Thread [Next in Thread>