Re: Mozilla Root Store Policy 2.4.1
On 07/03/17 10:07, Ryan Sleevi wrote: >>> - As you reformat this, perhaps it's worth borrowing the Microsoft of >>> approach of mapping trust bits to criteria I have now tried this; thank you for your wording suggestion. Please let me know what you think. I've also updated it to use RFC 2119 language throughout - please tell me if you think I missed any spots. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Mozilla Root Store Policy 2.4.1
Given that the patent disclosures have been withdrawn, the proposed changes in ballot 190, and that the validation working group will be working on a revised ballot for the remaining methods during the face to face, could Action 1 include methods added/revised in ballots adopted after 1.4.1? That way the CAs can introduce the revised methods rather than only the methods in 1.4.1 as written. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Gervase Markham via dev-security-policy Sent: Friday, March 17, 2017 9:41 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Mozilla Root Store Policy 2.4.1 On 06/03/17 15:10, Gervase Markham wrote: > The next stage in the improvement of the Mozilla Root Store Policy is > version 2.4.1. This is version 2.4, but rearranged significantly to > have a more topic-based ordering and structure to it. I have also made > editorial changes to clean up and clarify language, and improved the > Markdown markup. Thanks to Ryan for reviewing this, and I need to come back to his comments. If anyone else has time to look through it, I would be most grateful. CAs: this is worth your time, because you don't want a new normative requirement sprung on you accidentally! ;-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla Root Store Policy 2.4.1
On 06/03/17 15:10, Gervase Markham wrote: > The next stage in the improvement of the Mozilla Root Store Policy is > version 2.4.1. This is version 2.4, but rearranged significantly to have > a more topic-based ordering and structure to it. I have also made > editorial changes to clean up and clarify language, and improved the > Markdown markup. Thanks to Ryan for reviewing this, and I need to come back to his comments. If anyone else has time to look through it, I would be most grateful. CAs: this is worth your time, because you don't want a new normative requirement sprung on you accidentally! ;-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla Root Store Policy 2.4.1
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
Re: Mozilla Root Store Policy 2.4.1
Hi Gerv, I'm assuming as with previous discussions, you'd like to keep the discussion on the list. Overall: I would suggest every "should" be replaced with either a "must" or a "shall" RFC2119 style, to avoid any "best practice" vs "required mandate" confusion. 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) 3 Item 2: I realize the intent is to match the current wording, but it may be worth considering clarifying here, in the event of an RA who performs validation/verification functions, but does not press the so-called "Big Red Button" to issue the cert. Imagine a process where CA receives a request, RA does domain validation (... incorrectly), RA tells Subscriber, Subscriber then asks CA to issue, CA issues now that RA has fulfilled the DCV - this is absolutely something for which multi-factor authentication is intended, in the current Mozilla policy, but which ambiguity regarding "directly" leads to uncertainty. Perhaps this is for a separate policy modification (and I'll let you track that work as appropriate), but perhaps "all accounts capable of causing certificate issuance or perform validation functions" can clarify this? Item 3: "verify certificate signing requests" may also lead to ambiguity as to whether this applies only to CSRs (which are but one way of manifesting a certificate request) or you mean "requests for certificates" or simply "certificate request" (omitting signing to avoid the CSR ambiguity) 3 - Your markdown formatting for a-c is off :) 3 - As you reformat this, perhaps it's worth borrowing the Microsoft of approach of mapping trust bits to criteria 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. 4.2 - Another a/b/c markdown formatting snafu 5.2 - There's a thread in CA/Browser Forum regarding what an "ASN.1 DER encoding error" is. Given 5280/X.509 describe the signature as over the DER encoding (but that the certificate doesn't necessarily match - and see the IETF discussion), perhaps its' worth clarifying that CAs must not _sign_ such certificates. 6 - Is this a subset, superset, or replacement for the Baseline Requirements? That's a quick scan of more than enough feedback, and I figure if we start from there, I can review the subsequent sections if/as you make modifications. On Mon, Mar 6, 2017 at 10:10 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The next stage in the improvement of the Mozilla Root Store Policy is > version 2.4.1. This is version 2.4, but rearranged significantly to have > a more topic-based ordering and structure to it. I have also made > editorial changes to clean up and clarify language, and improved the > Markdown markup. > > *There is no intent to change any normative requirement in this update.* > > Therefore, I would appreciate people reviewing it to make sure I have > not accidentally done so. You can find the draft here: > > https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md > > Version 2.4, the current version, is here: > https://github.com/mozilla/pkipolicy/blob/2.4/rootstore/policy.md > > The diff isn't particularly useful, but here it is: > https://github.com/mozilla/pkipolicy/compare/2.4...master > > To assist with that review,
