MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Ben Wilson]

#147 <https://github.com/mozilla/pkipolicy/issues/147> - Require EV audits
for certificates capable of issuing EV certificates – Clarify that EV
audits are required for all intermediate certificates that are technically
capable of issuing EV certificates, even when not currently issuing EV
certificates.

This issue is presented for resolution in the next version of the Mozilla
Root Store Policy.

Suggested language is presented here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/a83eca6d7d8bf2a3b30529775cb55b0c8a5f982b


The proposal is to replace "if issuing EV certificates" with "if capable of
issuing EV certificates" in two places -- for WebTrust and ETSI audits.

[Wiedenhorst, Matthias]

Hi Ben, Hi all,

sorry for the late reply. Thanks to your summary yesterday, I re-checked all the open issues and stumbled upon one question with regard to this issue that didn't came to my mind earlier.

I am not sure if I am understanding correctly the desired outcome of this change. Forgive me if I am overlooking something to obvious at the moment.
Main parts of the EV requirements and hence of an EV audit are about the issuance and certificate profile of end-entity certificates.

Let's say we have an EV-enabled Root CA "A" and a Sub-CA "B", which is only used to issue DV certificates, but which is not properly constrained and hence would be EV capable.

Now, if I would perform an EV audit on Sub-CA "B", then of course all issued end entity certificate would fail to meet the EV requirements on end-entity certificates (obviously, because they are DV certificates...). As a result, such Sub-CA would be non-conformant with regard to EV requirements and not pass the audit.
So is the intent to not allow such Sub-CA's, because they can't pass the necessary audit?

Or is the intent only, that the Sub-CA certificate for "B" must meet all EV requirements on Sub-CA certificates?

Or did you have a scenario in mind, where a Sub-CA "C" has been used to issue EV certificates, is than (temporarily) taken out of service and sometime later activated again. Now someone could (bot of course shoulndn't) argue that "C" has not been issuing EV certs and hence no EV audits were necessary for that period.

Best regards
Matthias


> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im
> Auftrag von Ben Wilson via dev-security-policy
> Gesendet: Dienstag, 6. Oktober 2020 22:38
> An: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
> Betreff: MRSP Issue #147 - Require EV audits for certificates capable of issuing

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

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

[Dimitris Zacharopoulos]

On 6/10/2020 11:38 μ.μ., Ben Wilson via dev-security-policy wrote:
> #147 <https://github.com/mozilla/pkipolicy/issues/147> - Require EV audits
> for certificates capable of issuing EV certificates – Clarify that EV
> audits are required for all intermediate certificates that are technically
> capable of issuing EV certificates, even when not currently issuing EV
> certificates.
>
> This issue is presented for resolution in the next version of the Mozilla
> Root Store Policy.
>
> Suggested language is presented here:
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/a83eca6d7d8bf2a3b30529775cb55b0c8a5f982b
>
>
> The proposal is to replace "if issuing EV certificates" with "if capable of
> issuing EV certificates" in two places -- for WebTrust and ETSI audits.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Judging from the earlier discussion that took place in September 2020, I
understand that some CAs have an EV-enabled hierarchy (meaning that the
Root CA is in scope of the EV Guidelines and is included in an audit
with "EV scope"), has issued some Intermediate CAs that issue EV
Certificates and are included in the audit with "EV scope", and some
Intermediate CAs that have never issued EV Certificates, nor are they
intended to issue EV Certificates and were not listed in the "EV scope"
of the audit.

I realize that this policy change, will require Intermediate CAs that
have never issued nor intend to issue EV Certificates, to be included in
an EV scope audit with the sole purpose of asserting that no TLS
Certificates have been issued in scope of the EV Guidelines, which
translates into making sure that no end-entity certificate has been
issued asserting the EV policy OID in the certificatePolicies extension.
Is that a fair statement?

Is there going to be an effective date after which Intermediate CA
Certificates which were not intended to issue EV Certificates, will be
required to have an EV audit?

Assuming my previous statement is fair, would it suffice for an auditor
to examine the corpus of non-expired/non-revoked Certificates off of
these "non-EV" Issuing CAs to ensure that no end-entity certificate has
been issued asserting the EV policy OID according to the CA's CP/CPS?

Finally, I would like to highlight that policy OID chaining is not
currently supported in the webPKI by Browsers, so even if a CA adds a
particular non-EV policyOID in an Intermediate CA Certificate, this
SubCA would still be technically capable of issuing an end-entity
certificate asserting an EV policy OID, and that certificate would
probably get EV treatment from existing browsers. Is this correct?


Thank you,
Dimitris.

[Dimitris Zacharopoulos]

On 12/11/2020 10:41 π.μ., Dimitris Zacharopoulos via dev-security-policy
wrote:

> Finally, I would like to highlight that policy OID chaining is not
> currently supported in the webPKI by Browsers, so even if a CA adds a
> particular non-EV policyOID in an Intermediate CA Certificate, this
> SubCA would still be technically capable of issuing an end-entity
> certificate asserting an EV policy OID, and that certificate would
> probably get EV treatment from existing browsers. Is this correct?

I see that this is related to
https://github.com/mozilla/pkipolicy/issues/152, so I guess Mozilla
Firefox does not enable "EV Treatment" if an Intermediate CA Certificate
does not assert the anyPolicy or the CA's EV policy OID, including the
CA/B Forum EV OID, regardless of what the end-entity certificate asserts.

Dimitris.

[Ben Wilson]

On Thu, Nov 12, 2020 at 2:03 AM Dimitris Zacharopoulos via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> I see that this is related to
> https://github.com/mozilla/pkipolicy/issues/152, so I guess Mozilla
> Firefox does not enable "EV Treatment" if an Intermediate CA Certificate
> does not assert the anyPolicy or the CA's EV policy OID, including the
> CA/B Forum EV OID, regardless of what the end-entity certificate asserts.
>

> That's correct.

[Ben Wilson]

In addition to the original proposal, I propose that we hyperlink "capable
of issuing EV certificates" to
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable.