Re: X.509 certificate and its subject name field

[Stephen Kent <kent@xxxxxxx>]

Shyh-Wei,

	First off, the cited comment from me does not specifically imply
what you then went on to address:

>On May 28,  7:20pm, Stephen Kent wrote:
>>       - DNs are unique, by definition.  the set of attributes used to
>> define DNs in some context is determined by the CA, using well-defined
>> attribute types.  if you want a closed system, you can do anything you
>> like, but your comments are addressed toward an open, interoperable system.
>
>I don't know how you derived the conclusion that using a per-CA Unique Subject
>ID makes it a closed system.

However, let me make a couple of observations about what you propose here:

>Say, if I am registered with IBM's CA as employee number 123456 and
>I am authorized by hundreds of ACL's inside and outside IBM over a number of
>years.  It would be better if the ACL's use a (123456,CA=IBM) entry than a
>(IBM/Research/Almaden/Shyh-Wei Luan,123456) entry.  The latter would
>require me to request the change of all the ACL entries when I change my name
>(say, if I get an English name) or if I change a department.

If the basis for granting you access was because you are a member of a
given department at IBM, then the change of department, if reflected in
your DN, is a very good reason for invalidating your access, while changing
your name (to English) is not.  So, depending on the reason for the name
change, the use of a Subject UID might, or might or might not be a good
idea.  There is an underlying assumption in the model you present that
access is granted to a user based on who he.she is, not what role the user
occupies.  In many business environments, this may not be true, and hence
long-term persistance of this binding to a person, versus the person in the
context of a job, may not be appropriate.  For example, if the ACL is
outside of IBM, and another company is granting access to  you for some
inter-company activity, they are likely to be more concerned about granting
access to you because of your job position (and it's relation to some joint
activity) than to you as an individual.  In that case, a cert for a role,
or an organizational person cert with substantial organizational detail, is
much more relevant.

Finally, the example ACL entries you provided were both incomplete.  There
needs to be some context about the CA (and maybe superios CAs) in which to
evaluate the subject's ID in either case.  Otherwise, any CA might certify
someone with the DN in question, or might certify a CA with the same name
and then certify someone with the same SUID, and thus cause unintentional
access to be granted.  Yes, DNs are supposed to be unique, but if there are
any unscrupulous CAs out there, or even careless ones, relying solely on
the DN or SUID could cause problems.  Your latter example (based on SUIDs)
oversimplifies by referring to the CA by a name that is too short, the
former fails to take advantage of possible grouping of all IBM employees
from Almaden who are on the ACL, to minimize the size of each individual
entry.  There is room for improvement in the representation in each case.
When I suggest using a subject DN on an ACL, there is a lot of context that
has to be provided, as I mentioned in my recent message to Marc.  Also see
David kemp's message about some of he complexity lurking in a SUID-oriented
approach to ACLs.

Steve