Re: Summary of Camerfirma's Compliance Issues

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

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

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

Re: New Blog Post on 398-Day Certificate Lifetimes

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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

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

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

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

Re: Policy Module Ownership

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

Re: [FORGED] Re: How Certificates are Verified by Firefox

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

Re: [EXTERNAL] Re: INC8119596 Other | Entrust Certs and DHS

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

Re: Firefox removes UI for site identity

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

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,

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

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.

Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

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

Re: misissued.com FYI

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

Re: CA disclosure of revocations that exceed 5 days [Was: Re: Incident report D-TRUST: syntax error in one tls certificate]

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

Re: Incident report D-TRUST: syntax error in one tls certificate

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.

Re: How harsh (in general) should Mozilla be towards CAs?

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

Re: Visa Issues

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

Re: DEFCON Talk - Lost and Found Certificates

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

Re: DEFCON Talk - Lost and Found Certificates

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

Re: DEFCON Talk - Lost and Found Certificates

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: > >

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

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: >

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

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

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

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

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

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

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

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

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

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

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

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

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

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

Re: Discovering unlogged certificates in internet-wide scans

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

Re: TURKTRUST Non-compliance

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

Re: TURKTRUST Non-compliance

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

Re: Following up on Trustico: reseller practices and accountability

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

Re: Following up on Trustico: reseller practices and accountability

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: >

Following up on Trustico: reseller practices and accountability

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,

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: 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

Re: Certificates with 2008 Debian weak key bug

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

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

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

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

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 > >

Re: Proposed policy change: require private pre-notification of 3rd party subCAs

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

Re: Incident Report D-Trust certificates with ROCA fingerprints

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

Re: Mozilla’s Plan for Symantec Roots

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 <

Re: PROCERT issues

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

Re: FW: StartCom inclusion request: next steps

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

Re: O=U.S. Government for non-USG entity (IdenTrust)

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: > >

Re: Certificates with less than 64 bits of entropy

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'

Re: AC FNMT Usuarios and anyExtendedKeyUsage

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

Re: AC FNMT Usuarios and anyExtendedKeyUsage

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

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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 < > >

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

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

Re: Certificates with less than 64 bits of entropy

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

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

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. >

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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 < >

Re: Final Decision by Google on Symantec

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.

Re: [EXT] Symantec Update on SubCA Proposal

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

Re: WoSign new system passed Cure 53 system security audit

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

Re: StartCom issuing bogus certificates

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

Re: StartCom issuing bogus certificates

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,

Re: Symantec: Draft Proposal

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

Re: Symantec: Draft Proposal

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- >

Re: Symantec Conclusions and Next Steps

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

Re: [EXT] Re: Questions for Symantec

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 >

Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

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 <

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

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

Re: Symantec Response L

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-

Re: Symantec Response L

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

Re: Symantec Response L

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

Re: Symantec Response L

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.

Re: Symantec Response L

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

Re: 360 team hacks Chrome

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"

Re: A new US government CA for the web PKI

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

A new US government CA for the web 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

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

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. >

Re: Misissued/Suspicious Symantec Certificates

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