Richard Ankey wrote (6 Apr 1994):
Using the Subject UID field to identify a certificate (v. the
subject/user) will likely break the 1993 X.500 ACL mechanism, which
assumes some semantics of the UID, i.e. it distinguishes multiple
(serial) reuse of a DN. ACLs identify a user by the <DN/optional
UID> combination. I would suggest we take a closer look at
X.501/X.511 (93) before going too far in this direction...
Sorry, but I have to disagree. I maintain that no use of an UID will disturb
the X.500 (93) Access Control Mechanism, as far as you use the UID encoded as
an ASN.1/BER BIT STRING. The semantics that X.500 assumes upon an UID is that
of an unique sequence of bits for a given DN, so if you can ensure this
uniqueness in one way or the other, you are compliant with X.500.
Who is the responsible for uniquely assigning identifiers to name instances?
From my understanding, it is up to the entity that reuses a name who has to
(optionally) assign an UID to the new instance of name reuse. For example: if
a name authority reuses a DN for a different user, then it also assigns an
UID. If multiple certification authorities issues the same user with
different certificates, they are reusing its DN in different objects, i.e.
certificates, then they assign UIDs to this DN for each object. If a
certification authority issues multiple certificates to the same user, it
also assigns different UIDs for each one.
This makes sense in X.500 Access Control Mechanism, since (as far as I
understood the documents) the only way to have a DN with an UID is by means
of a certificate. On the other hand, X.500 access control decision functions
evaluate an UID, if and only if, the access control item contains a DN/UID
pair. So, access to the item will only be granted if the user uses strong
authentication. Moreover, the matching between the stored UID and the
presented UID is made in a bitwise basis, without regarding contents,
semantics, ... The way you generate an UID does not matter if you put it as a
BIT STRING into a certificate.
Regards,
Francisco