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

[Bruce Morton]

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> On Behalf Of Dimitris Zacharopoulos (HARICA) via Servercert-wg
Sent: Tuesday, March 3, 2020 10:11 AM
To: Pedro FUENTES <pfuentes at WISEKEY.COM>
Cc: CA/B Forum Server Certificate WG Public Discussion List <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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200303/04e1301b/attachment-0001.html>