On Tue, Sep 19, 2017 at 3:09 PM, Nick Lamb via dev-security-policy
wrote:
> I have no doubt that this was obvious to people who have worked for a public
> CA, but it wasn't obvious to me, so thank you for answering. I think these
> answers give us good reason to be confident that a cross-signed
On Tue, Sep 19, 2017 at 10:49 PM, userwithuid via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Either way, in the specific case, StartCom, this criticism seems to be
> inapplicable, as the revoked one was never deployed in the first place.
I don't think that's a fair con
On Monday, September 18, 2017 at 1:58:03 AM UTC, Ryan Sleevi wrote:
> I agree, Gerv's remarks are a bit confusing with respect to the concern.
> You are correct that the process of establishing a new root generally
> involves the creation of a self-signed certificate, and then any
> cross-signing t
Hi all,
On Friday, Sep 15, we discovered that 1090 certificates were rekeyed using
expired domain validation documents. In each case, the original
certificate's domain was properly verified at time of issuance using an
approved method. Organization verification properly completed for each
rek
On Tuesday, September 19, 2017 at 10:13:26 AM UTC-5, Gervase Markham wrote:
> >From the above, we see that Visa only issues certificates to their own
> customers/clients, and not to the public. They believe that this permits
> them to keep confidential details of the certificates which they wish t
On Tuesday, September 19, 2017 at 10:37:20 AM UTC-5, Gervase Markham wrote:
> On 19/09/17 14:58, Nick Lamb wrote:
> > An attacker only has to _prefer_ one particular CA for any reason,
>
>
> Yep, fair.
>
> Gerv
Quite true. In the example scenario that I have just posted, such preference
might
On Tuesday, September 19, 2017 at 8:02:36 AM UTC-5, Gervase Markham wrote:
> I'd be interested in your engagement on my brief threat modelling; it
> seems to me that DNSSEC only adds value in the scenario where an
> attacker has some control of CA Foo's issuance process, but not enough
> to overri
Forwarded Message
Subject: Summary of September 2017 Audit Reminder Emails
Date: Tue, 19 Sep 2017 19:00:08 + (GMT)
Mozilla: Overdue Audit Statements
Root Certificates:
Autoridad de Certificacion Firmaprofesional CIF A62634068
Standard Audit: https://cert.webtrust.org/SealF
On 19/09/17 14:58, Nick Lamb wrote:
> An attacker only has to _prefer_ one particular CA for any reason,
Yep, fair.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On 19/09/17 16:27, Peter Bowen wrote:
> I think your statement is a little broad. Every CA only issues
> certificates to themselves and their own customers (or as the BRs call
> them "Subscribers").
Yes, you are right. "Customers" was the wrong word. Perhaps I rather
meant they only issue to "o
On Tue, Sep 19, 2017 at 8:12 AM, Gervase Markham via
dev-security-policy wrote:
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1391087 , as part of
> their comments on a report of BR-non-compliant certificate issuance, a
> representative of VISA said the following:
>
> "Visa has been operating
https://crt.sh/mozilla-certvalidations?group=version&id=896972 is a very
informative graph for me -- this is the number of validations performed by
Firefox for certs under this CA. It looks like at the absolute peak, there
were 1000 validations in a day. That's very little value for our users, in
r
In https://bugzilla.mozilla.org/show_bug.cgi?id=1391087 , as part of
their comments on a report of BR-non-compliant certificate issuance, a
representative of VISA said the following:
"I would like to share with you some details regarding our PKI System
and our position within the CA/Browser Forum.
On Tuesday, 19 September 2017 15:46:09 UTC+1, Franck Leroy wrote:
> 1/ When we use our root, we produce a key ceremony report.
> 2/ The signature value doesn’t appears in the report so it is not possible to
> reproduce the certificate.
> 3/ My safe is in a closet which I don’t have the key, so I
On Tuesday, September 19, 2017 at 3:46:09 PM UTC+1, Franck Leroy wrote:
> Le lundi 18 septembre 2017 17:28:44 UTC+2, Nick Lamb a écrit :
> > On Monday, 18 September 2017 15:50:16 UTC+1, Franck Leroy wrote:
> > > This control that StartCom was not allowed to use our path was technical
> > > in pla
Le lundi 18 septembre 2017 17:28:44 UTC+2, Nick Lamb a écrit :
> On Monday, 18 September 2017 15:50:16 UTC+1, Franck Leroy wrote:
> > This control that StartCom was not allowed to use our path was technical in
> > place by the fact that I was the only one to have the intermediate cross
> > signe
Hi Gerv
>
> But once the cross-signed cert is publicly available (and it is; it's in CT,
> however it got there), all of those certificates become trusted (or
> potentially
> trusted, if the owner reconfigures their webserver to serve the intermediate,
> or if Firefox has already encountered it
On Tuesday, 19 September 2017 14:02:36 UTC+1, Gervase Markham wrote:
> I'd be interested in your engagement on my brief threat modelling; it
> seems to me that DNSSEC only adds value in the scenario where an
> attacker has some control of CA Foo's issuance process, but not enough
> to override the
Hi Inigo,
On 15/09/17 17:30, Inigo Barreira wrote:
> There wasn´t a lack of integrity and monitoring, of course not. All PKI logs
> were and are signed, it´s just the auditors wanted to add the integrity to
> other systems which is not so clear that should have this enabled. For
> example, if y
On 19/09/2017 14:59, Gervase Markham via dev-security-policy wrote:
> It might also be worth thinking about the value that DNSSEC adds, over
> and above a non-secure CAA check, in various attack scenarios. At the
> moment, I'm thinking that DNSSEC doesn't necessarily add much. Here are
> 3 quick sc
On 15/09/17 09:38, richmoor...@gmail.com wrote:
> I suspect many smaller CAs are non-compliant too, for example gandi's CPS
> hasn't changed since 2009 according to its changelog.
>
> https://www.gandi.net/static/docs/en/gandi-certification-practice-statement.pdf
Thank you for bringing this to m
On 13/09/17 23:57, Matthew Hardeman wrote:
> This is especially the case for CAA records, which have an explicit security
> function: controlling, at a minimum, who may issue publicly trusted
> certificates for a given FQDN.
I'd be interested in your engagement on my brief threat modelling; it
s
Hi Nick,
On 13/09/17 20:39, Nick Lamb wrote:
> Gerv, rather than start by digging into the specific technical details, let
> me ask a high level question.
>
> Suppose I have deployed DNSSEC for my domain tlrmx.org and I have a CAA
> record saying to only permit the non-existent Gotham Certifica
Hi Franck,
On 18/09/17 15:49, Franck Leroy wrote:
> Our understanding in April was that as long as StartCom is not
> allowed by Certinomis to issue EE certs, the disclosure was not
> mandated immediately.
I think that we need to establish a timeline of the exact events
involved here.
But I would
On 15/09/17 15:35, Inigo Barreira wrote:
> No, those weren´t tests. We allowed the use of curves permitted by the BRs
> but this issue came up in the mozilla policy (I think Arkadiusz posted) and I
> also asked about it in the last CABF F2F (I asked Ryan about it) and then,
> with that outcome a
25 matches
Mail list logo
