I'd like to chime-in on this particular topic because I had similar
thoughs with Pedro and Peter.
I would like to echo Pedro's, Peter's and other's argument that it is
unreasonable for Relying Parties and Browsers to say "I trust the CA
(the Root Operator) to do the right thing and manage their Root Keys
adequately", and not do the same for their _internally operated_ and
audited Intermediate CA Certificates. The same Operator could do "nasty
things" with revocation, without needing to go to all the trouble of
creating -possibly- incompatible OCSP responses (at least for some
currently known implementations) using a CA Certificate that has the
id-kp-OCSPSigning EKU. Browsers have never asked for public records on
"current CA operations", except in very rare cases where the CA was
accused of "bad behavior". Ryan's response on
https://bugzilla.mozilla.org/show_bug.cgi?id=1649939#c8 seems
unreasonably harsh (too much "bad faith" in affected CAs, even of these
CA Certificates were operated by the Root Operator). There are auditable
events that auditors could check and attest to, if needed, for example
OCSP responder configuration changes or key signing operations, and
these events are kept/archived according to the Baseline Requirements
and the CA's CP/CPS. This attestation could be done during a "special
audit" (as described in the ETSI terminology) and possibly a
Point-In-Time audit (under WebTrust).
We did some research and this "convention", as explained by others,
started from Microsoft.
In
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786428(v=ws.11),
one can read "if a CA includes EKUs to state allowed certificate usages,
then it EKUs will be used to restrict usages of certificates issued by
this CA" in the paragraph titled "Extended Key Usage Constraints".
Mozilla agreed to this convention and added it to Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=725351. The rest of the
information was already covered in this thread (how it also entered into
the Mozilla Policy).
IETF made an attempt to set an extention for EKU constraints
(https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/)
where Rob Stradling made an indirect reference in
https://groups.google.com/d/msg/mozilla.dev.security.policy/f5-URPoNarI/yf2YLpKJAQAJ
(Rob, please correct me if I'm wrong).
There was a follow-up discussion in IETF that resulted that noone should
deal with this issue
(https://mailarchive.ietf.org/arch/msg/spasm/3zZzKa2lcT3gGJOskVrnODPBgM0/).
A day later, all attempts died off because noone would actually
implement this(?)
https://mailarchive.ietf.org/arch/msg/spasm/_gJTeUjxc2kmDcRyWPb9slUF47o/.
If this extension was standardized, we would probably not be having this
issue right now. However, this entire topic demonstrates the necessity
to standardize the EKU existence in CA Certificates as constraints for
EKUs of leaf certificates.
We even found a comment referencing the CA/B Forum about whether it has
accepted that EKUs in CA Certificates are considered constraints
(https://mailarchive.ietf.org/arch/msg/spasm/Y1V_vbEw91D2Esv_SXxZpo-aQgc/).
Judging from the result and the discussion of this issue, even today, it
is unclear how the CA/B Forum (as far as its Certificate Consumers are
concerned) treats EKUs in CA Certificates.
CAs that enabled the id-kp-OCSPSigning EKU in the Intermediate CA
Profiles were following the letter of the Baseline Requirements to
"protect relying parties". According to the BRs 7.1.2.2:
/"Generally Extended Key Usage will only appear within end entity
certificates (as highlighted in RFC 5280 (4.2.1.12)), however,
Subordinate CAs MAY include the extension to further *protect
**r**elying parties* until the use of the extension is consistent
between Application Software Suppliers whose software is used by a
substantial portion of Relying Parties worldwide."/
So, on one hand, a Root Operator was trying to do "the right thing"
following the agreed standards and go "above and beyond" to "protect"
relying parties by adding this EKU in the issuing CA Certificate (at a
minimum it "protected" users using Microsoft that required this "EKU
Chaining"), and on the other hand it unintentionally tripped into a case
where a CA Certificate with such an EKU could be used in an OCSP
responder service to sign status messages for its parent.
There was also an interesting observation that came up during a recent
discussion. As mandated by RFC 5280 (4.2.1.12), EKUs are supposed to be
normative constrains to *end-entity Certificates*, not CA Certificates.
Should RFC 6960 need to be read in conjunction with RFC 5280 and not on
its own? Should conforming OCSP Clients to the Publicly-Trusted
Certificates (PTC) and BR-compliant solutions, implement both? If the
answer is yes, this means that a "conforming" OCSP client should not
place trust on the id-kp-OCSPSigning EKU in a *CA* Certificate
(basicConstraints: CA:TRUE). It is quite possible that browser PTC
conforming implementations, should not only take RFC 5280 into account
but also BRs 7.1.2.2, since this is the only normative policy
conformance tool for handling the EKUs in CA Certificates as a
constraint. This interpretation is consistent with what the CAs have
implemented, and is also consistent with the implementation of
mozilla::pkix code. Do others share this interpretation? It sounds a bit
"stretched" but it's not the first time we see different interpretations
on normative requirements. This is somewhat similar to Corey's
interpretation about the keyUsage extension.
I support analyzing the practical implications on existing Browser
software to check if existing Web Browsers verify and accept an OCSP
response signed by a delegated CA Certificate (with the
id-kp-OCSPSigning EKU) on behalf of its parent. We already know the
answer for Firefox. Do we know whether Apple, Chromium and Microsoft web
browsers treat OCSP responses signed from delegated CA Certificates
(that include the id-kp-OCSPSigning EKU) on behalf of their parent
RootCA, as valid? Some tests were performed by Paul van Brouwershaven
https://gist.github.com/vanbroup/84859cd10479ed95c64abe6fcdbdf83d. This
does not dismiss any of the previous statements of putting additional
burden on clients or the security concerns, it's just to assess this
particular incident with particular popular web browsers. This analysis
could be taken into account, along with other parameters (like existing
controls) when deciding timelines for mitigation, and could also be used
to assess the practical security issues/impact. Until this analysis is
done, we must all assume that the possible attack that was described by
Ryan Sleevi can actually succeed with Apple, Chrome and Microsoft Web
browsers.
As others have already highlighted, estimating the real practical attack
threat and likeliness of occuring, is critical to the remediation
timeline, because it affects not just TLS-server issuingCAs but even
Technically Constrained non-TLS ones, some of which are unaudited.
Finally, a lot has been said about separate hierarchies per usage. Ryan
Sleevi, representing Google Chrome at the CA/B Forum, is very clear
about Google's position pushing for separate hierarchies per usage [1].
It would be greatly appreciated if there were similar positions from
other Certificate Consumers that handle more than the server TLS usage
in their Root Stores (Apple, Microsoft and Mozilla). I plan on starting
such a discussion as stated in [1] at the CA/B Forum, but since this is
a Mozilla Forum, it would be great if we could have the position of the
Mozilla CA Certificate Policy owner. If this position is aligned with
Google's, as Rufus highlighted, some pages on the wiki (and possibly the
policy?) will need to be updated to highlight this position. When new
CAs apply, they should clearly be guided, with a "strong preference", to
include separate hierarchy for S/MIME and separate for server TLS. A
plan could also be discussed for existing included CAs that currently
have both trust bits enabled in their Roots, which is the majority
judging from
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport.
Thanks,
Dimitris.
[1]:
https://lists.cabforum.org/pipermail/servercert-wg/2020-July/002048.html
On 2020-07-03 3:09 π.μ., Ryan Sleevi via dev-security-policy wrote:
On Thu, Jul 2, 2020 at 6:42 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Does the operator of a root and it’s hierarchy have the right to delegate
OCSP responses to its own responders?
If your answer is “No”, then I don’t have anything else to say, but if
your answer is “Yes”, then I’ll be having still a hard time to see the
security risk derived of this issue.
Yes. But that doesn't mean we blindly trust the CA in doing so. And that's
the "security risk".
I totally appreciate that your argument is "but we wouldn't misuse the
key". The "risk" that I'm talking about is how can anyone, but the CA, know
that's true? All of the compliance obligations assume certain facts when
the CA is operating a responder. This issue violates those assumptions, and
so it violates the controls, and so we don't have any way to be confident
that the key is not misused.
I think the confusion may be from the overloading of the word "risk". Here,
I'm talking about "the possibility of something bad happening". We don't
have any proof any 3P Sub-CAs have mis-signed OCSP responses: but we seem
to agree that there's risk of that happening. It seems we disagree on
whether there is risk of the CA themselves doing it. I can understand the
view that says "Of course the CA wouldn't", and my response is that the
risk is still the same: there's no way to know, and it's still a
possibility.
I can understand that our views may differ: you may see 3P as "great risk"
and 1p as "acceptable risk". However, from the view of a browser or a
relying party, "1p" and "3p" are the same: they're both CAs. So the risk is
the same, and the risk is unacceptable for both cases.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
