Re: Website owner survey data on identity, browser UIs, and the EV UI

On Tue, Oct 08, 2019 at 07:16:59PM -0700, Paul Walsh via dev-security-policy wrote: > Why isn’t anyone’s head blowing up over the Let’s Encrypt stats? Because those stats don't show anything worth blowing up ones head over. I don't see anything in them that indicates that those 14,000

Re: Website owner survey data on identity, browser UIs, and the EV UI

> On Oct 2, 2019, at 1:16 PM, Ronald Crane via dev-security-policy > wrote: > > On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote: >> New tools such as Modlishka now automate phishing attacks, making it >> virtually impossible for any browser or security solution to detect -   >>

Re: Website owner survey data on identity, browser UIs, and the EV UI

> On Oct 2, 2019, at 3:41 PM, Ronald Crane via dev-security-policy > wrote: > > On 10/2/2019 3:00 PM, Paul Walsh via dev-security-policy wrote: >> On Oct 2, 2019, at 2:52 PM, Ronald Crane via dev-security-policy >> wrote: > [snip] >>> Some other changes that might help reduce phishing are:

Re: [FORGED] Website owner survey data on identity, browser UIs, and the EV UI

> On Oct 2, 2019, at 3:52 PM, Peter Gutmann wrote: > > Paul Walsh ​ writes: > >> I would like to see one research paper published by one browser vendor to >> show that website identity visual indicators can not work. > > Uhhh... are you serious with that request? You're asking for a study

Re: [FORGED] Website owner survey data on identity, browser UIs, and the EV UI

> On Oct 2, 2019, at 4:05 PM, Ronald Crane via dev-security-policy > wrote: > > On 10/2/2019 3:27 PM, Peter Gutmann wrote: >> Ronald Crane via dev-security-policy >> writes: >> >>> "Virtually impossible"? "Anyone"? Really? Those are big claims that need >>> real >>> data. >> How many

Re: Mozilla Policy Requirements CA Incidents

On Tue, Oct 8, 2019 at 8:16 PM Jeremy Rowley wrote: > I think requiring publication of profiles for certs is a good idea. It’s > part of what I’ve wanted to publish as part of our CPS. You can see most of > our profiles here: >

Re: Updated website owner survey data on identity, browser UIs, and the EV UI

I finally got around to digesting the email below. Summary/Reminder: CA related data on website identity from the perspective of website owners. As Homer Simpson said, "70% of all reports are made up”. So, everything put forward by me in previous messages, or anyone else, must be taken with a

RE: Mozilla Policy Requirements CA Incidents

I think requiring publication of profiles for certs is a good idea. It’s part of what I’ve wanted to publish as part of our CPS. You can see most of our profiles here: https://content.digicert.com/wp-content/uploads/2019/07/Digicert-Certificate-Profiles.pdf, but it doesn’t include ICAs right

Re: Mozilla Policy Requirements CA Incidents

(Sorry for the second e-mail, Erwann still having some Groups issues - this will be the one that shows up on the list) On Tue, Oct 8, 2019 at 6:43 PM Erwann Abalea via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > If this is to be read as an exclusive choice, then how do

Re: Mozilla Policy Requirements CA Incidents

On Tue, Oct 8, 2019 at 6:42 PM Jeremy Rowley wrote: > Tackling Sub CA renewals/issuance from a compliance perspective is > difficult because of the number of manual components involved. You have the > key ceremony, the scripting, and all of the formal process involved. > Because the root is

Re: Entrust Root Certification Authority - G4 Inclusion Request

On Mon, Oct 7, 2019 at 9:09 AM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote: > > > We will update section 4.2 and 9.12.3 in the next release of the CPS. > > The CPS Has been updated to address the above

Re: Mozilla Policy Requirements CA Incidents

Bonsoir, Le lundi 7 octobre 2019 20:53:11 UTC+2, Ryan Sleevi a écrit : [...] > # Intermediates that do not comply with the EKU requirements > > In September 2018 [1], Mozilla sent a CA Communications reminding CAs about > the changes in Policy 2.6.1. One specific change, called to attention in >

RE: Mozilla Policy Requirements CA Incidents

Tackling Sub CA renewals/issuance from a compliance perspective is difficult because of the number of manual components involved. You have the key ceremony, the scripting, and all of the formal process involved. Because the root is stored in an offline state and only brought out for a very

Re: Mozilla Policy Requirements CA Incidents

To try and minimize some of the tone-policing ad hominem, arguments from authority, and thread-jacking, especially on-list, let's circle back to the subject of this thread, and hopefully you can offer constructive solutions there. Is my understanding correct that your concern is you don't believe

