Hi Ben. I agree with Dimitris that the proposed language is a bit confusing.
> "(i.e. a subordinate CA under an EV-enabled root that contains no EKU or the > id-kp-serverAuth EKU or anyExtendedKeyUsage EKU, and a certificatePolicies > extension that asserts the CABF EV OID of 2.23.140.1.1, the anyPolicy OID, or > the CA's EV policy OID)." It's not clear from that sentence if "...that contains no EKU or the id-kp-serverAuth EKU or anyExtendedKeyUsage EKU" is meant to apply to "a subordinate CA" or "an EV-enabled root". For clarity, I suggest converting this sentence into a bulleted list; and to avoid repeating that bulleted list unnecessarily, I suggest putting it into a new section 3.1.2.3, which sections 3.1.2.1 and 3.1.2.2 would then reference. I've had a go at drafting a PR here: https://github.com/robstradling/pkipolicy/pull/1 ________________________________ From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> on behalf of Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.org> Sent: 16 October 2020 12:31 To: Ben Wilson <bwil...@mozilla.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 2020-10-15 11:36 μ.μ., Ben Wilson via dev-security-policy wrote: > This issue is presented for resolution in the next version of the Mozilla > Root Store Policy. It is related to Issue #147 > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F147&data=04%7C01%7Crob%40sectigo.com%7Ca230422a644142b9d71a08d871c70667%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384446910767139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SWvjOTEj6vaGRVCDZS%2FMMEPFCrsDfvpwli6lfKkzCHc%3D&reserved=0> > (previously posted for > discussion on this list on 6-Oct-2020). > > Possible language is presented here: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBenWilson-Mozilla%2Fpkipolicy%2Fcommit%2Fc1acc76ad9f05038dc82281532fb215d71d537d4&data=04%7C01%7Crob%40sectigo.com%7Ca230422a644142b9d71a08d871c70667%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384446910767139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s4Nf4ViQnw8W2ckrofP%2BGYFeF5P4UHUWGfyEo8lEv4M%3D&reserved=0 > > In addition to replacing "if issuing EV certificates" with "if capable of > issuing EV certificates" in two places -- for WebTrust and ETSI audits -- > it would be followed by "(i.e. a subordinate CA under an EV-enabled root > that contains no EKU or the id-kp-serverAuth EKU or anyExtendedKeyUsage > EKU, and a certificatePolicies extension that asserts the CABF EV OID of > 2.23.140.1.1, the anyPolicy OID, or the CA's EV policy OID)." Thus, Mozilla > considers that a CA is capable of issuing EV certificates if it is (1) a > subordinate CA (2) under an EV-enabled root (3) that contains no EKU or the > id-kp-serverAuth EKU or anyExtendedKeyUsage EKU, and (4) a > certificatePolicies extension that asserts the CABF EV OID of 2.23.140.1.1, > the anyPolicy OID, or the CA's EV policy OID. > > I look forward to your suggestions. Hello Ben, I am trying to understand the expectations from Mozilla: - If a CA that has an EV-capable RootCA , uses a subCA Certificate that contains the id-kp-serverAuth EKU and the anyPolicy OID that does not issue EV end-entity Certificates, is this considered a policy violation if this subCA is not explicitly included in an EV audit scope (ETSI or WebTrust)? - If a subCA Certificate that contains the id-kp-serverAuth EKU and the anyPolicy OID was not covered by an EV-scope audit (because it did not issue EV Certificates) and it later decides to update the profile and policies/practices to comply with the EV Guidelines for everything related to end-entity certificates in order to start issuing EV Certificates and is later added to an EV-scope audit, is that an allowed practice? Judging from the current EV Guidelines I didn't see anything forbidding this practice. In fact this is supported via section 17.4. The proposed language is a bit confusing so hopefully by getting Mozilla's position on the above two questions, we can propose some improvements. Best regards, Dimitris. > > Thanks, > > Ben > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&data=04%7C01%7Crob%40sectigo.com%7Ca230422a644142b9d71a08d871c70667%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384446910772135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ofpen2baqYtT4B7HgetKK%2Biq7SEy%2F%2Bq4x3lcI7OKgwU%3D&reserved=0 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&data=04%7C01%7Crob%40sectigo.com%7Ca230422a644142b9d71a08d871c70667%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384446910772135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ofpen2baqYtT4B7HgetKK%2Biq7SEy%2F%2Bq4x3lcI7OKgwU%3D&reserved=0 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
