Re: [certid] Why require EKU for certid?

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

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

Peter

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