On 9/22/10 10: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). >> >> 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. Sorry, by "editorial agreement" I meant consensus between the document editors about how we think it's best to address the issue that Stefan raised. Jeff and I have discussed many of the issues that have been raised, but haven't yet had a chance to discuss this one. > 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. Thanks for your input. Our little editors team will take your comments under advisement during our discussion of this open issue. :) Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf