Re: Last Call: MIME Security with Pretty Good Privacy (PGP) to Proposed Standard

[Ned Freed <[e-mail]>]

>    But to expand slightly since you seem to have missed it, in essence the
>    protocol design significantly depricates the MIME/SIG-ENC foundation
>    in favour of the native PGP data structures which profoundly limits the
>    potential for use within the Internet message realm. This is fixable and
>    should be fixed. I don't believe that fundemental issues of this sort can
>    or should be repaired here inside the last call period.

I disagree 100% with this assessment. The document as issue, 
draft-ietf-elkins-pem-pgp-03.txt, not only doesn't deprecate the MIME/SIG-ENC
function (i.e. security multiparts), it embraces it to the maximum extent
possible with present-day PGP. The draft characterizes the MIME/SIG-ENC
functions as "elegant" and refers to itself as being modelled on the MOSS
specification in its use of them.

More specifically, for signed material, this document adopts RFC1848's approach
of using RFC1847 mechansisms that split the data and signature. This is
actually somewhat difficult for PGP to do but it is done anyway.

As for encrypted material, while it would have been nice for PGP to use the
split approach advocated by RFC1847, doing so means using an operating mode
that PGP simply doesn't support at present, and in order for it to be useful
PGP would also have to adopt a symmetric encryption mechanism that is shared
with other services based on RFC1847. Changing this would necessitate
substantial changes to PGP proper, and such changes are out of scope of the
group that devised this specification, which was specifically tasked with
producing a specification for integrating existing PGP into MIME and nothing
more.

> Has it occurred to you that perhaps this MIME/SIG-ENC foundation might
> be one of the reasons that MOSS has seemed to "have done an effective
> job of killing itself"?

Absolutely not, and there is overwhelming evidence that this is not the case.

Far from being dead, security multiparts seem to be doing just fine. S/MIME has
embraced the use of security multiparts, albeit somewhat late, somewhat
reluctantly, and only after substantial misconceptions about MIME and security
multiparts were cleared up. PGP is also embracing security multiparts in this
specification. MSP is doing so as well, and while I have some grave
reservations about some aspects of the MSP proposal it nevertheless is based on
security multiparts at present.

This means that all of the various security services for email will soon sit on
top of a common foundation -- the same foundation that you claim killed MOSS.
Unless you are prepared to argue that the demise of S/MIME, MSP, and PGP is
imminent you don't appear to have much to back up this assertion.

> In the words of one of MOSS's authors:

> > Even more interesting is that S/MIME was put together after, and in
> > reaction to, MOSS, thus indicating that the basic scheme of the MOSS design
> > didn't satisfy the big players.

> > In a nutshell, MOSS is based on the idea of exploiting MIME pretty
> > thoroughly instead of just grafting cryptographic services into MIME as a
> > fresh application.  This degree of intimacy and interdependence on MIME
> > didn't sell well to the commercial players.

With all due respect to Steve Crocker, what he says here is not strictly
correct. First of all, the S/MIME effort started long before MOSS was
finalized. And it was started for one primary reason -- the IETF effort had
already failed. Yes, closure was finally reached and a specification was
finally produced, but a protocol three years in the making is a failure from a
commercial standpoint even if the IETF finally signs off on it. The frustration
this sort of things causes in the vendor community is immense and it doesn't
fade quickly.

S/MIME clearly began with the goal of getting a viable security service for
Internet mail done and out the door. It naturally drew on existing components
whereever possible -- the PKCS series was already specified so it was used,
MIME was already specified so it was used, and so on. Security multiparts were
looked at askance at first but have now been embraced by S/MIME.

Now, I said that Steve is not strictly correct because at least one aspect of
security multiparts definitely has not been well received: Separation of
encypted content from information about the encryption. There are many reasons
for this rejection. For one thing, most existing security envelopes, including
PGP, PKCS, and MSP, do not make this easy. For another, the separation is only
useful when multiple services are employed on the same content at the same
time, and for this to work there has to be a high degree of coordination
between different security services, something that simply doesn't exist today.

As such, when faced with the need for a major redesign in exchange for
something that is only of benefit when your scheme is used in conjunction with
a competing scheme, most designers opt out of this aspect of security
multiparts.

Is this desireable? Maybe not. If in the very long term we end up with multiple
stable security services that employ common symmetric services and are widely
used by overlapping populations, we will have made a mistake in rejecting a
mechanism that permits data sharing between services. But that's a lot of ifs,
and it isn't like this aspect of the service cannot be revived if there is need
for it. Always remember that encryption necessarily involves knowing something
about the destination, and as such it is much more feasible to phase in new
encryption mechanisms than any other sort of security service.

> So the fact that protocol significantly deprecates the MIME/SIG-ENC
> foundation may be considered a feature, not a bug.

I reject the so-called "fact" here. This protocol embraces security multiparts
rather than deprecating them. And I see embracing security multiparts as a
feature, not a bug as you would have it.

				Ned