Re: X.509 certificate and its subject name field

[Marc Branchaud <marcnarc@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 29 May 1997, Stephen Kent wrote:
> 
> 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.
> 

You're absolutely right -- I don't have anything very substantial to
support my claim.  I would welcome evidence to the contrary, but if no
such evidence exists then perhaps the matter merits deeper investigation. 
In any case, I'm basing the claim on comments by Shyh-Wei Luan regarding
possible DN changes during company reorganizations & mergers.  Nobody
seemed to disagree with that, so I worked with it.  As I've just stated in
my reply to Warwick Ford's message, my knowledge of X.500 isn't as good as
it could be.

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

But my whole premise is that we shouldn't base ACL entries on entire
DNs...

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

A good point.  Obviously, I am talking about cases when individuals are
specifically authorized.  It may very well be that the problem doesn't
arise often enough to be an issue, but it's best to be sure about that.

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

You're right about that.  If individual-level authorizations are the basis
for only a small minority of ACLs, then the issue isn't really worth
worrying about.  But I'm not yet convinced that this is the case.  Even if
it is, if an easy solution presents itself (not necessarily what I've
proposed) why not adopt it?

		Marc

- ---------------------------------------------------------------
Marc Branchaud, Chief PKI Designer

Xcert Software Inc.
1001-701 West Georgia Street         
P.O. Box 10145, Pacific Centre          tel:     1-604-640-6210
Vancouver, B.C., Canada V7Y 1C6         fax:     1-604-640-6220
http://www.xcert.com                  email: marcnarc@xcert.com
           Internet Security Technologies 
Press coverage - http://www.xcert.com/corp/clippings/index.html
- ---------------------------------------------------------------


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQB1AwUBM43o3lrdFXNdDxPlAQGNJgMAtKCBL4VyuImIn/cG6PG1R51C4sRwCfQ6
UUrRg/7mHiupX7GJ91ZjmAGn6iUTmqc2j7J31C/w81FfM4Evs9tVnLH8KBKm6aKB
+AY4FefNmlxJN9IBJ27BG7XNCzmPH5cV
=kw3C
-----END PGP SIGNATURE-----