Re: X.509 certificate and its subject name field

[dpkemp@xxxxxxxxxxxxxx (David P. Kemp)]

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


> From: "Shyh-Wei Luan" <luan@almaden.ibm.com>
> Date: Mon, 9 Jun 1997 14:52:21 -0700
> To: D.Pinkas@frcl.bull.fr, "David P. Kemp" <dpkemp@missi.ncsc.mil>
> 
> On Jun 9, 12:03pm, Denis Pinkas wrote:
> >
> > > But if you allow CA
> > > certs to have SUID fields, you get into "UID subordination rules",
> > > blah blah blah, the entire naming discussion all over again.
> 
> To David: I don't understand what you mean by "UID subordination rules" and
> the blah blah blah.  Why does one need to be subordinated to any other?
> It will be a chain of identities uniquely identified by SUIDs and annotated
> by names.
> 
> I bet that you are aware of Rivest and Lampson's SDSI.  What do you think of
> that???


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.  Businesses can keep whatever databases on customers they want,
maintained by whatever practices they feel are appropriate, without
requiring that information to be included in certificates.  If a DN
happens to be included in the customer database, fine, but if it is not
used in the access control decision, it is not germaine to the
discussion.

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

Alternatively, you could manage SUIDs across CAs in the same manner
that DNs are managed - by allowing CA's to certify only a subset of the
namespace.  One way of carving up the namespace is strictly by
heirarchy, again requiring names to be linked to the CA structure
(although not requiring strict topological equivalence), using
subordination rules. Another way of carving up the namespace is by
naming authority, using Name Constraints, which allows the naming and
certification functions to be separated.

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.

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



> > This is the reason why I limited the proposal to leaf certificates ...
> > until someone can find a story which is acceptable. I anticipate that no
> > one will be able to propose such a story .  :-)
> 
> To Denis:  I don't know what kind of "story" you would qualify as an
> acceptable "story". The shortage of desirable business/CA names will
> be a problem. Don't we agree?
> 
> Shyh-Wei


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

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