Dear Mr. Wilson,
Could you please share the risk assessment that you have received from
Mr. Sleevi?
I believe it would be very useful for the CAs to understand the gravity
of the issue.
Sincerely yours,
T.K. (No hat)
On 7/4/2020 12:23 PM, Ryan Sleevi via dev-security-policy wrote:
On Fri, Jul 3, 2020 at 10:49 PM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I don’t understand why you’re making a distinction as to CA certificates,
which are irrelevant with respect to the Delegated Responder profile. That
is, you’re trying to find a way that it’s compliant, but this introduction
of the CA bit as somehow special doesn’t have any basis, as far as I can
tell.
The argument you're asserting is akin to someone saying that a CA
certificate with serverAuth EKU is mis-issued if the subject Common Name is
"Super Duper High Assurance Issuing CA", which is not a hostname in
preferred DNS syntax. After all, the EKU definition for serverAuth in RFC
5280 states that certificates expressing that EKU value are used for TLS
server authentication, and clearly that is a malformed hostname so the
certificate can't be used for its intended purpose. In essence, the
argument you're presenting applies the end-entity profile definition to the
CA certificate profile for that EKU, which doesn't make sense.
I appreciate the comparison, but we both know that it's a flawed one.
You're inventing a distinction - the CA bit - that doesn't exist, within
the BRs or the RFCs.
Nothing in the RFCs specifies the profile you describe for commonName.
That's something the BRs do, and they explicitly do it contingent upon the
CA bit (Subordinate CA vs Subscriber Cert)
You're inventing a fiction that, no doubt, reflected a belief of some CAs
when they did it. But no such distinction exists within the profiles, and
it was, as far as I can tell, only Mozilla, and only in one of the three
verifiers (i.e. not applying to Thunderbird/S/MIME) that took the step to
profile things further.
The distinction you make, about KU, falls apart when you realize the
distinction you're making here, about CAs, is also made up.
Where? It seems you’re reading this as inferred through omission of a
prohibition in Section 5.3, but you’re using it in the remainder of your
argument to argue why it’s proactively allowed.
Ben's email from last evening [1] clearly stated that Mozilla has allowed
ocspSigning alongside other EKUs and the concrete example given was a CA
certificate that expresses the serverAuth and ocspSigning EKUs [2].
Notably, this certificate also lacks the digitalSignature KU bit.
I think this is dangerously close to divination. Mozilla did not chase down
non-compliance. That didn't mean it wasn't non-compliant, just that Mozilla
didn't enforce it, just like Microsoft didn't enforce their policy. That
doesn't mean it was/is allowed by the BRs, and it doesn't mean that the
non-compliance doesn't pose serious security risk.
But I can’t get the view that says, even in 2020, that a Thing is Not a
Thing, which in this case is a Delegated Responder. Just like I can’t
understand folks who say a Sub-CA is not a Sub-CA if it’s a
Cross-Certificate.
I think there's a world of difference between these two cases. In the
former case, there are technical controls for certificates used in a RFC
5280 PKI such that a CA certificate that expresses the ocspSigning EKU but
no digitalSignature KU bit will not have any OCSP responses created by the
CA trusted by clients. In the latter case, I entirely agree with you: the
only assurance that a "Cross-Certificate" can't be used to issue end-entity
certificates is pinky swears and promises and therefore must be treated as
a Sub-CA, because it technically is a Sub-CA.
"will not have any OCSP responses created by the CA trusted by clients". I
can literally show you the clients that do trust this, including Major
Ones. Even Mozilla doesn't check the Key Usage -
https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/mozpkix/lib/pkixocsp.cpp#127
We've already shown, however, that your argument about the "invalid" key
usage is still a Mozilla Program Violation, in that it violates what you're
declaring a defense mechanism (RFC 5280) by including an EKU not consistent
with the extensions. This isn't a question about the BRs allowing such
violations: they make no such statements.
However, I'm more concerned by your latest message, in which you dismiss
the very real security concern. That's something I think truly is dangerous
here, especially for CAs following, because you're simply not correct to
dismiss the concern. I also don't think it's correct to come up with a
fiction that, because something not written in any spec (that responder
certs are CA:FALSE) makes it OK to include the EKU to facilitate another
behaviour not written in any spec (EKU chaining), and to do so ignoring
both the RFC's profile (requiring KU) and the BRs profile (requiring
nocheck).
