On Mon, 14 Mar 1994 jueneman%wotan(_at_)gte(_dot_)com wrote:
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.
No argument from me. We can embed e-mail addresses in traditional DN's
any way you like. Let's just get a consensus huh? This "use CN, no use
two separate attributes, no use CN, ..." is getting us nowhere.
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.
For residential addresses, etc, the above method of embedding e-mail
addresses in traditional DN's works quite well, IMHO, and they _would_
include the country code. What I'm getting at is the other case where
there is no traditional DN, and the domain components are split out. The
top-level domain name is pretty close to a country code, so why duplicate
it? There is nothing stopping countries from handling both "C=??" and
"DC=??" in their X.500 directory spaces.
You don't seem to like splitting a domain name into its components.
Here's an argument that I think demonstrates why it's a good idea in the
case where there is no traditional DN. Without splitting, we get
something like this:
pemEmailAddress="rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au", CN="Rhys
Weatherley"
Therefore, we need to have every single e-mail address in the universe at
the top-most level of the X.500 directory. A total nightmare. Adding the
country code will just move the nightmare down to the country level. Note
that the case of using Persona CA's or similar for those who don't want an
organisation-based name is similar:
C=US, O="RSA Persona CA",
pemEmailAddress="rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au",
CN="Rhys Weatherley"
If the number of people using this scheme becomes huge (and in all
likelihood it will), then we substitute a nightmare at the top-most level
with a nightmare at RSA's level. My alternative on the other hand gives:
pemDomain=au, pemDomain=edu, pemDomain=qut, pemDomain=fit,
pemMailName=rhys, CN="Rhys Weatherley"
The advantages of a distributed directory are now available for those who
don't want a traditional DN.
[...discussion of RFC 1422's name subordination requirements...]
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.
Accident or not, the primary function of the certificate system is the
assigning of names, and the secondary function is attaching various
levels of trust based on the PCA that a certificate chain can be traced
back to. The DNS is an existing mechanism for assigning names, and
boot-strapping off it was one of the main reasons for considering e-mail
address encodings in the first place.
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.
This does not change the fact that the domain co-ordinator for gte.com
has the authority to assign the name sprint.gte.com to Sprint. No
ownership relationship is implied in the DNS. Am I owned by "C=AU" if my
DN happens to be underneath it? I'm sure the Australian government feels
that they own Oz citizens, but I don't feel that way. :-) Just as the
country-level DN's are convenient identifiers for grouping the name
assignment in X.500, domains are also convenient identifiers for grouping
the name assignment on the Internet. Other aspects such as ownership need
to be established separately.
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.
For the last time ( :-) ), if you want to use a traditional DN with an
embedded e-mail address, then I am not going to stop you, and that would
deal with the cases you cite. But I think I've prevented convincing reasons
why some (many?) of us would rather use the DNS names directly. For
traditional DN's, the normal name subordination rules already apply.
But, for the new style DN's, there is no subordination with your
proposals, but there is with mine.
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,
My local domain co-ordinator has a reasonable and logical connection to
me by virtue of the fact that he has set up a domain under which I have
been allocated a user-id. He accepts no other responsibility for my actions.
2. [...] 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.
I don't like this at all for 99% of use. If my system admins here were
responsible for my actions, my net access would have been terminated long
ago. This comes back to the "casual use vs. legal use" question. To use
PEM, I need a name, not authorisation. Authorisation is a completely
separate issue. The CA system of PEM has confused naming and
authorisation so much that it seems impossible for me to get you to accept
a way of assigning names, and only names.
3. Note that the issue of name subordination in the case of residential
persons is still _highly_ unresolved,
I'd make an even stronger statement and say that residential naming is
highly unresolved in general, not just the name subordination case.
Which in my view is yet another reason to use DNS until such time as the
residential naming problems have been resolved satisfactorily.
This is not just a residential naming problem. All CA's currently in
existence have problems in consistency across PCA's, standard naming
schemes, etc. Until these are resolved, I am going to steer clear of
traditional DN's and use an existing naming system that has a proven
track record.
[...] In any case, it will have very little to do with the user's e-mail
address.
Granted, trust has very little to do with e-mail addresses. But, you are
currently denying my the ability to use PEM _now_, and then explore the
issues of trust later. If at some later time it becomes prudent for me
to get a traditional DN for a greater level of trust then I will, but
until that time I just need a _name_.
1. Abandon the requirement for name subordination, or
Fine with me. The direct trust models being proposed elsewhere are one
step along the way of abolishing subordination anyway. Still, you can't
deny the benefits of parsing out the domain name would have on an X.500
directory search engine.
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.
3. Allow e-mail addresses as adjunts to existing DN's, and also allow
e-mail addresses to be used as DN's if the users so choose.
This word "insist" is what I object to in your arguments. Let's have it
both ways, not just your way.
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.
From what I saw, this thread started with the goal to use e-mail
addresses as DN's and then the issue of embedded e-mail addresses also
arose. While embedded e-mail addresses will assist to bolt-on, e-mail
addresses as DN's will assist to make PEM explode out of its currently
limited market. The naming issue is the most important here, with
bolt-on processing being an exteremely useful side-effect.
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.
Ummm, forgive me if I sound a bit naive, but the two CA DN's you gave are
NOT prefixes of the user DN you gave. How is the DN subordinate then?
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?"
"And, why the hell can't we boot-strap off the existing Internet naming
system so that PEM can explode and then worry about high levels of trust
after we have a user base that warrants it?" :-)
Cheers,
Rhys.