The issue of "extended" certifications like you mention is strictly
controlled in RIPEM via the "chain length allowed" value. When I make
a certificate for you, the chain length allowed defaults to zero
meaning that RIPEM will not accept certificates you make for others.
I must explicitly set chain length allowed to 1 or more according to
how deep I will accept chains "off of" the certificate I made for you.
(This is how RIPEM hooks into the Commercial Certification hierarchy.
I make a certificate with me as the issuer and the Comm CA as the
subject and then set its chain length allowed to 2.) The chain length
allowed information is of course authenticated with the user's
password to prevent tampering.
That seems like a very reasonable and flexible approach.
I don't know whether RIPEM currently includes PGP compatibility as a mode,
but
would you see any substantial problems with such an approach?
PGP uses different encoding mechanisms for public keys, names and
certificates. Also, as far as I understand, PGP's certification
mechanisms are pretty wild and crazy (more than RIPEM, that is :-) ).
For example, someone can be partially trusted by several certifiers
and these trusts must "add up" somehow for you to trust that person.
Also, I don't know whether PGP performs canonicalization of text and
other RFC 1421-required operations that RIPEM follows.
In other words, they use different certification code, text processing
code, key and certificate representation code, etc. One would have
to parallel all the RIPEM code with PGP code anyway, so I don't know
why you wouldn't just use PGP if you want PGP. I appreciate that you
are trying to build bridges to bring people in, so let me ask, what
advantage would you see with putting PGP compatibility in RIPEM? It
is already the case that PGP compatibility at this level is not
planned for PEM, which RIPEM follows. I expect the PGP community to
propose their own MIME formats - that's why the PGP identifier was
removed from this draft of MIME/PEM.
I wasn't suggesting that you implement PGP compatibility. I was just thinking
aloud, and wondering whether such an approach would be feasible, and/or whether
you were considering some kind of compatibility feature.
My crystal ball fell on the floor and broke a while ago, so I don't know
whether PEM, RIPEM, PEM/MIME, PGP, or encrypted mental telephathy will
eventually become the dominant means of providing privacy and/or integrity for
data communications. I hate to see the user community divided and unable to
communicate and interoperate, but even more I hate to see the scarce resources
that are available stretched to support two or more different public-key
infrastructures.
I'm concerned that if the PGP community goes off and implements a PGP/MIME, not
only will they not be able to interoperate with PEM or PEM/MIME, they might not
even be able to interoperate at the MIME level, and so my MIME-reader might not
be able to read their equivalent of MIC-CLEAR.
It certainly isn't clear to me what kind of a strategy to follow or suggest at
this point, even if we were all of one mind:
1. Ignore them, and hope that they go away.
2. Concentrate on building a better mousetrap, so the PGP users will beat a
path to our door.
3. Co-opt them by including compatibility mechanisms.
4. Co-exist with them as equals, as 45 and 33 rpm records coexisted, or as
Beta and VHS coexisted, until one standard achieves market dominance.
Let me ask you a more provocative question. The "conventional wisdom" seems to
be that PEM has failed, and in fact failed miserably. Yet it seems that perhaps
RIPEM has succeeded, if not brilliantly, then at least moderately. Is that your
view, and if so, do you have any explanation?
What in your judgment are the most significant differences between PEM and
RIPEM -- more features, fewer features, slicker implementation, better
marketing, lower price??
Perhaps more importantly, what areas, if any, of the PEM spec does RIPEM _not_
implement?
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM