On Thu, Feb 16, 2017 at 8:26 PM, blake.morgan--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
>
> Trustis has now revoked the SHA-1 Certificate for hmrcset.trustis.com and
> replaced it with a SHA-256 Certificate. This status is reflected in the
> latest CRL.
>
This list hosted an extensive discussion on this issue in May of 2016,
subject line "SSL Certs for Malicious Websites":
https://groups.google.com/d/topic/mozilla.dev.security.polic
y/vMrncPi3tx8/discussion
Most (all?) of the people on this thread participated on that one, and said
most (all?) of
Also relevant are Symantec's statements about two E regional auditors.
One section describes contradictions from E KR (Korea) in describing why
some CrossCert issuing CAs were not in scope:
• The list of CAs in the audit was produced by CrossCert and given to E
KR as the scope to audit. It was
On Tue, Apr 11, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> On 11/04/17 04:45, Eric Mill wrote:
>
> > But I think it's important to note that this relationship was not widely
> > understood or publicly discussed as part of the
On Wed, Apr 12, 2017 at 4:53 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 11/04/17 22:08, Eric Mill wrote:
> > I'll leave it to others to opine on the severity of the mistake and the
> > quality of the response, but I do want to at least
On Mon, Apr 10, 2017 at 10:56 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Issue L: Cross-Signing the US Federal Bridge (February 2011 - July 2016)
>
> Symantec, as well as VeriSign, has participated in the FPKI since 2006,
> and we take our
On Tue, Apr 11, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Eric,
>
> Perhaps you are being intentionally non-directive, in which case perhaps
> you can't answer my questions, but:
>
Yes, I am being intentionally non-directive.
For the benefit of the list, I'm the author of that text and that quote is
from this page, which is maintained by the General Services Administration
(though again, not by the Federal PKI team):
https://https.cio.gov/certificates/#does-the-us-
Major +1. Removing this language is consonant with Mozilla objectives, with
Web PKI trends, and with the health of the open web.
-- Eric
On Thu, Apr 20, 2017 at 9:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> There is an entry on Mozilla's
I strongly support removing any ambiguity about CAs not being required to
police certificate issuance, and agree on the unuseful level of
subjectivity that would be present in any attempt to enforce this clause.
-- Eric
On Thu, Apr 20, 2017 at 7:11 PM, Matt Palmer via dev-security-policy <
On Thu, Apr 20, 2017 at 8:04 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> > -Original Message-
> > On 03/04/17 13:11, Gervase Markham wrote:
> > > Hi Steve and Rick,
> >
> > Q9) Can you please tell us which audit covers the following two
>
I'll include Richard Barnes' response to cabfpublic here too, for
completeness:
-- Forwarded message --
From: "Richard Barnes via Public"
Date: Mar 6, 2017 8:58 AM
Subject: Re: [cabfpub] 360 team hacks Chrome
To: "CA/Browser Forum Public Discussion List"
On Fri, Mar 3, 2017 at 6:25 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 02/03/17 20:45, Eric Mill wrote:
> > Our goal is to start a new root and set of issuing CAs that is completely
> > disconnected and separate from the existing Federal PKI
Hi all,
Though we’re not at the point of filing an application for Mozilla’s root
program, I wanted to share with this community the beginnings of an effort
by the US government to start a new PKI intended for publicly trusted
certificates. This effort is being led by the General Services
On Tue, Aug 15, 2017 at 2:47 PM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> We have been moderately successful in replacing the five (5)
> certificates. One (1) has been voluntarily replaced, we have a commitment
> from our client to initiate a
On Fri, Aug 11, 2017 at 4:43 PM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thursday, August 10, 2017 at 11:51:54 PM UTC-4, Eric Mill wrote:
> > On Thu, Aug 10, 2017 at 11:34 AM, identrust--- via dev-security-policy <
> >
Hi Arno, Martin,
On Mon, Aug 14, 2017 at 11:37 AM, Arno Fiedler via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> As result we confirm to do the following steps and report about the
> implementation latest until 15-09-2017
> • Contact all effected customers, inform
On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote:
> > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy <
>
On Fri, Aug 11, 2017 at 5:20 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> If one integrates a project like certlint/cablint into the cert issuance
> pipeline, one suddenly takes on supplemental responsibility for certlint's
> bugs or changes.
>
If they're not going to revoke within 24 hours and willingly violate that
part of the policy, I would at least expect them to, within that 24 hours,
produce a description of why this happened, what they're doing to fix it,
and when they expect the certificates to be replaced (along with an
On Thu, Aug 10, 2017 at 11:34 AM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> We acknowledge seeing this issue and are looking into it.
> Details will be supplied as soon we can but not later that today’s end of
> business day.
>
Thanks for looking
So who acts as the CEO for WoSign when final executive decisions need to be
made?
On Sun, Jul 9, 2017 at 9:41 PM, Richard Wang via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Mr Wang is the COO now according to Mr. Tan's public announcement on March
> CAB Forum
On Wed, Jul 19, 2017 at 11:31 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Jakob Bohm via
On Fri, Apr 28, 2017 at 4:16 AM, Richard Wang via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> This Google decision’s problem is some big websites used a domain that not
> listed in Alexa 1M suffered disruption, for example, Qihoo 360’s search
> site and online gaming
Given that we're past the 7/31 deadline and the comments in support of
following Chrome's lead, it sounds likely that that's what's happening. And
I think that's an understandable conclusion for Mozilla to draw, given the
compatibility risk Mozilla would be leading on for at least several months.
On Wed, Aug 9, 2017 at 4:28 PM, Lee <ler...@gmail.com> wrote:
> On 8/9/17, Eric Mill via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
> > On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
> > dev-securit
On Fri, Aug 18, 2017 at 12:04 PM, Stephen Davidson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> 4) The list of affected certificates is attached in spreadsheet
> form; they will be uploaded to CT as well. You will note that the number
> has declined – Siemens'
Hi Jose,
There was no attachment to your email. Would you mind re-sending with an
attachment?
On Fri, Aug 18, 2017 at 8:17 AM, Jose Manuel Torres via dev-security-policy
wrote:
> Hello everyone,
>
> In response to the questions raised:
>
> AC FNMT
Hi Jose,
Apologies, on looking back through m.d.s.p, it's clear attachments aren't
processed by the list configuration. Would you be able to post it to a URL,
or attach it to a bugzilla bug?
-- Eric
On Fri, Aug 18, 2017 at 10:01 AM, Eric Mill wrote:
> Hi Jose,
>
> There was
The content on example.com isn't important. An unauthorized certificate can
still potentially be used to intercept an HTTPS connection to example.com
and cause malicious behavior that is unrelated to the "real" content of
example.com.
I'm pushing on this because it's important to understand that
It's absolutely not harmless to use example.com to test certificate
issuance. People visit example.com all the time, given its role. An
unauthorized certificate for example.com could let someone other than its
owner hijack user connections, and maliciously redirect traffic or inject
code/content,
On Sun, May 7, 2017 at 6:09 PM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I'm posting this on behalf of Symantec:
>
> We would like to update the community about our ongoing dialogue with
> Google.
>
> Following our May 4th post, senior executives at
On Thu, May 4, 2017 at 11:30 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Gerv, thank you for your draft proposal under consideration. We have posted
> our comments and detailed information at:
> https://www.symantec.com/connect/blogs/symantec-ca-
>
I didn't understand the original below comment by StartCom very well about
the cross-sign, but after Ryan's message I understand it better in
retrospect:
> On Thu, Sep 14, 2017 at 11:05 AM, Inigo Barreira via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I´ve never said
Adding code to Firefox to support the distrust of specified subCAs seems
like it would be a good long-term investment for Mozilla, as it would give
Mozilla a lot more flexibility during future distrust events.
-- Eric
On Mon, Oct 16, 2017 at 1:32 PM, Gervase Markham via dev-security-policy <
On Thu, Sep 28, 2017 at 12:50 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 27/09/17 18:54, Matthew Hardeman wrote:
> > In the case of StartCom, I can not help but feel that they are being
> > held to an especially high standard (higher than
Thank you for the continued updates, and for relaying the deadline by which
these will be revoked.
On Thu, Aug 31, 2017 at 9:35 PM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Monday, August 28, 2017 at 3:28:01 PM UTC-4, iden...@gmail.com wrote:
> >
Hi Kim,
I appreciate that you've reported this to m.d.s.p despite the certificates
not chaining to an NSS-trusted path. However, since you've called it an
"incident report" and said you would treat this as an incident as if it
were related to NSS trust, I feel I need to point out that this
Ben, I think Gerv addressed Doug's concern and indicated that situation
wouldn't fall under this policy. If that's not accurate, it'd be worth an
on-list clarification.
On Tue, Oct 24, 2017 at 9:01 AM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I echo
On Mon, Jan 15, 2018 at 4:22 PM, Ryan Sleevi <r...@sleevi.com> wrote:
>
>
> On Mon, Jan 15, 2018 at 4:11 PM, Eric Mill via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> That said, GlobalSign's offer to cut certificate lifetimes down t
On Mon, Jan 15, 2018 at 2:30 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, Jan 15, 2018 at 1:18 PM, Doug Beattie >
> wrote:
>
> >
> > - The potential risk in maintaining this whitelist, given both the
> >
WoSign and StartCom are untrusted, but Certum is still trusted, right?
On Mon, Feb 5, 2018 at 11:08 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi,
>
> I searched crt.sh for valid certificates vulnerable to the 2008 Debian
> weak key bug. (Only 2048
On Wed, Aug 15, 2018 at 6:36 AM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I'd like to call this presentation to everyone's attention:
>
> Title: Lost and Found Certificates: dealing with residual certificates for
> pre-owned domains
>
> Slide deck:
>
>
On Sun, Aug 19, 2018 at 3:56 PM Eric Mill wrote:
> On Thu, Aug 16, 2018 at 6:52 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> - While infinitely wealthy organizations can afford getting separate
>>certificates for each DNS name, and while
On Thu, Aug 16, 2018 at 6:52 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> It seems that my response to this presentation has brought out the crowd
> of people who are constantly looking to reduce the usefulness of
> certificates to anyone but the largest
Though I'm not a GlobalSign customer, I'm told that GlobalSign sent the
following email to its partner ecosystem:
Dear Partner,
In reaction to current events related to the private key exposure and mass
revocation by Trustico/Digicert, GlobalSign is reaching out to its trusted
Partners and
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:
I'll go further, and protest why the EV cert was revoked. Why can't Ian
have a "Stripe, Inc." EV certificate for his business if he wants to? What
makes the payment processing company somehow more deserving of one than
Ian's company? Why was GoDaddy allowed to effectively take Ian's site down
On Thu, Apr 12, 2018 at 2:41 PM, Matthew Hardeman
wrote:
>
>
> On Thu, Apr 12, 2018 at 1:24 PM, Eric Mill wrote:
>
>> Ian's intent may have been to demonstrate EV's weaknesses, but that
>> doesn't mean Ian was intending to deceive users. If Ian had used
ian.sh, as domain
>> holder, requested this certificate to be revoked?
>>
>> If anything, this highlights the deeply concerning practices of
>> revocation by CAs, and their ability to disrupt services of legitimate
>> businesses.
>>
>> On Thu, Apr 12, 2018 at
On Thu, Apr 12, 2018 at 1:03 PM, Wayne Thayer wrote:
> On Thu, Apr 12, 2018 at 9:45 AM, Ryan Sleevi wrote:
>
>>
>> In what way is it misleading though? It fully identified the organization
>> that exists, which is a legitimate organization. Thus, the
hether punitive measures are appropriate for this revocation.
-- Eric
>
> On Thu, Apr 12, 2018 at 10:20 AM, Eric Mill via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> > I'll go further, and protest why the EV cert was revoked. Why
On Thu, Apr 12, 2018 at 2:57 PM, Eric Mill wrote:
>
>
> Of course, that would break his proof-of-concept exploit. Which is the
>> right outcome. It demonstrates that an EV certificate used in a manner
>> which might cause confusion will be revoked. They're not stopping him
On Fri, Apr 20, 2018 at 9:30 AM, Tim Shirley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> First of all, it's important to distinguish between the BR r
> But even if you accept my premise there, then you have to ask "in what
> timezone?" March 1 00:00:00 2018 GMT in
On Sun, Apr 22, 2018 at 5:01 PM, Rob Stradling <r...@comodoca.com> wrote:
> On 22/04/18 21:04, Eric Mill via dev-security-policy wrote:
>
>> On Fri, Apr 20, 2018 at 9:30 AM, Tim Shirley via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>
Did you submit the ~25K unexpired unlogged certs to CT?
On Sat, Mar 31, 2018 at 6:14 PM, Tim Smith via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi MDSP,
>
> I went looking for corpuses of certificates that may not have been
> previously logged to CT and found some in
In TurkTrust's 2016 email noting that they were suspending their TLS
certificate business, they noted it stemmed mainly from not being accepted
to all major root stores (Apple did not accept them).
Therefore, the sites using these certificates are not trusted by some major
client bases, which is
On Tue, Mar 20, 2018 at 3:43 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 20/03/2018 18:49, Ryan Sleevi wrote:
>
>> On Tue, Mar 20, 2018 at 1:30 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> Are
Last week, Trustico (a reseller, formerly for Symantec and now for Comodo)
sent 23,000 private keys to DigiCert, to force their revocation. This
showed that Trustico had been storing customer keys generated through one
or more CSR/key generation forms on their website.
Though Trustico disagrees,
strict submission of CSRs to CA portals only.
> >
> > On Mon, Mar 5, 2018 at 12:51 PM, okaphone.elektronika--- via
> > dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> >
> > > On Sunday, 4 March 2018 22:44:26 UTC+1, Paul Kehrer 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 for misissued
> certificates to expire is not an acceptable response."
>
> This is a misunderstanding.
> We are preparing
On Thu, Nov 8, 2018 at 8:51 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Over the years, there has been some variation among participants in how
> harshly individual mistakes by CAs should be judged, ranging from "just
> file a satisfactory incident
On Thu, Sep 27, 2018 at 5:22 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Visa has filed a bug [1] requesting removal of the eCommerce root from the
> Mozilla root store. Visa has also responded to the information requested in
> the qualified audits
On Wed, Nov 28, 2018 at 4:41 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 27/11/2018 00:54, Ryan Sleevi wrote:
> > On Mon, Nov 26, 2018 at 12:12 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> 2.
On Wed, Dec 5, 2018 at 2:36 AM Fotis Loukos via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 4/12/18 8:30 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> > On Tue, Dec 4, 2018 at 5:02 AM Fotis Loukos <
> me+mozdevsecpol...@fotisl.com>
>
> As far as I can tell, if no
Would you consider tossing the backup in a zip file in an S3 bucket or
something, and sharing a link for the record here, for others finding this
in the future?
On Mon, Jan 28, 2019 at 10:05 AM Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi All,
>
> For
The BRs and Mozilla program policies don't support the idea of just
trusting a CA to issue certs for "internal" use or to keep them secret.
This is why CAs issuing "test certificates" on production CAs for domains
they don't own is clearly forbidden.
Given that, I don't see how it can be
I'm told my previous message to this thread was flagged as spam for some of
the recipients. But it did get posted to the Google Group, so for those who
didn't get my previous reply, here it is:
https://groups.google.com/d/msg/mozilla.dev.security.policy/iVCahTyZ7aw/tO3k5ua0AQAJ
On Thu, Aug 15,
On Thu, Aug 15, 2019 at 1:59 PM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> So far I see is a number of contrived test cases picking apart small
> components of EV, and no real data to back it up. Mostly academic or
> irrelevant research, imho.
On Thu, Dec 5, 2019 at 12:34 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> From looking at better security, the 'ideal' path is that modern clients
> are only trusting modern (new) roots, which never issued old crappy certs.
> That is, the path "D -> A
Phillip, that was an unprofessional contribution to this list, that could
be read as a legal threat, and could contribute to suppressing dialogue
within this community. And, given that the employee to which it is clear
you are referring is not only a respected community member, but literally a
Yeah, there's something amiss with how you're analyzing the issue here -
whether an entrust.com or entrust.net domain is in use shouldn't matter.
More generally, Mozilla is unlikely to add any root certificates whose
expected uses don't contain a significant public-facing component. The root
Hi Paul,
Those statements are both hyperbolic representations of others' points of
view.
There are plenty of people who are skeptical about the effectiveness of EV
and its associated UI who nonetheless believe that some sense of
trustworthiness about websites is important. For example, Mozilla
Wayne,
Thank you for your work on behalf of Mozilla in overseeing this program and
defending the online public's interests. In my opinion, you've done a
terrific and thorough job, and your tenure included some difficult and
high-impact decisions. You will most certainly be missed, and whoever is
On Sun, Apr 19, 2020 at 2:41 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Dear MDSP community,
>
> As you are aware from past discussions on this list, there has been a
> concern about the impact of COVID-19 on CA operations. COVID-19 continues
> to
On Thu, Aug 13, 2020 at 10:20 AM Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> "Every domain should be allowed to have a certificate ***regardless of
> intent***.”
>
> They are the most outrageously irresponsible words that I’ve heard in my
> career on the
On Sat, Jul 4, 2020 at 3:15 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> ...especially since many of those millions of certificates are not even
> TLS certificates and their consumers never expected the hard revocation
> deadlines of the BRGs to be
Just to depersonalize it a bit so it's not only Ryan responding - what Ryan
is saying is correct. Mozilla's blog post uses the phrase "impersonating a
website" to describe non-phishing attacks, such as performing active MITM
attacks that modify or replace (or surveil) data in flight, or relying on
Just to build on what Ryan said, and to clarify any confusion around the scope
of Chrome’s action here - Chrome is no longer accepting Camerfirma certificates
that are specifically used for *TLS server authentication* for websites.
Our planned action is related to the certificates Chrome uses
79 matches
Mail list logo