On Thu, Jul 2, 2020 at 10:47 AM Corey Bonnell <cbonn...@securetrust.com>
wrote:
> > No, this isn’t specified/required for Delegated Reaponders (at least,
> by 6960), and the client implementations I looked at did not check.
>
>
>
> From RFC 5280, section 4.2.1.12:
>
> If a certificate contains both a key usage extension and an extended
>
> key usage extension, then both extensions MUST be processed
>
> independently and the certificate MUST only be used for a purpose
>
> consistent with both extensions.
>
> …
>
> id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
>
> -- Signing OCSP responses
>
> -- Key usage bits that may be consistent: digitalSignature
>
> -- and/or nonrepudiation
>
>
>
> If clients aren’t checking for digitalSignature keyUsage when verifying
> OCSP responses signed by a delegated responder, that seems like a client
> implementation bug.
>
You're reading an obligation on the CA, not an obligation on the client.
I think it might be useful, if you'd like to talk about client mitigation
strategies, to start a separate thread. I agree, there's definitely useful
opportunities here, but there is no reasonable defense that the CA has not
introduced a meaningful security issue here by violating the BRs.
> > RFC 6960 is clear that the EKU indicates a designated responder, and
> you can’t “take back” that by suggesting the lack of the KU, as required by
> 5280, or the lack of nocheck, as required by the BRs, makes it “not a
> Responder”. It just makes it “not a correctly issued responder”.
>
>
>
> I don’t think it’s that clear-cut, as there’s an impedance mismatch
> between the use of EKU in CA certificates to enforce policy and IETF work
> products. In other words, several Root Programs/the BRs have used EKU in CA
> certificates to denote policy scope, whereas the IETF in its various
> standards have the assumption that EKU is generally only expressed in
> end-entity certificates. I think that this interplay needs to be kept in
> mind when reading RFC 6960 and asserting whether or not the sole determiner
> on whether a CA certificate is an OCSP responder certificate is the
> presence of the ocspSigning EKU.
>
I directly acknowledged that interplay, but it does not justify the
violation, nor ameliorate the security risk.
I wanted to nip this argument in the bud, because I have zero tolerance for
it, as it is fundamentally the question of intent. This is the same
argument regarding "We didn't intend for this to be able to issue TLS
certs, it just could", or the "We didn't intend for this sub-CA to be
unconstrained, it just was" or "We didn't intend to give a
basicConstraints:CA=TRUE certificate to a subscriber, it just happened". As
consumers of client certs, we sadly like insight into the ever complex and
tortured minds of those operating CAs, and cannot discern intent. We have
the certificate in front of us. And the certificate in front of us is,
unambiguously, a Delegated Responder. And lacks the requisite extension.
A wholly irresponsible argument would be "We clearly didn't intend for it.
Look, you can see that: we didn't comply with the certificate profile
specified! We omitted pkix-nocheck and the KU". I don't think that's the
argument you're making, or at least, I hope not, because that's a CA asking
to be judged based on how they feel, rather than what they do and how well
they do it. And I don't think anyone wants feelings to be introduced as the
primary factor when deciding whether to continue trusting a CA or not.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
