X.509, SSL & security of decentalized certification (RE: RSA getting rid of trusted third parties?)

[RL 'Bob' Morgan]

On Mon, 24 Jun 2002, Amir Herzberg wrote:

> This is not as simple as one may expect. X.509 has a hierarchy mechanism
> designed for allowing organizations issue (or at least control)
> certificates of departments and employees - the Distinguished Name (DN)
> and its keywords. However, browsers normally identify the server by its
> DNS name, which is usually included in the dNSName attribute in the
> subjectAltName extension, rather than in the X.509 DN. DNS names do not
> have a completely well defined structure, which makes it difficult to
> limit the organization's CA to issuing certs only to its employees and
> departments (e.g. would IBM's CA be able to issue certs for
> www.ibm.co.uk ?).

As Eric noted, despite the addition of subjectAltName to X509v3 many years
ago precisely so that Internet-style DNS-based names could be used instead
of those funky X.500 DNs, in fact subjectAltName (and issuerAltName, even
more, or less, so) have traditionally hardly ever been used by the public
CAs, or anyone else for that matter, as far as I can tell.  Look in SSL
certs you get from webservers and see.  The DNS host name is almost always
in the CN attribute of the Subject DN, which typically has O and OU
attributes also, and may or may not have location-based C, L, ST etc
attributes.

Note that this mixing makes things far worse.  What are the expressable
name constraints on a DN, one of whose components has a value that is a
DNS name?  If DNS-based altNames were used, name constraints would be much
easier (not easy, but easier).

> Anyway, the validation is up to the browser - it is _not_ part of the
> SSL/TLS functionality.

Well, if an implementation of SSL/TLS is intended to be compliant with the
relevant ITU and IETF standards, then it has to implement name constraints
as described in those standards, which includes precisely the validation
we're talking about here.  So it is certainly part of the specified
certificate validation functionality.  Whether it is so in practice is
another story.

> Furthermore, while X.509 and PKIX have mechanisms to allow a root CA to
> restrict the scope of certificates issued by a root CA, these mechanisms
> seem to focus on restricting the distinguished names in the issued
> certificates, rather than the subjectAltName (and in particular the DNS
> name).

I don't know why you say this.  The relevant section of RFC 3280
says, among other things:

   4.2.1.11  Name Constraints

   The name constraints extension, which MUST be used only in a CA
   certificate, indicates a name space within which all subject names in
   subsequent certificates in a certification path MUST be located.
   Restrictions apply to the subject distinguished name and apply to
   subject alternative names.

The section then goes on to give numerous examples of DNS-style
constraints.

> So my bet is that all or most browsers will not reject certificates with
> arbitrary DNS names issues by a corporation with a CA certified by RSA
> (or any other root CA).

I agree, but not because the technology is unspecified, but because it is
inherently extremely complicated.  Anyone putting name constraints into a
cert today would be taking a huge risk of that cert failing to work at all
on the deployed base of browsers and other verifiers.  Name constraints
won't be exercised until cert issuers start putting them into certs.
Chicken and egg.

> The problem here is not with the decentralized certification, IMHO; the
> problem is with the overly simplistic view of trust. The relying parties
> (e.g. browsers) should have tools that map each issuer of certificates
> to a `role` defining what it is trusted for. There have been lots of
> research in this direction (including a bit of my own) but it was not
> yet deployed in mainstream products such as browsers and web servers.

This is undoubtedly true, but at least for the near term this makes a
complex problem even more complex (what's a "role"?  who defines them?),
not less so.

 - RL "Bob"



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com