> -----Original Message----- > From: tls-bounces@xxxxxxxx [mailto:tls-bounces@xxxxxxxx] 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@xxxxxxxx; tls@xxxxxxxx > 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf