2020-07-13 13:39 GMT-04:00 Chema Lopez via dev-security-policy 
<dev-security-policy@lists.mozilla.org>:
> From my point of view, the arguments at
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13642.html
> are
> as incontestable as the ones stated by Corey Bonnell here:
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13541.html
> .
> 
> 
> RFC5280 and RFC6960 have to be considered and thus, a certificate without
> KU digitalSignature is not an OCSP Responder. We can not choose what to
> comply with or what is mandatory or if a RFC is mandatory but BR "profiles"
> the RFC. And when I say "we" I mean all the players, especially the ones in
> the CA / Browser forum.
> 
> 
> And yes, relying parties need to check this. For its own benefit, relying
> parties need to understand how a proper OCSP response is made and check it
> properly.
> 
> 
> It is astonishing how what looks like a bad practice of (some) relying
> parties has mutated into a security risk at CAs side.

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.

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. "No, you see, it's actually 
your fault" is the least trustworthy reaction I can possibly imagine to being 
caught not following the policy.

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.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to