Steve Dusse writes:
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)
I sympathize greatly with these sentiments. The development of security
multiparts took at least two years longer than it should have, while the
development of MOSS took at least a year longer than it should have. There are
various reasons for this, but my lack of forcefulness at certain points in the
process was clearly a factor.
However, there is nothing I can do about any of this. What certainly could have
been done is for these vendors to join in the effort and push for closure. Had
we had some additional interested parties I'll bet we could have finished up
security multiparts at least year earlier and MOSS at least six months earlier.
but also with the lack
of responsiveness of the authors to the comments and objections raised.
I don't think the facts bear this out. My records show that I personally sent
over 60 messages to the list in response to various comments and suggestions on
both security multiparts and MOSS this year alone. The good folks at TIS posted
comparable numbers as well, if not more. November and December of 1994 also saw
the posting of many messages from both myself and the folks at TIS.
Some people may not have liked what was in those responses, but there is
*absolutely* no basis for a claim of a lack of responsiveness during this
period. I remember lots and lots of days where I spent several hours writing
responses to mail relating to security multiparts and MOSS. Also remember that
for every response you see on the list there's usually one or two done in
private.
As far as not liking what was eventually agreed on, its important to keep
security multiparts and MOSS separate in any critique. We separated the two for
good reason -- we realized that there's no way that a single security service
like MOSS can be all things to all people, whereas there is no reason for a
security encapsulation not to be generally useful. Strong opposition to MOSS in
some quarters is both predictable and acceptable -- we long ago abandoned any
intention of MOSS being the ultimate security service.
But security multiparts are another matter. X.400 gets by with two or three
ASN.1 macros for all of its security encapsulations. Its important that there
not be a proliferation of encapsulations since adding support for proper
interpretation of new encapsulations is a complex, tedious, and pitfall-laden
process. The problems with the design of S/MIME provide ample evidence of
this, I think.
I want to keep this discussion focused on security multiparts in any case.
PKCS#7 versus MOSS is a separate matter, possibly an interesting one, but not
one we've dug into. Security multiparts and the failure to use them in S/MIME
are the central issue for me.
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.
Since I don't know who has been involved in the discussion of S/MIME, its
impossible for me to assess the participation of anyone other than the folks at
RSA. But my records indicate that with the exception of this recent discussion,
persons with RSA addresses have posted nothing on the PEM-DEV list about
security multiparts in either 1994 or 1995. I did receive one private message
from you on 30-DEC-1994 regarding the 7bit encoding mandate in security
multiparts, which I responded to almost immediately, but that's all. I also
recall a discussion with you at an early working group meeting regarding the
need to expose the type of material outside of an encrypted enclosure (I
observe that both security muliparts and S/MIME lack this feature), but this
was years ago. There may also have been some discussion back in 1993 or 1992,
but since both MOSS and security muliparts have changed drastically since then
I don't see it as relevant
If your own level of recent involvement is in any way indicative, I would say
that calling this "general non-involvement" is a charitable representation of
the situation.
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.
Depending on what you mean by "existing MIME parts", you have either failed to
live up to your own rules or else you cannot exclude security multiparts
as a solution to the problem you set out to solve.
Specifically, if "existing MIME parts" means no new subtypes, you have
broken your own rule not once but several times.
If "existing MIME parts" means no new primary types, then security multiparts
are a viable option you should have considered.
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".
Let's look at the facts. The first notice regarding the development of S/MIME
appeared on the PEM-DEV list on 15-May-1995. In this notice you talk about the
development of some sort of security service within MIME. It was pretty vague,
but it sounded to me at the time like some sort of certificate issuer/exchange
mechanism, so I didn't pay close attention to it. Had there been some
indication of the degree of overlap with security multiparts I would have paid
a lot more attention to it.
The first time that S/MIME was mentioned by name on the PEM-DEV list appears to
have been 11-Jul-1995, at which point it appears to have been a done deal.
I regard it as somewhat axiomatic that a notice of any sort of public
discussion of these matters would have been made on the PEM-DEV list simply
as a matter of common courtesy. Yet no such notice was ever published, and
when S/MIME first came to the attention of this group it was presented
as a fait accompli.
Now, as it happens, presentation of a fait accompli to a working group by a
private subgroup is really not a problem in the IETF. Nathaniel and I did this
with MIME, as a matter of fact. It also happened with the SMTP extensions, and
with SNMPv2 as well. The idea is to form a small, tight, design group, do the
basic design, and then turn it over to the IETF, setting up a working group to
take the proposal and turn it into a useful, interoperable specification.
Its the last step that you haven't done, and its the one where your approach
really breaks down. You are generating and releasing actual products already,
without any public discussion of any sort. This is not the IETF way. It is also
far from clear that you're willing to cede change control over S/MIME to the
IETF. When this came up with PKCS matters in the past you not only made it
clear that RSA owns PKCS absolutely, you also made it clear that any discussion
of PKCS on this list was totally inappropriate. (I can send you a copy of your
own message if you like.)
In conclusion, let me be very, very clear about what my goal is here. I want
the encapsulation scheme in S/MIME changed to use security multiparts. I have
no problem at all with the continued use of PKCS #7. You have said that if
there's consensus to do this then it will be done. Consensus where? On the
S/MIME list? The list appears to be completely dead -- I have yet to receive a
single response to anything I have posted there. The only discussion on this
matter has occurred here, on a list associated with a working group that is now
shut down.
I confess to being at a loss at this point as to how to proceed. You're rushing
into implementation and deployment of a service I regard as seriously flawed
and potentially highly dangerous. Your one counterargument has been of the form
"we don't expect many people to do those sorts of things". Even if you're
right, this is no way to handle security concerns!
Ned