Re: [certid] Why require EKU for certid?

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

On 9/30/10 12:36 AM, Stefan Santesson wrote:
> 
> 
> 
> 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.

Right, you are interpreting the contents of the CN as a domain name. The
question is: should the name constraints that apply to dNSName also
apply to the contents of the CN (which are conventionally interpreted as
a domain name if they have a "." somewhere in the middle)?

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

Agreed.

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

In current practice, people are treating certain kinds of strings from
the CN as domain names. Whether that is *best* current practice is
another matter. :)

Peter

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