Re: X.509 certificate and its subject name field

[Marc Branchaud <marcnarc@xxxxxxxxx>]

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


On Wed, 28 May 1997, Stephen Kent wrote:
> 
> Shyh-Wei Luan,
> 
> 	A driver's license number would be a fine DN component for a state
> issuing the cert equivalent of licenses; it need not be put in the Sub UID
> field.  Look at the SET spec and note how they handled this issue based on
> credit card numbers.
> 
> 	Still, the issue is that an arbitrary Subject UID value makes for a
> terrible ACL entry, by itself.  It creates a tremendous opportunity for
> management errors, as one cannot look at the ACL entry to figure out who is
> authorized to do what.  Instead, one must go through a (trusted) mapping
> form Subject UID to Subject name.  That is the point several of us have
> been making.
> 
> Steve
> 

On the other hand, it would be good to have an ACL entry that won't get
invalidated by changes that don't really concern the management of the
ACL-protected resource.  In that sense, UIDs make good ACL entries.

It's okay to say that name-uniqueness should be completely left to each
local CA until you start to think about CAs interoperating.  Then a CA's
uniqueness scheme has to be mapped to the schemes of the other CAs they
want to work with.  More specifically, the ACL engines have to be made
aware of the uniqueness schemes of all the CAs they rely upon.  (Remember,
an ACL shouldn't use the full DN since a DN can change for reasons that
the ACL doesn't care about.)

Clearly that's not very acceptable either.  The UID fields help by
providing a formal place where uniqueness can be found.  An ACL that
relies on specific bits of a DN might be fine when only a few CAs are
involved.  But when many CAs are involved it helps to have one standard
place to find the unique part -- the UID.  It's either that or come up
with de facto DN parts that everyone agrees to use... 

I seem to recall that the intent of these fields was to overcome
accidental re-use of a DN.  That is, if one John Smith is hired then fired
and another John Smith is hired, they had better not get assigned the same
DN.  This is obviously solved by including a unique-ifying part in the
DN, but I think the interoperability issue I described above goes beyond
that, and it may be time to revise the definition of these UID fields.

		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

iQB1AwUBM4y0LVrdFXNdDxPlAQHMogL/b7ekgwaQN3u4wRICi721/dXw/4asAhPG
bETK+2E+2dP/7SIy0SPHZePTE20udloS2pbhVVOAWJodQnDExCGO+jMp7Z7JYDWp
ebzrSyS/rGg2P70QGLEM6jxOc3anb+57
=pELH
-----END PGP SIGNATURE-----