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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
