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, and would like to
offer comments on your Mark 2 draft. Indented lines are from your original:
The "emailAddress" (from PKCS #9) may appear in any RDN in a
distinguished name, either on its own or in combination with
another attribute, typically CN. Examples:
You might also say "in any order".
<{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.
<{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 type of distinguished name is suitable for traditional
PEM CA hierarchies, which are usually based on civil naming
structures. The e-mail address is simply auxillary information
that may be useful in the transition between Internet e-mail
addresses and X.500 distinguished names.
I'll buy that.
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.
<{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>"
Other attributes may be added at the discretion of the subject
or the issuer. This type of distinguished name is suitable for
self-signed certificates, direct trust between Internet users,
and PEM CA hierarchies based on domains as described below.
In particular, mailing addresses and telephone numbers may be helpful until
X.500 directories are widely deployed with such information.
But this does bring us directly to the name subordination issue, which I
perceive
to really be at the heart of most of the discussion and controversy over the
past
month or two.
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.
CA hierarchies based on the structure of the Internet domain
name system may be achieved by having the postmaster of a domain
sign the subject's certificate. For example, the following
chain traces the e-mail address
"rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au" back to
the top-level domain "au":
<{C=AU}, {EA="rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au"}, {CN="Rhys
Weatherley"}>
<{C=AU}, {EA="postmaster(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au"},
{CN="????"}>
<{C=AU}, {EA="postmaster(_at_)qut(_dot_)edu(_dot_)au"}, {CN="????"}>
<{C=AU}, {EA="postmaster(_at_)au"}, {CN="????"}>
Note that sometimes a suitable postmaster or domain co-ordinator
does not exist at some levels of the domain name system.
The only "trust" that should be placed in such a chain is that
of "authority to use a name". The postmaster at each domain is
responsible for assigning e-mail addresses and subdomains only.
No other responsibility, especially for commercial or legal purposes,
should be assumed unless established by some out of band means.
I'm sorry, but I think you filled up one grave and dug yourself another at the
smae time!
I don't think that the issue of legal responsibility or "authority to use the
name"
is necessarily the showstopping issue here. Instead, I think it would be just
as hard,
and maybe even harder, to get the "postmaster" at any given level to issue any
kind
of a certificate at all, for any reason.
I am the "postmaster" at wotan%gte.com. I'm going to try it, but I doubt if I'll
get any answer if I send a message to postmaster(_at_)gte(_dot_)com(_dot_) And
to the best of
my knowledge, postmaster(_at_)com doesn't make any sense at all.
In the case of the rest of GTE, as a result of the fact that we used to own
Sprint,
much of the company is anchored off of the GTE domain which is "run" by
GTE Labs (but I think really run by BBN, which manages our part of the link).
We certainly would not be in a position to authenticate anyone addressable
via telemail sent to xxx(_at_)sprint(_dot_)gte(_dot_)com(_dot_) Likewise,
sprint is not in such a position
either.
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.
I really think that you would be better off to face up to the fact that without
an organizational committment, you are going to have to rely on either
a direct trust model, or perhaps on use of e-mail addresses and connectivity
as a pragmatic means of confirming "right to use" of an email name.
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.
(Does anyone know whether MasterCharge needs to know the card holders name
in order to validate the card and card holder? Or is just the charge number
sufficient? In any case, if the wrong user is charged, the CA would eventually
find out, and could CRL the certificate.)
(Those who insist on anonymity could send International Money Orders or cash
via snail mail, unless someone wants to implement digital cash along with
everything
else, just as an additional handicap to prove how macho they are.)
So I like the scheme I outlined in my previous message to Warwick and you, i.e.,
C=CA, caDistinguishedName=(C=US,O=RSA Data Security, Inc., OU=E-mail Responder
CA),
EA=wford(_at_)bnr(_dot_)ca, CN="Warwick Ford"
If patriotism, nationalistic pride, and/or balance of payments issues arise,
surely
_someone_ could be found in Australia to set up and operate such a low
assurance CA, even if it operates under the auspices of one of the other
out-of-country PCAs. On the other hand, you can reach the US almost as well as
you
can reach Sydney, presumably.
In summary, I am becoming convinced of the following, although I reserve the
right to change my mind:
1. The civil naming rules for DNs should be preserved, or at least accommodated,
as there are a number of real users already using them (not necessarily PEM
users).
2. The use of e-mail addresses to supplement DNs makes eminently good sense
as a transition aid (assuming there will ever be a transition), and likewise be
accomodated within the DN structure. This just requires a new attribute, and if
PKCS #9 has already registered their emailAddress attribute and OID that's fine
with me. They have as much standing as anyone else, and real users.
3. The use of civil name DNs _only_, without an e-mail address, may retard the
deployment of PEM and similar systems, and so should be mildly deprecated if
in fact e-mail addresses exist or are relevant to that application. But it must
be
recognized that e-mail address are in fact NOT relevant to many uses of PKC
technology, from EDI transactions to schemes for setting up encrypted sessions,
so their use cannot be mandated within X.509 certificates in general.
4. Likewise, the use of e-mail names in the absense of certified civil name
DNs, for
either residential persons or organizational persons, does not provide a very
strong basis for either individual or organizational identification or
attribution,
and therefore should be limited to low assurance PCA and CA hierarchies,
and/or direct trust modelsituations. I.e., it should be realized that the usual
notions of nonrepudiation (which are difficult enought as it is) for digitally
signed
messages can almost surely not be supported for this model, but that may be Ok
and even preferable in some cases.
5. Trying to transform the Internet's domain name space into a trust model
simply
doesn't work with sufficient generality to be useful. Too many people are
served by
commercial providers and/or network gateways whose administrators have
absolutely
no control over the ultimate end-users to warrant any degree of trust
whatsoever.
Trying to maintain the name subordination rules in this case is therefore
pointless.
6. Name subordination should therefore be viewed as an optional but highly
desirable
policy requirement to be imposed by PCAs and CAs on originating users, and
should
be a user-selectable implementation option by recipient users.
7. The precise syntax and semantics of the name subordination requirements
still needs
to be specified. Options would seem to include the use of an OU (real or an
alias), a
caName AVA, or a full-blown caDistinguishedName attribute which would allow the
CA to be completely independent of the user and his organization.
8. The incorporation of an e-mail address within the DN of a CA or a PCA would
appear to be a "good thing". At a minimum, this e-mail address should provide a
user
with either a human contact or an automatic responder that would return other
useful information such as how CRLs are made available, the location of the
PCA's
policy, mailing adddresses and phone numbers, automatic voice response units to
confirm certificate validity, etc.
Comments?
Bob