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

Tue Mar 3 09:09:50 MST 2020

Thanks Bruce,

Similarly with the code signing CA example, the same should apply for a 
subCA that only has an EKU of id-kp-emailProtection.

Dimitris.

On 2020-03-03 5:43 μ.μ., Bruce Morton wrote:
>
> 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/2a575954/attachment.html>