Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
2020-07-15 12:30 GMT-04:00 Chema López via dev-security-policy : > El martes, 14 de julio de 2020 a las 9:02:01 UTC+2, Filippo Valsorda escribió: > > > > This whole argument seems to lose track of the difference between CAs and > > RPs. CAs have strict responsibilities to follow all the rules of the > > policies they committed to in order to be trusted by RPs. Full stop. There > > is no blaming RPs for a CA's failure to follow those rules. RPs, > > themselves, only have a responsibility to their users—not to the CAs—and > > uphold it as they see fit. > > > > I utterly agree with you at this point, Filippo. Especially when you state > that "RPs, themselves, only have a responsibility to their users—not to the > CAs—and uphold it as they see fit. ". If the RP does not check what they > shall to be sure if a specific item is trustworthy, it is up to them and > their clients. But, again, if the RP does not check what they shall to be > sure if a specific item is trustworthy, it is not CA's fault. Do we agree on > that? What the RPs do have little direct bearing on the CAs responsibilities, yes. (Indirectly, RPs forge policies that allow them to operate safely.) The CAs have to follow the policies regardless of whether the RPs are behaving correctly or not, and regardless of whether it impacts the RPs or not. RPs are also allowed to rely on all and any parts of the policies, because CAs are supposed to follow them all. It seems we agree on that, but disagree on the interpretation of the rules, so I'll skip ahead. > > RPs trust the CAs to do exactly what they say in the policies, not to do > > something that is sort of the same as long as the RPs follow the > > specification correctly. That's not the deal. We trust the CAs only because > > and as long as they show they can precisely follow those policies. > > And, in general, CAs show that they can precisely follow those policies. > > For example, let's see the beginning of this thread: > - "Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST > include an id-pkix-ocsp-nocheck extension." > - but BR also state: Section 7.1.2.2. Subordinate CA Certificate " e. > keyUsage This extension MUST be present and MUST be marked critical. Bit > positions for keyCertSign and cRLSign MUST be set. If the Subordinate CA > Private Key is used for signing OCSP responses, then the digitalSignature bit > MUST be set. ". This section is align with RFC5280 and RFC6960 > > So, an ICA or SCA cert. without keyUsage set to digitalSignature is not an > OCSP Responder. Full stop. We can agree that this would be kind of a weird > certificate, but it is not a valid OCSP responder certificate and RPs > shouldn't trust their responses. I implement and sometimes write RFCs as a day job, and this interpretation of "MUST" is new to me. Let me pull up an RFC I am familiar with, for example RFC 8446. Section 4.1.4. Hello Retry Request states: > The server's extensions MUST contain "supported_versions". By your interpretation if a TLS client receives a Hello Retry Request message that does not contain a "supported_versions" extension, then it's not an HRR message, the client should not consider it a HRR message, and... ignore it? All of the other rules that apply to HRR messages don't apply anymore? This is such a mismatch in the understanding of how policies _work_ between you and most* *(as Ryan pointed out) RPs that I don't think it matters who's right. If we are not on the same page on how to fundamentally read the rules, there is no way to communicate and trust each other. Needless to say, that's _a problem_ and RPs don't have a lot of pleasant ways to fix it. (Because of course, RPs owe it to their users to only trust CAs they can effectively communicate with, so that they can agree on a set of mutually understood policies they can trust the CAs to follow, in order to protect the users. When there's a mismatch, incidents like this happen.) We can discuss here what "MUST" means in our personal capacities, but when speaking in your professional capacity, my personal advice is to acknowledge how RPs interpret the language in the policies and try to demonstrate you can understand and abide by that. Anything else is unworkable, I'm afraid. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Wed, Jul 15, 2020 at 12:30 PM Chema López via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > So, an ICA or SCA cert. without keyUsage set to digitalSignature is not an > OCSP Responder. Full stop. False. Full stop. I mentioned in my reply to Corey, but I think it's disastrous for trust for a CA to make this response. I realize you qualified this as a personal capacity, but I want to highlight you're also seeming to make this argument in a professional capacity, as highlighted by https://bugzilla.mozilla.org/show_bug.cgi?id=1649943 . My hope is that, in a professional capacity, you'll respond to that issue as has been requested. Absent a further update, it may be necessary and appropriate to have a discussion as to whether continued trust is warranted, because there's a lack of urgency, awareness, transparency, and responsiveness to this issue. I appreciate you quoting replies from the thread, but you also seem to have cherry-picked replies that demonstrate an ignorance or lack of awareness about the actual PKI ecosystem. * macOS does not require the digitalSignature bit for validating OCSP responses * OpenSSL does not require the digitalSignature bit for validating OCSP responses * GnuTLS does not require the digitalSignature bit for validating OCSP responses * Mozilla NSS does not require the digitalSignature bit for validating OCSP responses * As best I can tell, Microsoft CryptoAPI does not require the digitalSignature bit for validating OCSP responses (instead relying on pkix-nocheck) Mozilla code explicitly stated and referenced the fact that the digitalSignature bit was not only seen as not necessary, but harmful for interoperability, due to CAs. You cannot pretend these are not OCSP responders simply because you haven't issued OCSP responses (intent). They are, for every purpose, OCSP responders that are misissued. And you need to treat this with the urgency, seriousness, gravity, and trustworthiness required. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
El martes, 14 de julio de 2020 a las 9:02:01 UTC+2, Filippo Valsorda escribió: > This whole argument seems to lose track of the difference between CAs and > RPs. CAs have strict responsibilities to follow all the rules of the policies > they committed to in order to be trusted by RPs. Full stop. There is no > blaming RPs for a CA's failure to follow those rules. RPs, themselves, only > have a responsibility to their users—not to the CAs—and uphold it as they see > fit. > I utterly agree with you at this point, Filippo. Especially when you state that "RPs, themselves, only have a responsibility to their users—not to the CAs—and uphold it as they see fit. ". If the RP does not check what they shall to be sure if a specific item is trustworthy, it is up to them and their clients. But, again, if the RP does not check what they shall to be sure if a specific item is trustworthy, it is not CA's fault. Do we agree on that? Some evidences that some RPs at least have doubts if they are doing things correctly would this comment in Chromiums OCSP code: // TODO(eroman): Not all properties of the certificate are verified, only the // signature and EKU. Can full RFC 5280 validation be used, or are there // compatibility concerns? And this fact, as a user of Chromium based browser that I am, awakens conflicting feelings in me: on one hand, I appreciate the transparency; on the other, I'm not sure when a Chromium based browser is trusting in a certificate, if the browser is checking what it shall. > RPs trust the CAs to do exactly what they say in the policies, not to do > something that is sort of the same as long as the RPs follow the > specification correctly. That's not the deal. We trust the CAs only because > and as long as they show they can precisely follow those policies. And, in general, CAs show that they can precisely follow those policies. For example, let's see the beginning of this thread: - "Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST include an id-pkix-ocsp-nocheck extension." - but BR also state: Section 7.1.2.2. Subordinate CA Certificate " e. keyUsage This extension MUST be present and MUST be marked critical. Bit positions for keyCertSign and cRLSign MUST be set. If the Subordinate CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set. ". This section is align with RFC5280 and RFC6960 So, an ICA or SCA cert. without keyUsage set to digitalSignature is not an OCSP Responder. Full stop. We can agree that this would be kind of a weird certificate, but it is not a valid OCSP responder certificate and RPs shouldn't trust their responses. It seems it is also clear to more people, according to: - https://bugzilla.mozilla.org/show_bug.cgi?id=1652581 - https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13541.html - https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13599.html > "No, you see, it's actually your fault" is the least trustworthy reaction I > can possibly imagine to being caught not following the policy. > Not worth commenting on > As an outsider (because again I speak in my personal capacity, and at most I > work on a non-browser RP, Go's crypto/x509) it's puzzling to see the > CA/Browser forum regularly lose track of the different roles of the > participants. I would like to make it clear that I speak in my personal capacity too, and my fault in previous messages has been to use Corporate email Thanks. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
