Technically Constrained Sub-CAs and the BRs

[Ryan Sleevi]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1311200 , Kathleen suggested I bring the broader discussion to mozilla.dev.security.policy, so this is that thread.

At present, there's an element of inconsistency between the BRs and Mozilla Policy that leads to some confusion.

With respect to Mozilla's current policies, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ :
8. All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited.

This wording implies that technically constrained sub-CAs, from a Mozilla Policy standpoint, are not required to adhere to the Baseline Requirements.

However, the Baseline Requirements have a different set of criteria. In Section 8.1 of the BRs (v1.4.1, https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf ), it states:
Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with section 7.1.5 and audited in line with section 8.7 only, or Unconstrained and fully audited in line with all remaining requirements from this section

Section 8.7 reads:
During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CA’s Certificate Policy and the Subordinate CA’s Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA shall ensure all applicable CP are met.


That is, according to the BRs, the issuer of a technically constrained subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to the BRs and the issuing CA's policies and practices, as well as conduct a sampling audit quarterly.

The element of inconsistency is what the expectations of Mozilla are, if the issuing CA, which has a BR obligation to monitor their TCSCs, and which Mozilla expects to adhere to the BRs, does not perform this task, and the TCSC does not adhere to the issuing CA's (which is subject to Mozilla's requirements) policy.

On one hand, this is a BR violation by the issuing CA, and Mozilla nominally cares about BR violations for CAs subject to its requirements. On the other hand, the root cause is due to a TCSC, for which Mozilla policy explicitly carves out.

Given that the issuing CA may be subjected to a qualified audit finding, on the basis of the the actions of the TCSC, it may be useful to understand Mozilla's position on this, as well as determine what guidance, if any, should be provided to auditors and to the CA/Browser Forum about this apparent disagreement between Mozilla Policy and the Baseline Requirements.

[Kurt Roeckx]

On Tue, Oct 25, 2016 at 12:12:47PM -0700, Ryan Sleevi wrote:
> That is, according to the BRs, the issuer of a technically constrained subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to the BRs and the issuing CA's policies and practices, as well as conduct a sampling audit quarterly.

My expection of this is that the CA (CA1) that issued such a
constrained CA (CA2) is responsible for auditing CA2. when CA is
then audited, part of that audit is that they check that the
audits of CA2 have been done.


Kurt

[Ryan Sleevi]

That is what the BRs state, and what would potentially lead to a qualified audit of the unconstrained CA1 if it failed to check the controls of CA2.

However, what is the expectation of Mozilla when they encounter such a qualified audit for CA1? If CA2 - the constrained sub-CA - is known to be failing its BR obligations, then correspondingly CA1 will be failing its BR obligations (potentially) for failing to address this. However, Mozilla does not require CA2 to follow the BRs, as presently stated in policy.

The linked bug is a concrete example, where an unconstrained sub-CA was revoked, due to non-compliance with the BRs, but has now been cross-certified as a constrained sub-CA. All of these non-BR compliant certificates are now valid, by utilizing the technically constrained path. From a Mozilla policy, what are the implications of this new cross-certified constrained sub-CA?

Perhaps most material to this discussion is a consideration about technically constrained sub-CAs and problematic practices. Can a TCSC engage in problematic practices, which thus cause issues for Mozilla clients or introduce the need to support legacy/improper encodings?

A very concrete example of the implications of this relate to SHA-1 certificates. If, prior to Dec 31, 2015, CAs had issued some N-million TCSCs, signed with SHA-1, to all parties that wished to keep issuing SHA-1, could these TCSCs have continued issuing SHA-1 certificates without violating the Mozilla requirements? One interpretation is that yes, they could have, at least from Mozilla policy. However, from the BRs, the answer is that no, they couldn't have.

Had the answer been, for both, "yes", then the ability to turn off SHA-1 in Firefox 51, as currently scheduled, could have broken millions of more sites than presently expected. Would Mozilla have been comfortable with saying "TCSCs aren't considered" - or would the compatibility risks have overridden the policy concerns, causing Mozilla to continue to support SHA-1 in order to avoid disrupting those sites?

I don't have good answers for this, but the current ambiguity with respect to Mozilla's expectations and the BRs does seem like an area for real ecosystem damage to happen as Mozilla works, within the CA/Browser Forum, to deprecate insecure functionality, while minimizing disruption to users. This is a more simplified concern, already manifest, but I'm also thinking about the future implications of what happens if a million such certificates exist, rather than the several thousand that do today.

[Nick Lamb]

On Tuesday, 25 October 2016 21:16:36 UTC+1, Ryan Sleevi wrote:
> The linked bug is a concrete example, where an unconstrained sub-CA was revoked, due to non-compliance with the BRs, but has now been cross-certified as a constrained sub-CA. All of these non-BR compliant certificates are now valid, by utilizing the technically constrained path. From a Mozilla policy, what are the implications of this new cross-certified constrained sub-CA?

Is it possible for someone to write up the details of the non-compliant issuances and so on ? I would find it much easier to comment on the particulars of 1311200 if they were more specific.

> A very concrete example of the implications of this relate to SHA-1 certificates. If, prior to Dec 31, 2015, CAs had issued some N-million TCSCs, signed with SHA-1, to all parties that wished to keep issuing SHA-1, could these TCSCs have continued issuing SHA-1 certificates without violating the Mozilla requirements? One interpretation is that yes, they could have, at least from Mozilla policy. However, from the BRs, the answer is that no, they couldn't have.

Unless I'm missing something, these constrained certificates pose a much smaller risk under our expected threat model for SHA-1.

We suppose a bad guy can (or will soon be able to) pull off a chosen prefix attack on SHA-1 enabling them to trick a CA into signing document A and then use its signature on document B successfully.

Back when this happened for MD5, many CAs were issuing from roots, or at best from completely unconstrained intermediates, just because. The attack was used to produce a working unconstrained CA:TRUE certificate. One successful attack translated into unlimited issuing power across all of the Web PKI. It seem eminently reasonable to believe this one certificate might be extremely valuable to criminals with an effective plan to exploit it before any effective remedy is deployed, and everybody in the Web PKI (which is now basically everyone) is put at risk.

In contrast for the TCSCs a successful attack would produce /at best/ another constrained intermediate, and in most cases I've seen not even a working CA:TRUE certificate but just some arbitrary wildcard end entity certificate for a subset of the constrained names. The attack must also be launched against infrastructure controlled by the very organisation the certificates will be used to impersonate, not some unrelated third party as with the MD5 attacks.

Finally, as I understand it the hypothetical SHA-1 TSCSs would be revoked along with any other still extant SHA-1 certificates by the issuing CA, before the planned Firefox 51 public release. So I don't think this would imperil the planned action in Firefox 51. Am I wrong about that ?

[Ryan Sleevi]

On Tuesday, October 25, 2016 at 4:56:57 PM UTC-7, Nick Lamb wrote:
> Is it possible for someone to write up the details of the non-compliant issuances and so on ? I would find it much easier to comment on the particulars of 1311200 if they were more specific.

This doesn't seem relevant; that is, the specifics of 1311200 are irrelevant, so much as we're discussing BR non-compliance. Even if the issues are seen as technically trivial, we have an inconsistency the deserves some degree of guidance.

> Unless I'm missing something, these constrained certificates pose a much smaller risk under our expected threat model for SHA-1.

I think you're missing a key purpose of the sunset date of 1/1/2016, which perhaps wasn't as clearly communicated outside the Forum.

The purpose of having a date for no new issuance, and distinct from full distrust of SHA-1, was to allow a graduated fade-out without having a giant flag day of disruption, which would then also suffer from the first-mover problem due to browsers non-uniform schedules.

That is, had we simply stated 1/1/2017 as the date SHA-1 was turned off, we would have seen continued issuance up to that day. As a result, turning it off would have broken huge numbers of sites - and for compatibility reasons, been re-enabled. This isn't theoretical either - we saw this both with attempts to deprecate MD5 (which lacked such a schedule) and with Mozilla's attempts to disable new SHA-1 certificates.

So I think the remaining discussion of the technical details of a SHA-1 collision are largely immaterial, because the point I was making about it, and apologies for not being clearer on this, was that some of the things we deprecate in the CA/Browser Forum so that browsers can eventually remove support for the (insecure) thing, while minimizing disruption/breakage of sites.

As a further example, consider the requirement that a subjectAltName field be present, and that the CN field, if present, contains a value represented in the SAN. The entire purpose of such a requirement is to ensure that the technical representation of authorized hosts uses an unambiguous representation (which dNSName and iPAddress are), rather than the ambiguous heuristic of CN. This goal itself was expressed as far back as 1999, in RFC 2818, but it still took 15 years after that (2014) before it actually became standard practice of CAs, and only then, because of the Baseline Requirements.

In spite of this, we still see CAs issuing certs lacking a SAN, which potentially means applications still need to support these certs (for another ~3 years). While Mozilla has taken steps to phase this practice out, they're only doing it on the basis of a notBefore of *this* year, in order to minimize breakage.

So we certainly know that Mozilla's policies are, in some ways, designed to minimize the number of errors that users are presented with, by allowing a gradual fade out of insecure or undesirable practices. A change in the BRs is, in theory, supposed to be fully reflected in all valid certificates within 39 months of the effective date, after which time, application software vendors can remove support.

An interpretation that suggests TCSCs don't have to abide by these policies - which Mozilla policy implies, but the BRs prohibit - means that any such deprecations do not apply to TCSCs, and as a consequence, such things bear a greater compatibility risk when they are removed. If we imagine a world with millions of TCSCs - something that the TLS WG has expressed interest in, in the past - potentially means breakage for millions of sites, and means that the path of deprecating things via the CA/Browser Forum may no longer be a viable solution to minimizing user disruption.

Does that more concretely express the concerns, which are more fundamental than specifics about commonNames or SHA-1?

> Finally, as I understand it the hypothetical SHA-1 TSCSs would be revoked along with any other still extant SHA-1 certificates by the issuing CA, before the planned Firefox 51 public release. So I don't think this would imperil the planned action in Firefox 51. Am I wrong about that ?

Yes. There is no obligation or expectation, presently communicated, to revoke extant certificates. Indeed, CAs were adamantly opposed to such a requirement. So these certificates will still very much be valid.

[Nick Lamb]

On Wednesday, 26 October 2016 02:31:07 UTC+1, Ryan Sleevi wrote:
> Yes. There is no obligation or expectation, presently communicated, to revoke extant certificates. Indeed, CAs were adamantly opposed to such a requirement. So these certificates will still very much be valid.

Ah yes, I had muddled this with the obligation to revoke remaining certificates for non-Internet addresses (e.g. example.corp, 10.20.30.40) at the start of this month for which it's on my TODO list to verify the extent of compliance. So this would be a significant risk.

[Gervase Markham]

On 26/10/16 02:30, Ryan Sleevi wrote:
> So we certainly know that Mozilla's policies are, in some ways,
> designed to minimize the number of errors that users are presented
> with, by allowing a gradual fade out of insecure or undesirable
> practices. A change in the BRs is, in theory, supposed to be fully
> reflected in all valid certificates within 39 months of the effective
> date, after which time, application software vendors can remove
> support.

I certainly agree that this is the goal. And, insofar as the BRs are
only meaningful to CAs because root program policy requires it, we need
to make sure that Mozilla's application of the BRs is correctly scoped.

Perhaps it would be worth revisiting the reasons why technically
constrained sub-CAs were excluded from Mozilla policy. As I remember,
this was a privacy requirement - CAs wanted to be able to have some
sub-CAs which were not publicly disclosed, as Mozilla policy was set to
require. The compromise reached was that public disclosure was not
necessary if the sub-CA were name-constrained. Am I correct in this, or
were there other reasons? Are there parts of Mozilla's policy and/or the
BRs that it would be reasonable for such sub-CAs to be exempt from?

If privacy was the extent of the issue, would it solve the problem to
change bullet 8 of the inclusion policy as follows?

8. All certificates that are capable of being used to issue new
certificates, and which directly or transitively chain to a certificate
included in Mozilla’s CA Certificate Program, MUST be operated in
accordance with Mozilla’s CA Certificate Policy and MUST either be
technically constrained or be publicly disclosed and audited.

->

8. All certificates that are capable of being used to issue new
certificates, and which directly or transitively chain to a certificate
included in Mozilla’s CA Certificate Program, MUST be operated in

accordance with Mozilla’s CA Certificate Policy (including being
included in audits) and MUST either be technically constrained or be
publicly disclosed.

Gerv

[Kurt Roeckx]

On Tue, Oct 25, 2016 at 12:12:47PM -0700, Ryan Sleevi wrote:

> 8. All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited.
>

> This wording implies that technically constrained sub-CAs, from a Mozilla Policy standpoint, are not required to adhere to the Baseline Requirements.

So I think what you're trying to say is that you interprete it as:
"MUST either be (technically constrained) or (be publicly disclosed and audited)"
While maybe it was meant to say:
"MUST either be (technically constrained or be publicly disclosed) and audited"

Where audited can either be done by an external auditor, or by the
CA that issued the TCSC. But you could also interprete is like we
only require an audit report from those that are not technically
constrained.

To avoid confusing, you could make it a list like:
- technically constrained or be publicly disclosed
- audited

It's also not clear from that sentence that they need to adhere to
the BRs, but I guess that comes from the audit requirements.


Kurt

[okaphone.e...@gmail.com]

Reading this makes me wonder. Will it still be possible to have such a thing as a non disclosed sub-CA now that Chrome has announced that they soon will require CT?

CU Hans

[Ryan Sleevi]

On Wednesday, October 26, 2016 at 3:52:23 AM UTC-7, Gervase Markham wrote:
> Perhaps it would be worth revisiting the reasons why technically
> constrained sub-CAs were excluded from Mozilla policy. As I remember,
> this was a privacy requirement - CAs wanted to be able to have some
> sub-CAs which were not publicly disclosed, as Mozilla policy was set to
> require. The compromise reached was that public disclosure was not
> necessary if the sub-CA were name-constrained. Am I correct in this, or
> were there other reasons? Are there parts of Mozilla's policy and/or the
> BRs that it would be reasonable for such sub-CAs to be exempt from?

My understanding was actually that it was two-fold:

1) A small subset of CAs felt that TCSCs should be private.
2) Generally, it was felt that because the most 'harm' you can do with a TCSC is to your own domains, the need for a third-party audit, or for some of the more substantial requirements (e.g. standing up an OCSP and CRL responder, HSM protection, etc) were unnecessary, and more an element of local security policy.

I'm actually entirely unsympathetic to the argument in 1, and even RFC 6962 (early drafts) and RFC 6962-bis (current draft) seemed to support this, without objection from CAs, by requiring that a TCSC be disclosed via CT, but that it's leaves would be exempt. Independent of Chrome's view of that (wearing that hat for only this sentence), by allowing leaves under a TCSC to be unlogged seems to support the interpretation of #2. This is also why I support the mandatory disclosure of TCSCs to Mozilla Salesforce, to ensure that the Technical Constraints are properly implemented and conforming in order for the CA to claim its exclusion.

The challenge with the interpretation in #2 is that, while the damage may be localized to a specific domain, we know that it can present ecosystem issues, particularly around deprecation. If we fully accept that TCSCs can do no harm to the Web PKI, then arguably, requirements such as using 2048-bit RSA keys are unnecessary in the BRs, because they're also "localized" harm (if for a non-CA cert).

Since we have precedent of using the BRs to set ecosystem-wide minimum security requirements (to receive secure UI), such as using unambiguous subjectAltNames, presenting the right EKU, and using reasonably sufficient cryptographic key sizes (RSA-2048, ECC-256), I think the interpretation that nothing below a TCSC can do any harm is a bad interpretation.

So then the question becomes - what ARE the things that TCSCs should be exempt from, and to what degree? As it stands in the BRs, they are exempt from only one thing: An independent, third-party audit. All other requirements are in full force, regarding the certificate profile, key protection, and key revocation services. Under Mozilla policy, as interpreted at present, they are exempt from all requirements. This is the core inconsistency - because the Issuing CA has a BR obligation to ensure the TCSC is compliant.


While I'm supportive, in general, of you're suggested modification, I do want to highlight the implications that it brings. It means that TCSCs must ensure FIPS 140-2 Level 3 HSMs and key protection, audit logs, etc. In effect, the only benefit a TCSC provides is that it allows you to avoid an independent auditor, but doesn't allow you to avoid any of the substantial obligations in capital to conform to the BRs and the netsec requirements.

Alternatively, we could try to suggest that a TCSCs' certificates must conform to the certificate profile, but not other obligations (like separation of duty, offline protection, etc), but then we still have to figure out which elements of that technical profile are relevant - for example, OCSP and CRL services for the TCSC.

Or we could go with the current perceived interpretation - out of sight, out of mind - in which case, that means that any BR-violating sub-CA may be reissued as a TCSC, provided that its only for domains it controls. That, of course, leaves the situation I described as a possibility - largescale, automated TCSC issuance as a way to avoid BR-based deprecations - but we can cross that bridge when it comes up.

[Gervase Markham]

On 26/10/16 18:53, Ryan Sleevi wrote:
> interpretation of #2. This is also why I support the mandatory
> disclosure of TCSCs to Mozilla Salesforce, to ensure that the
> Technical Constraints are properly implemented and conforming in
> order for the CA to claim its exclusion.

If we were to require this, would it present administrative issue? At
the moment, we are dealing with approximately 2500 intermediates in
Salesforce. If we added the TCSCs, do we have any idea what that number
would go up to? Rob has only discovered 300 TCSCs, so perhaps the
increase would not be so large? Or are lots of them hidden from public view?

> Since we have precedent of using the BRs to set ecosystem-wide
> minimum security requirements (to receive secure UI), such as using
> unambiguous subjectAltNames, presenting the right EKU, and using
> reasonably sufficient cryptographic key sizes (RSA-2048, ECC-256), I
> think the interpretation that nothing below a TCSC can do any harm is
> a bad interpretation.

I think you are correct. The view "it can't hurt" was, at least in my
mind, related to the risk of misissuance. And therefore I was not so
concerned about them getting an audit, using a level 4 HSM and so on.
Perhaps we did not give sufficient consideration to issues like use of
SHA-1.

> While I'm supportive, in general, of you're suggested modification, I
> do want to highlight the implications that it brings. It means that
> TCSCs must ensure FIPS 140-2 Level 3 HSMs and key protection, audit
> logs, etc. In effect, the only benefit a TCSC provides is that it
> allows you to avoid an independent auditor, but doesn't allow you to
> avoid any of the substantial obligations in capital to conform to the
> BRs and the netsec requirements.

Right - but we would just be matching what the BRs already require,
wouldn't we? So if we adopted this view, we wouldn't be giving anyone
any costs they didn't already have.

> Alternatively, we could try to suggest that a TCSCs' certificates
> must conform to the certificate profile, but not other obligations
> (like separation of duty, offline protection, etc), but then we still
> have to figure out which elements of that technical profile are
> relevant - for example, OCSP and CRL services for the TCSC.

This seems like a route worth investigating; the work required to decide
this would not be massive.

Gerv

[Santhan Raj]

> Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with section 7.1.5 and audited in line with section 8.7 only, or Unconstrained and fully audited in line with all remaining requirements from this section
>
> Section 8.7 reads:
> During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CA’s Certificate Policy and the Subordinate CA’s Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA shall ensure all applicable CP are met.
>
>
> That is, according to the BRs, the issuer of a technically constrained subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to the BRs and the issuing CA's policies and practices, as well as conduct a sampling audit quarterly.

May be I'm missing it, but I don't see 8.7 (or at least the lines quoted above) requiring TCSC to be compliant with BR. I read it as TCSCs must adhere to the Issuing CA's CP and their own (TCSC's) CPS, adhereance towards which should be verified by the Issuing CAs, however it doesn't (explicitly) state TCSC compliance towards BR.

Is this how you arrived at "TCSC should adhere to BRs", (which to me at least, personally, sounds fair and logical):
Issuing CA must be BR compliant
-> Issuing CA's CP must be BR compliant (unless the CA gets creative)
-> TCSC's CPS should adhere Issuing CA's CA
-> TCSC's CPS should adhere to BR

[Ryan Sleevi]

On Monday, November 7, 2016 at 4:38:53 PM UTC-8, Santhan Raj wrote:
> May be I'm missing it, but I don't see 8.7 (or at least the lines quoted above) requiring TCSC to be compliant with BR. I read it as TCSCs must adhere to the Issuing CA's CP and their own (TCSC's) CPS, adhereance towards which should be verified by the Issuing CAs, however it doesn't (explicitly) state TCSC compliance towards BR.

Section 8 requires it.

Section 8.1 does not eliminate the requirement to compliance with Section 8, merely, it limits the auditing of compliance to that defined in Section 8.7