On Tue, November 3, 2015 4:24 pm, Kathleen Wilson wrote: > Topic to discuss [1]: > â(D3) Make the timeline clear about when the audit statements and > disclosure has to happen for new audited/disclosed subCAs.
> What further clarification needs to be added to Mozillaâs CA Certificate > Policy to make it more clear when the audit statements and disclosure > has to happen for new subCAs? Thanks for continuing to drive the discussion, Kathleen. I think with respect to the Mozilla policy, the Baseline Requirements themselves are quite explicit as to what the requirements are, and they're a reasonable set of requirements. Where the disconnect appears to be is how these are translated into auditable criteria under WebTrust or ETSI, which unfortunately seems to be what a number of CAs (particularly ETSI CAs, based on the issues) are relying on, rather than the standard they're held to. There are a number of ways to draw attention to this, but I think we should be careful about how much attention we draw to it, relative to the BRs as a whole. I'm not necessarily advocating these options, but hopefully they can spark a more thoughtful and thorough discussion: Example 1: "The CA with a certificate included in Mozillas CA Certificate Program MUST disclose this information prior to the signing of the subordinate CA certificate." Example 2: "The CA with a certificate included in Mozilla's CA Certificate Program MUST disclose this information following the completion of a point in time readiness assessment, as described in Section 8.[whatever] of the Baseline Requirements, and prior to the issuance of the first Publicly Trusted Certificate." Example 3: Keep the present language, but similar to documents such as https://wiki.mozilla.org/CA:Schedule or https://wiki.mozilla.org/CA:How_to_apply as an informal explanation of the technical language. I can think of pros and cons for each of these examples, but I present them as ways to get people to think of the issues, as well as to see if there are alternative solutions to the issue raised. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
