RE: [TLS] Why require EKU for certid?

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Paul
> Hoffman
> Sent: Wednesday, September 22, 2010 9:44 AM
> To: Peter Saint-Andre; Stefan Santesson
> Cc: IETF cert-based identity; ietf@ietf.org; tls@ietf.org
> Subject: [TLS] Why require EKU for certid?
> 
> 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).
> >
> >Jeff and I are still discussing this topic and do not yet have
> >editorial agreement about how to proceed.
> 
> This is not editorial, this is definitely technical. 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.
> 
> > > 2.3
> > > It would be good if we could restrict the use of CN-ID for storing a
> > > domain name to the case when the serverAuth EKU is set. Requiring
> > > the EKU reduce the probability that the CN-ID appears to be a domain
> > > name by accident or is a domain name in the wrong context.
> 
> That makes no sense from an operational standpoint. The inclusion of an
EKU
> has nothing to do with the decision-making for the domain name location.
> 
> > > In many deployments, this also affects the name constraints
> > > processing to
> >> perform domain name constraints also on the CN attribute.
> 
> True, and irrelevant.
> 
> > > There should at least be a rule stating that any client that accepts
> > > the CN
> >> attribute to carry the domain name MUST also perform name constraints
> >> on this attribute using the domain name logic if name constraints is
> >> applied to the path. Failing this requirement poses a security threat
> >> if the claimed domain name in CN-ID violated the name constraints set
for
> domain names.
> 
> Fully disagree.

I also agree that this is not something that I would ever like to see as a
required element.  Applying name constraint logic in places that it should
not be performed is something that is very hard on any certificate
evaluation logic.

I think it would be much more an issue of "asking" CAs not to issue
certificates that have this characteristic.

Jim

> 
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls