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

Tue Mar 3 09:09:23 MST 2020

Hello,
As I’m a newcomer here, I won’t dare challenging more informed opinions, and I’d actually I see that my statement was too assertive, so sorry about it if I sounded arrogant.

My rational, and how stating clearly that is “in my humble opinion”, is that the BR sets requirements to the certificates issued by a CA that is in scope of a BR audit, that’s why I think that the BR would apply to the subordinate CA certificate, because it’s issued by an Issuing CA that is in scope of the BR, despite the fact that the subordinate could issue end-entity certificates that are out of the scope of the BR.

Actually we also have the case of certificate suspension, that ends up by being disallowed for the full hierarchy under a Root in scope of BR, independently of the EKU of the end-entity… which is something I consider disproportionate, but it was clarified in other discussions that is the case.

I’ll be happy to get a better understanding on this issue….

Thanks,
Pedro 

> El 3 mar 2020, a las 16:43, Bruce Morton <Bruce.Morton at entrustdatacard.com> escribió:
> 
> Hi Dimitris,
>  
> I think that we have determined that the scope is based on the EKU(s) which are in the end entity certificates. If there is no EKU, then all scope would apply based on what the root is trusted for. We also have requirements in the BRs and from Mozilla, where we are not allowed to mix specific EKU values. I assume that this is in place, so that we will not have a certificate, which is meeting multiple and potentially conflicting policies.
>  
> So I agree, that if the only EKU in the certificate is for Code Signing, then the (SSL) BR requirements do not directly apply.
>  
> Bruce.
>  
> From: Servercert-wg <servercert-wg-bounces at cabforum.org <mailto:servercert-wg-bounces at cabforum.org>> On Behalf Of Dimitris Zacharopoulos (HARICA) via Servercert-wg
> Sent: Tuesday, March 3, 2020 10:11 AM
> To: Pedro FUENTES <pfuentes at WISEKEY.COM <mailto:pfuentes at WISEKEY.COM>>
> Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>>
> Subject: [EXTERNAL]Re: [Servercert-wg] Critical Name Constraints (Was: Re: Question on BR 3.2.2.6)
>  
> WARNING: This email originated outside of Entrust Datacard.
> DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
>  
> 
> On 2020-03-03 2:42 μ.μ., Pedro FUENTES wrote:
> 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.
> 
> 
> I would like to ask other members if this interpretation is accurate. If the CA Certificate is out of scope of the BRs (i.e. not technically capable of issuing TLS Certificates), I believe it does not need to comply with the BRs. For example, if we create -say- a code-signing CA, the CA Certificate Profile described in 7.1.2.2 and 7.1.4.3.1 do not apply. This is my understanding after following many discussions and conversations in the Forum and SCWG over the last couple of years.
> 
> 
> Thanks,
> Dimitris.
> 
> 
> 
> 
>  
>  
> 
> 
> El 3 mar 2020, a las 10:10, Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr <mailto: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.

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/50552180/attachment-0001.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/50552180/attachment-0001.p7s>