Re: X.509 certificate and its subject name field

[Stephen Kent <kent@xxxxxxx>]

Marc,


>Let me try again...  The issue isn't really uniqueness but the variability
>of the unique parts.  My point is that while DNs are unique, they are too
>variable for practical use in ACLs.  An ACL needs to be based on something
>that is not only (relatively) unique but also invariant.

We don't necessarily agree on this point.  You've made an assertion that it
would be infeasible to manage ACLs based on DNs, but have not provided a
detailed argument in support of that claim.   Have you examined the 1993
X.500 directory (internal) access control facilities and decided that they
are fatally flawed?   Have you considered the relationship between cert
validation and ACL entry format?  What about group entries?  What sorts of
syntactic sugaring have been considered and rejected as impractical?  There
are a lot of possibilities here and we have not been presented with a
thorough analysis to support the rather broad assertion you have made.

>CAs are being encouraged to add unique-and-invariant attributes to their
>RDNs, such as employee numbers or SSNs or whatever.  ACLs will come to
>rely on the persistence of these attributes, since they'll always identify
>the same subject despite changes in the other attributes.  ACL maintenace
>is much easier if the ACL only uses these persistent attributes, since the
>ACL won't have to be updated whenever there's a change to the DN.

I think we have a miscommunication at this point.  Directory administrators
(not necessarily just CAs) are encouraged to design naming schema that will
include a value in the terminal RDN to avoid the name reuse problem.  Since
DNs are supposed to be globally unique, this advice is simply a way to help
ensure this, and it helps deal with uniqueness over time as well.  In a
large company, one would expect to see this sort of naming schema anyway,
just to meet the uniqueness criteria, without regard to temporal
uniqueness.  For example, the folks at Univ of Texas contacted me 3 years
ago and noted the name overlap potential for their student body, on a per
cmapus basis  They already understood this problem and planned to adopt the
solution we have discussed, i.e., including a student ID # as the second
component of the terminal RDN.

>But this will lead to problems for ACL maintainers when they want to rely
>on many CAs in an open system.  For each CA they want to rely on, they'll
>have to tweak their ACL engine to recognize the persistent part of each
>CA's subjects' DNs.

Again, a communication problem.  The simple model is to require ACL entries
to be based on whole DNs, not just selected parts.  So, if one adopts the
model that it is the whole subject DN that is the entry (perhaps with some
syntactic sugaring to make maintenance easier), then this is not a relevant
criticism.

>What is needed is a standard so that ACL maintainers can always find this
>persistent information in the same place.  It was suggested that the UID
>fields would be a good place for this.  I can see now that this was a poor
>suggestion, which confused more than it clarified.

If I grant access to a group of users, because all are in the same
department of a company, then I want to be able to use a partially
qualified DN to define this group entry, not a list of per-user ID numbers
of any sort.  What you are suggesting is a model that assumes that
individual users will always be the authorized entities, which will not
always be the case.

>Let me suggest an entirely new field, the PID (for Persistent ID).  The CA
>assigns a locally-unique PID to each of its subjects, and these PIDs will
>never change as long as that subject is registered to that CA.  The PID
>can be included in certificates to give ACL maintainters something to use
>in their lists.
>
>This information shouldn't be optional, so it can't be a subversion of
>UIDs or some new DN attribute.  It should be a required part of all
>certificates.

This is a suggestion to create a new extention, that would be critical(?),
to accommodate a specific model of how to manage CAL entries.  The
specificity of this makes it hard to recommend, since there are alternative
models for ACL management.