On Fri, Oct 16, 2020 at 9:20 AM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:
> > > 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-security-policy@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 >> > 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. >> >> 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. > > 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 > 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. > 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
