Re: Requirements for CNNIC re-application

On Mon, Apr 13, 2015 at 8:19 PM, Matt Palmer mpal...@hezmatt.org wrote: To my mind, if a CA isn't trustworthy enough to be trusted to issue certificates for every site on the Internet, they shouldn't be trusted to issue certificates for *any* site on the Internet. In the case of the proposed

Re: Name-constraining government CAs, or not

On Sat, May 16, 2015 at 6:12 PM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote: On Sat, May 16, 2015 4:45 pm, Eric Mill wrote: Another factor is _why_ the government CA is applying to the trusted root program. If the government CA only intends to issue certs for its own properties

Re: Name-constraining government CAs, or not

On Tue, May 19, 2015 at 12:07 AM, Matt Palmer mpal...@hezmatt.org wrote: On Mon, May 18, 2015 at 10:32:05PM -0400, Eric Mill wrote: On Mon, May 18, 2015 at 9:15 PM, Matt Palmer mpal...@hezmatt.org wrote: I don't see the relevance of anything you wrote, to the perspective of we

Re: Name-constraining government CAs, or not

On Mon, May 18, 2015 at 9:15 PM, Matt Palmer mpal...@hezmatt.org wrote: I disagree that we, the browsers and standards bodies of the Internet have very different leverage. In either case, if a CA misbehaves, their root certs can be pulled from the trust store (or otherwise neutered). That

Re: Name-constraining government CAs, or not

