On Tuesday, October 25, 2016 at 1:01:04 PM UTC-7, Kurt Roeckx wrote: > 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.
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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
