[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] [certid] Why require EKU for certid?
From:       "Henry B. Hotz" <hotz () jpl ! nasa ! gov>
Date:       2010-09-23 17:43:50
Message-ID: 76232140-6713-416F-8758-8042A82B8857 () jpl ! nasa ! gov
[Download RAW message or body]

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.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu


[prev in list] [next in list] [prev in thread] [next in thread]