ietf-smime
[Top] [All Lists]

Re: Simplifying S/MIME v3

1997-10-14 13:05:28
All,

I am forwarding Peter Williams' response to my earlier message because I
believe that it important for everyone to know of his reasons for requesting
continued support of the SignedAndEnvelopedData content type in the "S/MIME
v3" set of specifications.  Please respect his request that he no longer
wishes to take part directly in the debate of this issue.

Is there anybody else who has an opinion regarding the continued support of
the SignedAndEnvelopedData content type in the "S/MIME v3" set of
specifications??

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


Return-Path: <peter(_at_)verisign(_dot_)com>
Reply-To: "Peter Williams" <peter(_at_)verisign(_dot_)com>
From: "Peter Williams" <peter(_at_)verisign(_dot_)com>
To: "John Pawling" <jsp(_at_)jgvandyke(_dot_)com>
Subject: Re: Simplifying S/MIME v3
Date: Tue, 14 Oct 1997 11:02:14 -0700
X-Msmail-Priority: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3

John,

This is the last mail Im sending on the topic, so as to avoid any argument.
Those who are building UAs or relaying MTAs should really define these
messaging needs, not CA vendors. Its only because the msging semantic
involves advanced legal-signing semantics, guaranteed by the
CA policy, that I even mention it. My aim was to encourage people to look
out
two years towards the needs of real business users for signing and
EDI  message-release semantics, and allow feature options to accomodate
future needs.

I have argued for 24 months that the existing, optionally-deployed
SignedAndEnveloped capability offers an unparalleled semantic. It
ensure that the originator **always** controls **authorized reliance** on
the
signature; this is not true of any other construct, to my knowledge.

The semantic is particularly useful when a signed message
(for an offer "to sell at price p" letter, say) is to be distributed over
public networks, but the offer is only intended to be
applicable to a nominated set of preferred recipients/buyers.

This vital  commercial semantic cannot be protected by any other
S/MIME construct. A recipient of an encrypted mail may at any time forward
an inner bodypart, independent of its outer wrapper. While we
cannot prevent anyone forwarding the eventual payload of
a commercial implemenation's S/MIME message, or attributes of signedData
envelopes, we can prevent these bearing a legally-binding signature
except under legal reliance controls defined by the originator (and enforced
by conforming SignedandEnveloped implementations)  on a per-recipient
basis.

Remember, S/MIME signing is not only about ensuring identification of msg
origin; its also about automating long-standing commercial protocols
involving
authorization and release of  signed payload -- because of the legal act or
consequences which origination inherently represents.

You can summarize this argument on the list if you wish; I no longer
wish to take part directly.

-----Original Message-----
From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: Peter Williams <peter(_at_)verisign(_dot_)com>; 
ietf-smime(_at_)imc(_dot_)org
<ietf-smime(_at_)imc(_dot_)org>
Date: Tuesday, October 14, 1997 6:51 AM
Subject: Re: Simplifying S/MIME v3


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>