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

[Ryan Sleevi]

I would be happy to draft a ballot to clarify this, but I believe Pedro's
answer is far closer to what we (Google) expects than those answers offered
by Bruce and Dimitris.

At the very heart of the differing interpretations is this:
- Do the BRs apply to what a CA in-scope can issue/sign; or
- Do the BRs apply to what is issued/signed?

I'm not sure if that distinction is immediately obvious, so I think a more
practical example would be to set aside nameConstraints for a second, to
think about something much more obviously problematic: SHA-1 issuance.

Is the prohibition on SHA-1 end-entity certificates a prohibition on how
the Subordinate CA Certificate uses its private key, or is it a prohibition
on the certificate profile for in-scope end-entity certificates? That is,
if I use an id-kp-serverAuth-capable sub-CA to issue a certificate that
does not contain id-kp-serverAuth (for example, perhaps my subCA has
anyExtendedKeyUsage, and the end-entity cert has id-kp-emailProtection)?

It should be obvious that the security risks that exist are there because
of the /use/ of the private key. The prohibition on the use of SHA-1 thus
applies, transitively, to everything that Sub-CA issues, even if the
end-entity certificate might be ostensibly considered out of scope. This is
because the risk is transitive; the "not-TLS" certificate might be used to
forge a "like-TLS" certificate.

Now, with this in mind, let's swing back to nameConstraints. The question
at play here is not whether or not the technically-constrained sub-CA is in
scope. The question is with regards to the issuer. Can the issuer use their
private key to sign arbitrary "somethings"? In this case, something that
does not comply with RFC 5280, which requires critical nameConstraints. As
mentioned, the reason it requires critical nameConstraints is to prevent
security issues: it's intentional to break clients that don't understand
why or how a CA is restricted.

Pedro's answer focuses, correctly, on the fact that the issuer of said
constrained certificate *is* in scope of the BRs, and absolutely should not
be signing things that don't conform with RFC 5280. Or, more succinctly, it
applies a "default deny" interpretation: unless there is clear permission
to sign some deviant cert, it cannot be signed.

Bruce and Dimitris' answer seems to focus on the certificate that is
issued, which, just like in the case of SHA-1, is focusing on the result,
not the action. This is applying a "default allow" permission - if the BRs
don't say you can ONLY sign conforming things, it's perfectly fine to sign
non-conforming things.

This isn't a new discussion; for example, see Peter Bowen's excellent
discussion at https://cabforum.org/pipermail/public/2016-April/007237.html
 or https://cabforum.org/pipermail/public/2016-November/008966.html which
tried to tackle this as well.

If folks recall, although it may not have been clear as to why, this was
also discussed in the context of Ballot SC23. One of the suggested paths,
which would have resolved this ambiguity, was to be explicit about the use
of a CA's private key, what it's permitted to sign, and what the
expectations are of the things it signs.

As I mentioned, I'm happy to draft a ballot if CAs feel this is ambiguous.
The requirements of both Mozilla and Microsoft policy (to use separate
intermediates for different scopes of certificates) means that this issue
is, or should be, only an issue for Root CA Certificates, and possibly
Sub-CAs that are (cross-organizational, doppelgangered to a root) Cross
Certificates. However, that's exactly where security is most critical, and
making sure the root private key is only used to sign Acceptable Things is
essential, if that Root is going to be trusted for multiple purposes.

This is, of course, largely moot if folks ensure their Root is only trusted
for TLS, and use a separate Root for other uses. While we would still
substantially benefit from such clarity, there would be no way for a CA to
argue a given thing-signed is somehow outside of the scope of the audit.

On Tue, Mar 3, 2020 at 11:10 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg <servercert-wg at cabforum.org> wrote:

> 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>
> <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> <pfuentes at WISEKEY.COM>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org> <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> 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.
>
>
>
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200303/7efeafda/attachment-0001.html>