On Sat, Oct 17, 2020 at 3:48 PM Ben Wilson <bwil...@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 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. > Well, as I mentioned to Dimitris, this is something that ballots like SC31 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) > 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
