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

stinfo/dev-security-policy> > > > > > > _______ > > > dev-security-policy mailing list > > > dev-security-policy@lists.mozilla.org dev-security-policy@lists.mozilla.org> > > > https://lists.mozilla

Re: New Blog Post on 398-Day Certificate Lifetimes

_ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Eric Mill 617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone> ___

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

o be security advantages for organizations that do so. But if the security and agility needs of the WebPKI don't align with an organization's needs, using an alternate PKI is a reasonable solution that reduces friction on both sides of the equation. -- Eric Mill 617-314-0966 | konklone.com | @konklone <h

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

gt; > [5] https://docs.microsoft.com/en-us/security/trusted-root/2020/april2020 > > [6] > https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html > > [7] https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay > _

Re: Policy Module Ownership

nce again thank everyone for your > support and contributions to this amazing community. > > - Wayne > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy >

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

-constrained subCAs, in terms of validation volume among browser clients which rely on the Web PKI? > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Eric Mill 617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

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

s purposes. > > > > > > > > The CA you are using is intended for government-only applications. The > > CAs that are included in the Mozilla Trust Store are intended for citizen > > or business-facing applications. It sounds like DHS is recommending that > >

Re: Firefox removes UI for site identity

; Both parties in Congress have already signalled that they intend to go > after 'big tech'. Security is an obvious issue to focus on. While it is > unlikely Mozilla will be a target of those discussions, Google certainly is > and one employee in particular. > > This is the poin

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

Encrypt has issued 14,000+ DV certs to domains > with PayPal - we believe every website needs to be encrypted. And Let’s > Encrypt isn’t responsible for phishing." > > Can Mozilla please reconcile these two assertions? I still can’t get my > head around it. > >

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

t the cesspool of websites). > > > > I don't doubt that at all. However see the first email in this thread > citing research showing that users don't notice the difference. > > > > > > ___ > dev-security-policy mailing list &

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

the reports I've seen, the percentage of > phishing and malware sites that use EV is drastically lower than DV (which > are used to protect the cesspool of websites). > > > > I don't doubt that at all. However see the first email in this thread > citing research showing that users

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

anything about being valid or not. > > > > I don't think that interpretation is very useful. I think that the OCSP > server should know about the certificate before the customer has > > the certificate. I think that if you have a properly signed certificate > within it's validity

Re: misissued.com FYI

-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Eric Mill 617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone> ___ dev-security-policy mailing li

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 f

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 <e...@konklone.com> 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

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 <mharde...@gmail.com> wrote: > > > On Thu, Apr 12, 2018 at 1:24 PM, Eric Mill <e...@konklone.com> wrote: > >> Ian's intent may have been to demonstrate EV's weaknesses, but that >> doesn't mean Ian was intendi

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

mation presented to users is misleading, so these CAs did what was > required of them. > That's not accurate -- the EV information presented to users was not misleading. It correctly described Ian's registered company. The certificate was incorrectly revoked. We should probably be discussing w

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

, 2018 at 4:04 PM, Eric Mill <e...@konklone.com> wrote: > 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 &g

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

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

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

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

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

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

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

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

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

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

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

  1   2   >