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
