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