As a follow-up to the message concerning DNs in v1 and v3, I'm going to post a
private message from Warwick, together with some of my observations. Some of
his views echo comments I made previously, because the messages crossed in the
mail.
Warwick>
I should clarify what I was saying re DNs and "identifier". I realize the
problems which existed with v1/v2 certificates - about the only useful field
was the DN, so all sorts of semantics needed to be squeezed into it to make the
certificate useful.
However, I am now talking about v3 where we have some extra fields. A very
important one for this discussion is subjectDirectoryAttributes, which allows
any X.500 attributes of the subject (as chosen by the CA) to be carried in the
certificate, separate to the DN. What the CA is now doing is binding together
the public key, the DN, and the attributes.
This allows us to stop trying to attach semantics to the DN. The DN is now
simply a directory entry name in the sense X.500 always intended, i.e., it
identifies the subject's directory entry. The internal structure of the DN
will be influenced by such factors as name space administration, but not by
anything to do with CAs.
Bob>
I agree.
Warwick>
The CA comes into it by selecting a set of attribute values to bind to that
name (e.g., organizational role, postal address, whatever). There is no
requirement that these attributes also be in the directory entry, although that
will probably frequently occur.
Using the DN to support nameSpace constraint and nameSubordination provides
added options which may prove useful to CAs. The nameSpace constraint allows a
CA which certifies another CA to specify the set of names for which the subject
CA can issue certificates. This can be any set of (possibly chopped) DIT
subtree specifications, i.e., it can describe any arbitrary set of pieces of
the DIT. The nameSubordination constraint may prove useful in many scenarios,
depending upon the naming approach used in the part of the DIT involved.
Bob>
I haven't yet read the ISO text on the extensions, and perhaps my qeustion will
be addressed there.
But I have some concern regarding this approach, because I am increasingly
uncertain that the "traditional" DIT structure that people have imagined will
be used may not be all that useful in practice.
It may work reasonably well in the case of organizational persons, assuming
that organizations actually list their employees that way. It pretty obviously
doesn't work in the case of residential persons.
Some of work we have been doing in looking at telephony white pages led us to
focus on the issue of how competing telephone companies and/or directory
service suppliers can effectively jointly administer the public name space for
residential persons, given that there is no monoply, and the service boundaries
for the phone companies do not coincide with the geopolitical boundaries.
We presented this problem to the NADF, and illustrated it with sample
directories loaded with data from GTE's Downey, and Long Beach, CA areas. In
this case, as in the Dallas/Irving area, northern Virginia/Manassas area and
elsewhere, the service territories for GTE and the adjacent RBOC look a bit
like a gerrymandered voting map, and in many cases overlap at the county level
and sometimes at an even lower level. Assuming that it is not desirable or
even reasonable to require that someone looking up a person's telephone number
would have to know in advance which telephone carrier you are served by, or
your directory service provider, or where the person lived with some precision,
it appears that all of these entries will have to be in the public name space.
This has significant consequencs on the overall interworking of DSAs, and the
problem is now jokingly referred to as the "Downey" problem within the NADF.
Although this problem is bad enough for telephone customers, where
traditionally the calling party does have some idea where the person lives, it
is a much worse problem when we start to deal with residential persons whom we
wish to communicate with via e-mail, when generally it will be necessary to
search the entire c=US DIT subtree. (I'm think of the case where someone
obtains service from an independent supplier such as AOL, not through an
affiliation with his company.)
In addition to this problem, one of my original assumptions was that in order
to ensure that residential person's DNs were unique, it would be necessary to
include the individual's postal or residence address, including state, country,
street, and street number. When I mentioned that to another member of the NADF,
a woman, she very properly objected, saying that in this day and age of
stalking, etc., many people would not want to have their street address and
similar details made widely available. The point to be drawn from this is that
although access controls can be applied to individual entries in the payload
associated with the DN, THE INDIVIDUAL RDN COMPONENTS IN THE DN ARE ACCESSIBLE
BY EVERYONE.
Some people may not wish to have even their given names listed, much less their
children's names, etc. And others may not want to have any correlation between
the work and home addresses or telephone numbers published. Although it isn't
clear to me that the existing access controls will support this degree of
control and still make the directory usable, I think we have to think seriously
about these issues.
For this reason, I have begun to think about the feasibility of listing people
by only their surname and a 128 bit uniqueID which is randomly selected using a
cryptographic one-way function by the directory service provider. (Assuming
that we have less than 2**64 or 10**19 users, the probability of a single
accidental collision is less than 50%, and if we ever have that many users so
much money will be flowing in that we can afford to solve the problem some
other way!)
Depending on the user's wishes and access control constraints, other
information can be made accessible to different classes of users, and as Joe
Tardo of DEC pointed out, most X.500 directory implementations can search just
as quickly on other attributes as on the DN, by building appropriate reverse
search tables. In our directory with approximately 100,000 entries for
Downey/Long Beach, it is just as fast to acquire the customer's name by
entering the telephone number as it is to go the other direction -- a fact that
may add fuel to the CallerID fire.
In summary, the DIT might end up to be much less structured than most people
currently envision it to be, cetainly far less than when we were dumping into
it all of the identity information that would be likely to be needed within a
certificate.
There is another concern is perhaps even more important, however, and that is
the question of independence of the CA and the Directory service supplier, and
the degree of responsibility and liability each shares.
By suggesting that the nameSpace or nameSubordination rules be applied and tied
to the DN and the DIT, I believe that you have improperly tied the proper
performance of the trust model, including the CA's choice of the nameSpace and
nameSubordination requirements, to the structure of the DIT, WHICH IS NOT UNDER
THE CONTROL OF THE CA.
I belive that this was one of _the_ most fundamental mistakes made in the X.400
spec -- it placed a burden for security and integrity on the carrier/PTT, and
this was legally indefensible, since the end users may not have an binding
agreement with that carrier that would allow enforcement on a third party.
I'm not suggesting that nameSpace and nameSubordination rules cannot be
applied, but they should be applied to attributes that are extensions under the
control of the CA, presumably one or more of the subjectDirectoryAttributes
(although I am beginning to believe that may be an inappropriate choice of
attribute name, since it isn't the Directory that is naming it, but the CA).
And the X.500 DSAs and DUAs may not even have to recognize or understand those
extension attributes!
Warwick>
Any CA can specify nameSpace and/or nameSubordination constraints in its
CA-certificates. There is no need for RFC 1422 to specify any particular
"rules" - just to state that these optional extensions should be supported.
BTW, the v3 system obviates the need for the strict IPRA-PCA-CA structure - any
CA in a chain can stipulate policy restrictions to apply to the chain.
Bob>
By that I assume that you mean with regard to name subordination, etc. I am
also VERY interested to see what was done to support the notion of a publicaly
available Policy statement, e.g,, the PCA's policy for identification and other
concerns. Probably the CA needs to have a written Policy as well, and one of my
long-standing objectives in this area is to provide some means of the USER
including a Policy, Terms and Conditions, or Representations and Caveats,
whereby the user can limit the potential exposure if his key is compromised,
etc.
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820