Re: Unrevocation of BT Class 2 CA - G2 CA Certificate

Here is the report Ben filed in the bug. He tried to send it to the list but for some reason it was rejected as spam. Dear Mozilla Community, As part of our efforts to meet the April 15 requirements imposed by the Mozilla Root Store Policy v.2.5, DigiCert has been reviewing

Unrevocation of BT Class 2 CA - G2 CA Certificate

I've filed an incident report here: https://bugzilla.mozilla.org/show_bug.cgi?id=1442091 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

On Wednesday, February 28, 2018 at 10:42:25 AM UTC-8, Alex Gaynor wrote: > If the "fail verification only" option is not viable, I personally think we > shouldn't expose this to extensions. > I agree, there are far too many ways this will be abused and the cases in which it would be useful are

Re: How do you handle mass revocation requests?

Trustico doesn't seem to provide any hosting or CDN services that would make use of the private key, nor do they appear to explicitly inform users about the storage of this private key. In their statement, they say they keep the private keys explicitly to perform revocation as necessary:

Re: How do you handle mass revocation requests?

On Wednesday, February 28, 2018 at 4:44:50 PM UTC-6, Jeremy Rowley wrote: > 1) Not all of the certificates being revoked use the Symantec hierarchy. > There are some certs that use the DigiCert replacement hierarchy. Not many > though. > 2) Sorry my wording was strange. It almost always is. What

RE: How do you handle mass revocation requests?

1) Not all of the certificates being revoked use the Symantec hierarchy. There are some certs that use the DigiCert replacement hierarchy. Not many though. 2) Sorry my wording was strange. It almost always is. What I meant, is Trustico specifically asked for the certs to be revoked within 24

Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 5:23 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, February 28, 2018 at 3:55:37 PM UTC-6, Ryan Duff wrote: > > >From what I've read, it appears the situation here is that Trustico > wanted to revoke all their

Re: How do you handle mass revocation requests?

On Wednesday, February 28, 2018 at 3:55:37 PM UTC-6, Ryan Duff wrote: > >From what I've read, it appears the situation here is that Trustico wanted > >to revoke all their customer certs from Digicert so they could do a mass > >migration to another CA (which is not a proper reason to revoke).

Re: [cabfpub] How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 4:50 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Posted to cab forum accidentally instead of Mozilla dev > > > Begin forwarded message: > > From: Jeremy Rowley > > Date:

Re: How do you handle mass revocation requests?

No. Just the 23k. Part of the reason I posted to the Mozilla list are open questions about whether Trusticos request is sufficient to trigger the br requirements. My gut is no, and sounds like the browsers agree. We’ll only revoke the remaining 27k if we receive evidence of compromise On Feb

Re: How do you handle mass revocation requests?

>From what I've read, it appears the situation here is that Trustico wanted to >revoke all their customer certs from Digicert so they could do a mass >migration to another CA (which is not a proper reason to revoke). When asked >for proof by Digicert that the certificates were compromised and

Re: How do you handle mass revocation requests?

> Basically, we're revoking 50k people without > being able to explain why (well, other than the key was compromised). Unless I misunderstood, you originally said you received 23k compromised keys and are revoking those. > Currently, we are only revoking the certificates if we received the

Fwd: [cabfpub] How do you handle mass revocation requests?

Posted to cab forum accidentally instead of Mozilla dev Begin forwarded message: From: Jeremy Rowley > Date: February 28, 2018 at 2:33:41 PM MST To: Ryan Sleevi >, Geoff Keating

RE: How do you handle mass revocation requests?

Yep - that was you. Thanks a ton. We posted 10 CSRs so far. Is this what you were thinking? -Original Message- From: Nick Lamb Sent: Wednesday, February 28, 2018 2:37 PM To: dev-security-policy@lists.mozilla.org Cc: Jeremy Rowley Subject:

RE: How do you handle mass revocation requests?

We don't have a process to prevent third parties from storing private keys. I'm not sure how that would even work considering the approved third-party use cases vs. non-approved use cases. In fact, I'd postulate there's nothing wrong with Trustico holding the private keys if they were hosting the

Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 4:23 PM, urijah--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Is Trustico's storage of private keys related to this security report from > a few months back (which did not appear to ever have been fully > investigated...)? > It was fully

Re: How do you handle mass revocation requests?

On Wed, 28 Feb 2018 20:03:51 + Jeremy Rowley via dev-security-policy wrote: > The keys were emailed to me. I'm trying to get a project together > where we self-sign a cert with each of the keys and publish them. > That way there's evidence to the

Re: How do you handle mass revocation requests?

Is Trustico's storage of private keys related to this security report from a few months back (which did not appear to ever have been fully investigated...)? https://groups.google.com/d/msg/mozilla.dev.security.policy/CEww8w9q2zE/F_bzX1guCQAJ Does Digicert have (or will it have) some sort of

RE: How do you handle mass revocation requests?

It’s absolutely incredible that Trustico has 23k private keys, and just attached them to an email. This suggests serious flaws in the CA/reseller relationship. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: How do you handle mass revocation requests?

Did this whole thing start because someone at Trustico wanted to accelerate the process of getting their resold Symantec certificates reissued under a DigiCert trust path? And somehow some misinformed soul imagined creating a revocation crisis would somehow help achieve that goal without

Re: TunRootCA2 root inclusion request

Dear Jonathan, Given the misissued certificates in CT under the existing root, I believe this request should be rejected, and a new clean root with audits should be required before moving forward. ==>All the misissued certificates have been revoked by the NDCA and new correct ones were

Re: How do you handle mass revocation requests?

I would echo Mr. Gaynor's point. While it's perhaps a pedantic distinction, the private keys are definitely compromised now and were the moment that Trustico provided the keys to Digicert, even if Trustico is defined to be the original authorized recipient. The CA is explicitly not to be in

Re: How do you handle mass revocation requests?

On Wednesday, February 28, 2018 at 11:56:04 AM UTC-8, Ryan Sleevi wrote: > Assuming Trustico sent the keys to DigiCert, it definitely sounds like even > if Trustico was authorized to hold the keys (which is a troubling argument, > given all things), they themselves compromised the keys of their

RE: How do you handle mass revocation requests?

The keys were emailed to me. I'm trying to get a project together where we self-sign a cert with each of the keys and publish them. That way there's evidence to the community of the compromise without simply listing 23k private keys. Someone on Reddit suggested that, which I really appreciated. I

Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 2:40 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The end user agreed to the subscriber agreement, not Trustico. Our > analysis follows what Peter B. posted – the subscriber is the “natural > person or Legal Entity to whom a

RE: How do you handle mass revocation requests?

The end user agreed to the subscriber agreement, not Trustico. Our analysis follows what Peter B. posted – the subscriber is the “natural person or Legal Entity to whom a Certificate is issued and who is legally bound by a Subscriber Agreement or Terms of Use"—which in this case was Trustico’s

Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 11:29 AM, Wayne Thayer via dev-security-policy wrote: > On Wed, Feb 28, 2018 at 12:13 PM, timx84039--- via dev-security-policy > wrote: > >> >> Regarding to our investigation they were only

Re: How do you handle mass revocation requests?

I would say that at the point that Trustico emailed them to DigiCert they necessarily became compromised -- while Trustico may (or may not) have been authorized to escrowing the keys by the subscriber, the subscriber did not authorize them to be emailed around, presumably. Alex On Wed, Feb 28,

Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 12:13 PM, timx84039--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Regarding to our investigation they were only able to send the private > keys for those certificates where the CSR / private key pair were generated > within their online

RE: How do you handle mass revocation requests?

