On 1/30/2015 5:59 AM, Jeremy Rowley wrote: >> Some initial thoughts: >> >> 1) Membership in the CAB Forum is not required for a CA to commit to >> complying with the BR, and if non-membership avoids any obligation to comply >> with the BRs, I think you'll quickly see a mass exodus from the group. No >> member of the CAB Forum is bound to its requirements by agreement or through >> participation. Instead, the requirements are only imposed by the browsers >> are part of their root programs. > The question is only whether a CA can have their Webtrust audit statement > indicate their commitment to comply with the BRs, rather than putting the > commitment to comply statement in the CP/CPS. Therefore, the CA is still > required to comply with BR according to Webtrust audit. > [JR] No - as Kurt mentioned, the CA is attesting to its compliance, not the > auditors. Putting it in the audit statement doesn't make sense as the audit > statement is only the auditors opining on your compliance with whatever audit > criteria is relevant not the CA's assertion of compliance. [MH] If that's the case, the trustworthiness of a Webtrust audit would be weakened. Auditors should obtain the CA's assertion of compliance, and assess whether it's reasonable with respect to the CA's CP/CPS and the target scope of audit (i.e. the BR). And finally give their opinions in Webtrust audit report for public knowledge. > >> 2) The goal of Section 8.3 is for the CA to inform the public about which >> certs are being issued in compliance with the BRs and which are not. It's >> not a marketing requirement. It's a technical requirement to provide >> relying parties (and browsers) information about how the CA operates. >> Section 8.3 basically requires the CA to assert that it is doing the MINIMUM >> required to issue certs. Any CA unwilling to assert this should not be >> issuing trusted certs. > The CA's assertion to issue certificate in accordance to BR is REQUIRED by > Webtrust audit anyway. The assertion is also publicly disclosed with the > audit report. Again, the question is only whether a CA should put a statement > in the CP/CPS as section 8.3 required. If yes, it is a marketing requirement, > because not aware of other audit requirements or standardization bodies that > have such requirement, e.g. Webtrust, ETSI, even Mozilla's CP itself. > [JR] Not true. Audits can have restricted scope and only cover the CA's > compliance with its CPS. Not all audit reports are clear on what parts of > the audit covered which certs. > >> 3) Every CA should comply with the latest version of BRs. CAs who are so >> inflexible that they can't keep up with the "minor" changes made by the CAB >> Forum really shouldn't be issuing certs. Recent "minor" changes include >> deprecation of 1024 bit certs, SHA2 migration, deprecation of internal >> names, etc. These are pretty important issues, all of which should be >> promptly implemented by CAs when adopted. > Exactly. Changes in BR may be "minor" or "important" from different point of > views. A CA may be in trouble of making a false statement in its CP/CPS if > the latest version of BR suddenly changed. Worst of all, the BR is suddenly > changed just before annual audit. But of course, the "minor" changes that you > have mentioned should have already fulfilled by CAs. > [JR] That's my point. Minor is not in the discretion of the CA. If the > CA/Browser Forum adopted a change, there was a probably a good reason behind > it. Also, as Kurt mentioned, changes restricting a practice are always > enacted with a lead time to give CAs time to comply. Truly minor changes > (those without a lead time) don't restrict a CAs practices, just permit > additional ways for compliance. [MH] Requiring CA to comply with BRs is good thing. But I also point out that once a CA put a statement of compliance with "latest version" of BRs in CP/CPS, the CA has committed to public that it "has already complied" with all potential changes of BRs at all time. That may be a false statement. The proper approach is for Mozilla's CP to require the CA to perform audit on the latest version of BR. And the audit report must state which version of BR that the CA adhere to. > >> 4) Although relying parties might not frequently review audit reports and >> CPS docs, the Mozilla community does look at CPS docs. Asserting compliance >> in the CPS lets the community know the criteria under which the CA is >> operated and permits them to compare the CPS to a third party standard. >> Without the assertion, the CA isn't telling you anything about which policy >> they are operating under. > I think Mozilla community should have no problem looking at Webtrust report > and CA's assertion to which version of BR since it's required by Mozilla's > CP. I understand that Kathleen is somehow maintaining a spreadsheet of CA > audits, isn't it? This approach is actually a better alternative. > [JR] There's a lot more relying parties than the Mozilla community. Not only > that, but many CAs have confusing CPS docs making it difficult to know > exactly which certs comply with which policy. The assertion is an easy way > for reviewers to understand when the CA is complying with the BRs and they > are not. Plus, it's a representation that the CA understands the requirements > and the importance of compliance. It makes the CA set forth when exactly it's > deviating from the BRs (such as for code signing and clients, which are not > covered by the BRs) rather leaving reviewers guessing about which policy is > applicable. [MH] CA's assertion is a mandatory requirement of Webtrust audit. If an auditor has prepared the audit report, it should be no doubt. > >> Obviously, I think an exception to this simple requirement is a mistake. > Obviously I don't think that section 8.3 of BR is a simple requirement. > [JR] Which tells me either you don't want to comply with the BRs (which is > bad), you don't have control over the CP (which is also bad for someone going > through the Mozilla program), or there is some third reason? Why can't the > CA assert BR compliance? Non-compliance with the BRs SHOULD be public > knowledge (not hidden) so concerned Internet citizens can choose whether to > trust that CA. [MH] On the contrary, we want to comply with the BRs. We do have very stringent control over our CP/CPS, which does not allow to over-commit a practice to public. If there is non-compliance, they will be disclosed in a public Webtrust audit report.
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
