Re: X.509 certificate and its subject name field

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

On Jun 10,  9:49am, David P. Kemp wrote:

> Perhaps this is of general interest, so we return to the list ...

This is certainly a good idea.

> Forget about "annotated by names" - that's just a red herring.  Your
> access control decisions will be based on some information.  That
> information either includes something other than the SUID or it does
> not.

So, let's also forget about "user and group names" in Unix, that's just a
red herring.  Your access control deceisions will be based on some information.
That information either includes something other than the uid/gid or it does
not.  :-)

> So, if you are going to base decisions on SUIDs, those SUIDs need to be
> allocated in some manner.  You have proposed that they not be managed
> across CA's, i.e. not be required to be unique.  Therefore the Access
> Control List must maintain the entire path of SUIDs from the trusted
> ("root") CA down through the subject's SUID.  Therefore the SUID path
> is required to be topologically equivalent to the certification path,

The SUID path *is* the certification path.

> i.e.  you cannot separate naming authorities from certification
> authorities.

> That is the SDSI model - a subject is named by an entire path: "Fred's
> Bob's Alice's Denis' Shyh-Wei", which may or may not be the same person
> as "Fred's Mike's John's Dave's Shyh-Wei".

I would more likely see something like "Department of Commerce's IBM" or
"California DMV's Shyh-Wei".   PC's in the future might have built-in
public keys of Department of Commerce, DMV's, and other well-known CA's.

> If you are happy with purely local, SDSI-type, names for your subjects,
> then put those names in the DN, not in a separate SUID field, and base
> your ACL identity on a path of DNs.  But you can't have your cake and eat it
> too - if you aren't going to manage the namespace across CAs, you'll
> have to use the full SDSI name-path in your ACLs, whether the relevant
> name is contained in the DN field or the SUID field.

Do I have to use my name in UNIX file owner uid/gid filed?  Can't
I use the uid/gid for access checking and use the name (the cake) for
displaying owner and group names?

> Above all, you can't claim the simplicity of local SUIDs and then turn
> around and wave your hands and claim the advantages of managed DNs
> on the grounds that "DNs are available as annotation".

Why not???

> How does using the SUID field address any hypothetical shortage of
> CA names?

You may be able to register your business today with Department of Commerce
as "Dave Kemp Enterprises".  Then you start doing businesses with a lot of
places and "Dave Kemp Enterprises" gets on the ACL's or identity databases
all around the world.   Assume that the company goes out of business
in December.  Then, Department of Commerce cannot register anyone else as
the "Dave Kemp Enterprises", because the new party might be gaining accesses
that belonged to you.   Dave, please be fair with future "Dave Kemp's",
will you? :-)

If you are registered with Department of Commerce as SUID 19970001 today, then
some other successful Dave Kemp can register as 20070001 10 years later,
because the ACL's won't inadvetantly grant your accesses to SUID 20070001.

> If you assume that IBM goes out of business this year, and next year
> Dave Kemp Enterprises wants to issue certs under the name "ibm.com",
> those two IBMs have to be kept separate in some manner.

I believe there are tons of "going-nowhere" companies/enterprises out there.
I would not assume IBM is one of them. ;-)

> Assuming for
> a moment that the lawyers and the PTO agree to allow reuse of the
> IBM name,
>
>   "..., CN=ibm.com" and SUID=1
>
> seems no more effective at designating the real IBM in a name reuse
> scenario than does
>
>   "..., CN=ibm.com + SN=1"
>
>
> What precisely is the advantage of SUIDs over unique terminal RDN's?

advantages:

(1) explicitness in what field is going to be persistent and temporally unique
(2) DN's do not need to be persistent and temporally unique and can be simpler
(3) the SUID scheme is not tied to the X500-type of names

Shyh-Wei