Re: [certid] Why require EKU for certid?

[Martin Rex <[e-mail]>]

Paul Hoffman wrote:
> 
> At 1:20 AM +0200 9/30/10, Stefan Santesson wrote:
> >My point is more that it is good practice to have serverAuth set when the CN
> >attribute is allowed to carry a DN.
> 
> Yes it is. However, that is irrelevant to this document. It would be
> relevant to a document saying how to create a well-formed server
> certificate for TLS.

It is my understanding that the target audience of this document
includes CAs, WebServer Admins, Sysadmins and applications on top of TLS
... however it is a little weak in clarifying to which particular
audience which particular recommendation/imperative applies.


> 
> >Absent the serverAuth EKU it is hard to programmatically be sure that the CN
> >actually contains a DNS name. Yes you can probably be pretty sure but there
> >is just a slight chance for problems due to overloaded semantics.
> 
> Even if the serverAuth EKU is set, you cannot be sure the CN actually
> contains a DNS name. The two are orthogonal.

They are independent, correct.  Server endpoint identification has been
performed by SSLv3 clients and TLS v1.0 (rfc-2246) clients based on
CN-IDs exclusively for many years.  rfc-2459 defines an EKU / KeyPurposeId
for TLS Servers and TLS clients http://tools.ietf.org/html/rfc2459#page-39
while the server endpoint identification by dNSName SANs instead of CN-IDs
appears to be first documented in rfc-2818.

Conceptually, every extension that is added to an X.509v3 certificate
further constraints its purpose/applicability (compared to not carrying
the extension).  There are small deviations for the BasicConstraints
defined in PKIX, but basically, that's it.

So a server cert with the TLS id-kp-serverAuth EKU is "limited" to
TLS server auth, not "extended" to it.  AFAIK there are also two
private OIDs from Netscape and two from Microsoft with the same
meaning as id-kp-serverAuth and id-kp-clientAuth.  And I would not
rely on clients being strict in checking TLS server EKUs...



> 
> >More importantly it has to do with name constraints processing. If you
> >accept the CN attribute as a domain name you need to make sure that it also
> >matches any name constraints set for the dNSName of the path. It is much
> >cleaner again to use the serverAuth as a mechanism for switching in this
> >logic.

EKUs primarily affect usage scenarios that are born with EKU requirements,
rather than SSL&TLS clients and servers, where the EKU situation
started as a big mess and the current status is fairly undetermined.


> 
> >Absent this check, the domain name may violate name constraints and you
> >would never know. This is the most important point.
> 
> If the TLS client is doing full certificate path validation, the
> certificate cannot violate name constraints. That is quite different
> than what you just said.

As defined by PKIX, name constraints defined for dNSName SANs do not
apply to directoryNames such as a certificate subject.

Some people are trying to artificially redefine the semantics of
name constraints to ensure business models of CAs coming preconfigured
as trusted with the software.  They're asking TLS clients for a gruesome
breach of the PKIX name constraints architecture to "protect" against
CAs from evading "dNSName SAN name constraints" imposed by their
superiorCAs by issuing server certs without dNSName SANs
(and CN-IDs instead, to which dNSName SAN name constraints do no apply).


I think it is an extremely bad idea to increase the complexity of
CN-ID server-id-check semantics, which have been deprecated 10 years ago,
by the order of a magnitude -- in particular in a BCP document,
because most of the installed base does not work that way and
a huge part of them is quite unlikely to ever adopt such weird
CN-ID semantics.


-Martin