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. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf