[Servercert-wg] [EXTERNAL]Re: Critical Name Constraints (Was: Re: Question on BR 3.2.2.6)
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Wed Mar 4 08:35:45 MST 2020
You have added a lot of context to your reply. I've made an honest
attempt to answer most of your points to the best of my
knowledge/understanding.
On 2020-03-03 6:54 μ.μ., Ryan Sleevi wrote:
> 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?
My understanding all these years is that other sections of the BRs are
more related to the former and others to the latter. For example, the
end-entity Certificate Profiles are related to CAs in-scope. This means
that if a CA is technically capable of issuing a TLS Certificate, it
must follow all the end-entity Certificate Profile requirements. A Root
CA that is participating in a TLS hierarchy is definitely in scope of
the BRs (we even made an update to 6.1.7 to ensure Root Keys are not
used to sign time-stamping certificates). Once a Root signs a CA that is
not technically capable of issuing TLS Certificates, then in my
understanding that subCA is out of BRs scope. Of course, the Root still
needs to provide CRLs, OCSP services according to the BRs.
>
> 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.
The SHA-1 example has been used in several discussions related to
interpretation or applicability of the BRs. Of course anything that adds
"risk" and possible impact on TLS-capable CAs and TLS end-entity
Certificates must be followed. Section 6.1.5 must be met by the Root CA
Certificates signing new Subordinate CA Certificates. The same applies
for CA Key Generation as described in 6.1.1 because we don't know if the
resulting certificate will be in scope of the BRs or not.
But 7.1.2.2.g is very focused on Subordinate CA Certificates that are
technically capable of issuing TLS Certificates. If a CA wanted to
create an emailProtection-only Subordinate CA from a Root that is
trusted in a Root Program for TLS and S/MIME, with the "default-deny"
interpretation it would be impossible. Therefore, perhaps this is
another issue to add to the list of things to clarify in the
default-allow/deny discussion.
Once an out-of-BRs-scope subCA is created (e.g. one that contains an EKU
with only id-kp-codesigning), I hope you can agree with me and Bruce
that this subCA can sign end-entity Certificates that don't meet the BRs.
>
> 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.
>
I understand your point. The SHA-1 case is crystal clear as described in
7.1.3 so a compliant Root or Intermediate cannot issue a Subordinate CA
Certificate using the SHA-1 hash algorithm. In any case, I think we need
to find the appropriate balance and language to allow BR-compliant Root
CAs to create Subordinate CA Certificates that meet a slightly different
CA Certificate Profile for non-TLS usage.
> 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.
I agree we should try to reasonably define what these "Acceptable
Things" look like.
>
> 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.
The current practice used by several CAs is to have a single trust
anchor (Root CA) that issues subordinate CAs for different purposes
(TLS, S/MIME, Code Signing, Time-stamping, docSigning, etc).
Historically some Root Programs have advised against adding multiple
Root CA Certificates in their Root store.
The benefits of completely separate, distinct, hierarchies are very
clear in terms of compliance enforcement. However, it is extremely
difficult to achieve this separation with the various Root Programs and
the time it takes to process Root inclusion requests. The ubiquity
problem is also very real, so we would be looking at a long-term
transition if we were to follow that route. Perhaps it would be worth
discussing and see how supportive the various Root Programs would be to
such a change, and also examine possible unexpected consequences in
separating those hierarchies.
Trust anchor stores would increase significantly for sure :-)
Dimitris.
>
> On Tue, Mar 3, 2020 at 11:10 AM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg <servercert-wg at cabforum.org
> <mailto: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>
>> <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.
>>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org <mailto: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/20200304/bf6b3848/attachment-0001.html>
More information about the Servercert-wg
mailing list