Re: [certid] Why require EKU for certid?

[Stefan Santesson <[e-mail]>]

On 10-09-30 2:13 AM, "Paul Hoffman" <[e-mail]> 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.
> 
>> 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.
> 

You are correct. But IF you accept the domain name from the CN attribute and
the serverAuth, you do at least know that the certificate is issued to a TLS
server endpoint. It thus holds the name of a TLS server.

>> ServerAuth provides a much cleaner indication than parsing the CN attribute
>> only. I see potential security problems if a CA allows you to for example
>> set your CN as a friendly name while other attributes such as givenName and
>> SureName are checked against your registered name. The friendly name may be
>> hard to check as it may differ from your registered name (ex Tim Polk).
>> Thus some not so careful implementation may have poor checks and allow you
>> to choose a domain name as your friendly name. This certificate may never be
>> intended to be used for server authentication, but following the rules of
>> the draft this certificate now allows spoofing and you would never detect
>> that.
> 
> See both points above.
> 
See point above.

You can't possibly mean that the risk of spoofing is the same regardless of
whether serverAuth is checked.

>> 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.
> 
> Then there should be a PKIX document saying this. It is not relevant to a
> document that tells how to match a domain name the client has in its left hand
> against the identities in the cert it holds in its right hand.
> 

AFAIK there is no PKIX document supporting the use of CN to carry a domain
name. This is a non standard practice.

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

That is just a game with words Paul. Of course the certificate does not
violate name constraints. It is the USE of the certificate that violates the
name constraints of the path.

CA-X in the path has stated "You can only rely on this CA certificate to
validate claims about domain names within the example.com namespace"

If the end certificate holds the domain name "foo.com" in the CN, But no
dNSName SAN, and you accept this claim then you are in fact trusting the
CA-X certificate beyond its declared scope.


This document is about best current practice right?

I'm not an advocate for hopelessly rigid requirements and I do respect
legacy. But I think it is reasonable to at least recommend clients to check
any domain name against dNSName name constraints regardless of what
attribute they pulled that information from. I also think it would be good
practice to not blindly accept domain names from any attribute unless you
have some indication that it is likely to hold a domain name.

A large percentage of installed TLS clients perform these checks, so it is
not taken from nowhere.

I don't think we can create perfect, but we could limit the risks with
reasonable recommendations.

/Stefan