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

[Pedro FUENTES]

Hi Dimitris,

Just to clarify that what I said is that the decision can’t be taken only considering serverAuth, because this requirement applies to every subordinate CA issued under a Root that undergoes BR compliance. 

To be clear: a SubCA that only has emailProtection, but that is issued by a Root that needs to be compliant with BR, will need to have the nameConstraints extension set as critical or not depending of the BR mandate, as in other case the Root won’t be compliant with BR.

So even if this WG is not for S/MIME, the decision must be taken considering the impact in other scopes that “the WebPKI”.

Best,
Pedro

PS Personally I can’t give more information on interoperability issues. We had issues in the past with Apple software, but it seems that it's already solved.



> El 3 mar 2020, a las 10:10, Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr> escribió:
> 
> 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.
> 
> 

WISeKey SA
Pedro Fuentes
CSO - PM eSecurity Solutions
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790
Address: 29, Rte de Pré-Bois - CP 853 | Geneva 1215 CH - Switzerland
Stay connected with WISeKey <http://www.wisekey.com/>

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200303/61d41cf8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2498 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200303/61d41cf8/attachment.p7s>