2020-07-15 12:30 GMT-04:00 Chema López via dev-security-policy <dev-security-policy@lists.mozilla.org>: > 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
