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
------------------------------------------------------------------------
*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
