Re: X.509 certificate and its subject name field

[Marc Branchaud <marcnarc@xxxxxxxxx>]

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


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.

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.

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.

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. 

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.

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


On Wed, 28 May 1997, Stephen Kent wrote:
> 
> Marc,
> 
> I'm very puzzled by some of your comments:
> 
> 	- 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.
> 
> 	- if you don't put the whole DN in the ACL entry, then you are not
> ensured of uniqueness, since no sequence of RDNs is guaranteed to be
> unique, at least not in an open system.  duplicate RDNs may well arise
> under different CAs, so it would seem imprudent to use them as ACL entries.
> 
> 	- if it's an open system, and you are creating ACL entries for
> users under the auspices of other CAs, then you must be prepared to have
> these CAs use various attributes and naming schema for the DNs, which will
> affect the ACL code
> 
> 	- the Subject UID field is OPTIONAL in the X.509 v2/3 specs.   an
> open system, basing an ACL design on them, irrespective of the management
> vulnerabilities I alluded to earlier, seems inconsistent with the status of
> these fields as OPTIONAL.
> 
> Base on these observations, I'm not sure I understand how interoperability
> is enhanced by the proposed use of Subject UIDs.
> 

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

iQB1AwUBM4zIe1rdFXNdDxPlAQGlCQL+LIh0jz8sNuAg+ovaawU9Owxl+NH6FL7b
OFTXN0MpycVUv/5hl3dwXgEWbo3HX4Nnlq5ea8vweZ5nPruP/YJpM+D4EVMjvqUP
YuuIm80loPr2M0ESsodI4JnbluHBcLmq
=4AkK
-----END PGP SIGNATURE-----