On Tue, Mar 7, 2017 at 5:09 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > 1.1 Scope > > Item 2: > > Bullet 1: This would allow the anyEKU to be considered 'out of > scope'. > > Is that intentional? (notwithstanding Section 5.3.1) > > Bullet 2: This potentially leads to confusion as to what it means to > > 'not allow' such types, given that nameConstraints only apply to the type > > for which they're present. That is, the absence of an iPAddress > > nameConstraint means there's no restriction, while the presence has to be > > constructed in a way to exclude all IP addresses in the excludedSubtrees. > > Similarly, as captured during the SRVName discussions in the CA/Browser > > Forum, there's uncertainty as to how to capture such an exclusion with an > > SRVName nameConstraint. > > > > I don't know how best to suggest rephrasing this, other than I think > the > > scope may need to forward-reference a subsequent section that defines the > > technical means for that scope. I suspect you were trying to avoid this, > > but I think that to avoid ambiguity as to what the scope is, you'll want > to > > ensure a precise technical definition is linked to the prosaic goal. > > > > Item 3: Similar to above, this allows excluding the anyEKU from scope > > (notwithstanding Section 5.3.1) > > Are these issues also present in 2.4? > Ish? I can't quite decide whether or not, hence why I raised it. For example, Inclusion, Item 9 describes what it takes for something to be technically constrained, which explicitly excludes anyExtendedKeyUsage and then further refines the definition (with a forward declaration to the BRs) for id-kp-serverAuth. So overall, I can't see an explicit prohibition on anyExtendedKeyUsage within the existing Mozilla Policy, and all requirements (particularly audits) flow down. > 3 > > - As you reformat this, perhaps it's worth borrowing the Microsoft of > > approach of mapping trust bits to criteria > > Can you link to an example? > I did in my 4.1.2 notes - but http://aka.ms/auditreqs and more specifically https://social.technet.microsoft.com/wiki/contents/articles/31635.microsoft-trusted-root-certificate-program-audit-requirements.aspx#Conventional_CA_Audit_Standards I think 4.1.2 is the appropriate place for such a mapping, but I highlighted it because Section 3.3 leaves some confusion relative to 4.1.2, so perhaps it may be worth c Small 3.3 nit: Replace "Below" with "The following list" ? "Below" leaves it uncertain if 'every conflict in Section 3.3 + onwards is intentiona' ;) > > > 4.1.2 > > - You link to the "Baseline Requirements" document, but don't define > what > > a BR audit is. While 4.1.1 lists audit criteria, this ambiguity may be > > undesirable. As with my immediately preceeding section, it may be worth > > mapping "trust bits" to "accepted audits", e.g. "For CA certificates > which > > have the SSL trust bit set, we expect the following audits ..." > > - Similarly, when two audit schemes are interchangable, it may be > worth > > clarifying. For example, would Mozilla accept an ETSI TS 102 042 audit to > > the DVCP profile along with a WebTrust for cAs - 2.0 audit? My hope would > > be 'no', but the proposal leaves this ambiguous. > https://aka.ms/auditreqs > > gives a clearer idea of what I'm thinking. > > I've added lists of acceptable criteria beside each audit requirement. > > Should we simply say that a given root (and I say root, as opposed to > 'CA') has to be covered by all-WebTrust or all-ETSI auditing? > I think your new wording is still fairly unclear, and had quite a bit of time parsing it. For example, 4.1.1 (7) leaves it ambiguous what "appropriate for the trust bit(s) being applied for". 4.1.1 (4) suggests QCP is appropriate for TLS (it isn't; it's accepted for email though?) Your new wording still suggests a mix and match approach, so I'd suggest: 4.1.2 Required Audits (Do all sub-CAs need to use the same scheme as the parent CA? I would presume yes, but not clear) 4.1.2.1 WebTrust If being audited to the criteria developed by the WebTrust Task Force of AICPA (or is it just CPA Canada? I think it's still AICPA), the following audits are required: * For the SSL trust bit, a CA and all subordinate CAs technically capable of issuing server certificates [ref] must have all of the following: * WebTrust for CAs - v2.0 * WebTrust for CAs - SSL Baseline with Network Security - v2.0 * If applying for EV recognition, a WebTrust for CAs - EV SSL v.1.4.5+ * For the email trust bit, a CA and all subordinate CAs technically capable of issuing email certificates [ref] must have all of the following: * WebTrust for CAs - v2.0 4.1.2.2 ETSI If being audited ... * For the SSL trust bit, a CA and all subordinate CAs ... must have all of the following: * ETSI TS 102 042 v.2.3.1 DVCP, OVCP, PTC-BR [note: This will shortly be disallowed and replaced with the EN version, see how Microsoft addresses this] * ETSI EN 319 411-1 v1.1.1 DVCP, OVCP, PTC-BR * For the email trust bit, a CA and all subordinate CAs ... must have: * ETSI TS 101 456 v1.2.3 and ETSI TS 102 042 v.2.3.1 LCP, NCP, NCP+ * or ETSI EN 319 411-1 v.1.1 and ETSI EN 319 411-2 v.2.1.1 LCP, NCP, NCP+ I would suggest checking with Kathleen, but this is consistent with my understanding of what Mozilla already requires (e.g. it's not a normative change, it's a clarifying change) I'm sure you can word it and structure it better, but I think it tries to make it clearer that trust bits map to audit criteria, rather than trying to list criteria independent of requirements. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