Re: Mozilla Policy Requirements CA Incidents

> On Oct 8, 2019, at 12:44 PM, Ryan Sleevi wrote: > > Paul, [snip] > It does not seem you're interested in finding solutions for the issues, [PW] You are mixing things up Ryan. I am interested in finding solution to issues. I specifically kept my message on point, which was your tone and

Re: Mozilla Policy Requirements CA Incidents

My apologies. I messed up when trimming that down. I was quoting Ryan Sleevi there. On Tue, Oct 8, 2019 at 2:55 PM Paul Walsh wrote: > > On Oct 8, 2019, at 12:51 PM, Matthew Hardeman wrote: > > > On Tue, Oct 8, 2019 at 2:10 PM Ryan Sleevi via dev-security-policy < >

Re: Mozilla Policy Requirements CA Incidents

> On Oct 8, 2019, at 12:51 PM, Matthew Hardeman wrote: > > > On Tue, Oct 8, 2019 at 2:10 PM Ryan Sleevi via dev-security-policy > > wrote: > On Tue, Oct 8, 2019 at 2:44 PM Paul Walsh > wrote: > > so we need better

Re: Mozilla Policy Requirements CA Incidents

On Tue, Oct 8, 2019 at 2:10 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Oct 8, 2019 at 2:44 PM Paul Walsh wrote: > > so we need better solutions. It's also being willing to acknowledge that if > we can't find systemic fixes, it may be that we

Audit Letter Validation (ALV) on intermediate certs in CCADB

CAs, There is now an "Audit Letter Validation (ALV)" button on intermediate certificate records in the CCADB. There is also a new task list item on your home page. In the summary section you will see a line item like the following. "Intermediate Certs with Failed ALV Results: 8" When

Re: Mozilla Policy Requirements CA Incidents

Paul, If you'd like to continue this conversation, might I respectfully ask you take it elsewhere from this thread? It does not seem you're interested in finding solutions for the issues, and you've continued to shift your message, so perhaps it might be better to continue that discussion

Re: Mozilla Policy Requirements CA Incidents

Ryan, You just proved me right by saying I’m confused because I hold an opinion about how you conduct yourself when collaborating with industry stakeholders. My observations are the same across the board. I don’t think I’m confused. But you’re welcome to disagree with me. And, it’s not

Re: Mozilla Policy Requirements CA Incidents

On Tue, Oct 8, 2019 at 2:44 PM Paul Walsh wrote: > Dear Ryan, > > It would help a great deal, if you tone down your constant insults towards > the entire CA world. Questioning whether you should trust any CA is a > bridge too far. > Instead, why don’t you try to focus on specific issues with

Re: Mozilla Policy Requirements CA Incidents

I read Jeremy’s last response before posting my comment. Dear Ryan, It would help a great deal, if you tone down your constant insults towards the entire CA world. Questioning whether you should trust any CA is a bridge too far. Instead, why don’t you try to focus on specific issues with

Re: Mozilla Policy Requirements CA Incidents

On the topic of root causes, there's also https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3425554 that was recently published. I'm not sure if that was peer reviewed, but it does provide an analysis of m.d.s.p and Bugzilla. I have some concerns about the study methodology (for example, when

Re: CAs cross-signing roots whose subjects don't comply with the BRs

On Tue, Oct 8, 2019 at 10:04 AM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Unless I found a root that Ryan isn’t referring to, Mozilla Policy 2.1 ( > https://wiki.mozilla.org/CA:CertificatePolicyV2.1) would have been in > force when the root was first

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

> But the target audience for phishing are uninformed people. People which have > no idea what a EV cert is. People who don't even blink if the English on the > phishing page is worse than a 5-year old could produce. > > You cannot base the decision if a EV indication in the browser is useful

Re: CAs cross-signing roots whose subjects don't comply with the BRs

On 08/10/2019 13:41, Corey Bonnell wrote: On Monday, October 7, 2019 at 10:52:36 AM UTC-4, Ryan Sleevi wrote: I'm curious how folks feel about the following practice: Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They create this Root Certificate after the effective date

Re: CAs cross-signing roots whose subjects don't comply with the BRs

On Monday, October 7, 2019 at 10:52:36 AM UTC-4, Ryan Sleevi wrote: > I'm curious how folks feel about the following practice: > > Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They > create this Root Certificate after the effective date of the Baseline > Requirements, but

Re: OCSP responder support for SHA256 issuer identifier info

This prompted me to dig up more information of this old issue. Here is the issue in our tracker: https://jira.primekey.se/browse/ECA-3149 Looking back in my records it's not only a local jurisdiction auditor that enforced SHA-256. We also received several request from Web PKI CAs to