Re: Key selectors (Was: Re: unpublished public keys )

[Ned Freed <[e-mail]>]

> Im sure you have been through this for your own purposes, but
> can you describe in short how PGP interfaced to MIME, please, in the
> "old" way?

Please read the Internet Draft that described it if you want the particulars. I
believe it is still available as draft-borenstein-pgp-mime-00.txt.

> What was considered wrong with it?

> (a) did it facilitate forwarding, with all modes of message security

Yes, as long as you limit yourselves to the normal modes PGP is used in.
There's trouble once you add the ways PEM is used and some people want to use
PGP (e.g. MIC-CLEAR).

> (b) did it support list explosion, with all modes of message security

Yes.

> (c) did PGP change in any way, in integrating with MIME

No. This is the biggest problem with the proposal -- it needed to change.

> (d) can PGP used in this mode to protect (recursively) MIME messages

Yes.

> (e) was it easy to integrate with MIME handlers

Not especially. This is the second biggest problem with the proposal.

> (f) did multiple signature issues arise in practice?

No, but I doubt that anyone tried this or cared about it. This is typically
not what PGP is used for.

> (g) how did the MIME versus non-MIME issue go?

MIME integration is tricky. Non-MIME use is even worse.

> What did the community of MIME/PGP (old) complain about to
> consider change?

I never heard any complaints. The security multipart proposal works better in
practice, that's all, as a cursory examination of the two schemes will show.

I wish to emphasize that the people who developed the PGP integration scheme
are the ones who, once they had fully assessed the security multipart approach,
decided that switching was a good idea.

> Can we learn from this, and justify  the progressive harmonisation
> of MIME/PEM and PEM on this experience?

Yes. See above.

> Perhaps really we can leverage of PGP and harmonize much
> faster than imagined:

I don't see how. The major issues that are killing us here have little if
anything to do with the integration of PEM into MIME per se.

> When we look at the advantages of the MIME multipart constructs versus
> conventional MIME standard, can we *just*, for starters, do what old
> MIME/PGP achieved?

No. This is not a viable approach, as I have explained in previous messages.

> (perhaps this means just supporting encryption (or privacy) services,
> in the meantime, as identified by users as the primary demanded
> feature)

No. These are not the issues that matter.

> And can we do this without jettisoning any core PEM services? including
> the various forms of key distribution, or secured mail exploding, or
> the privacy service of RFC 1422?

You have yet to demonstrate that ANY of the core PEM services are lost with the
MIME-PEM scheme.

The security multipart scheme has nothing to do with what security services you
provide in any case. It would have been possible to take the core PEM services
and bundle them up inside of the security multipart approach with NO changes
and NO additions. (Actually there would have been one change, in that there
would have been no way to require that encrypted material also be signed, but
then again the "requirement" for this in PEM is purely a formal one, and it
would have been possible to attach a similar formal requirement to a service
based on security multiparts.) However, it is the MIME-PEM designer's position
that fixing this aspect of PEM is nowhere near sufficient to turn PEM into a
viable service.

> Or, are the multi-part constructs responsible for the need to jettison
> core PEM services?

This is nonsensical since there is no need or any attempt to jettison any
services in the MIME PEM.

> Or were these jettisoned for reasons of the designers' judgement as to
> what the users want, or communities to be served, only? (there are some
> tricky ego issues, here, to hopefully avoid.)

Again, since no services were lost, this is nonsensical.

