[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPsec near term work

Phil,

You wrote:

> >o Licenses for public key technology are obtainable.  RSADSI and PKP
> >  seem to consummate deals quite regularly, and quite a few major
> 
> Yes, but. The problem isn't so much that you have to pay and get a
> license to use public key cryptography, but that PKP puts so many
> conditions on it. Conditions that I feel unreasonably hamper our
> traditional freedom to explore multiple technical approaches in
> parallel, with experience and the marketplace choosing the eventual
> winner.
> 
> Case in point: approaches to public key certification. I personally
> strongly prefer the PGP "mesh" model over PEM's strict hierarchy. It's
> much more elegant and easier to use than the PEM model, which it could
> even handle as a special case. It's also far more practical in a
> decentralized environment like the Internet. I would very much like to
> explore the use of the PGP certification structure as a base for IP
> security.

See below for my view on the mesh model, etc.

> You and others may disagree. Fine; reasonable people often do.

Actually, I agree.

> There's no problem as long as we can all prototype our approaches,
> test them, and let the market decide the winner(s). It's happened many
> times before in the Internet, and it's a proven way to make progress.

I believe it's entirely plausible to prototype any approach you want.
If there's trouble on this point, I would lend a hand to resolve
whatever the trouble might be.

> However, this assumes that we all play on a level field.
> Unfortunately, it's not. PKP blesses only the PEM model, and they
> have consistently refused to grant licenses, at any price, for the
> use of PGP and PGP-derived software, even for personal use.

PGP itself is a very special problem.  I don't believe we'd have any
trouble prototyping, or indeed building, a system that works like PGP.
Attempting to use PGP directly combines a technical approach with some
legal and business issues.  The history here is unfortunate but not
overly important.


With respect to the particular certificate model we have in force for
PEM, I'm afraid the blame for our choice of PEM design, hierarchy,
etc. is squarely on our shoulders.  The original design came from the
PSRG.  It was transitioned over to the PEM WG.  The first PEM WG
meeting under the IETF's auspices took place at the Atlanta IETF
meeting a few years ago.  The certificate hierarchy which had been
designed by the PSRG was the focus of some intense criticism, and the
situation changed rapidly thereafter.  The certificate mechanism we
have now is entirely our own responsibility.

I have come to agree with you completely that the hierarchy we have is
entirely too rigid.  We should have built a more open system and
evolved the more rigid hierarchy over a period of time if it turned
out to be desired by some or all of the community.

The certificate hierarchy is handled in the PEM WG.  The relevant
standard is 1422.  It's in proposed standard status.  Three
possibilities exist.

1. Leave things as is.

2. Enter into the PEM WG and exert pressure according to your views.

3. Petition to organize a certificate or public key management WG
   which serves all applications, including PEM, IPSEC, etc.


If the current design of the hierarchy does not meet our needs, we
should do what the IETF is best at: fix it.

I have spent considerable time and effort working toward opening up
the certificate model.  There are lots of competing forces.  In our
implementation of TIS/PEM, the user is able to designate a set of
certificates which she wants to trust.  A certificate is considered to
be valid if there's a chain leading up to a designated certificate.
If the only designated certificate is the IPRA's, this implements the
official hierarchy.  If all of the certificates are designated, this
implements the simplest form of direct trust.

Our implementation does not match PGP's web of trust completely.  I'm
not sure I understand all of the implications of a web of trust.  But
the general thrust of our work here is to attempt to deal with a
larger range of models for precisely the same reasons you have in
mind.

Steve
Follow-Ups: References: