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 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. On Sat, Oct 17, 2020 at 12:26 AM Ryan Sleevi <r...@sleevi.com> wrote: > > > 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
