>> 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. > You're reading an obligation on the CA, not an obligation on the client. It’s an obligation on the client, because the verb “processed” makes no sense if the intent were to restrict only CAs. >> 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. If there’s no digitalSignature KU, then the certificate is not a OCSP responder certificate due to the technical inability to sign OCSP responses that would be accepted by clients conforming to RFC 5280, section 4.2.1.12. Therefore, section 4.9.9 is not applicable for those certificates that not express the digitalSignature KU. This is directly relevant to the topic at hand. Thanks, Corey From: Ryan Sleevi <r...@sleevi.com> Sent: Thursday, July 2, 2020 10:59 AM To: Corey Bonnell <cbonn...@securetrust.com> Cc: r...@sleevi.com; Neil Dunbar <ndun...@trustcorsystems.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs On Thu, Jul 2, 2020 at 10:47 AM Corey Bonnell <cbonn...@securetrust.com <mailto: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 ><http://scanmail.trustwave.com/?c=4062&d=5Pb93gULBMmYYjWfo2KCGEGxPtFEeeo_pjimEvYGzQ&s=5&u=http%3a%2f%2f4%2e2%2e1%2e12> > : 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
