Hi Dimitris. I don't see where you're getting "in order to get an EV audit" from. The proposed language deals with whether or not a CA has got all of the audits that Mozilla deems necessary, not with whether or not a CA may obtain new audits.
________________________________ From: Dimitris Zacharopoulos <ji...@it.auth.gr> Sent: 16 October 2020 12:48 To: Rob Stradling <r...@sectigo.com>; 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. Rob, This looks like a chicken-egg problem. A RootCA that wants to enable EV needs to get an EV audit. The proposed language, if I am not misunderstanding something, says that in order to get an EV audit, it must be... "EV-enabled"? Dimitris. On 2020-10-16 2:33 μ.μ., Rob Stradling wrote: 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frobstradling%2Fpkipolicy%2Fpull%2F1&data=04%7C01%7Crob%40sectigo.com%7C267f980cdb1d4264989708d871c976a5%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384457389648046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7kZEIqg9yhYyzf1HGTq979OACtnaUyy4CtGLwXcvuAE%3D&reserved=0> ________________________________ From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org><mailto:dev-security-policy-boun...@lists.mozilla.org> on behalf of Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.org><mailto:dev-security-policy@lists.mozilla.org> Sent: 16 October 2020 12:31 To: Ben Wilson <bwil...@mozilla.com><mailto:bwil...@mozilla.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org><mailto: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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F147&data=04%7C01%7Crob%40sectigo.com%7C267f980cdb1d4264989708d871c976a5%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384457389653038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GErhYhRKrMJFWwPpsbjgQx0GNYbHO6PNehEhnbGtBJ4%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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBenWilson-Mozilla%2Fpkipolicy%2Fcommit%2Fc1acc76ad9f05038dc82281532fb215d71d537d4&data=04%7C01%7Crob%40sectigo.com%7C267f980cdb1d4264989708d871c976a5%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384457389658028%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dUiZ8pfleIi9af8yuG%2FX5bagzx9qTAy3Fcb%2BK1RdPgA%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<mailto: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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&data=04%7C01%7Crob%40sectigo.com%7C267f980cdb1d4264989708d871c976a5%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384457389663020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7ULtrrbqWYSQxg27h2MCb3%2BDUG9kAB1A1O2aPGVRebU%3D&reserved=0> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto: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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&data=04%7C01%7Crob%40sectigo.com%7C267f980cdb1d4264989708d871c976a5%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384457389668012%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YwZdkQxyJSB7ErKKagTtoYKDzumwC2Fd%2FvOCcLaR3tY%3D&reserved=0> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
