Re: [certid] Why require EKU for certid?

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

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.

Peter

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