Rhys,
Let me explore some of the more subtle points of your response.
1. The user's common name should be used in addition, to
qualify the mailbox name.
Both of my major proposals allow this. The only modification is that I
will probably be adjusting the second method (e-mail addresses inside
traditional DN's) to use CN="name <address>" rather than {CN="name",
RM="address"} since that seems more popular on the list and would cause
probably less heartache for existing PEM implementations.
If we are going to have to revise the PEM specs and existing PEM code
to incorporate these ideas, we probably ought to do it as cleanly as
possible. If and when we ever display these names with an X.500
DUA, including the user's name with the mail address will always look
like a hack. I originally suggested it as a possible way of implementing
your ideas without any changes to PEM, at least in the attributes
required to be supported in X.509.
If we have the situation I described where my secretary and I
share a mailbox, then it would be much cleaner to use the
pemMailbox="<address>", cn="User's name" style. Now the user's
common name clearly is subordinate to the mailbox name.
On the other hand, if a user has multiple mailboxes and wants to use
different certificates for each, then the order could be reversed. Both
forms are meaningful.
4. What else do we need? Well, in a previous message I
pointed out that even though any Internet mail address
is fully qualified, if you want to use it with any practical DUA
you'd better at least include the country code.
That is something that an X.500 expert should confirm I think. My
proposal was based squarely on one from an X.500 expert (Steve Kille)
which did not have the country code. But, putting the country code in is
no skin off my nose, as long as it is absolutely necessary.
You'll recall that my original proposal used C/O/OU with the top-level
domain mapped to a country code. There are two problems with this: (a)
some fiddling is needed for the US domains, and (b) some domains such as
"uk" actually map to country codes like "GB". What do we map "su" (Soviet
Union domain) to? Do we map it to the country code of the former republic
that the user resides in, or just "SU", or "RU"? These special cases
would have become ugly very quickly, especially (b) in today's changing
geopolitical environment. By sticking with the domain name we let the
Internet slowly evolve to incorporate the new codes over time, without
needing to add special case code to all PEM implementations each time a new
country splits off from an old one.
The country code should be ALLOWED, even if it is not always needed.
I don't think that you should try to impute the country in which a person
is actually listed (for directory purposes) from their Internet address.
I may want to be listed as a residential person with my US address, even
if I attend your university for an extended period of time. The C=US
is therefore necessary to tell my local X.500 directory where in the
overall universe there is an ADDMD that knows about me. (I am assuming
that the current CAN mechanisms used by the NADF will not scale to
a world-wide environment, and that likewise, no one will volunteer
to run a master directory for Planet Earth that contains the name of
every organization and individual, regardless of where they my be listed.)
Your comments on political instability is another reason not to try to
do this -- let the user enter it.
The major benefit of pemMailHost is that it is smaller in length. But,
the CA possibilities are lost without overhauling the name subordination
requirements at the same time. For example, GTE.COM may have (using your
encodings) the following as a CA DN:
C=US, pemMailHost=GTE.COM
Your DN and your secretary's are subordinate to this, which is good.
But, this DN is _not_ subordinate to:
C=US, pemMailHost=COM
Having such subordination may be important in a future version of DNS
that uses signing to assign authority for allocating portions of the
namespace to prevent DNS spoofing.
I've just had another look at RFC 1422, which clearly states that all DN's
on certificates must be subordinate to the DN of the issuer unless the
issuer happens to be a PCA or the IPRA. Hence, unless we were to make all
domains PCA's, this rule would be broken. In your case, it may make some
sense to have "C=US, pemMailHost=COM" be a PCA, but in my case, the
immediate parent of my domain would be "C=AU, pemMailHost=AU.EDU.QUT"
which would probably not make a good PCA.
I think we may have a major glitch here. Again, the issue arises because
naming and addressing rules often follow the same organization tree, more
or less, but this is an accident.
As you point out, GTE is not an organization under COM, nor is COM a PCA.
"GTE" in the GTE.COM sense is a historical accident, in that the Labs was
the first to register a name within the Internet name space. Other business
units have "Sprint.GTE.COM" as part of their Internet adress. Although we
used to own Sprint, we don't anymore. So even if GTE were replaced with
"GTELabs", we would not be a CA over Sprint. Finally, the reason for
using Sprint is to provide Telemail access (almost X.400) to many of the
business units, so the mailbox address in this case is an almost full
X.400 address, and Sprint.GTE.COM is the gateway.
The important point is that none of these connection details have anything
to do with being a certification authority. GTE employees might very well
have e-mail accounts on DOCKMASTER, or CompuServe, or the Well,
or a number of other locations. We can include the e-mail name
of such users within their certificate, if you like, but the name subordination
issue is going to be much more difficult.
Maybe we should review the bidding as to why we have the name
subordination requirement. Steve Kent could certainly do a better job,
but I would say that it was for the following reasons:
1. We want to make sure that the Certification Authority has some
reasonable and logical connection to the user that is being certified,
so that a CA doesn't certify users without their knowledge. Remember,
the CA, (and the PCA) can impersonate anyone they wish, just by making
up a certificate or set of certificates. This is the Rogue CA problem.
Presumably users under a given CA have ready access to that CA's
list of certificates, and can object if a false certificate is included.
2. Requireing the user to include the name of the CA in their name
also provides a degree of additional trust in the identification
of the user, because to an arguable extent, the CA becomes implicitly
liable for the actions of those who are certified, and they therefore
have to exercise a certain amount of prudence in authorizing someone.
3. Note that the issue of name subordination in the case of residential
persons is still _highly_ unresolved, unless you buy Steve Kent's
argument that the residential CAs are effectively acting as agents for
the individual states. But the RSA residential person CA does not
follow that convention, and instead identifies itself as C=US, O=RSA Data
Security, Inc., OU=Unaffiliated User Certification Authority. TIS
doews something different, and we haven't yet cme to grips with this
problem. In any case, it will have very little to do with the user's e-mail
address.
The conclusion I draw from this is that we either have to:
1. Abandon the requirement for name subordination, or
2. Avoid using e-mail addresses as the _exclusive_ DN, but instead
insist on using the e-mail address as an _adjunct_ to (additional
RDN within) the DN.
I realize that you probably won't like this solution, because it still leaves
you with the "where do I get someone to assign me a DN" problem.
But I can solve the problem of how to integrate PEM with a mailer in
a bolt-on fashion (which is how this thread got started), by either including
the e-mail name as a subordinate RDN to the organization name, or by
adding it as an auxiliary, non-distinguished name within a modified X.509
certificate.
If my DN is
C=US, O=GTE Labs, OU=Employee,
emailAddress="Jueneman(_at_)GTE(_dot_)COM",
cn="Robert R. Jueneman"
and my CA's DN is
C=US, O=GTE Labs, OU=Employee,
CN="RSA Commercial Hierarchy Certification Authority"
or even C=US, O=GTE Labs, OU=Employee,
CN="RSA Commercial Hierarchy Certification Authority",
emailAddress="CRL_Responder(_at_)GTE(_dot_)COM"
then that satisfies the name subordination requirement and doesn't
even require breaking the address into the mailbox and mailhost parts.
In conclusion, I believe that we have been addressing two primary
problems. One, raised primarily by Steve Crocker, is that we need a way to
conveniently associate outbound messages with the e-mail address of
the recipient, so that bolt-on postprocessors can easily determine which
certificate to use to encrypt the message. This problem I believe, is
adequately solved by the above approach.
The second problem is your original concern, and probably the concern
of almost every trail-blazing user within his organization, i.e., "where do
I get a valid DN, and how many people to I have to convince to allow
me to use it?"
I'll try to address the second concern tomorrow.
Bob