> If MIME/PGP within the multipart constructs is to be a reality, and we
> are all actively expecting a world of multiple signature protocols
> ANYWAY, then surely we have a perfectly usable and harmonious way of
> addressing PGP in the Interent, anyway!! And we can avoid changing PEM
> so fundamentally. (That PGP's concept of trust may be accomdated in a
> future version of PEM's privacy service, would be a further bonus)

Not at all. It is my assessment that we need a service that can start small and
grow. PEM started large and was a nonstarter as a result. PGP in turn has
problems with certain kinds of growth that PEM does not.

Fail to fix PEM so it can be used this way and we'll be forced to start with
PGP and add the necessary scaling infrastructure to it instead. Once this
happens (and I predict that it will happen fairly quickly) PEM will be dead as
a dodo.

> Ive said before that I believe that most of the TIS publicised
> underlying justification of MIME/PEM design was founded upon reaction
> to implementation and piloting issues of TIS/PEM and some design issues
> concerned with their research product, combined with raw fear of PGP's
> growth and success.

I disagree. While it is undeniably true that there were substantial problems
with the TIS/PEM code (many of which have been fixed as a result of changes
that have nothing whatsoever to do with the move to MIME/PEM), the real problem
was PEM itself. I speak here as someone who ported TIS/PEM to a non-UNIX
environment and actually got it running, but found myself stymied by the
problems MIME/PEM specifically addresses.

As for there being some fear of PGP here, I certainly would not characterize it
that way. What there was was an assessment of why PGP succeeded and why PEM did
not. That information was in turn used to improve the design of PEM in several
ways.

> I find with your reasoning a far more tenable line as its based on
> choices of a clear and articulate expert who doesnt emit iconoclastic
> statements, and doesnt based reasoning wholly on one set of evidence.
> If you can help bring us all up to speed on the design issues
> concerning an integration of secured messages with MIME, I certainly
> believe that a fast and progressive integration of MIME/PEM and PEM
> will happen, to everyone's benefit.

The design issues in the security multipart area have already been discussed
in detail on this list and elsewhere. And I really don't see how these
design decisions are relevant in the context of the substantive remaining
issues with MIME/PEM. I see these as centered entirely on the additions to
security services PEM provides (note that I didn't say deletions or
changes), whereas the specific encapsulation that's used is no longer
the focus of ongoing discussion.

> Im convinced that the last 3 weeks of dicussion have identified all big
> issues which can direct the integration emphasis of MIME/PEM and PEM.

Frankly, I see the only substantive issue anyone has raised in the past three
weeks as being the business about key selectors. The rest has really been
nothing but a rehash of choices made many months ago.

> Is there a will to merge and compromise, by adjusting things around a
> bit? Or do you believe it has to be the goals of MIME/PEM, or
> MIME/PEM?

Compromise is good, and in fact compromise is exactly what the additions to the
security services PEM provides are all about. I believe that the designers of
MIME/PEM see it very much as a compromise proposal already.

The problem here is that there seems to be no willingness to compromise on YOUR
side. For you it seems to be certificate hierarchies, IPRAs, PCAs, and such, or
nothing. You are unwilling to entertain any notion that other public key
distribution and trust models have any business being in PEM. "If they want
that let them use PGP" seems to be the thrust of your argument here.

I think this is going to kill PEM. I really do. Dave Crocker's explanation of
this was an excellent one and I don't propose to repeat it except to note that
I am in complete agreement with it.

The other problem with compromise is that it takes time. Time is something we
no longer have. Had this discussion occurred two years ago, when it should have
happened, there would have been a lot more willingness to flex in various ways.
For example, we could have defined two separate types of service, one using
classic PEM and the other using a "PEM like PGP" approach. We could have played
around with key selectors in all sorts of ways. Or whatever.

But those are the flowers of the past. We are holding the nettles of the
present. And I, for one, have products to ship and schedules to meet. I need to
have a viable security scheme to put into my product soon. Classic PEM was not
viable -- I've been down that road already -- I need something that can start
small and grow. And once I have something that meets these criteria that isn't
PEM I see no reason to add PEM later.

As such, I've set my own deadline here. As of January 1, 1995 I'm going to sit
down and assess where PEM is going. If I think the MIME/PEM proposal is going
to go places I'll stick with it. It if looks like more of the same I'm going to
have to find some other technology with more promise. And it looks to me like
that will end up being PGP -- I don't know of any other contenders, really.

I don't mean this as a threat or ultimatum of any sort. My involvement here has
largely been on the side of the security multipart scheme anyway, and that's
needed for PGP as well as PEM, so my real involvement in the WG won't change.
What will change is the liklihood of implementation of any sort of PEM in my
products. There will also be a new MIME/PGP proposal on the table ASAP, even if
I have to write the damn thing myself. (I won't -- there are several other
people who are ready and willing to help.)

> If people believe that the intention is to merge the goals of PEM with
> the innovations of MIME/PEM, than I don't believe that there will be
> any lack of concensus to supporting the promotion of MIME multipart ID
> to stds track, in order to get lots of implementation experience going
> with the MIME multipart constructs. (Its happening anyway!)

But this is exactly what the present proposals do already!

> That PGP is merged in there at the MIME level, that multipart
> constructs become commonly used all round for messaging
> signature-protocols, and PEM's quality and mechanisms of privacy are
> available to users who require them, would be a most satisfying,
> doable, outcome.

As I say, if this happens I have no intention of and see no reason to implement
PEM services at all. PEM will simply be dead. PGP will simply grow in whatever
ways are necessary to deal with any scaling problems that arise.

> It would be a strategy to create a common goal of all the active
> parties, here. No?

See above. I think this will kill PEM's chances of having any role at all
in the future.

				Ned