Re: [certid] Why require EKU for certid?

[Stefan Santesson <[e-mail]>]

On 10-09-30 12:24 AM, "Peter Saint-Andre" <[e-mail]> wrote:

> On 9/29/10 4:20 PM, Paul Hoffman wrote:
>> At 2:03 PM -0600 9/29/10, Peter Saint-Andre wrote:
>>> [trimming tls@ and ietf@ from cc list]
>>> 
>>> On 9/23/10 11:43 AM, Henry B. Hotz wrote:
>>>> 
>>>> On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote:
>>>> 
>>>>> At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote:
>>>>>> On 9/14/10 12:51 AM, Stefan Santesson wrote:
>>>>>>> General: I would consider stating that server certificates
>>>>>>> according to this profile either MUST or SHOULD have the
>>>>>>> serverAuth EKU set since it is allways related to the use
>>>>>>> of TSL and server authentication. At least it MUST be set
>>>>>>> when allowing checks of the CN-ID (see 2.3 below).
>>>>>> 
>>>>>> [..snip..]
>>>>> 
>>>> 
>>>>> What possible advantage is there to making certificates that do
>>>>> not have this flag set be excluded from the practices you are
>>>>> defining? That is, if a TLS client gets a certificate from a
>>>>> TLS server that the TLS server says is its authentication
>>>>> certificate, why should the client care whether or not that
>>>>> flag is set? That flag is an assertion from the CA, not from
>>>>> the server who is authenticating.
>>>> 
>>>> 
>>>> Does this point need discussion?  Without checking, I suspect
>>>> that 5280 says you obey the EKU, period.  OTOH I think Paul
>>>> raises a valid point.
>>>> 
>>>> OTOH (again) one could argue that the EKU provides a way to
>>>> prevent a stolen cert/key issued to the machine for a different
>>>> function from being repurposed to support a fake server.  (I'm
>>>> not convinced this is significant, but it's something.)
>>>> 
>>>> Absent discussion and consensus, I vote for whatever 5280 says,
>>>> which I suppose is what the current silence on the topic equates
>>>> to.
>>> 
>>> This I-D shall never be taken to override anything in RFC 5280 or
>>> any other normatively-referenced specification on which it depends.
>>> If folks think we need a blanket statement to that effect, please
>>> let us know. Version -10 will have a new section containing an
>>> applicability statement, which starts as follows:
>>> 
>>> This document does not supersede the rules for certificate
>>> validation provided in [RFC5280].
>>> 
>>> But we can always add a stronger statement if need be.
>> 
>> This misses the point I made when I started this thread.
> 
> That's because I was replying only to the small item of whether the
> server-id-check can be taken to override RFC 5280.
> 
>> Stefan
>> proposed a change that would require that only certs that included
>> this EKU be considered, you said you would consider that,
> 
> I think I said only that Jeff and I hadn't discussed it yet. It's still
> on our todo list.
> 
>> and I said
>> that would be a bad change. Henry's point did not negate or support
>> my proposal.
> 
> My sense of the discussion so far is that there's no strong agreement to
> accept the proposal that Stefan made.
> 

My point is more that it is good practice to have serverAuth set when the CN
attribute is allowed to carry a DN.

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.

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.

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.

Absent this check, the domain name may violate name constraints and you
would never know. This is the most important point.

/Stefan