Re: X.509 certificate and its subject name field

["Shyh-Wei Luan" <luan@xxxxxxxxxxxxxxx>]

On May 29,  6:08pm, Stephen Kent wrote:

> >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.

I think there is finally some convergence in our views. ;-)  I agree that
Subject UID would not always be the basis for granting accesses.  That is why I
mentioned in my recent summary posting that the basis of access might also be
the patterns and attributes in the names.  This is more like a role or function
based access control.  But I believe there will be a lot cases where the
identity (not his or her role) of the individual will be the basis of the
access control.  For example, the acessses to my personel data inside the
company or my professional subscriptions outside the company.

Including a DN with a UID component as an ACL entry is bad for both the
identity-based and role-based access controls, because you need to change
ACL's for both types of access controls when you change your role or name.
Say, if (IBM/Research/Almaden/Shyh-Wei Luan,123456) is on the ACL's for
some IBM Almaden's database and Usenix on-line publication library, then
both ACL's need to be changed either when I change to use an English name
or when I change a department.  The root of the problem is the ACL's included
more information than necessary.  An ACL should not include the full DN when it
is identity based, and it should not include the SUID when it is role based.

> Finally, the example ACL entries you provided were both incomplete.

I thought it should be obvious that the examples were just depicted enough to
make my points.

>  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.

I think I have made it clear in numerous examples that I give, that the context
of CA's (I usually call it a CA path or a certification path) is important
and should be a part of the ACL entries.  I are in violent agreement here
again, interestingly. ;-)

> Your latter example (based on SUIDs)
> oversimplifies by referring to the CA by a name that is too short,

Are you nitpicking me on not using an X.500 DN name? :-)

>  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.

As I said, I believe ACL's based on patterns/attributes of names are also
useful.  But when it comes to the cases where the access is based on the
Subject identity, it is better to use a persistent ID.

> 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.

Shyh-Wei