I agree with the OV, EV, and IV. Admittedly, DV certs, which constitute almost all the certs, are relatively new to DigiCert so that's partly where the question arises. We identified it as the key holder or the domain holder. Hence, we'd revoke with confirmation of a domain validation. The

RE: How do you handle mass revocation requests?

Let's talk it through with Mike J as this will end up in court -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+john.merrill=digicert@lists.mozilla.org] On Behalf Of Jeremy Rowley via dev-security-policy Sent: Wednesday, February 28, 2018 12:20 PM To:

RE: How do you handle mass revocation requests?

I believe transparency is the best policy. I think it'd be helpful to the community if we could post the email exchange about the revocation. We can redact the agreement termination portions if you'd like, but that'd give a lot more clarity around what's going on. Do I have your permission to

Re: How do you handle mass revocation requests?

We have purchased thousands of certificates using Trustico as a reseller within the last years. Back in these days Trustico created CSR / Private Key pair within their online platform (Yes, you read it right - you can create CSR/Private Key on their webpage !!!) which was the default at this

Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 9:37 AM, Jeremy Rowley via dev-security-policy wrote: > Once we were alerted, the team kicked > off a debate that I wanted to bring to the CAB Forum. Basically, our > position is that resellers do not constitute subscribers under the

Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 12:37 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On February 2nd, 2018, we received a request from Trustico to mass revoke > all certificates that had been ordered by end users through Trustico. > Unfortunately, the email

How do you handle mass revocation requests?

Jeremy, Today many of our customers experienced lengthy delays when attempting to contact us via phone, e-mail and live chat. The reason for the delays were due to an unexpected e-mail that DigiCert sent to our customers containing some inaccurate information. We were not informed that the

Re: Allowing WebExtensions to Override Certificate Trust Decisions

On Wed, Feb 28, 2018 at 11:54 AM, Tom Ritter via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Of the examples I gave (Cert Patrol, Perspectives, Convergence, DANE, > DNSSEC-Stapling) - every single one of them would not actually allow > experimenting with Server

Re: How do you handle mass revocation requests?

On 28 February 2018 at 11:37, Jeremy Rowley via dev-security-policy wrote: > What kind of transparency would the Mozilla community like around this > issue? There aren't many more facts than I shared above, but there is a lot > of speculation. Let me know

How do you handle mass revocation requests?

Hi everyone, I wanted to share an incident report regarding the revocation of certain certificates ordered through a reseller. On February 2nd, 2018, we received a request from Trustico to mass revoke all certificates that had been ordered by end users through Trustico. Unfortunately, the

Re: Allowing WebExtensions to Override Certificate Trust Decisions

On 27 February 2018 at 10:23, Alex Gaynor via dev-security-policy wrote: > A reasonable compromise that jumps out to me is allowing extensions to make > an otherwise-secure connection fail, but not allow them to rehabilitate an > insecure connection. This

Re: Japan GPKI Root Renewal Request

On Wed, Feb 28, 2018 at 9:13 AM, Eric Mill via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Feb 28, 2018 at 12:58 AM, apca2.2013--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > "I would like to again point out that simply waiting

Re: Japan GPKI Root Renewal Request

On Wed, Feb 28, 2018 at 12:58 AM, apca2.2013--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > "I would like to again point out that simply waiting for misissued > certificates to expire is not an acceptable response." > > This is a misunderstanding. > We are preparing

Trustico / Digicert Mass Revocation

This is likely to be of interest to people on this list. It sounds like a mass revocation with little detail as to why: https://www.reddit.com/r/sysadmin/comments/80uaq3/digicert_certificates_being_revoked/ ___ dev-security-policy mailing list

Re: Allowing WebExtensions to Override Certificate Trust Decisions

On 28/2/2018 1:52 πμ, Ryan Sleevi via dev-security-policy wrote: On Tue, Feb 27, 2018 at 6:15 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: In the bug I referenced as [2], people said that they specifically need to be able to override "negative"