I'm scratching my head here and preparing to write a second draft of my
e-mail address proposals. Here's a summary of my latest ideas.
The basic encoding scheme is as follows:
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:
<{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"}>
<{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 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.
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:
<{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"}>
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.
Note: I changed from "rfc822Mailbox" to "emailAddress" mainly because the
latter is registered a bit more formally than the former. Alternatively,
we can get an OID under the Internet arc. I'm easy. Just tell me how
to go about getting such an OID.
If we are willing to throw out name subordination (and we'll probably
have to for the proposed non-hierarchical trust mechanisms), then I can
integrate the domain scheme with the e-mail address scheme.
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.
Note: One possible objection is that the postmaster may not be the person
responsible for subdomains. Is there some other standard alias, that can
be used instead, that I don't know off?
I must admit that I still like my DC/RM scheme better for achieving a CA
hierarchy based on the DNS, but as a compromise solution I am willing to
live with this one. Arguably it doesn't subvert the X.500 way of doing
things to the same extent.
To be cynical about it, it is also uglier which would encourage people to
get traditional DN's as soon as possible when they no longer want to use
self-signed e-mail address certificates. This should make Bob happier. :-)
Comments?
Cheers,
Rhys.