There has been some offline discussion about Distinguished Names in X.509
certificates, and I think it might be beneficial to recap some of the points
made to the general list.
So that the > marks don't become 17 deep by the time we finish this discussion,
let me just indicate the speak before each change. The statements have been
culled froma a succession of messages, and in some cases I've cleaned them up
or moved them around for improved readability.
Bob>
On a slightly different note, do you understand what Ned meant in his message
regarding DNs, and especially his insistance that they not contain a users
name? I've read it several times, and am at a loss to see what he is driving
at.
Amanda>
The issue of what a DN "means" and how it should be interpreted, processed,
and stored is just as complex as what a digital signature "means". I suspect
that you and he are just seeing DNs from different angles. I personally
view DNs as nothing more than a collection of arbitrary attributes, and a
certificate as such a collection signed by a particular key pair. This does
not seem to be the prevailing view, though--many people are hung up about what
DNs "mean".
Bob>
In general, I support the notion of a DN being just an arbitrary collection of
strongly typed attribute values, for which the CA is responsible for assuring
the accuracy. WHICH attribute types are required (or a which of a set of
acceptable aternatives) should be specified by the PCA's policy, I should
think. The issue of actual and implied liability that may flow from the use or
choice of certain attributes is a different subject best left to the PCA and
their lawyers. Which attributes are optional but should be supported by a large
number of implemtnations still needs to be discussed, but we need not all
agree. That's what makes horse races.
Warwick>
I think I support Amanda's "...view DNs as nothing more than a collection of
arbitrary attributes..." more strongly than you. The DN is just an identifier.
Bob>
Warwick, I tend to agree with you in the case of v3, but my comment was more
historical. You may have already thought through this case, but I'm just
beginning to consider it. In the past, when there was nothing available but the
DN to carry any information about the subject, loading some semantics onto the
DN within the certificate, either explicitly or implicitly, was inescapable.
Nonrepudiation of an utterance which is accurately identified as to its source
implies responsibility and potential liability for the utterance, and must be
recognized as such.
The whole ESSENCE of a certificate is to bind a user's identity to his public
key, and until v3, the DN was the only "container" for that identity that was
available, however flawed. If the notion of "identity" is transferred to a
different set of extensions, however, that becomes a different ball game.
Bob>
Interestingly, and I'm thinking aloud now, we may want to get away from the use
of DNs in certificates almost entirely (using v3), for they really serve almost
no useful purpose [vis a vis identity] that I can think of that can't be better
handled by extensions, critical or optional. The PCA would then be free to
specify extensions to the certificate as critical or not, depending on their
policy. In this case the DN would _not_ have to be globally unique, but could
be a backwards reference to the X.500 entry that contained it. There could even
be multiple DNs for this purpose! By decoupling the DN in the certificate from
theinformation that may be needed to assess whether I want to correpond with
someone and/or accept what he says at face value would be a "Good Thing" IMHO.
Then, and only then, could be recouple the DN in the certificate to one or more
DNs in the X.500 directory, but now the DN in the certificate CAN match the
X.500 provider's schema and choice of directory DN.
[Actually, the proposed syntax for v3 wouldn't support multiple DNs, I don't
think. And it isn't clear that it would be needed in any case - a single
backward reference would suffice to locate a replacement certiifcate. I can't
think of a reason why all possible Directory listings that contained or pointed
to a single certificate wold have to be identified.]
[In a previous message to Jeff Thompson which I can't locate, I argued that the
relationship between directory DNs and certificates is potentially many to
many. A single "person" may have multiple directory entries, e.g., one for his
primary residence, one for a blind PO box, one for his vacation home, etc.
These might all be in different states. Depending on the details of how these
are listed, they could be aliases, but if it is necessary to disassociate some
kinds of information (e.g., my street address and telephone number when all I
want to provide to you is my PO Box), it may be necessary to create different
and unique DNs. Howedver, depending on the details of how the individual is
identified in the certificate, it is the _same_ individual, and not a different
role. So there is no requirement for more than one certificate.]
[On the other hand, even as a single individual/role, I may have multiple
certificates. One might use a limited key size and be intended for
implementation in software, for not particularly important messages. Another
might use a long key, and be implemented on a smart card. I might have one for
decyption only, the access code for which I share with my secretary so she can
open my mail while I am gone. And another, so that only I can sign my mail. And
so on.]
[So in general, a one-to-one relationship between any "reasonable" DN in a
directory and the DN in the certificate will be impossible. Obvoiusly you could
artificially create a directory DN for each unique certificate, but this seems
pointless. And you could artificially create a new certificate for every
possible DN listing instance, but that would not only be pointless by
burdensome.]
Warwick>
I cannot support this direction. [Referring to theabove text without the
information in brackets, which is new.] The DN in the certificate identifies
the directory entry of the subject. Given v3 and the addition of a
subjectDirectoryAttributes extension, we can now very clearly kill off all the
old misguided ideas that there was some sort of semantics associated with a DN.
Bob>
I think I agree with the second part, but I'm not so sure about the first,
maybe because up to now I have argued so strongly that for versions < 3, there
is NO correlation necessary or even possible between the Directory DN and the
certificate DN. (This may be part of the difference of viewpoint between Ned
and I on this issue, although I haven't explored that yet).
Even now, if I am a Directory service provider, I may be at odds with an
independent CA as to what constitutes a "good" DN. for example, As a potential
Directory service provider, I might decide to construct a DN for my customers
that consists of a 128-bit message digest of the user's name and billing
address, or perhaps surname plus that digest. Is that compatible with intended
uses of the DN in v1 or v2 of X.509? Clearly not. Is it workable in v3, if the
"identity" portions of the certificate previously carried in the DN are now
carried as extensions? Probably so, and perhaps better that way. As I said, it
may be possible to recouple that which I think has been decoupled until now,
but some more thought will have to go into it.
Warwick>
Also in v3 the DN continues to play some special roles - it provides the basis
of name-space constraints and name-subordination constraints.
Bob>
You obviously have me at a disadvantage, since I haven't followed your work in
detail for a year, and haven't seen the proposed extensions. But off-hand, I'm
not convinced that the DN should carry the baggage you mentioned, because of
the possible conflict with what the directory service provider chooses as for a
schema.
[Just as we began to develop new constructs for PCA to CA hierarchy
relationships using an extension for hierarchy chaining, I think we should
reexamine the name subordination rules. They clearly don't work, and are
meaningless besides, in the case of residential persons. They may continue to
have a role to play in identifying a CA as a kind of deep-pockets guarantor for
the user. and finally name subordiantion provides some protection to an
innocent user against a rogue CA, who issues a certificate in a fradululent
name to an accomplice or himself. If name subordination is in place, this
causes a self-inflicted wound. But whether we continue the name subordination
rules or not, the DN is almost surely not the place for them. Another attribute
should be used, in an attribute extension.
--------
Ned: With this as a background for discussion, would you please amplify your
previous remarks about what you think a DN should look like and/or shouldn't
look like, differentiating between a v1 and a v3 certificate?
I didn't understand your previous message at all, but I suspect it may have a
lot to do with how you are storing or retrieving the certificate and/or
correlating it with the To or CC address in the message. Can you elaborate?
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820