Steve,
I didn't mean to imply that we had discussed all of these items last week.
Instead, I was recalling an exchange that we had several months ago,
and I thought we were in agreement at that time.
The problem that I was addressing was how to distribute and load into
PEM in a trusted manner the root key of whatever hierarchies you choose
to embrace. I think it is quite clear from the unfortunate problem we
currently have with the Apple AOCE software that hard coding the root key,
ANY root key, into the software would be a mistake. (To the best of my
knowledge the IPRA is not yet operational, so the public key for the
IPRA is not yet available even if someone wanted to hard code it.)
As a result, Jeff Schiller was discussing a mechanism for specifying
the root keys for multiple PCAs. I was suggesting that hard coding
multiple PCAs root keys into PEM was an even worse mistake than
coding only one, because it assumes that all PCAs are equal
regardless of their policies. Instead, I suggested that the user use his
own private key to sign the PEM code itself and the startup script which
specifies the root keys of whichever PCAs are considered acceptable,
and should store the public key necessary to validate his private key on a
secure floppy disk or other mechanism that is not likely to be compromised.
I was also suggesting that there may eventually be PCAs that do not
operate under the aegis of the IPRA ut may even consider themselves toi
be above the IPRA (heretical thought!), and likewise there may be
individual CAs that may be considered trustworthy by the user, but which
are not (yet) connected to a PCA. In particular, if the problems I have
been having with GTE's lawyers regarding the (perceived) risks of using or
releasing digitally signed mail outside of the company are any indication,
many companies may wish to set up CAs for internal use only, and
deliberately eschew being certified by any PCA. I believe that users should
have the ability to indicate that such uncertified CAs are allowable. In
some cases they may be the ONLY acceptable ones.
Finally, I believe that there may be individual users who may find
themselves in a similar position, yet may wish to exchange encrypted
or signed messages without any CA certification.
You may have stretched my argument a little further than I intended
when you started talking about the user being the root of a certification
path or mesh, but I suppose that is one way of viewing it.
You asked, " In a certification mesh of that sort, where does name
subordination kick in? How do you automatically distinguish
between PCAs, CAs and users? " I would suggest that although
there are many valid reasons why we imposed the name subordination
requirements for PEM, there may be certain instances where it may not be
achievable or even desirable, especially for residential users who are
not certified by the local government of the state and locality in which they
reside, but rather by an private organization such as RSA, the Post Office,
the local telephone or public utility company, or a bank or other non-civil
authority. Exceptions may therefore have to be made, and if we have to
make them at all it might be nice to have a general-purpose mechanism.
From your point of view, if the user is the root of the mesh, then he is at
least the equivalent of a PCA. If he is the PCA, then CAs are not required
to follow the name subordination rules. And if a user submits a self-signed
certificate, then he is acting as his own CA and the names would be
subordinate in a certain sense (i.e., equality), and I as the de facto PCA
can then certify that CA as conforming with my own PCA policy! :-)
I don't agree that selecting or rejecting a particular PCA because
of the policies that they do or do not enforce is merely an access
control decision. Instead, I believe that it is fundamental to the whole
issue of trust.
I understand that PEM was developed under the auspices of the Internet
society, and therefore has an "Internet-centric" view of the universe.
But surely it is the user (or the user's management) that has to decide
whether or not to accept or reject the IPRA, any particular PCA, or, by
extension, an CA or individual user.
Although the current implementation of PGP allegedly suffers from some
issues of scalability because they do not as yet support CRLs (and neither
does Apple's AOCE, and the support within other main-steam PEM
implementations is rather marginal at best), that problem could easily
be fixed by using the same mechanisms as PEM uses or will use.
Your view of what PEM is and/or should be seems to be concerned
almost exclusively with the strictly syntactical validation of a chain of
digital signatures, with little or no concern for the semantic issues of
TRUST in the individuals and institutions that lie behind those signatures.
I am much more concerned with knowing whether the PCA is reputable
and will perform due diligence in selecting and certifying CAs, so
as to provide me a reasonable level of assurance that the individuals
which those CAs certify are in fact who they claim to be, at least
from the standpoint of identity.
And once I have identified some individual, before I can trust them
(either to keep a secret, in case I wish to send them an encrypted
message, or to honor their obligations and keep their word, in the event
I receive a message which makes certain representations or undertakes
certain obligations), I have to build up a certain amount of confidence in
that individual.
There are various ways I can increase the level of confidence that I
have in an individual. One is direct knowledge, whether achieved by
day to day acquaintance, by an introduction from a mutually trusted
friend, or perhaps from extended cyberspace interaction (some
people even get married based on such interactions!). Second hand
knowledge may also be somewhat useful -- maybe if I know someone
is a member of the {Knights of Columbus, Elks, IEEE, NRA, Rosacrucians,
take your pick} and I happen to agree with the overall outlook that
is typical of member of that orgaizations, I may be inclined to take
soemone's work on faith.
The second way is perhaps unfortunate in this increasingly litigous
society, but that is to make sure that the individual in question has
sufficient assets and/or reputation, either personal or as a result of a
corporate backer, to be able to make good on his or her committment,
if necessary by seeking a judgment against them.
I'd like to reiterate that I am not talking about the ability to allow or
reject any particular operation or application -- some people seem to think
that I am focused on implementing some sort of automatic EDI type of
system. I'm merely trying to provide the human user with the most reliable
and easy to understand indication of whether a given message meets his
previously established criteria of trust, REGARDLESS OF THE CONTENT
OF THE MESSAGE. Having said that, I also don't see any reason
why a decent PEM implementation could not be used in an automatic
mail responder type of application, with virtually no changes.
Even if I were to agree that we were talking about the use of ACL
mechanisms (really Integrity Control Lists), and I don't, I would still
suggest that discussions of requirements and features of particular
PEM implementations would be very germain to this list.
Finally, I'd like to make a plea. I understand that the IETF and the Privacy
Working Group have only certain limited objectives and charter, and that
trying to solve all of the problems in setting up a global public-key
infrastructure probably exceeds that charter. So be it -- there are other
groups within the Government and within the IEEE, CCITT, ANSI F9X1,
X12 and EDIFACT, the ABA, and probably elsewhere that will try to
contribute to this larger goal. But the PEM group has by far the most
experience, both theoretical and practical, in actually implementing such
a system, warts and all. I would therefore encourage the continued use
of the PEM-DEV mailing list as an appropriate forum for the discussion of
these larger issues, rather than forcing these discussions to a different
venue. I think we would all lose a lot if this list were fragmented or
abandoned.
Bob