(I guess we're all wearing our affiliations on our backs, but disclosure: I'm a US federal government employee, but am not speaking on behalf of the USG, and don't have any professional affiliation with the US FPKI run out of the Treasury Department.) On Fri, May 15, 2015 at 11:49 AM, Ryan Sleevi

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

On Thu, Jun 4, 2015 at 9:18 PM, Chris Palmer pal...@google.com wrote: Certificate Transparency gets us what we want, I think. CT works globally, and is safer, and significantly changes the trust equation: * Reduces to marginal/effectively destroys the attack value of mis-issuance * Makes it

Re: New certificate search tool - crt.sh

This is outstanding - simple, but totally what people need to start getting the idea and benefit of CT. One high ROI addition might be RSS feeds for search terms. That way, I could create e.g. an IFTTT alert that emails me whenever a certificate is publicly logged as being issued for my domains.

Re: New certificate search tool - crt.sh

in practice. -- Eric Sent from my iPhone. Please excuse brevity. On Jun 3, 2015, at 10:01, Rob Stradling rob.stradl...@comodo.com wrote: On 03/06/15 14:43, Eric Mill wrote: This is outstanding - simple, but totally what people need to start getting the idea and benefit of CT. Thanks

Re: Name-constraining government CAs, or not

On Sun, May 31, 2015 at 6:43 PM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote: On Sat, May 30, 2015 2:47 pm, Brian Smith wrote: The main sticks that browsers have in enforcing their CA policies is the threat of removal. However, such a threat seem completely empty when removal

Re: WoSign Root Renewal Request

Is there any effort or interest to maintain native translations of the CA/B Forum's Baseline Requirements, at least in the native languages of participating CAs? -- Eric On Tue, Jun 30, 2015 at 9:11 PM, Richard Wang rich...@wosign.com wrote: Hi Kurt, Hi Jesus, Hi Martin, Very thanks for your

Re: Requirements for CNNIC re-application

On Fri, May 22, 2015 at 5:15 PM, Kathleen Wilson kwil...@mozilla.com wrote: On 4/7/15 5:31 PM, Richard Barnes wrote: 5. April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion, so SSL certificates issued after Apr 1 2015 for new domains will be recognized. Do you

Re: Requirements for CNNIC re-application

On Fri, May 22, 2015 at 7:24 PM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote: On Fri, May 22, 2015 3:11 pm, Eric Mill wrote: On Fri, May 22, 2015 at 5:15 PM, Kathleen Wilson kwil...@mozilla.com wrote: On 4/7/15 5:31 PM, Richard Barnes wrote: 5. April 1, 2016

Re: Clarify that a ccTLD is not acceptable in permittedSubtrees

Regardless of whether technically allowed by the BRs -- a technically constrained subordinate CA that is not (directly) audited that is allowed to issue a valid *.us certificate would, if actually discovered in the wild, create some shockwaves. Really, any *.us certificate would create

Re: New certificate search tool - crt.sh

at 9:05 AM, Rob Stradling <rob.stradl...@comodo.com> wrote: > On 03/06/15 19:48, Rob Stradling wrote: > > On 03/06/15 18:02, Eric Mill wrote: > >> > >> On Wed, Jun 3, 2015 at 11:46 AM, Rob Stradling < > rob.stradl...@comodo.com > >> <mailto:rob.s

Re: Symantec's Test Certificates Incident Final Report

Some relevant highlights -- Symantec supporting CAA and bringing a proposal to the CAB Forum to require other CAs to do the same thing: We have implemented support for Certification Authority Authorization, enabling customers to explicitly specify from which CAs certificates for their domains

Re: Firefox security too strict (HSTS?)?

On Wed, Sep 23, 2015 at 5:35 PM, Anil G <gulati...@gmail.com> wrote: > And finally, regrettably, Eric Mill: ". . . you should channel your > passion in the direction of the enterprise IT group -- or its political > overlords -- that are inconveniencing you and driving t

Re: Firefox security too strict (HSTS?)?

On Wed, Sep 23, 2015 at 3:17 PM, R Kent James <k...@caspia.com> wrote: > On 9/23/2015 1:57 PM, Eric Mill wrote: > >> I'd phrase it instead as: what can be done to educate people responsible >> for deploying/buying enterprise software deployment that a rapid update

Re: Firefox security too strict (HSTS?)?

Except in both of these cases -- removing TLS fallback to v1.0, and raising DH parameter minimums -- Chrome joined Firefox in doing so. Firefox went out first, and so that was the first impression people got, but Chrome's policies are no less strict. In at least some enterprises, "everyone use IE"

Re: Firefox security too strict (HSTS?)?

On Wed, Sep 23, 2015 at 2:55 PM, R Kent James <k...@caspia.com> wrote: > On 9/23/2015 1:25 PM, Eric Mill wrote: > >> Except in both of these cases -- removing TLS fallback to v1.0, and >> raising >> DH parameter minimums -- Chrome joined Firefox in doing so. Fir

Re: Policy Update Proposal -- Remove Email Trust Bit

If this is a wakeup call to the S/MIME community that they need to demonstrate enough organization and interest to create the same level of reliability that browsers did for HTTPS, can anyone lay out what the steps to doing that would look like so the S/MIME community can react in more concrete

Re: Firefox security too strict (HSTS?)?

Small note, to correct a misunderstanding from earlier in the thread -- even if *.mozilla.org were doing key pinning, Chromium/Chrome will ignore key pins if the observed cert chains up to a user/enterprise-installed root. So that wouldn't cause any issues. -- Eric On Fri, Sep 18, 2015 at 12:06

Re: Remove trust of Symantec's Class 3 Public Primary Certification Authority?

Sorry, you're right -- I inferred incorrectly from filtering censys.io on key size. On Sat, Dec 12, 2015 at 9:56 PM, Yuhong Bao wrote: > The VeriSign "Class 3 Public Primary Certification Authority - G2" is also > 1024-bit. > >

Re: Remove trust of Symantec's Class 3 Public Primary Certification Authority?

Peter Bowen has suggested that the G2 root should be considered the same way, since it seems to be used for the same purpose as the one Google referenced: https://twitter.com/pzb/status/675354162071252992 I believe this censys.io link is a (slightly) friendlier way of showing the same thing:

RE: Remove trust of Symantec's Class 3 Public Primary Certification Authority?

The G2 root identified by Peter is 2048-bit. -- Eric On Dec 12, 2015 7:56 PM, "Yuhong Bao" wrote: > I think this and most of the other 1024-bit roots was removed or > restricted to email in Mozilla some time ago (last remaining one is > Equifax). They had been

Re: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ?

The Mozilla Trusted Root program can and should police violations of the Mozilla Trusted Root program, and any other fraudulent *publicly trusted* certificates. That's non-controversial. Policing violations of more general social norms -- by choosing to actively distrust non-publicly-trusted

Re: Should we block Blue Coat's 'test' intermediate CA?

-- Eric On Tue, May 31, 2016 at 11:18 AM, Eric Mill <e...@konklone.com> wrote: > Symantec has also stated that Blue Coat never had possession of the > private key: > > http://www.symantec.com/connect/blogs/symantec-protocol-keeps-private-keys-its-control > > And, on an ex

Re: Job: Is it OK to post a job listing in this forum?

I could tolerate a policy like that, and it's always possible to revisit it if it turns out to be abused, or causes people to unsubscribe (which I would recommend Mozilla watching, especially right after postings go out). One suggested change: > * The Subject of the posting begins with "Job: "

Re: Should we block Blue Coat's 'test' intermediate CA?

Symantec has also stated that Blue Coat never had possession of the private key: http://www.symantec.com/connect/blogs/symantec-protocol-keeps-private-keys-its-control And, on an existing Mozilla bug about the issue, Rick Andrews from Symantec stated that it would have been limited to

Re: Intermediate certificate disclosure deadline in 2 weeks

On Tue, Jun 21, 2016 at 12:10 PM, Peter Bowen wrote: > On Tue, Jun 21, 2016 at 8:26 AM, Rob Stradling > wrote: > > Revocation of a "parent intermediate" does not exempt "child > intermediates" > > from the disclosure requirement, AFAICT. So I think

Re: Intermediate certificate disclosure deadline in 2 weeks

On Wed, Jun 22, 2016 at 6:11 PM, Kurt Roeckx wrote: > On Wed, Jun 22, 2016 at 02:25:37PM -0700, Peter Bowen wrote: > > I think there are two things getting conflated here: > > > > 1) Disclosure of revoked unexpired CA certificates signed by a trusted CA > > > > 2) Disclosure of

Re: Intermediate certificate disclosure deadline in 2 weeks

wrote: > That's correct. > > -Original Message- > From: Peter Bowen [mailto:pzbo...@gmail.com] > Sent: Thursday, June 23, 2016 2:39 PM > To: Ben Wilson <ben.wil...@digicert.com> > Cc: Eric Mill <e...@konklone.com>; Kurt Roeckx <k...@roeckx.be>; Richard

Re: SHA1 certs issued this year chaining to included roots

On Mon, Jan 18, 2016 at 10:45 PM, Reed Loden wrote: > https://cabforum.org/pipermail/public/2016-January/006519.html has > more information on these certs. > I don't think that includes the Digicert one, though? > > ~reed > > On Mon, Jan 18, 2016 at 10:23 PM, Kurt Roeckx

Re: Update to phasing out SHA-1 Certs

On Mon, Jan 18, 2016 at 11:24 PM, Ryan Sleevi < ryan-mozdevsecpol...@sleevi.com> wrote: > > > There isn't in Chrome, and here's the bug thread where the > > Chrome team denied fervent requests by someone behind an enterprise > > firewall to add MD5 support in behind a command line flag: > >

Re: Update to phasing out SHA-1 Certs

On Mon, Jan 18, 2016 at 10:19 AM, Richard Barnes wrote: > ... > > One thing that has been proposed is to have an exception for local roots, > i.e., to let non-default trust anchors continue to use SHA-1 for some more > time. What do folks here think about that idea? > That

Re: Intermediate certificate disclosure deadline in 2 weeks

And for the benefit of readers of the thread not already familiar with this, below are the two documented browser approaches to revocation of intermediates that I'm aware of, for Firefox and Chrome. Both require browser-maintained (not CA-maintained) lists of revoked certificates to be updated

Re: Proposed limited exception to SHA-1 issuance

On Wed, Feb 24, 2016 at 9:31 AM, Gervase Markham <g...@mozilla.org> wrote: > On 24/02/16 02:26, Eric Mill wrote: > > It would also be worth learning what segment of the market these 10,000 > > terminals would affect. I've seen these terminals before: > > > >

Re: Proposed limited exception to SHA-1 issuance

On Tue, Feb 23, 2016 at 9:38 PM, Peter Gutmann wrote: > Gervase Markham writes: > > >Mozilla is very keen to see SHA-1 eliminated, but understands that for > >historical reasons poor decisions were made in private PKIs about which > roots > >to

Re: Proposed limited exception to SHA-1 issuance

On Tue, Feb 23, 2016 at 1:57 PM, Gervase Markham wrote: > > Our proposal, which we have sent to Symantec, Worldpay and the other > browsers, is as follows: > Thank you for bringing this to the list for public input, even with a tight timeline and under immense pressure. It

Re: Proposed limited exception to SHA-1 issuance

On Sat, Feb 27, 2016 at 6:50 PM, David E. Ross wrote: > > According to Softpedia, Mozilla is the only organization that agreed to > Symantec's request. Microsoft, Google, and others are holding firm on > rejecting SHA-1 certificates. See > < >

Re: Update to phasing out SHA-1 Certs

On Tue, Jan 19, 2016 at 9:38 PM, Ryan Sleevi < ryan-mozdevsecpol...@sleevi.com> wrote: > On Tue, January 19, 2016 5:38 pm, Eric Mill wrote: > > If your experience with MD5 supports the notion that removing support > for > > it in the enterprise hurt user se

Re: Update to phasing out SHA-1 Certs

On Tue, Jan 19, 2016 at 4:15 AM, Ryan Sleevi < ryan-mozdevsecpol...@sleevi.com> wrote: > On Mon, January 18, 2016 9:05 pm, Eric Mill wrote: > > Really? Given your last few years of experience, if you could time > travel > > back to 2012, you would tell Past Ryan Sl

Re: Drafting Q1 2016 CA Communication

On Mon, Mar 14, 2016 at 4:08 PM, Kathleen Wilson <kwil...@mozilla.com> wrote: > On 3/10/16 9:25 PM, Eric Mill wrote: > >> Would this be a good opportunity to ask CAs to do an audit of any >> undisclosed cross-signatures they may have to other unconstrained roots? >>

Re: Fixing the BR scope (was Re: More SHA-1 certs)

On Mon, Mar 7, 2016 at 12:04 PM, Jeremy Rowley wrote: > Programmatic enforcement is outside the scope of the BRs. I'd like to do > something (as CAs) to remediate the issue. > But the potential for programmatic enforcement by browsers is a factor for all CABF

Re: SSL Certs for Malicious Websites

On Wed, May 18, 2016 at 9:35 AM, Ben Wilson wrote: > Looking at the threat from a defense-in-depth/orthogonal perspective, > doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does > something to combat malicious websites for the public? > It

Re: SSL Certs for Malicious Websites

On Sat, May 21, 2016 at 12:04 PM, wrote: > > Peter, once again you are ignoring the full language of BR 4.9.2 to > 4.10.2. These CA requirements are not limited to reports of "misuse" > submitted to a CA, but apply to reports of "suspected Key Compromise, > Certificate

Re: SSL Certs for Malicious Websites

On Mon, May 16, 2016 at 8:24 AM, Ben Wilson wrote: > Gerv wrote, > "Counter-question to many of these: who defines what is malware, and who > made them king?" > > The contract that the CA enters into with the subscriber should have done > that. > > Subscriber Agreements

Re: ISRG Root Inclusion Request

One small thing I noticed - the CA Hierarchy diagram the bug links to is out of date: https://bugzilla.mozilla.org/attachment.cgi?id=8660928 At a minimum, X3 and X4 now exist: https://letsencrypt.org/certificates/ -- Eric On Wed, Apr 20, 2016 at 4:01 PM, Kathleen Wilson

