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" certif
On 2018-02-27 17:23, Alex Gaynor 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 would allow experimenting with stricter controls
while avoiding some of the real
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
dev-secur
I was planning on posting something about this later today. Give me a couple
hours to drink a lot of caffeine, and I'll update the entire community.
-Original Message-
From: dev-security-policy
On Behalf Of Richard Moore via dev-security-policy
Sent: Wednesday, February 28, 2018 6:43 AM
T
On Wednesday, February 28, 2018 at 1:50:08 PM UTC, Jeremy Rowley wrote:
> I was planning on posting something about this later today. Give me a couple
> hours to drink a lot of caffeine, and I'll update the entire community.
Great, thanks Jeremy.
Rich.
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 t
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
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 would allow experimenting with stricter co
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 e
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 what I can share to help alleviate confusi
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 Authentic
If the "fail verification only" option is not viable, I personally think we
shouldn't expose this to extensions.
I don't think the ability to experiment with new trust models for the web
is worth the price we'd be paying in malicious-extension risk, in
fracturing the ecosystem risk, or in general
On Wed, 28 Feb 2018 17:37:25 +
Jeremy Rowley via dev-security-policy
wrote:
> Hi everyone,
> On February 2nd, 2018, we received a request from Trustico to mass
> revoke all certificates that had been ordered by end users through
> Trustico.
Is this date (2 February, so almost four weeks ago)
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 e-ma
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 was
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 Baseline
> Requirement's definitions (Se
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 ti
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 p
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:
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 resel
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 priv
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, 20
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 able to send the private
>> keys for those certificates where the CSR / private ke
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 c
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 Ce
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 t
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 cus
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 posse
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 substitu
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 signi
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
https://lists.mozi
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 proc
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 community of the compromise without
> simply l
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 inve
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
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?
Posted to cab forum accidentally instead of Mozilla dev
Begin forwarded message:
From: Jeremy Rowley
mailto:jeremy.row...@digicert.com>>
Date: February 28, 2018 at 2:33:41 PM MST
To: Ryan Sleevi mailto:sle...@google.com>>, Geoff Keating
mailto:geo...@apple.com>>
Cc: CA/Browser Forum Public Dis
> 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 priva
>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 ne
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 2
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 jeremy.row...@digicert.com>>
> Date: February 28, 2018 at 2:33:41
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). When
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 cu
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 hour
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
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:
https://w
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 n
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
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 CA
49 matches
Mail list logo
