Re: [TLS] [certid] Why require EKU for certid?

[Martin Rex <[e-mail]>]

Paul Hoffman wrote:
> 
>>> There should at least be a rule stating that any client that accepts the CN
>>> attribute to carry the domain name MUST also perform name constraints on
>>> this attribute using the domain name logic if name constraints is applied to
>>> the path. Failing this requirement poses a security threat if the claimed
>>> domain name in CN-ID violated the name constraints set for domain names.
> 
> Fully disagree.

I do agree with Paul that something is very wrong about this paragraph.

What it seems to request is that dNSName SAN name constraints ought
to be performed on CN-ID if server endpoint identification is
performed with CN-ID.

Since there is a requirement to use (issue) DNS-IDs in server certs,
and a requirement to ignore CN-ID when DNS-ID is present, such a
name constraints processing scheme looks awkward to me.

Name Constraints (and its processing) is something that is specified
in PKIX Internet Certificate and CRL profile (rfc-5280 and its
predecessor rfc-3280) plus some ISO-specs (btw. are these publicly
available anywhere), and that is normally implemented entirely within
the certificate path validation of the PKI software.

The BCP for server endpoint identification with TLS is something,
that according to the last sentence of section 1 of all TLS specs
is a matter of the application on top of TLS.

A CA with name constraints for DNSName SANs (required critical according
to rfc5280, mind you) in its own CA certificate that issues TLS server
certificates without dNSName SANs yields "fubar" on my scorecard.


The support of CN-IDs is "legacy" and retained for backwards
compatibility with the installed base.

Those that need the backwards compatibility will _not_ disable
the matching fallback if DNSName SANs are present, and they're
even more unlikely to adopt such a weird name constraints
processing of a fallback they shouldn't be doing in the 
first place and keep doing only to not interfere with
installed base.

-Martin