Re: SSL Certs for Malicious Websites

On Wed, May 25, 2016 at 9:50 AM, wrote: > > Why should CAs delegate to or rely on browsers for this type of user > protection? Isn't it better for CAs to remain involved by revoking certs / > refusing to issue certs to known bad sites, like CAs have done for at least > the

Re: FW: Intermediate certificate disclosure deadline in 2 weeks

q5RnStn50=yxnEOhIxqEJxYCndopgWxHD8FxhHFsjtBlvztmv > > whhM= > | Thought Leadership: > > Protiviti.com<http://www.protiviti.it/en-US/Pages/Insights.aspx> > > > > On Jun 24, 2016, at 08:01, " > dev-security-policy-requ...@lists.mozilla.org dev-securit

Re: The prevalence of HTTPS interception

The concluding discussion has a lot of great pointers to future work and things the security community needs to work out. This part is relevant to this community (and my favorite part of the paper): Many HTTPS security features expect connections to be end-to-end by mixing the HTTP and TLS

Re: cablint/certlint updated

To save folks a step, here's the link to the certlint repo, which contains both executables: https://github.com/awslabs/certlint And Matt Palmer's asn1c refactoring work is here: https://github.com/awslabs/certlint/pull/38 -- Eric On Sat, Oct 8, 2016 at 5:59 PM, Peter Bowen

Re: Sanctions short of distrust

On Wed, Sep 21, 2016 at 6:18 PM, Richard Wang wrote: > > > Do we trust that WoSign will not collect information on hits to any OCSP > responders they have set up and share that info with...whomever? > > Yes, any CA can do this if need. But you can use OCSP Stapling in your

Re: Comodo issued a certificate for an extension

On Sun, Oct 2, 2016 at 9:23 PM, Nick Lamb wrote: > On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote: > > There is some good news. The CA/Browser Forum has already addressed > > this, even prior to the current discussions. Ballot 169 > >

Re: Apple's response to the WoSign incidents

On Sat, Oct 1, 2016 at 6:40 AM, wrote: > Do you have a link to that process and is it automated. Reason is I have a > few hundred startSSL certs that my clients rely on. > Apple's statement was limited specifically to WoSign. StartSSL certificates won't be affected, though

Re: Remediation Plan for WoSign and StartCom

Hi Richard, A few questions - 1) Your post says "There will be new SSL certificates issued by a new WoSign intermediate CA which is signed by the one of global trusted root CA, it supports all the browsers (including Firefox). This will be done within one months." How will this WoSign

Re: Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents)

The first thing that comes to mind is to define an intermediate representation of per-root constraints, that Mozilla can distribute alongside certdata.txt. The simplest piece would be name constraints, but incorporating things like CT constraints and date-based constraints would clearly be

Re: Please avoid S/MIME signatures when posting to this group

Can you confirm whether this affects people who subscribed through Google Groups but participate via email, or whether it only impacts users who read the list through the Google Groups web interface? -- Eric On Oct 21, 2016 3:27 PM, "Gervase Markham" wrote: > In a development

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 9:00 AM, Peter Bowen wrote: > On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham wrote: > > > > One possible answer is just to say: "Mozilla will not accept 'but we > > have a lot of certs under TCSCs which will be affected by this' as

Re: Something About CFCA (China Financial Certification Authority)

On Mon, Oct 31, 2016 at 8:29 PM, Percy wrote: > On Sunday, October 30, 2016 at 4:19:12 AM UTC-7, Han Yuwei wrote: > > According to their CPS (Chinese version 3.2 Jul.2016), > > > > 1. All CAs can issue SM2 certificates and uses SM3 Hash. > > > > 2. There is a "signing key"

Re: Remediation Plan for WoSign and StartCom

