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
<mailto: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.
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.
- 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.
See above. I think the existing policy requirements for EV Roots and
non-EV Roots are exactly the same (perhaps with the exception of 17.7,
in which if a CA can demonstrate that the non-EV Root CA was following
this rule during the key generation ceremony, it should be accepted).
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.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
