2021-01-19 18:01 GMT+01:00 Andrew Ayer via dev-security-policy
:
> It's troubling that even at this stage, Camerfirma still doesn't seem
> to grasp the seriousness of their compliance problems. Today,
> they are arguing that there was no security threat from a certificate
> issued for a domain
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
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:
>
2020-07-11 13:17 GMT-04:00 Oscar Conesa via dev-security-policy
:
> f) For CAs that DO have sole control of the keys: There is no reason to
> doubt the CA's ability to continue to maintain the security of these
> keys, so the CA could reuse the keys by reissuing the certificate with
> the same
2020-07-02 10:40 GMT-04:00 Ryan Sleevi via dev-security-policy
:
> On Thu, Jul 2, 2020 at 10:34 AM Paul van Brouwershaven via
> dev-security-policy wrote:
>
> > I did do some testing on EKU chaining in Go, but from my understand this
> > works the same for Microsoft:
> >
>
> Go has a bug
I am also personally surprised and confused by this announcement.
I could imagine of course incident reports being handled with more
leniency when the details reveal that the health emergency contributed
to the issue. I thought that was the point of the no exceptions policy,
to push the CAs to
6 matches
Mail list logo
