Peter,
We have two camps within pem-dev - those who care about design suitable
for operational non-repudiation services, and those who dont. I think
we already agreed in the last IETF, that they would split their
activities, as they are not reconcilable.
I can't help jumping into this food-fight. Since I haven't seen anything
worthwhile posted to PEM in the last three months or more, we might as well
spend the bandwidth on this! :-)
As one of several beaters of dead horses in this argument, I would still like
to contend that although the differences in the points of view of the two camps
may be irreconcilable, the technical approaches to solving the problems posed
by both camps need not be.
Eschewing labels like the Forces for Good vs. the Evil Empire, what are the
requirements/arguments?
Camp A (academic/anonymous/anarchist/...) assigns relatively little value to
nonrepudiation, and probably would try to disavow it if forced upon them. They
are primarily interested in privacy of communications, particularly at the
personal level, and are not likely to be part of a well-organized hierarchical
civil name structure, especially of there are any organizational downsides to a
C=US,O=XYZ Corp, CN=Joe Cool type of name, e.g., any particular liability that
might be assumed or imputed to such a signature. Their notion of identification
is primarily based on continuity of communication over time -- in many cases
they have never met the people thay would like to communicate with privately,
but they have often enjoyed a dialog with them. In any case, they are not
likely to reveal there real inner thoughts until a LOT of trust has been built
up. Since the hierarchical civil name structure doesn't have anything at all to
do with _trust_, but only identification, they can't go back against a
guarantor in any case. Since it is not at all likely that they would sue
someone in this environment, the fact that they don't have access to a
long-term positive binding between an individual's claimed identity and his
"real" persona (a metaphysical point in any case) does not concern them at all.
PGP or RIPEM with a very pragmatic, heuristic form of key distribution suits
them just fine. Finally, because of some missing components in existing
implementations, namely any commercially available UAs that would support both
PEM and an X.500 DUA, many of these people would like to cram into the
certificate the user's e-mail address, which to them is the "real" name of the
user, and if necessary (or even preferably) forego the use of the civil name
structure entirely.
Camp B (business/bureaucratic/belittled-beltway-bandits/...) is not as
concerned about privacy in the individual sense, as they are interested in
using encryption to protect business secrets. But even more, they are
interested in electronic commerce, EDI, etc., becausee, evil money-grubbers
that they are, they think that they can save a buck here and there, and maybe
even offer a new commercial service that other people could use. Unlike the
"purer" academics, they don't give the horse's patoot about the precious
Internet and all of the standards, RFCs, etc., they just want to see a public
key infrastructure developed that will be suitable for their purposes, whether
the information is carried via Novell, ccMail, SMTP/TCP/IP, X.400/GOSIP, or
even SNA (gasp/chortle).
Because these people are in business, and businesses have certain record
keeping practices, they want to be able to sign documents electronically and be
reasonably sure that their electronic signature will have the same weight as
their written signature. If they use it to buy goods or services worth more
than $500, they don't want to have that transaction thrown out because the
Statute of Frauds says that such contracts must be "in writing" to be
enforceable, and no one is quite sure what that means. (Ask any two lawyers,
and you'll probably get three opinions, a disclaimer, a reversal, and five
caveats.) When they look at an X.509 certificate, they want to be sure that a
person's name, rank, and serial number are included, especially if it involves
someone who has, or is claiming, the right of agency for his employer's
organization. So they don't care at all what someone's e-mail address is,
because it isn't germain to their purposes. Unless or until we get to the point
of having authorization or capability certificates (sometimes called an
attribute certificate), these people also don't have any real basis for trust
in the conventional sense, but they do trust in the law, and if necessary can
sue for redress if someone causes them harm. They would at least like to be
able to threaten suit, even if such an action would cost them more than it
would benefit, just to keep people generally honest. In summary, these people
very much want to see someone's civil name, in particular who they work for and
what authorization they claim to have. Note that the IPRA doesn't help here,
either, except by publishing the Policy statement of the PCA under which the
individual is eventually certified.
The point is, however, that BOTH OF THESE DIFFERENT CAMPS CAN BE
ACCOMMODATED BY THE SAME CERTIFICATE STRUCTURE. If one PCA decides
that they want to _require_ the use of a complete civil name hierarchy and
optionally support the use of an e-mail address in an X.509 certificate, that
can easily be done. At present, it would mean the overspecification of a
Distinguished Name in the X.509 certificate, but as has been pointed out
several times, there is very little direct connection between the DN that is
contained in the X.509 certificate and the DN of the entry that CONTAINS that
certificate. That is a detail of someone's X.500 directory design, and can be
handled easily using aliases. Yes, it would be nice if we could have
non-Distinguished attributes within the certifiate, but it isn't necessary. We
could also adopt the PKCS#6 conventions, which signs those additional
attributes outside of the X.509 certificate proper. That isn't necessary
either, however. All we really need is some certificate generation software
that will support the addition of some attributes outside of the
not-particularly-useful set defined in X.520, and we are off and running. Now
that I have at least two DUAs actually up and running, I have more confidence
that it will be relatively simple for users to add additional attribute types
as required (at least if they are strings, integers, etc. -- simple basic
types). So displaying these new attributes should not be difficult.
I hope that it is obvious that if another PCA wants to _require_ Internet
formatted e-mail addresses (with all of the potential awkwardnesses that Peter
has pointed out), well, that is OK also. The e-mail name would be part of the
DN, and the civil name could either be an over-burdened part of that same DN,
or it could be carried as some form of a non-Distinguished attribute, or left
out entirely. And oh by the way, the same is true if someone wants to use their
DUNS number, or their international telephone number, or a message digest of
their birth certificate. All are presumably globally unique, and therefore
Distinguished (or distinguishable, at least). Whether such naming conventions
are _good_ ones depends on what you are going to use them for.
IMHO, the primary mistake we made in the very beginning of PEM was to use the
mail paradigm at all. If instead of signing and optionally encrypting
_messages_ we had made signing and encryption independent, and if the focus had
been on arbitrary objects, rather than messages per se, we would have been a
lot further ahead. At least we wouldn't be compelled to insert an e-mail
address in a certificate that someone wanted to use to digitally sign a peice
of software, or a routing table for a network, or a property deed, just because
someone else wanted to handle routine e-mail messages with the same mechanism.
(Following this line of thought for a moment -- what we really need is a
strongly typed object that is self describing and has an associated label(s).
The label would include the digital signature as a more general statement of
the _provenance_ of that object, showing where it came from, who authorized its
creation, what the inputs were to the oprocess that created it, etc., etc.
another part of the label would contain both the Mandatory Access Control and
Discretionary Access Control constraints, both enforced though the use of
encryption. Mail messages, MIME, etc., would all be folded into the generic
self-describing object type. If anyone wants to follow up on this subject, I've
got a paper I published about 5 years ago that discussed about half of this
notion. The other half was partly written, but never published.)
Is it too late to hope for a last minute reconciliation between these two point
of view? If it is, I'm going to vote with my checkbook, and if necessary go
with the PKCS standard and ignore the Internet RFCs and the failed PEM effort
as an unfortunate tragedy and a sad lesson well learned. But shame on us all if
it really gets to that point.
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM