Hi Dave,
Gee, I thought Ned was pretty mild. He didn't cast any aspersions
about parental derivations or culinary preferences. By IETF measures this
didn't even show up as a blip on the screen.
I suppose you're right. Lest my true lineage and diet be exposed, let me
apologize for my sarcasm (last week was particularly taxing).
Separate from the accuracy of MOSS concerns, benefits of S/MIME
functionality, or any of that really practical stuff, I am puzzled by what
appears to have been the general non-involvement of the S/MIME folks in the
multipart/security and/or MOSS discussions and then also holding the s/mime
design discussions in private.
For interoperability systems designs in general, and security work
in particular, the benefits of open design processes are quite
substantial, as Netscape most recently discovered. I would greatly
appreciate your elucidating the process model that was the basis for the
consortium's method of operation.
At the risk of drawing even more colorful criticism I will try to address
your comments by recounting the brief history of the S/MIME effort.
Early this year a number of email vendors approached us independently with
the desire to field interoperable security in their respective products.
There was considerable interest in PEM, PGP, MIME, and MOSS. There were
varied opinions about PEM and PGP. Folks generally agreed that PEM was
sortof older (text-only) technology and PGP looked like viable technology,
but might not scale well to some of the vendors' respective customer bases.
Two things, however, seemed common among these vendors; a desire to do MIME
and frustration with the PEM-MIME integration effort. Frustration was
voiced not only with the amount of time that the effort was taking and
would potentially take to produce standards (remember that this was early
this year, at the height of the PEM-MIME paralysis) but also with the lack
of responsiveness of the authors to the comments and objections raised. I
must subjectively admit that from my personal experience with the PEM-MIME
effort these comments did not fall on deaf ears. I must also admit that I
did not spend a whole lot of time going into detail about each of the
vendors' past involvement in the PEM-MIME effort, but in my opinion,
"general non-involvement of the S/MIME folks in the multipart/security
and/or MOSS discussions" does not seem to be a fair representation.
The S/MIME effort started out with 3 goals in mind; basic security
services, strict interoperability and quick time to market. In order to
achieve the last goal there was consensus to try to draw entirely from
existing (well-established) mechanisms and not invent anything new. Hence
the desire to work with PKCS #7 and existing MIME parts. By the time the
first meeting took place (April 17) there were about a dozen vendors
involved in the integration of PKCS #7 and MIME and plenty of (sometimes
spirited) discussion that led to the current arhictecture. The use of
multipart/alternative versus multipart/signature was, in fact, one of the
more hotly debated topics.
In my opinion, the S/MIME design discussions were no more "private" than
any early architecture discussions involving small groups of highly
motivated individuals/vendors within the IETF or anywhere else. It has
always been our intention to submit this S/MIME specs to the IETF as soon
as there is "rough consensus and working code".
Yet-Another-Steve Dusse