At 4:02 AM -0700 4/26/96, Steve Crocker wrote:
wasn't much choice. We did consider computing the signature on an abstract
representation of the message instead of the concrete representation -- I'm
using "abastract" and "concrete" in the sense of "abstract syntax" vs in
"concrete syntax" in compiler technology, but it seemed clear that such an
approach would pose far greater difficulties in documentation and
implementation by a wide range of implementers.
While acknowledging the greater difficulty in specification and
implementation, I personally wish that the choice had been to base things
on the abstraction. (Yes, I remember the debate and I'm truly not
criticizing the choosing that was done. As I recall there was broad
pressure to simplify. I just wish things had gone a different direction.)
But in fact this was not the concern I was citing about multipart.
I have not heard general criticism of multipart/signed. (Yes, there's
criticism of everything, everywhere these days but I mean that discussions
about whether to use multipart security have not tended to assert major
problems or showstoppers with multipart/signed.) One of the benefits of
the email security workshop seems to have been an increased appreciation
for the benefits of multipart/signed.
The problem is with multipart/encrypted. And again, the problem
that is the showstopper does not appear to be with the spec. It's
basically fine.
The problem is that it isn't a useful capability unless it can be
meaningfully used to send one message to multiple recipients, with
different security mechanisms, sharing one encrypted content. Without this
benefit, it's just as good to use multipart/alternative and have a set of
wholly independent encryption methods.
That is, we need to be able to generate something like:
multipart/encrypted
application/des3-encrypted
encrypted content
multipart/mixed (alternative?)
application/pgp-encrypted
application/smime-encrypted
application/moss-encrypted
application/msp-encrypted
control information
so that there is one and only one copy of the encrypted data, with
different control sections depending on the certificate scheme being used.
It requires that the different schemes to use exactly the same algorithms
and formats for encrypting the content, however.
This is, in a pure sense, a political issue not a technical one. I
believe that Multipart/encrypted would support the style of use I
described, just fine. More importantly I think that the likely future of
multiple certificate schemes and security "systems" makes this capability
an extremely useful one.
Getting it to be usable was the one major follow-on benefit I hoped
would come out of the Resolving Email Security Workshop. We formed a
follow-on discussion group for the principals of the alternatives, with the
goal of obtaining discussion that would produce detailed delineation of the
technical differences among the schemes and look for areas to make common.
(I.e., areas for which there was no market or technical advantage to keep
different.) Multipart/encrypted was my personal goal. Unfortunately,
almost no activity took place among the discussion list.
The range of options and choice that MOSS provides is usually what
I hear cited as its major problem, not its integration with MIME.
This surprises me. And if it's really an issue, it would seem trivial to
choose a specific profile. I can't speak for the other authors or the rest
I guess the question is whether that would make a difference, at
this stage? Perhaps it would?
Hmm... Perhaps the "choice" you're talking about is that MOSS allows
signatures before or after encryption. I've seen debate on this point, and
I have heard people use this line of criticism. However, anytime
the conversation included a range of people and expertise (e.g., at the
workshop) it is handily shot down. That is, the benefit of supporting such
combinatorials is successfully defended.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr.
dcrocker(_at_)brandenburg(_dot_)com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org,
info(_at_)imc(_dot_)org