On Thursday, October 09, 1997 10:09 AM, Peter Williams
[SMTP:peter(_at_)verisign(_dot_)com] wrote:
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.
I don't disagree with the argument that these constructs serve a purpose
in the universe. The question is, do they serve a purpose in all of the
problem domain that we are working on (that being defined as security
services for MIME entities, regardless of transport), or are they only
useful in a subset of the problem domain (HTTP / SSL-specific
transport). I think the answer is the latter, and so to the extent that
we would like to support these constructs, we should create a separate
draft that explains their use for that particular transport.
You may have a point about signedAndEnvelopedData (forcing the fact that
only a recipient may validate the signature), and I welcome more
discussion about that. My gut feeling is that no one is going to care
about that particular semantic, so it boils down to implementation
complexity vs. utility.
Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060