Re: [certid] Why require EKU for certid?

[Peter Saint-Andre <[e-mail]>]

On 9/29/10 9:24 PM, Martin Rex wrote:
> Paul Hoffman wrote:
>>
>> At 1:20 AM +0200 9/30/10, Stefan Santesson wrote:
>>
>>> 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.

Agreed.

As I see it, the Common Name is just a series of characters. Sometimes
that series happens to contain one or more instances of the "."
character, arrayed in a way that leads people to interpret the series of
characters as a DNS domain name. That doesn't mean that it's sensible to
take the PKIX name constraints that have been defined for the dNSName
SAN and apply those constraints to a series of characters that happens
to look like and be interpreted as a DNS domain name.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/