Rhys,
I am beginning to be persuaded that name subordination should be a _PCA
policy requirement_ for user certification, and a_ user option_ for
validation.
Maybe we should address this issue head on.
I think so. One thing that has been concerning me a little about the
direct trust models is "where do you stop validating the chain?". e.g. I
may not trust everything signed by RSA's low-assurance CA, but I do trust
everything signed by some PCA. For some reason, this PCA signs RSA's
low-assurance CA key (plausible under the current PEM RFC's), and my PEM
software could be fooled into believing everything signed by RSA's
low-assurance CA. Just how do we indicate that when following the chain
back that validation should stop at a certain key? Is this a local
issue that the user decides, or something that should be spelled out in
the certificate (i.e. "stop here"), or what? Left as an exercise for the
reader, because I'm unsure.
I don't recall whether you were on pem-dev at the time, but Steve Kent
and I went around on the issue for a while, and I, at least, came up
with an implementation model you may wish to consider:
The user obviously trusts his own keys, and should probably keep his
own public key (one used for this purpose only) on a write-protected disk
which also contains the minimal software necessary to validate the
integrity of the PEM software and startup script. This key, under
password control, should validate the list of certificates which
the user considers to be valid. In the Steve Kent, totally top-down
model of the universe, this would be the self-signed certificate
of the IPRA. In the continuing absence of the IPRA, the user would
include the self-signed certificates of the one or more PCAs which he
wishes to trust.
In the absence of a PCA, or in the case of a CA that has chosen not to
go totally public, self-signed certificates of individual CAs could be added.
And finally, of course, the user would include his own certificates and
any others that are communicated via the direct trust model. All of these
so-called self-signed certificates are signed by the user, either en mass or
individually.
This is sufficient to provide syntactic validation of whatever certificate
chains the user chooses to accept, but it does not quite go far enough
along the line of assisting the user in routinely validating the
trustworthiness of the signer of a message.
Therefore in addition to adding these self-signed certificates to the
user's cache, he should be provided some sort of an access control list
capability to control the processing of messages from various hierarchies.
Even if I trust a particular PCA to reliably sign a CAs certificate, I may view
some CAs with somewhat more of a jaundiced eye than others. Likewise, I
may hold some PCAs in higher esteem than others, and the same is certainly
true of individuals.
Therefore, when a signed message is validated, I may want to color code
the validation message with a green, yellow, or red flag to indicate
the degree of caution I should use in evaluating that particular message.
I'll leave it to you to figure out how to code it, but perhaps some kind of
wildcard indication could be devised to indicate stop/caution/go
with respect to an entire PCA, to everyone under a given CA, and/or
particular individuals. Although this would be a nice feature to have
for ordinary e-mail, it is a virtual necessity for any computer-driven
processes that make decisions based on signed messages or transactins.
As I've said before, it shouldn't be very difficult to get RSA, TIS, COST,
or some other PCA (or someone who is willing to operate a CA under one of
those PCAs) to agree to set up an automatic certificate issuing system
that is based on the use of an e-mail responder. This system could use the
normal RFC822 protocols to confirm the existance of the user's mailbox, if
necessary in realtime (to avoid using list exploders and gateways), and would
deliver the certificates back to the user's address specified in the
Reply-To.
Even with a free service, this always brings us back to PEM user scenario #256:
Fred Nyerk purchases/downloads/obtains/borrows/steals a piece of
PEM software. He generates a private key and then wants to make
a certificate to start talking. The software says, "Find a CA to sign
your key". Fred says, "What the blazes is a CA?". The software
says, "Certification Authority". Fred says, "OK, well I'll take
your word for it. Where do I find one?". The software says, "It
continually changes and since this software was released 10 months
ago, the chances are that even if I knew back then, they would
have changed. Go find a guru." Fred says, "No wonder Jane
Schmane swears by PGP ...".
I see this as a big problem with your "go talk to RSA, TIS, COST, etc"
angle Bob. The set of low-assurance CA's will be continually changing
with more coming online all the time. Now, I could hard-wire procedures
for using RSA's low-assurance CA into my software, but that gives them a
slight unfair advantage, and some people may be less than willing to
trust them (for whatever reason). You'll usually know if a local
organisational CA exists and who to talk to about it. But, where is the
list of low-assurance CA's kept? FAQ? Ftp site? WWW? Mail server? In
someone's head? A figment of Bob's imagination? ( :-) ).
I think you have really hit the nail on the head here. In point of fact, I
think
that the list of PCAs has been quite stable -- we're far from being overrun
with people who wish to provide this service, even for a fee. :-)
But how do potential users find out about PEM in general, and PEM
implementations in particular, much less the list of PCAs and CAs,
frequently asked questions, etc?
I don't have time to go Internet surfing, or even read the various
news groups except for this one, the NADF, and recently OSI-DS. I'm
in the process of upgrading my software so I can get MOSAIC to work
properly, for that rainy Saturday afternoon when I have nothing better to do,
but I haven't used it yet and am not qualified to make suggestions in this area.
In your view, how _should_ this information be distributed to the masses,
if that is what we need to do? Should someone be running a discussion group
on CompuServe or AOL, etc.? If MOSAIC and WWW are as great as everyone
seems to think, then it would certainly appear that someone should bring up
a server with the RFCs, FAQ, list of CAs, available freeware or shareware,
etc. What other distribution mechanisms would you recommend? How are
people learning about RIPEM and PGP?
These kinds of things take work, of course. Who do you think should do this:
1. The PEM working group, perhaps as part of the IPRA function?
2. The providers of freeware software, e.g., TIS?
3. The providers of commercial software, e.g., COST?
4. The license holder, RSA?
The answer would seem to be pretty obvious -- all of the above, with cross
references to the other sources, but I'll be interested in your feelings on the
subject.
Bob