On Wed, 30 Mar 1994 jueneman%wotan(_at_)gte(_dot_)com wrote:
Rhys,
I think we are beginning to get closer. I'd appreciate your comments
on my recent note to Warwick Ford with cc to you,
I'll try to get to that next week. In a couple of hours I'll be getting
on a bus out of Brisbane for the Easter long weekend, and so won't have
enough time to compose a good reply to that message.
<{C=AU}, {O="Queensland University of Technology"},
{OU="Faculty of Information Technology"},
{CN="Rhys Weatherley"},
{EA="rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au"}>
The first example makes the EA subordinate to your CN, which would
be perfectly appropriate if you had two or more mailboxes, and
wanted to differentiate between them _in the certificate_ for some reason.
You might add such an example.
That can certainly be done. There is a number of other e-mail addresses
by which I'm known that are redirected here. (In fact, the address in
the pem-dev mailing list server is one of my old ones that I haven't
bothered to change yet. :-) )
<{C=AU}, {O="Queensland University of Technology"},
{OU="Faculty of Information Technology"},
{CN="Rhys Weatherley",
EA="rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au"}>
This is a multivalued RDN, which may or may not be supported
by all implementations, although it should be legal. (Don't people
usually indicate this by a +, rather than a comma?) It may
make it somewhat harder to search for the person's entry,
unless both the exact common name and the email address are known.
This is really just an X.500 thing. I'll probably recommend that the
former style be used, but others may find this style more useful in some
cases. I suppose it depends on how the searching works: is it an OR
match in the RDN's, or an AND match? If the latter, then separate RDN's
are certainly the way to go, but I can't think why you'd want to use an
AND match in any case. How often do you know both names compared to how
often you know one?
If a suitable organisation name or other civil DN is not
available, then the only required attributes are C and EA,
with CN recommended. Examples:
I think this ought to be a PCA requirement/option, rather than being
dictated by the PEM RFCs.
I intend the "stripped down" DN structure (C/EA/CN only) to be mainly
used for self-signed or direct trust scenarios. Since there is no PCA in
those cases, it can't very well be a PCA option. :-)
<{C=AU}, {EA="rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au"}>
<{C=AU}, {EA="rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au"}, {CN="Rhys
Weatherley"}>
<{C=US}, {EA="Jueneman(_at_)gte(_dot_)com"}, {CN="Jueneman, Robert R."}>
<{C=US}, {EA="Jueneman(_at_)gte(_dot_)com"}, {CN="Neilson, Theresa"}>
These are all good examples. You might also add
C=AU, EA="Rhys Weatherley <rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>"
Hmmm ... I don't think this really buys us much except more special cases
on the parsing of DN's. From/To/Cc lines are bad enough without
spreading it to the certificates as well, especially when there is an
existing X.500 method of splitting. The only thing it may buy us is the
ability to use MIME header encodings in the name for non-English names.
But we can just as easily "tweak" the definition of CN to allow such
encodings if it seems prudent.
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'm sorry, but I think you filled up one grave and dug yourself another
at the smae time!
Me too. :-) It is definitely uglier than the previous proposal. Maybe
I'll just dump the domain idea altogether until such time as the working
group can come up with better ways of integrating DNS with DN's for CA
purposes. The current system addresses all of the following:
1. Some way for a CA to bind an e-mail address to a DN to ease us
over the backwards-compatibility hurdle.
2. A naming mechanism for using e-mail addresses as DN's in a
self-signed or direct trust trust model.
3. The chicken and egg problem of getting a lot of people going
quickly and then formulating good naming strategies for
organisations as the need arises.
Only the domain-based CA's aren't handled cleanly.
So I have to conclude that trying to set up CA domains based on Internet
domain names is a non-starter. The trust model, if any, tends to follow
organizational
lines, whereas the communications model may or may not.
Let's just say that I may be coming around, but don't hold your breath
just yet. :-)
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.
This is particuarly easy if such a system were offered as a free service,
giving away candy at first to prime the user's sweet tooth. But even if the
CA decided to charge for the service, the user could sing his request with
his MasterCard number, and the CA could put through the charge before
issuing the certificate.
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? ( :-) ).
The self-signed keys and direct trust models go some way towards
alleviating this problem, but it may still eventually be useful to have
fairly centralised low-assurance CA's for looking up people in a
directory. Without a suitable FAQ, preferably in a machine-processable
format, they won't be well-known to many people outside of pem-dev.
In summary, I am becoming convinced of the following, although I reserve the
right to change my mind:
[...List of 8 things deleted...]
I don't have any major quibbles with these, although I've only just
glanced at them.
See you (metaphorically) after Easter!
Cheers,
Rhys.