Ned> Let's say I want to send you an encrypted message. But I don't
have your exact DN; we have never communicated before. How do I go
about finding your DN and corresponding public key? I have to do a
directory search, of course. Even assuming the necessary directory
connectivity is available to me, it won't do me much good if the way you
organize people in the directory isn't something my software knows how
to deal with.
I have had trouble deciding just how I would do a directory search
myself, but I have never heard that I need to know an entity's entire DN
in order to find him in a directory. That seems to be an unnatural
limitation on a directory. Is it not the case that a directory search
could be performed with a limited set of AVA's (some distinguished and
some not) and then return multiple entries?
- -
Ned> There are all sorts of issues surrounding the concept of setting up
and maintaining a genuinely useful distributed directory. Connectivity
is a big problem: in my experience the reason the Internet X.500 pilot
doesn't work too well is because so few of the DSAs are actually on-line
at any given point. But this is just transient stuff -- structural
differences in directory schema can cause *big* problems that are
anything but transient.
I thought the question being discussed in the current thread was the
construction of a DN. How could that have any effect on the "structural
differences in directory schema"? If I wish to make a assertion about
myself, there is no reason that I can imagine for a directory to prevent
that. I am much more worried about the assertions a directory makes
about me without my knowledge. (I noticed telephone number, what about
salary?)
- -
Ned> I'm aware that I'm glossing over all sorts of security concerns
here. We're having enough trouble getting a directory deployed without
worrying about whether or not the information in it is trustworthy.
Well now, if I can't trust the directory, I guess that means that CA's
and their entire trust structure are not a transient necessity, but a
permanent fixture in trusted communications! Prior to this I had
thought that the CA hierarchy would go away, once X.500 reached its full
glory.
- -
Steve> - The name in a certificate is a DN, and some of the other
attributes you note in your message seem unlikely to be distinguished
attributes in most people's idea of appropriate schema. The problem Bob
has is that he is trying to add attributes to the certificate to provide
useful information from a security standpoint, but these attributes are
not appropriate as distinguished attributes from an X.500 standpoint.
Why not - do they not serve to distinguish one DN from another? As I
took Bob's request, he might have multiple DN's for himself, one with
liability and one without, those certainly need to be distinguished, one
from the other!
- -
Steve> - A DN defining a role would not have a CN for the role occupant,
I think. If you look at the object classes in X.500 you'll see that the
semantics of role and role occupant go together. I would expect a DN
for a role, and the entry corresponding to the DN could have an
attribute that specifies the DN of the role occupant, but the role
occupant would not be a distinguished attribute and this should not be
in the subject name for the certificate corresponding to that entry.
I guess that seems to be exactly the point. Is the role occupant a
distinguishing feature of the binding between a DN and a public key? If
it is, then it should be in the DN, if not, then not.
- -
Steve> - The same reasoning applies to attributes that indicate the
assurance level the hardware and procedures used by a CA; these are
interesting aspects of the CA and the user's he certifies, but these
"attributes" have no place in the DNs of either.
I'm not sure that's the case either, it is application dependent. If I
wish to send a private message that uses the recipient's hardware
protected key, then that key is distinguished from any other key that
was not hardware protected.
- -
Rich> There can be multiple CNs in a directory *entry* (only one of
which is distinguished), but not in the *same RDN*. You could construct
a hierarchy, I suppose, where two levels both used the CN for naming,
but I can't think of a good example off the top of my head. (Maybe Org.
Role, with Org. Person subordinate to it?)
It's true that only one CN can be in one RDN, however, we are discussing
DN's which can, in fact, can have multiple CN's. My understanding of
most implementations (including our own) is that each RDN will have one
and only one AVA (and exactly one CN for a DN) as generated. I repeat
my earlier assertion, I would not like to see anyone put multiple CN's
in a DN. I strongly encourage the use of other attributeTypes besides
CN. By the way, if the CN's are in different RDN's, it seems to me that
they are, ipso facto, distinguished.
Peace ..Tom Jones