On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote:
> On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote:
> > (Resending after I typo'd the ML address)
> >
> > At the risk of further embarrassing myself in the same week, while
> > working further on mimicking Fire
On Friday, February 8, 2019 at 7:25:08 PM UTC-8, Jakob Bohm wrote:
> On 09/02/2019 01:36, Santhan Raj wrote:
> > On Friday, February 8, 2019 at 4:09:32 PM UTC-8, Joanna Fox wrote:
> >> I agree on the surface this bug appears to be the same, but the root cause
> >> is
On Friday, February 8, 2019 at 4:09:32 PM UTC-8, Joanna Fox wrote:
> I agree on the surface this bug appears to be the same, but the root cause is
> a different. The issue for bug 1462844 was a specific status not counting as
> active when it was. To mitigate this issue, we updated the query to i
t was likely the
> > starter cert that MyEtherWallet.com first went with before securing an EV
> > cert.
> >
> > On Wed, Apr 25, 2018 at 11:42 AM, Santhan Raj via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On We
On Wednesday, April 25, 2018 at 1:57:28 AM UTC-7, Ryan Hurst wrote:
> On Tuesday, April 24, 2018 at 5:29:05 PM UTC+2, Matthew Hardeman wrote:
> > This story is still breaking, but early indications are that:
> >
> > 1. An attacker at AS10297 (or a customer thereof) announced several more
> > spec
On Wednesday, January 10, 2018 at 1:33:31 AM UTC-8, jo...@letsencrypt.org wrote:
> At approximately 5 p.m. Pacific time on January 9, 2018, we received a report
> from Frans Rosén of Detectify outlining a method of exploiting some shared
> hosting infrastructures to obtain certificates for domain
On Wednesday, August 2, 2017 at 6:44:51 PM UTC-7, Peter Bowen wrote:
> On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy
> wrote:
> > Today, DigiCert and Symantec announced that DigiCert is acquiring the
> > Symantec CA assets, including the infrastructure, personnel, roots, an
On Wednesday, June 21, 2017 at 12:02:51 PM UTC-7, Jonathan Rudenberg wrote:
> > On Jun 21, 2017, at 14:41, urijah--- via dev-security-policy
> > wrote:
> >
> > Apparently, in at least one case, the certificate was issued directly(!) to
> > localhost by Symantec.
> >
> > https://news.ycombinato
> > For the kind of RA that only does specific relevant parts of validation
> > (a "traditional" RA), the suggested policy as written would "simply"
> > require the CA to set up and maintain one (set of) subCAs for each of
> > their RAs, while your rephrasing as a ban on RA/DTP relationships would
On Friday, February 24, 2017 at 5:12:43 PM UTC-8, Peter Bowen wrote:
> "auditing standards that underlie the accepted audit schemes found in
> Section 8.1"
>
> This is obviously a error in the BRs. That language is taken from
> Section 8.1 and there is no list of schemes in 8.1.
>
> 8.4 does hav
On Monday, February 13, 2017 at 3:14:06 PM UTC-8, Santhan Raj wrote:
> On Monday, February 13, 2017 at 4:22:34 AM UTC-8, Gervase Markham wrote:
>
> > That is why, despite some IPR-related tangles, Mozilla will be requiring
> > in its next CA Communication that all CAs move t
On Monday, February 13, 2017 at 4:22:34 AM UTC-8, Gervase Markham wrote:
> That is why, despite some IPR-related tangles, Mozilla will be requiring
> in its next CA Communication that all CAs move to using only those
> documented methods in a fairly short timeframe, regardless of what the
> BRs sa
If a domain administrator approves a request without checking why/who needs the
cert, there is little a CA can do to mitigate such threats.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev
> Certificates that are capable of being used to issue new certificates MUST
> either be Technically Constrained in line with section 7.1.5 and audited in
> line with section 8.7 only, or Unconstrained and fully audited in line with
> all remaining requirements from this section
>
> Section 8.7
14 matches
Mail list logo
