Re: [TLS] Why require EKU for certid?

[Peter Saint-Andre <[e-mail]>]

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/