Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Hi Christian,
I think your concern is about how our code will enforce this. Because our
policy only applies to roots that are built in, our intent is to have our
code apply this restriction only to certificates that chain up to built-in
roots.
Thanks,
Ben

On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:
> >
> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
>
> Hi,
>
> blog post should clarify if this is valid for certificates issued by
> preinstalled root CAs only or also for CAs installed by user.
>
>
> regards
> Christian
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
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

[Filippo Valsorda via dev-security-policy]

2020-07-13 13:39 GMT-04:00 Chema Lopez via dev-security-policy 
:
> 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