Re: X.509 certificate and its subject name field

[Peter Williams <peter@xxxxxxxxxxxx>]

Folks may want to recall that in practical https systems deployed
today, certificate-based access control is actually keying off the
hash(cert), not any
component of the certificate. The cert fingerprint is mapped by the
authorizing party to a user account or network id, which is the subject
on the
ACL or the subject of organizational network policy controls.

The combination of likely unique subject name, likely unique public key,

likely unique serialNumber per issuer, and likely unique encoding
per certificate, means a unique fingerprint in practice (especially if
one has decided to trust the reliability of the CAs involved) and
one has a secure hash function.

I have found mainstream acceptance of this notion, which
satisifes a number of parties requirements for separation
and control between those doing naming, those doing
key certification, those doing authorization management, and
those who desire minimal infrastructural coordination yet
maximal ubiquity of the id certs.

For S/MIME protected email UA filters enforcing discretionary
access control, I can see implementations acting similarly, based on
Address
Book mappings of cert (fingerprint) to email Names.

I realise its possible to use an LDAP server as an authorization
service to similarly map certificate to subjects  (and enforce rights
management)
at the server, but its also possible just as easily to use native
OS facilities for the same thing with OS level assurances
and auditability, thereby. In any case, the architecture is
the same, and does not seem to depend upon detailed agreement
of particular certificate or name contents, or agreements between naming

or certifying providers so as to enable global discreationay access
controls.

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