On Thu, Oct 15, 2020 at 4:36 PM Ben Wilson via dev-security-policy <
dev-security-policy@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
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?
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to