One thing I forgot to mention: Although I think Viriginia's view of the process is fine, passing the ballot now puts the requirement into a weird status where it may be adopted or not adopted, depending on the CA's interpretation on when changes are adopted. This then becomes an exercise in whether the auditor believes the process is allowed instead of something that is prohibited. The status of the ballot as binding may be unclear from the Forum's perspective but that at least shifts it over to the CA to explain to auditors. The process definitely needs clarification, but I can see the point in Wayne wanting to pass the ballot before the governance/IPR issues are resolved (that plus we never voted to suspend ballots so I think we permit members to continue following the process until there is clarity - we're no worse off than we were before)
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Ryan Sleevi Sent: Wednesday, October 26, 2016 11:53 AM To: [email protected] Subject: Re: Technically Constrained Sub-CAs and the BRs 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
