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. - If a subCA Certificate that contains the id-kp-serverAuth EKU and the > anyPolicy OID was not covered by an EV-scope audit (because it did not > issue EV Certificates) and it later decides to update the profile and > policies/practices to comply with the EV Guidelines for everything > related to end-entity certificates in order to start issuing EV > Certificates and is later added to an EV-scope audit, is that an allowed > practice? Judging from the current EV Guidelines I didn't see anything > forbidding this practice. In fact this is supported via section 17.4. It has been repeatedly discussed in the CABForum about explicitly why this is undesirable for users, and why the set of policy updates, in whole, seek to prohibit this. I would refer you to the discussions in Shanghai, in the context of audit discussions and lifetimes, about why allowing this is inherently an unacceptable security risk to end users. In this scenario, there is zero reason not to issue a new intermediate. The desired end state, for both roots AND intermediates, is that a change in capabilities leads to issuing a NEW intermediate or root. There is no legitimate technical reason not to issue a new intermediate, and transition that new certificate issuance to that new intermediate. 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
