Re: [certid] Why require EKU for certid?

[Paul Hoffman <[e-mail]>]

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. Stefan proposed a change that would require that only certs that included this EKU be considered, you said you would consider that, and I said that would be a bad change. Henry's point did not negate or support my proposal.

--Paul Hoffman, Director
--VPN Consortium