For the convenience of the thread -- assuming that a 1-year-oriented policy covered the certs up to and including those listed as 2017-10-01, then summing up Kurt's numbers: * Certs expiring by Oct 2017: 2,088,329 * Certs expiring after Oct 2017: 1,419,593 On Sat, Oct 15, 2016 at 4:28 AM, Kurt

Re: StartCom & Qihoo Incidents

On Sat, Oct 15, 2016 at 4:31 AM, Peter Gutmann wrote: > The only one who's openly addressed this > seems to be Mozilla. > It would certainly be nice if Mozilla weren't the only openly operated root program. :) It seems to put Mozilla in the situation of being the

Re: Remediation Plan for WoSign and StartCom

wrote: > On Sat, Oct 15, 2016 at 06:07:50PM -0400, Eric Mill wrote: > > For the convenience of the thread -- assuming that a 1-year-oriented > policy > > covered the certs up to and including those listed as 2017-10-01, then > > summing up Kurt's numbers: > > > &g

Re: Policy 2.4 Proposal: Require open licensing of CPs and CPSes

An edge case: works of the US government, whether documents or code, are not copyrightable in the US, and so they can't be licensed or dedicated to the public domain in the US. There is some discussion of this here: https://theunitedstates.io/licensing/ (Note: I'm an author of that, in an old work

Re: Policy 2.4 Proposal: Add CC-0 license to policy

I would try to avoid "licensed" for CC0, which is meant to be a public domain dedication (which actively removes one's copyright) rather than a license (which retains and uses one's copyright to attain a goal). In my day job (with a US government agency), we acknowledge the automatic public

Re: Policy 2.4 Proposal: Require open licensing of CPs and CPSes

t;> On 14/12/16 23:13, Eric Mill wrote: >> >>> Sure, that works. Is the "in writing" part necessary? You might say >>> instead >>> "publicly accepted by Mozilla.", which would imply text on m.d.s.p or >>> bugzilla that would nec

Re: Proposal: Switch generic icon to negative feedback for non-https sites

Not claiming to have the solution at hand, but the best first step might be non-scolding, non-lock-related imagery that clearly and affirmatively gets across that this is a *public* connection. Just brainstorming a bit here: * A charming low-fi icon of the all-seeing eye

Re: Formalize a SHA-1 deprecation announcement?

I hadn't caught the wiki update -- that's terrific! Thanks for pointing it out. I can make an announcement in Mozilla's Security Blog if you all think that is needed. I do think a quick announcement, linking to your wiki page and linking to MS' and Chrome's announcements, would be helpful in

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: 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: Misissued/Suspicious Symantec Certificates

. That clarifying letter stated a 2015 audit period. E BR does not meet our requirements for RA audit quality, timeliness, and responsiveness to our demands. Symantec will no longer accept audits from E BR should we have a future need for in-market audit support. On Sun, Feb 12, 2017 at 2:11 PM, Eric Mill

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

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

Re: Symantec Response L

d root program, between 2009 and 2016. In February 2016, Eric Mill prompted discussions with Symantec and the > community about why the cross-certification resulted in some FPKI certs > being trusted in browsers at https://github.com/18F/fpki-testing/issues/1. > That discussion highlighted tha

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

; > The new ACES CP dated Jan 17 2017 does not assure public use of the ACES > root. > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Eric Mill

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

A new US government CA for the web PKI

first email to the list from my work .gov address, so I'll just quick note that that means I'm speaking in my work capacity. Emails that are not from my work address are not speaking in my work capacity.) -- Eric Mill Senior Advisor, Technology Transformation Service, GSA eric.m...@gsa.gov, +1-617

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 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: 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 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: 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: 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: [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: 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: 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: 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 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, 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: 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 <e...@konklone.com> wrote: >

Re: StartCom issuing bogus certificates

re present for all connections that fail to treat the network as untrusted. -- Eric On Wed, May 31, 2017 at 8:48 PM, Yuhong Bao <yuhongbao_...@hotmail.com> wrote: > I don't think there is anything important on example.com though > ____ > From: Eric Mi

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

  1   2   >