[Servercert-wg] Critical Name Constraints (Was: Re: Question on BR 3.2.2.6)

[Dimitris Zacharopoulos (HARICA)]

On 3/3/2020 10:36 π.μ., Pedro FUENTES wrote:
> Hello,
>
> On my side… I’d be keen to align with #2, as I think it’s the way to 
> go, but for that we’d need some objective data to assess the impact 
> and be sure we aren’t shooting in our foot… Do we have any idea of 
> what software nowadays would reject certificates or would malfunction 
> if we enforce the critical thing?
>

Hello Pedro,

One of the purposes of this thread is to collect some objective data to 
assess the impact :-) If you have evidence to share about TLS 
Certificate Issuing CAs, it would be very helpful.


> Just as a side comment… In our case, we mostly used name constraints 
> for subordinates intended for "S/MIME certificates" (in reality this 
> means "personal certificates used for authentication, digital 
> signature and secure email", but let’s go for the over-simplified term 
> “S/MIME Certificates” I see it’s used in the Forum) so assuming a rule 
> that is only considering “the webPKI” is maybe not something 
> appropriate. We must see interoperability as a whole as these 
> decisions won't only impact TLS certs, because this rule of the BR 
> applies to all subordinates, not only the ones having the serverAuth EKU.
>
> Best,
> Pedro



I don't think conflating S/MIME with serverAuth is useful for this 
thread. According to several Root programs, you should not include 
emailProtection and serverAuth Extended Key Usages in the same Issuing 
CA. Also, please remember that this Working Group does not discuss 
issues related to S/MIME Certificates.

It would help if you have been using name constraints for serverAuth 
Issuing CAs and share your experience with legacy software.


Thanks,
Dimitris.