info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints
343 views
Skip to first unread message
Ben Wilson
Oct 15, 2020, 4:36:38 PM10/15/20
to mozilla-dev-security-policy
This issue is presented for resolution in the next version of the Mozilla
Root Store Policy. It is related to Issue #147
<https://github.com/mozilla/pkipolicy/issues/147> (previously posted for
discussion on this list on 6-Oct-2020).
Possible language is presented here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4
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.
Thanks,
Ben
Root Store Policy. It is related to Issue #147
<https://github.com/mozilla/pkipolicy/issues/147> (previously posted for
discussion on this list on 6-Oct-2020).
Possible language is presented here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4
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.
Thanks,
Ben
Dimitris Zacharopoulos
Oct 16, 2020, 7:31:31 AM10/16/20
to Ben Wilson, mozilla-dev-security-policy
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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Rob Stradling
Oct 16, 2020, 7:33:50 AM10/16/20
to Ben Wilson, mozilla-dev-security-policy, Dimitris Zacharopoulos
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-...@lists.mozilla.org> on behalf of Dimitris Zacharopoulos via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: 16 October 2020 12:31
To: Ben Wilson <bwi...@mozilla.com>; mozilla-dev-security-policy <mozilla-dev-s...@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
> 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-secur...@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
> "(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)."
I've had a go at drafting a PR here: https://github.com/robstradling/pkipolicy/pull/1
________________________________
From: dev-security-policy <dev-security-...@lists.mozilla.org> on behalf of Dimitris Zacharopoulos via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: 16 October 2020 12:31
To: Ben Wilson <bwi...@mozilla.com>; mozilla-dev-security-policy <mozilla-dev-s...@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
> 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
>
> Possible language is presented here:
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
Dimitris Zacharopoulos
Oct 16, 2020, 7:49:03 AM10/16/20
to Rob Stradling, Ben Wilson, mozilla-dev-security-policy
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-...@lists.mozilla.org> on behalf of Dimitris
> Zacharopoulos via dev-security-policy
> <dev-secur...@lists.mozilla.org>
> *Sent:* 16 October 2020 12:31
> Zacharopoulos via dev-security-policy
> <dev-secur...@lists.mozilla.org>
> *To:* Ben Wilson <bwi...@mozilla.com>; mozilla-dev-security-policy
> <mozilla-dev-s...@lists.mozilla.org>
> *Subject:* Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception
Ryan Sleevi
Oct 16, 2020, 8:22:20 AM10/16/20
to Dimitris Zacharopoulos, Ben Wilson, mozilla-dev-security-policy
On Fri, Oct 16, 2020 at 7:31 AM Dimitris Zacharopoulos via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
>
> 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://github.com/mozilla/pkipolicy/issues/147> (previously posted for
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
>
> 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
> > discussion on this list on 6-Oct-2020).
> >
> > Possible language is presented here:
> >
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4
> >
> > Possible language is presented here:
> >
> >
> > 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)?
Explicitly, yes, it is 100% the intent that this would be a violation.
> > 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)?
Audits that are limited based on whether or not certificates were issued
are not aligned with the needs of relying parties and users. We need
assurances, for example, that keys were and are protected, and that audits
measure technical capability.
- 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.
is undesirable for users, and why the set of policy updates, in whole, seek
to prohibit this. I would refer you to the discussions in Shanghai, in the
context of audit discussions and lifetimes, about why allowing this is
inherently an unacceptable security risk to end users.
In this scenario, there is zero reason not to issue a new intermediate. The
desired end state, for both roots AND intermediates, is that a change in
capabilities leads to issuing a NEW intermediate or root. There is no
legitimate technical reason not to issue a new intermediate, and transition
that new certificate issuance to that new intermediate.
The discussion about cradle to grave is intentionally: you can only issue
certificates of the type that you have been audited for from the moment of
key creation. Anything less than that exposes users to security risks,
because it allows certificates issued before the audit and supervision to
appear as valid to relying parties.
Mozilla has, for several years now, reliably and consistently done this for
new root inclusions, in which pre-BR CAs have been rejected, and CAs have
been required to issue *new* roots with *new* keys, and ensure BR audits
from the moment of creation for those certificates, in order to be
included. This provides relying parties the assurance that any certificates
they encounter will be and are subject to the requirements.
This is part of the “cradle to grave” discussion moreso than this, but it
is the combination of these that ensures users are protected.
Rob Stradling
Oct 16, 2020, 8:48:36 AM10/16/20
to Dimitris Zacharopoulos, Ben Wilson, mozilla-dev-security-policy
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 <bwi...@mozilla.com>; mozilla-dev-security-policy <mozilla-dev-s...@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.
________________________________
From: dev-security-policy <dev-security-...@lists.mozilla.org><mailto:dev-security-...@lists.mozilla.org> on behalf of Dimitris Zacharopoulos via dev-security-policy <dev-secur...@lists.mozilla.org><mailto:dev-secur...@lists.mozilla.org>
Sent: 16 October 2020 12:31
To: Ben Wilson <bwi...@mozilla.com><mailto:bwi...@mozilla.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org><mailto:mozilla-dev-s...@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.
> 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-secur...@lists.mozilla.org<mailto:dev-secur...@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>
________________________________
From: Dimitris Zacharopoulos <ji...@it.auth.gr>
Sent: 16 October 2020 12:48
To: Rob Stradling <r...@sectigo.com>; Ben Wilson <bwi...@mozilla.com>; mozilla-dev-security-policy <mozilla-dev-s...@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.
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-...@lists.mozilla.org><mailto:dev-security-...@lists.mozilla.org> on behalf of Dimitris Zacharopoulos via dev-security-policy <dev-secur...@lists.mozilla.org><mailto:dev-secur...@lists.mozilla.org>
Sent: 16 October 2020 12:31
To: Ben Wilson <bwi...@mozilla.com><mailto:bwi...@mozilla.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org><mailto:mozilla-dev-s...@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
> This issue is presented for resolution in the next version of the Mozilla
> Root Store Policy. It is related to Issue #147
> 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>
>
> Possible language is presented here:
>
> 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)?
> 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.
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-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
Mozilla's position on the above two questions, we can propose some
improvements.
Best regards,
Dimitris.
>
> Thanks,
>
> Ben
> _______________________________________________
> dev-security-policy mailing list
> 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-secur...@lists.mozilla.org<mailto:dev-secur...@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>
Dimitris Zacharopoulos
Oct 16, 2020, 9:20:11 AM10/16/20
to ry...@sleevi.com, Ben Wilson, mozilla-dev-security-policy
On 2020-10-16 3:21 μ.μ., Ryan Sleevi wrote:
>
>
> On Fri, Oct 16, 2020 at 7:31 AM Dimitris Zacharopoulos via
> dev-security-policy <dev-secur...@lists.mozilla.org
> <mailto:dev-secur...@lists.mozilla.org>> wrote:
>
>
>
> 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://github.com/mozilla/pkipolicy/issues/147> (previously
>
>
>
> 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
> posted for
> > discussion on this list on 6-Oct-2020).
> >
> > Possible language is presented here:
> >
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4
> > discussion on this list on 6-Oct-2020).
> >
> > Possible language is presented here:
> >
> Explicitly, yes, it is 100% the intent that this would be a violation.
>
> Audits that are limited based on whether or not certificates were
> issued are not aligned with the needs of relying parties and users. We
> need assurances, for example, that keys were and are protected, and
> that audits measure technical capability.
The same exact assurances are included in the BR audit. There are no
>
> Audits that are limited based on whether or not certificates were
> issued are not aligned with the needs of relying parties and users. We
> need assurances, for example, that keys were and are protected, and
> that audits measure technical capability.
additional requirements in the EV Guidelines related to the CA
Certificates except in section 17.7 for the Root CA Key Pair Generation
which is the same in the BRs.
So from a practical standpoint, unless I'm missing something, there is
no policy differentiation in terms of CA Certificates (Root or
Intermediate CA) explicitly for EV. In fact, that's why it was allowed
(and to the best of my knowledge, is still allowed) for a CA to obtain
an EV audit for a BR-compliant Root.
I agree that for Issuing CAs, it's very easy to forge a new one and make
it explicitly clear in the future that it is EV capable, although there
is zero added value, because as I explained there are no separate policy
rules for "EV CAs", but only in regards to end-entity certificates.
>
> - 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.
>
>
> It has been repeatedly discussed in the CABForum about explicitly why
> this is undesirable for users, and why the set of policy updates, in
> whole, seek to prohibit this. I would refer you to the discussions in
> Shanghai, in the context of audit discussions and lifetimes, about why
> allowing this is inherently an unacceptable security risk to end users.
>
> In this scenario, there is zero reason not to issue a new
> intermediate. The desired end state, for both roots AND intermediates,
> is that a change in capabilities leads to issuing a NEW intermediate
> or root. There is no legitimate technical reason not to issue a new
> intermediate, and transition that new certificate issuance to that new
> intermediate.
See above. I think the existing policy requirements for EV Roots and
> this is undesirable for users, and why the set of policy updates, in
> whole, seek to prohibit this. I would refer you to the discussions in
> Shanghai, in the context of audit discussions and lifetimes, about why
> allowing this is inherently an unacceptable security risk to end users.
>
> In this scenario, there is zero reason not to issue a new
> intermediate. The desired end state, for both roots AND intermediates,
> is that a change in capabilities leads to issuing a NEW intermediate
> or root. There is no legitimate technical reason not to issue a new
> intermediate, and transition that new certificate issuance to that new
> intermediate.
non-EV Roots are exactly the same (perhaps with the exception of 17.7,
in which if a CA can demonstrate that the non-EV Root CA was following
this rule during the key generation ceremony, it should be accepted).
>
> The discussion about cradle to grave is intentionally: you can only
> issue certificates of the type that you have been audited for from the
> moment of key creation. Anything less than that exposes users to
> security risks, because it allows certificates issued before the audit
> and supervision to appear as valid to relying parties.
>
> Mozilla has, for several years now, reliably and consistently done
> this for new root inclusions, in which pre-BR CAs have been rejected,
> and CAs have been required to issue *new* roots with *new* keys, and
> ensure BR audits from the moment of creation for those certificates,
> in order to be included. This provides relying parties the assurance
> that any certificates they encounter will be and are subject to the
> requirements.
>
> This is part of the “cradle to grave” discussion moreso than this, but
> it is the combination of these that ensures users are protected.
that were past BRs.
Ryan Sleevi
Oct 16, 2020, 7:55:58 PM10/16/20
to Dimitris Zacharopoulos, Ryan Sleevi, Ben Wilson, mozilla-dev-security-policy
On Fri, Oct 16, 2020 at 9:20 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:
Apologies, in my attempt to provide an explanation, I failed to include a
link to where this was previously discussed, such as
https://cabforum.org/2018/10/18/minutes-for-ca-browser-forum-f2f-meeting-45-shanghai-17-18-october-2018/
While it is indeed possible to obtain an EV audit for a BR-compliant root,
I do hope you recall the lengthy discussion that highlighted the tangible
and practical issues for relying parties for allowing such gaps in such
audits from the moment of key creation, which is fundamentally what you're
asking.
My quick response above was meant to highlight that /just as/ it would be
unacceptable to have a CA key created, have a gap in the time of that
creation, and then later produce an audit without addressing that gap in
time, it should be equally unacceptable to do so for an EV certificate.
A gap in the BR audit means you have no assurances of key protection.
A gap in the EV audit means you have no assurances with respect to whether
or not they issued certificates with the "EV OID" while not subject to and
operated according to the EV Guidelines.
This should be fairly basic and trivial to see the gap, but it is
unfortunate that we still see CAs audited according to the ETSI standards
fail to account for this. Indeed, you will hopefully recall the discussion
in Shanghai that examined how some ETSI CAs issued certificates bearing a
Qualified certificate OID, well before they had been audited as such.
However, once they were included within the Qualified Trust List, then all
of those certificates were retroactively granted legal effect - undermining
the very objective of qualified certificates in the first place!
I agree that for Issuing CAs, it's very easy to forge a new one and make it
> explicitly clear in the future that it is EV capable, although there is
> zero added value, because as I explained there are no separate policy rules
> for "EV CAs", but only in regards to end-entity certificates.
>
With respect, I believe you've fundamentally misunderstood the issue,
although I'm glad to hear you agree that it is a very easy task for a CA to
address.
The value proposition is precisely to ensure that the end-entity
certificates are issued according to the appropriate policies.
As discussed in Shanghai, and as highlighted both by WebTrust and ETSI
representatives, the effect of an audit does not test the negative (i.e.
that the CA had *not* issued any EV certificates in the time prior to the
EV audit). We had a productive discussion on a number of ways to address
that, of which this is the most practical of them, being, as you note, very
easy.
> The discussion about cradle to grave is intentionally: you can only issue
> certificates of the type that you have been audited for from the moment of
> key creation. Anything less than that exposes users to security risks,
> because it allows certificates issued before the audit and supervision to
> appear as valid to relying parties.
>
> Mozilla has, for several years now, reliably and consistently done this
> for new root inclusions, in which pre-BR CAs have been rejected, and CAs
> have been required to issue *new* roots with *new* keys, and ensure BR
> audits from the moment of creation for those certificates, in order to be
> included. This provides relying parties the assurance that any certificates
> they encounter will be and are subject to the requirements.
>
> This is part of the “cradle to grave” discussion moreso than this, but it
> is the combination of these that ensures users are protected.
>
>
> I think I now see a possible misunderstanding. I was considering Roots
> that were past BRs.
>
As was I.
As noted above, for the same reason that a "pre-BR" keypair being audited
and included would retroactively grant trust to any certificates issued
prior to the BR period, which would be an unacceptable security risk that
concerns not just key protection but all certificate profiles, a "pre-EV"
keypair that may have issued "proto-EV" certificates prior to any relevant
audit would be equally retroactively grandfathered in, and as a
consequence, an unacceptable risk to the value proposition of an EV
certificate.
The discussion of Shanghai was quite productive, and resulted in a number
of positive suggestions, but I can understand and appreciate it was two
years ago and thus may not be at the forefront. For example, it may not be
obvious that the recently adopted SC31 included language, incorporated from
Microsoft's Root Program, into the Baseline Requirements specifically to
address the risk posed by CAs audited under the ETSI standards. This
approach made explicit, within the Baseline Requirements, that the use of
the CA/B Forum EV OID was contingent upon the certificate being compliant
with the EV Guidelines. However, that benefit is only recognized when
client applications, such as Mozilla Firefox, refuse to accept any EV
certificate *except* those that bear that CA/B Forum EV OID.
However, that benefit does not fully address the threat, merely provides
some limited assurances, while ensuring a CA is audited for all
certificates it will /ever/ issue from the moment of creation is the only
technical path forward. Alternative solutions (such as "only trust
certificates issued after a date") were, of course, discussed in the F2F
and pointed out that they are flawed, since both pre-dating and post-dating
certificates are not yet prohibited by the Baseline Requirements, nor are
they explicitly required (... yet) to be included in the scope of audits
accepted by browsers and operating systems. Hopefully this refresher of
that past discussion helps better capture the benefit, as well as provide
greater transparency to the many productive and fruitful discussions in the
CA/B Forum.
For reference, the specific portion of the minutes that capture this are
reproduced below:
> One area that Wayne brought up was about EV audits – what happens when an
> existing root requests EV status? Ryan raised the example of European CAs
> that were issuing QWACs before they’d been audited against 319 411-2. They
> could be successfully audited after-the-fact. If root programs granted EV,
> that would retroactively grant EV, while for qualified status, it’d only be
> from the point of the audit – which is probably not what browsers expect.
> Clemens said they shouldn’t be issuing qualified certificates before then,
> but if they do, they just don’t have qualified status in terms of the law.
> When asked about WebTrust, Don said the same thing was possible – the
> Webtrust for BRs audit is not going to look at their EV issuance, so they
> could have issued certificates with that EV OID before they were EV
> audited. If browsers didn’t want that, they could push for new criteria
> into the BRs that would have the auditors explicitly test that the CA
> hadn’t issued EV certificates, such as by using/requiring all new EV certs
> use the CABF EV OID, so that you could have assurance that a BR-audited CA
> that later applied for EV wouldn’t have a bunch of pre-audit EV
> certificates.
wrote:
link to where this was previously discussed, such as
https://cabforum.org/2018/10/18/minutes-for-ca-browser-forum-f2f-meeting-45-shanghai-17-18-october-2018/
While it is indeed possible to obtain an EV audit for a BR-compliant root,
I do hope you recall the lengthy discussion that highlighted the tangible
and practical issues for relying parties for allowing such gaps in such
audits from the moment of key creation, which is fundamentally what you're
asking.
My quick response above was meant to highlight that /just as/ it would be
unacceptable to have a CA key created, have a gap in the time of that
creation, and then later produce an audit without addressing that gap in
time, it should be equally unacceptable to do so for an EV certificate.
A gap in the BR audit means you have no assurances of key protection.
A gap in the EV audit means you have no assurances with respect to whether
or not they issued certificates with the "EV OID" while not subject to and
operated according to the EV Guidelines.
This should be fairly basic and trivial to see the gap, but it is
unfortunate that we still see CAs audited according to the ETSI standards
fail to account for this. Indeed, you will hopefully recall the discussion
in Shanghai that examined how some ETSI CAs issued certificates bearing a
Qualified certificate OID, well before they had been audited as such.
However, once they were included within the Qualified Trust List, then all
of those certificates were retroactively granted legal effect - undermining
the very objective of qualified certificates in the first place!
I agree that for Issuing CAs, it's very easy to forge a new one and make it
> explicitly clear in the future that it is EV capable, although there is
> zero added value, because as I explained there are no separate policy rules
> for "EV CAs", but only in regards to end-entity certificates.
>
although I'm glad to hear you agree that it is a very easy task for a CA to
address.
The value proposition is precisely to ensure that the end-entity
certificates are issued according to the appropriate policies.
As discussed in Shanghai, and as highlighted both by WebTrust and ETSI
representatives, the effect of an audit does not test the negative (i.e.
that the CA had *not* issued any EV certificates in the time prior to the
EV audit). We had a productive discussion on a number of ways to address
that, of which this is the most practical of them, being, as you note, very
easy.
> The discussion about cradle to grave is intentionally: you can only issue
> certificates of the type that you have been audited for from the moment of
> key creation. Anything less than that exposes users to security risks,
> because it allows certificates issued before the audit and supervision to
> appear as valid to relying parties.
>
> Mozilla has, for several years now, reliably and consistently done this
> for new root inclusions, in which pre-BR CAs have been rejected, and CAs
> have been required to issue *new* roots with *new* keys, and ensure BR
> audits from the moment of creation for those certificates, in order to be
> included. This provides relying parties the assurance that any certificates
> they encounter will be and are subject to the requirements.
>
> This is part of the “cradle to grave” discussion moreso than this, but it
> is the combination of these that ensures users are protected.
>
>
> I think I now see a possible misunderstanding. I was considering Roots
> that were past BRs.
>
As noted above, for the same reason that a "pre-BR" keypair being audited
and included would retroactively grant trust to any certificates issued
prior to the BR period, which would be an unacceptable security risk that
concerns not just key protection but all certificate profiles, a "pre-EV"
keypair that may have issued "proto-EV" certificates prior to any relevant
audit would be equally retroactively grandfathered in, and as a
consequence, an unacceptable risk to the value proposition of an EV
certificate.
The discussion of Shanghai was quite productive, and resulted in a number
of positive suggestions, but I can understand and appreciate it was two
years ago and thus may not be at the forefront. For example, it may not be
obvious that the recently adopted SC31 included language, incorporated from
Microsoft's Root Program, into the Baseline Requirements specifically to
address the risk posed by CAs audited under the ETSI standards. This
approach made explicit, within the Baseline Requirements, that the use of
the CA/B Forum EV OID was contingent upon the certificate being compliant
with the EV Guidelines. However, that benefit is only recognized when
client applications, such as Mozilla Firefox, refuse to accept any EV
certificate *except* those that bear that CA/B Forum EV OID.
However, that benefit does not fully address the threat, merely provides
some limited assurances, while ensuring a CA is audited for all
certificates it will /ever/ issue from the moment of creation is the only
technical path forward. Alternative solutions (such as "only trust
certificates issued after a date") were, of course, discussed in the F2F
and pointed out that they are flawed, since both pre-dating and post-dating
certificates are not yet prohibited by the Baseline Requirements, nor are
they explicitly required (... yet) to be included in the scope of audits
accepted by browsers and operating systems. Hopefully this refresher of
that past discussion helps better capture the benefit, as well as provide
greater transparency to the many productive and fruitful discussions in the
CA/B Forum.
For reference, the specific portion of the minutes that capture this are
reproduced below:
> One area that Wayne brought up was about EV audits – what happens when an
> existing root requests EV status? Ryan raised the example of European CAs
> that were issuing QWACs before they’d been audited against 319 411-2. They
> could be successfully audited after-the-fact. If root programs granted EV,
> that would retroactively grant EV, while for qualified status, it’d only be
> from the point of the audit – which is probably not what browsers expect.
> Clemens said they shouldn’t be issuing qualified certificates before then,
> but if they do, they just don’t have qualified status in terms of the law.
> When asked about WebTrust, Don said the same thing was possible – the
> Webtrust for BRs audit is not going to look at their EV issuance, so they
> could have issued certificates with that EV OID before they were EV
> audited. If browsers didn’t want that, they could push for new criteria
> into the BRs that would have the auditors explicitly test that the CA
> hadn’t issued EV certificates, such as by using/requiring all new EV certs
> use the CABF EV OID, so that you could have assurance that a BR-audited CA
> that later applied for EV wouldn’t have a bunch of pre-audit EV
> certificates.
Ryan Sleevi
Oct 17, 2020, 2:26:54 AM10/17/20
to Ben Wilson, mozilla-dev-security-policy
On Thu, Oct 15, 2020 at 4:36 PM Ben Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> This issue is presented for resolution in the next version of the Mozilla
> Root Store Policy. It is related to Issue #147
> <https://github.com/mozilla/pkipolicy/issues/147> (previously posted for
> discussion on this list on 6-Oct-2020).
>
> Possible language is presented here:
>
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4
>
> 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.
Given the continuing issues we see with respect to audits, it seems like
dev-secur...@lists.mozilla.org> wrote:
> This issue is presented for resolution in the next version of the Mozilla
> Root Store Policy. It is related to Issue #147
> <https://github.com/mozilla/pkipolicy/issues/147> (previously posted for
> discussion on this list on 6-Oct-2020).
>
> Possible language is presented here:
>
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4
>
> 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.
this notion of “technically constrained (from issuing EV) sub-CA” is going
to encounter many of the same fundamental issues we’ve seen with audit
scopes being incorrect and improper.
It seems the easiest, and best (for users) way, is to ensure that once a
root is trusted for a given purpose, as much as possible it’s ensured that
*all* CA certificates beneath that hierarchy are included within the scope
of the audit.
It’s already well-accepted that, for example, the expectations of the BR
audits still apply even if a CA has not issued, whether that “not issued”
was because it has never issued a very (e.g. just created and not used
yet), whether it is no longer issuing certs (e.g. it is being retired),
*and* for situations where the key had previously issued certs, but did not
issue certs within the audit period (e.g. a pause, rather than simply not
being used yet).
For separate purposes (e.g. S/MIME vs TLS), we know there are practical
reasons to ensure separate hierarchies; most pragmatic of them being the
creation of certificates for one purpose that impact the trustworthiness of
certificates for another purpose (e.g. S/MIME certs, both those technically
separated and those merely “intended” for S/MIME, impacting TLS trust, such
as we saw with the recent OCSP issue).
Because of this, it seems that there is a simpler, clearer, unambiguous
path for CAs that seems useful to move to:
- If a CA is trusted for purpose X, that certificate, and all subordinate
CAs, should be audited against the criteria relevant for X
This would avoid much of the confusion CAs seemingly continue to encounter
with respect to audit scope, disclosure, and intent, by making it as simple
as “If you signed it, you audit it.”
If we apply this concept to the proposed language, then the requirement for
an EV audit is simply about whether there is any unexpired, unrevoked path
to a root CA which can issue EV certificates. Similarly, checking the scope
for an EV audit becomes “the entire hierarchy”.
This is accomplished by simply removing your proposed “(i.e. ...)”
parenthetical, and allowing the language from 3.1 to apply, by changing the
language to “if the root is recognized for issuing EV certificates”.
>From an audit ingestion point, and for CAs, it becomes easier now: the
scope of the EV audit would be 1:1 the scope of a BR audit. There’s no
worry or confusion about capability, as those “not intended” and those “not
capable” can easily be audited that they have not issued such certificates.
In addition to the simplification of scope above, further have the benefit
of addressing any scenario in which a subordinate CA uses Policy X for some
time (T=0 ... T=5), and then later (T=6) decides to apply for that policy
to be recognized for EV. Under the language proposed, if Mozilla grants EV
to the root for Policy X at T=10, on the basis of an audit period for (T=6
... T=9), then all the certificates from T=0 to T=5 will be retroactively
granted EV status, and the subordinate CA will not be or have been in
violation of any Mozilla policy requirement.
It seems like this should cause no incompatibility for CAs.
Ben: what do you think of this simplified approach to the problem?
Ben Wilson
Oct 17, 2020, 3:48:27 PM10/17/20
to Ryan Sleevi, mozilla-dev-security-policy
Ryan wrote:
> If we apply this concept to the proposed language, then the requirement
for an EV audit is
> simply about whether there is any unexpired, unrevoked path to a root CA
which can issue
> EV certificates. Similarly, checking the scope for an EV audit becomes
“the entire hierarchy”.
> This is accomplished by simply removing your proposed “(i.e. ...)”
parenthetical, and allowing
> the language from 3.1 to apply, by changing the language to “if the root
is recognized for
> issuing EV certificates”.
I think it might need to be phased in or have some effective date. Also, I
> If we apply this concept to the proposed language, then the requirement
for an EV audit is
> simply about whether there is any unexpired, unrevoked path to a root CA
which can issue
> EV certificates. Similarly, checking the scope for an EV audit becomes
“the entire hierarchy”.
> This is accomplished by simply removing your proposed “(i.e. ...)”
parenthetical, and allowing
> the language from 3.1 to apply, by changing the language to “if the root
is recognized for
> issuing EV certificates”.
haven't mapped out how this might affect CAs that we sometimes add to the
root store without EV enablement and with the suggestion that they apply
later for it.
Ryan Sleevi
Oct 17, 2020, 6:25:27 PM10/17/20
to Ben Wilson, Ryan Sleevi, mozilla-dev-security-policy
On Sat, Oct 17, 2020 at 3:48 PM Ben Wilson <bwi...@mozilla.com> wrote:
> Ryan wrote:
>
> > If we apply this concept to the proposed language, then the requirement
> for an EV audit is
> > simply about whether there is any unexpired, unrevoked path to a root CA
> which can issue
> > EV certificates. Similarly, checking the scope for an EV audit becomes
> “the entire hierarchy”.
>
> > This is accomplished by simply removing your proposed “(i.e. ...)”
> parenthetical, and allowing
> > the language from 3.1 to apply, by changing the language to “if the root
> is recognized for
> > issuing EV certificates”.
>
> I think it might need to be phased in or have some effective date.
>
That’s reasonable. Given that it’s very easy for CAs to transition new TLS
> Ryan wrote:
>
> > If we apply this concept to the proposed language, then the requirement
> for an EV audit is
> > simply about whether there is any unexpired, unrevoked path to a root CA
> which can issue
> > EV certificates. Similarly, checking the scope for an EV audit becomes
> “the entire hierarchy”.
>
> > This is accomplished by simply removing your proposed “(i.e. ...)”
> parenthetical, and allowing
> > the language from 3.1 to apply, by changing the language to “if the root
> is recognized for
> > issuing EV certificates”.
>
> I think it might need to be phased in or have some effective date.
>
issuance to new intermediates, it’s fairly simple to work out a transition
plan that has an immediate/near term deadline for new issuance, so that
within two years (given that the transition to one year certs only happened
in September, we have to deal with the certs prior to that), the full
policy can be effective.
Would you like language to show how that practically works, along with
diagrams to show what’s expected for CAs?
Also, I haven't mapped out how this might affect CAs that we sometimes add
> to the root store without EV enablement and with the suggestion that they
> apply later for it.
>
were trying to make easier. However, as with the above, it’s a very simple
transition: when a CA wishes to apply for EV, they cut a new certificate
hierarchy (i.e. a new root and new issuing intermediates), sign that new
root with their old root, and ensure the new root is audited for EV from
the beginning.
This is functionally no different than what Mozilla has required for CA
keypair as that existed pre-BRs, or which have certified things
inconsistent with Mozilla policy (e.g. One CA that cross-signed two
government subordinates for which they were forbidden from disclosing the
certificate or those certificates CP/CPA). In those cases, the CA generates
a new hierarchy to apply for inclusion within Mozilla products, and operate
according to Mozilla’s policies from the creation to destruction of the
key. For interoperability with products that trust their legacy old root,
they have the old root sign the new root, so that paths can also be built
to the legacy CA through the new root.
Given that anything issued “before” the audit is retroactively
grandfathered in, this hopefully simplifies the process for CAs, by
ensuring appropriate audits from cradle to grave, and for the entire given
hierarchy. BR and EV audits would have the exact same scope, which is
already true with respect to ETSI (as, largely for worse, they don’t check
this to begin with) and can be adopted easily to WebTrust, provided the CA
demonstrates appropriate controls (e.g. to provide auditable logs that they
haven’t issued EV, if they assert they haven’t issued EV from a CA)
Nick Lamb
Oct 18, 2020, 8:21:58 PM10/18/20
to dev-secur...@lists.mozilla.org, Ben Wilson
On Thu, 15 Oct 2020 14:36:15 -0600
have spent a day thinking about it on and off without reaching a
different conclusion.
Surely it wouldn't make sense in 2020 for a root to seek Mozilla EV
enablement? Firefox doesn't present EV enabled certificates with a
different UI these days as I understand it. So there doesn't
seem to be any benefit from being EV enabled in Firefox, instead you
get a bunch of extra requirements imposed by these policy documents.
Nick.
Ben Wilson via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> Possible language is presented here:
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4
I write this fully expecting to be corrected on the substance but I
<dev-secur...@lists.mozilla.org> wrote:
> Possible language is presented here:
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4
have spent a day thinking about it on and off without reaching a
different conclusion.
Surely it wouldn't make sense in 2020 for a root to seek Mozilla EV
enablement? Firefox doesn't present EV enabled certificates with a
different UI these days as I understand it. So there doesn't
seem to be any benefit from being EV enabled in Firefox, instead you
get a bunch of extra requirements imposed by these policy documents.
Nick.
Wiedenhorst, Matthias
Oct 19, 2020, 4:03:17 AM10/19/20
to mozilla-dev-s...@lists.mozilla.org
Hi everybody,
this might not be closely connected to original topic, but allow me to comment on one issue below.
Best regards
Matthias
> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im
> Auftrag von Ryan Sleevi via dev-security-policy
> Gesendet: Samstag, 17. Oktober 2020 01:56
>
> [...]
This understanding is also captured in the statement of Clemens, as included in the minutes you quoted below.
>
> [...]
______________________________________________________________________________________________________________________
Sitz der Gesellschaft/Headquarter: TÜV Informationstechnik GmbH * Langemarckstr. 20 * 45141 Essen, Germany
Registergericht/Register Court: Amtsgericht/Local Court Essen * HRB 11687 * USt.-IdNr./VAT No.: DE 176132277 * Steuer-Nr./Tax No.: 111/57062251
Geschäftsführung/Management Board: Dirk Kretzschmar
TÜV NORD GROUP
Expertise for your Success
Please visit our website: www.tuv-nord.com<http://www.tuv-nord.com>
Besuchen Sie unseren Internetauftritt: www.tuev-nord.de<http://www.tuev-nord.de>
this might not be closely connected to original topic, but allow me to comment on one issue below.
Best regards
Matthias
> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im
> Auftrag von Ryan Sleevi via dev-security-policy
> Gesendet: Samstag, 17. Oktober 2020 01:56
>
> [...]
>
> Indeed, you will hopefully recall the discussion in Shanghai that examined how
> some ETSI CAs issued certificates bearing a Qualified certificate OID, well before
> they had been audited as such.
> However, once they were included within the Qualified Trust List, then all of those
> certificates were retroactively granted legal effect - undermining the very
> objective of qualified certificates in the first place!
That is not my understanding of eIDAS and the Trusted Lists. Different from EV handling, qualified status and corresponding legal effect is not granted / changed retroactively. It is granted at a certain point in time and is only valid from that time until is withdrawn. For that purpose, the TLS includes the "current status starting date and time" and "previous status starting date and time" entries, which shall not be back-dated (see section 5.5.5 of ETSI TS 119 612 v2.1.1).
> Indeed, you will hopefully recall the discussion in Shanghai that examined how
> some ETSI CAs issued certificates bearing a Qualified certificate OID, well before
> they had been audited as such.
> However, once they were included within the Qualified Trust List, then all of those
> certificates were retroactively granted legal effect - undermining the very
> objective of qualified certificates in the first place!
This understanding is also captured in the statement of Clemens, as included in the minutes you quoted below.
>
> [...]
>
> For reference, the specific portion of the minutes that capture this are reproduced
> below:
>
> > One area that Wayne brought up was about EV audits – what happens when
> > an existing root requests EV status? Ryan raised the example of
> > European CAs that were issuing QWACs before they’d been audited
> > against 319 411-2. They could be successfully audited after-the-fact.
> > If root programs granted EV, that would retroactively grant EV, while
> > for qualified status, it’d only be from the point of the audit – which is probably
> >not what browsers expect.
> > Clemens said they shouldn’t be issuing qualified certificates before
> > then, but if they do, they just don’t have qualified status in terms of the law.
> > When asked about WebTrust, Don said the same thing was possible – the
> > [...]
> For reference, the specific portion of the minutes that capture this are reproduced
> below:
>
> > One area that Wayne brought up was about EV audits – what happens when
> > an existing root requests EV status? Ryan raised the example of
> > European CAs that were issuing QWACs before they’d been audited
> > against 319 411-2. They could be successfully audited after-the-fact.
> > If root programs granted EV, that would retroactively grant EV, while
> > for qualified status, it’d only be from the point of the audit – which is probably
> >not what browsers expect.
> > Clemens said they shouldn’t be issuing qualified certificates before
> > then, but if they do, they just don’t have qualified status in terms of the law.
> > When asked about WebTrust, Don said the same thing was possible – the
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
______________________________________________________________________________________________________________________
Sitz der Gesellschaft/Headquarter: TÜV Informationstechnik GmbH * Langemarckstr. 20 * 45141 Essen, Germany
Registergericht/Register Court: Amtsgericht/Local Court Essen * HRB 11687 * USt.-IdNr./VAT No.: DE 176132277 * Steuer-Nr./Tax No.: 111/57062251
Geschäftsführung/Management Board: Dirk Kretzschmar
TÜV NORD GROUP
Expertise for your Success
Please visit our website: www.tuv-nord.com<http://www.tuv-nord.com>
Besuchen Sie unseren Internetauftritt: www.tuev-nord.de<http://www.tuev-nord.de>
Kathleen Wilson
Nov 5, 2020, 7:28:04 PM11/5/20
to mozilla-dev-s...@lists.mozilla.org
On 10/16/20 11:26 PM, Ryan Sleevi wrote:
> Because of this, it seems that there is a simpler, clearer, unambiguous
> path for CAs that seems useful to move to:
> - If a CA is trusted for purpose X, that certificate, and all subordinate
> CAs, should be audited against the criteria relevant for X
>
I am in favor of this approach for a future version of Mozilla's Root
> Because of this, it seems that there is a simpler, clearer, unambiguous
> path for CAs that seems useful to move to:
> - If a CA is trusted for purpose X, that certificate, and all subordinate
> CAs, should be audited against the criteria relevant for X
>
Store Policy, but I prefer not to try to tackle it in this v2.7.1
update. So I filed a github issue to remind us to consider this in the
next version:
https://github.com/mozilla/pkipolicy/issues/220
I have added a section called "EV TLS Capable" to the wiki pages, and I
will appreciate feedback on it:
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
For this MRSP Issue #152 update to v2.7.1, I propose that we make each
occurrence of "capable of issuing EV certificates" link to
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
Thanks,
Kathleen
Tim Hollebeek
Nov 6, 2020, 4:45:25 PM11/6/20
to Kathleen Wilson, Mozilla
In the definition of EV TLS Capable, I'd move the last bullet up to the top.
This is because the definition is inherently recursive, and it's easy to
miss that
if the recursion rule isn't first.
For example, I had a question about whether "revoked" meant just the
certificate
itself, or whether a revoked parent (etc) also qualifies. But the ambiguity
goes
away once you realize that the parent/cross/etc also needs to be EV TLS
Capable,
hence not revoked.
-Tim
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On Behalf Of Kathleen Wilson via dev-security-policy
> Sent: Thursday, November 5, 2020 7:28 PM
> To: Mozilla <mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for
Policy
> Constraints
>
This is because the definition is inherently recursive, and it's easy to
miss that
if the recursion rule isn't first.
For example, I had a question about whether "revoked" meant just the
certificate
itself, or whether a revoked parent (etc) also qualifies. But the ambiguity
goes
away once you realize that the parent/cross/etc also needs to be EV TLS
Capable,
hence not revoked.
-Tim
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On Behalf Of Kathleen Wilson via dev-security-policy
> Sent: Thursday, November 5, 2020 7:28 PM
> To: Mozilla <mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for
Policy
> Constraints
>
> On 10/16/20 11:26 PM, Ryan Sleevi wrote:
> > Because of this, it seems that there is a simpler, clearer,
> > unambiguous path for CAs that seems useful to move to:
> > - If a CA is trusted for purpose X, that certificate, and all
> > subordinate CAs, should be audited against the criteria relevant for X
> >
>
> > unambiguous path for CAs that seems useful to move to:
> > - If a CA is trusted for purpose X, that certificate, and all
> > subordinate CAs, should be audited against the criteria relevant for X
> >
>
> I am in favor of this approach for a future version of Mozilla's Root
Store
> Policy, but I prefer not to try to tackle it in this v2.7.1 update. So I
filed a
> github issue to remind us to consider this in the next version:
>
> https://github.com/mozilla/pkipolicy/issues/220
>
>
> I have added a section called "EV TLS Capable" to the wiki pages, and I
will
> appreciate feedback on it:
>
> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
>
> For this MRSP Issue #152 update to v2.7.1, I propose that we make each
> occurrence of "capable of issuing EV certificates" link to
> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
>
> Thanks,
> Kathleen
>
Store
> Policy, but I prefer not to try to tackle it in this v2.7.1 update. So I
filed a
> github issue to remind us to consider this in the next version:
>
> https://github.com/mozilla/pkipolicy/issues/220
>
>
> I have added a section called "EV TLS Capable" to the wiki pages, and I
will
> appreciate feedback on it:
>
> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
>
> For this MRSP Issue #152 update to v2.7.1, I propose that we make each
> occurrence of "capable of issuing EV certificates" link to
> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
>
> Thanks,
> Kathleen
>
Kathleen Wilson
Nov 6, 2020, 6:44:00 PM11/6/20
to mozilla-dev-s...@lists.mozilla.org
>> For this MRSP Issue #152 update to v2.7.1, I propose that we make each
>> occurrence of "capable of issuing EV certificates" link to
>> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
>> occurrence of "capable of issuing EV certificates" link to
>> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
> In the definition of EV TLS Capable, I'd move the last bullet up to the top.
>
Done. Thanks!
>
Ben Wilson
Jan 24, 2021, 4:20:04 PM1/24/21
to Kathleen Wilson, mozilla-dev-security-policy
In line with the proposed hyperlink to
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable from
"capable of issuing EV certificates" (see Issue #147), then I don't think
the proposed parenthetical is necessary anymore, and I think this issue can
be considered resolved without needing to explain policy constraints for EV
audit exceptions in the MRSP.
On Fri, Nov 6, 2020 at 4:43 PM Kathleen Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> >> For this MRSP Issue #152 update to v2.7.1, I propose that we make each
> >> occurrence of "capable of issuing EV certificates" link to
> >> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
>
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable from
"capable of issuing EV certificates" (see Issue #147), then I don't think
the proposed parenthetical is necessary anymore, and I think this issue can
be considered resolved without needing to explain policy constraints for EV
audit exceptions in the MRSP.
On Fri, Nov 6, 2020 at 4:43 PM Kathleen Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> >> For this MRSP Issue #152 update to v2.7.1, I propose that we make each
> >> occurrence of "capable of issuing EV certificates" link to
> >> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
>
> > In the definition of EV TLS Capable, I'd move the last bullet up to the
> top.
> >
>
> Done. Thanks!
> top.
> >
>
0 new messages