Re: ComSign Root Renewal Request

I hope you can understand that trust is not just based on the state of the world 'today', but based on everything that key has ever done and every bit of infrastructure that key has run on. We know that key has been run on deficient infrastructure, with deficient software, and done deficient

Re: ComSign Root Renewal Request

On Mon, Feb 12, 2018 at 1:50 PM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Wayne, > Please realize our situation versus the Israeli market. We are the major > certificate authority and we comply with every piece of local regulation, > we are also members

Re: Mozilla’s Plan for Symantec Roots

On Mon, Feb 12, 2018 at 11:36 AM, Kai Engert <k...@kuix.de> wrote: > On 09.02.2018 22:20, Ryan Sleevi wrote: > > As a small clarification - while Chrome has included the certificates, > > as noted in the readme, the whitelist is based on SPKI. This was > > inten

Re: Mozilla’s Plan for Symantec Roots

Hi Wayne, As a small clarification - while Chrome has included the certificates, as noted in the readme, the whitelist is based on SPKI. This was intentional, to avoid situations of interoperability issues. Whitelisting by certificate, rather than either SPKI or SPKI-Tuple, brings with it

Re: Certificate for com and it

On Thu, Feb 8, 2018 at 3:14 PM, Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, 8 Feb 2018 15:50:08 + > Gervase Markham via dev-security-policy > wrote: > > > In this case, the certificates are revoked in

Re: Misissuance/non-compliance remediation timelines

So your view is the “carrot” is getting to use Mozilla’s brand as an endorsement, and the “stick” being that if you don’t get that endorsement for a while, you get kicked out? The assumption is that the branding of “best” is valuable - presumably, through the indirect benefit of being able to

Re: Certificates with 2008 Debian weak key bug

On Tue, Feb 6, 2018 at 10:48 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 5/02/2018 17:08, Hanno Böck wrote: > >> https://crt.sh/?id=308392091=ocsp >> > > It has: > Subject: > commonName= ftp.gavdi.pl >

Re: IP Validation using method 3.2.2.5 (4) "any other method"

On Tue, Jan 30, 2018 at 10:37 AM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > I'm sending this to this list because CAs are required to monitor this > list, > and I need to get feedback from smaller and more obscure CAs. > > > > The validation

Re: Taiwan GRCA Root Renewal Request

On Fri, Jan 12, 2018 at 2:27 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, June 1, 2017 at 5:03:15 PM UTC-7, Kathleen Wilson wrote: > > On Friday, May 26, 2017 at 9:32:57 AM UTC-7, Kathleen Wilson wrote: > > > On Wednesday, March 15, 2017

Re: Summary of Responses to the November CA Communication

ew > chair. > > James > > On Fri, Jan 26, 2018 at 1:58 PM, Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Fri, Jan 26, 2018 at 5:43 AM Gervase Markham <g...@mozilla.org> wrote: >> >> > On 24/01/18 13:56, Rya

Re: Summary of Responses to the November CA Communication

On Fri, Jan 26, 2018 at 5:43 AM Gervase Markham <g...@mozilla.org> wrote: > On 24/01/18 13:56, Ryan Sleevi wrote: > >> more frequently when requirements change. I propose that we require CAs > to > >> update their CPS to comply with version 2.5 of the Mozilla root s

Re: DRAFT January 2018 CA Communication

On Fri, Jan 26, 2018 at 5:24 AM Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 24/01/18 22:19, Jonathan Rudenberg wrote: > > While these CAs might want six months, it’s not clear that a good > > argument has been made for this. Let’s Encrypt stopped

Re: DRAFT January 2018 CA Communication

On Thu, Jan 25, 2018 at 4:20 PM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Jan 25, 2018 at 1:02 PM, Ryan Sleevi via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On Thu, Jan 25, 2018 at 3:3

Re: DRAFT January 2018 CA Communication

On Thu, Jan 25, 2018 at 3:34 PM, Wayne Thayer wrote: > On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg < > jonat...@titanous.com> wrote: > >> This is a great improvement. I think we should also ask that any CAs >> using these methods immediate disclose that they are and

Re: DRAFT January 2018 CA Communication

On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Is there a reason to make this deprecation conditional on the ballot? > > Given what we know about how the vulnerable methods are used in the wild, > > they have the same

Re: Summary of Responses to the November CA Communication

On Wed, Jan 24, 2018 at 4:41 PM, Wayne Thayer wrote: > To the best of my knowledge, the only "standard" sanction we have today is > complete distrust of a root or intermediate, and in practice that rarely > happens. On the surface, the idea of lesser sanctions like removing

Re: Summary of Responses to the November CA Communication

liant CAs for lateness > of documents, incidents and etc. > There needs to be a switch developed which allows program members to > disable features such as EV without messing around in code. > > James > > > On Wed, Jan 24, 2018 at 1:56 PM, Ryan Sleevi via dev-securi

Re: Summary of Responses to the November CA Communication

On Tue, Jan 23, 2018 at 7:47 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Everyone, > > I have reviewed the responses we received from the November 2017 CA > Communication [1], and I have the following comments to share: > > * Beginning with the

Re: GlobalSign certificate with far-future notBefore

On Wed, Jan 24, 2018 at 6:52 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > We don't allow customers to set the notBefore date into the past. > > And regarding the Mozilla checks for > https://bugzilla.mozilla.org/show_bug.cgi?id=908125, perhaps the >

Re: GlobalSign certificate with far-future notBefore

On Wed, Jan 24, 2018 at 7:05 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > > -Original Message- > > From: Gervase Markham [mailto:g...@mozilla.org] > > Sent: Wednesday, January 24, 2018 7:00 AM > > To: Doug Beattie

Re: Google OCSP service down

On Sun, Jan 21, 2018 at 4:00 PM Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi, > > On Sun, 21 Jan 2018 12:09:23 -0800 (PST) > Ryan Hurst via dev-security-policy > wrote: > > > We maintain contact details both within

Re: Google OCSP service down

On Sun, Jan 21, 2018 at 2:08 PM David E. Ross via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 1/21/2018 9:50 AM, Ryan Sleevi wrote: > > I couldn’t find that listed in the CP/CPS as where to report problems. > > Instead, I see a different email

Re: Google OCSP service down

On Sun, Jan 21, 2018 at 11:12 AM David E. Ross via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 1/21/2018 7:47 AM, Paul Kehrer wrote: > > Is there a known contact to report it (or is someone with a Google hat > > reading this anyway)? > > On Friday (two days ago), I

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 3:58 PM Doug Beattie wrote: > Matthew, > > > > That’s a good summary. It seems we have 2 methods that can be used only > if the CAs using the methods have the design and risk mitigation factors > reviewed and approved. It’s basically the

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 1:44 PM, Matthew Hardeman wrote: > Ultimately, if it should arise that other CAs who rely on mechanisms > implementing or claiming to implement method #10 have similar risk and > vulnerabilities, those CAs should be called to task for not having

Re: TLS-SNI-01 and compliance with BRs

use of the .9 and .10 methods, and then evaluate on a case by case basis the mitigating factors and risks that may necessitate a gradual phase out on a per-CA basis. > > > [1] https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-10.2 > > > > > > *From:*

Re: Updating Root Inclusion Criteria

On Thu, Jan 18, 2018 at 9:33 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Thu, Jan 18, 2018 at 9:11 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 18/01/18 13:55, Ryan Sleevi wrote: >> > Was i

Re: Updating Root Inclusion Criteria

On Thu, Jan 18, 2018 at 4:59 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/01/18 19:14, Ryan Hurst wrote: > > Since Google's PKI was mentioned as an example, I can publicly state > > that the plan is for Google to utilize the Google Trust

Re: Updating Root Inclusion Criteria

On Thu, Jan 18, 2018 at 4:24 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/01/18 15:13, Jonathan Rudenberg wrote: > > I like this concept a lot. Some concrete ideas in this space: > > > > - Limit the validity period of root certificates to a

Re: CCADB disclosure of id-kp-emailProtection intermediates

Specifically, https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3mogw7 On Tue, Jan 16, 2018 at 6:06 PM, Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > What about the Mozilla CA communication

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

On Mon, Jan 15, 2018 at 4:54 PM, Eric Mill wrote: > I can only go on what's on the public list, but if it is as it appears and > GS proactively researched their offering, identified a similar weakness via > a separate BR method, and voluntarily turned off their implementation

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

On Mon, Jan 15, 2018 at 4:40 PM, Doug Beattie <doug.beat...@globalsign.com> wrote: > > > > > *From:* Ryan Sleevi [mailto:r...@sleevi.com] > *Sent:* Monday, January 15, 2018 4:14 PM > *To:* Doug Beattie <doug.beat...@globalsign.com> > *Cc:* r...@

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

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 to X months > during the short-term, and to make sure OneClick is disabled within Y > months from now, seems like a

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

On Mon, Jan 15, 2018 at 3:36 PM, Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ryan, > > I’m not sure where we go from here. As suggested, we encourage you to work on devising technical mitigations or alternative methods of validating such certificates

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

On Mon, Jan 15, 2018 at 1:18 PM, Doug Beattie <doug.beat...@globalsign.com> wrote: > > > > > *From:* Ryan Sleevi [mailto:r...@sleevi.com] > *Sent:* Friday, January 12, 2018 5:53 PM > *To:* Doug Beattie <doug.beat...@globalsign.com> > *Cc:* Wayne Thayer <wtha

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

On Sat, Jan 13, 2018 at 8:46 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, January 12, 2018 at 6:10:00 PM UTC-8, Matt Palmer wrote: > > On Fri, Jan 12, 2018 at 02:52:54PM +, Doug Beattie via > dev-security-policy wrote: > > > I’d like to

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

On Fri, Jan 12, 2018 at 4:24 PM, Doug Beattie wrote: > Wayne, > > > > We didn’t really investigate wildcard issuance yet, but we can. > > > > Given the discuss so far, we’re planning to proceed with a whitelisting > approach tomorrow and we will plan to end the use

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Fri, Jan 12, 2018 at 5:46 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 11/01/2018 05:38, Ryan Sleevi wrote: > > On Thu, Jan 11, 2018 at 2:46 AM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org&g

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

On Thu, Jan 11, 2018 at 4:50 PM, Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Based on reported issues with TLS-SNI-01, we started investigation of our > systems late yesterday regarding the use of "Test Certificate" validation, > BR section 3.2.2.4.9.

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 4:33 AM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > At approximately 5 p.m. Pacific time on January 9, 2018, we received a > report from Frans Rosén of Detectify outlining a method of exploiting some > shared hosting infrastructures

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Thu, Jan 11, 2018 at 1:36 AM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, January 10, 2018 at 6:17:34 PM UTC-6, Ryan Sleevi wrote: > > On Wed, Jan 10, 2018 at 5:53 PM, Matthew Hardeman <mharde...@gm

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Thu, Jan 11, 2018 at 2:46 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 11/01/2018 01:08, Ryan Sleevi wrote: > > On Wed, Jan 10, 2018 at 6:35 PM, Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 5:53 PM, Matthew Hardeman wrote: > For comparison of "What could be worse", you could imagine a CA using the >> .10 method to assert the Random Value (which, unlike .7, is not bounded in >> its validity) is expressed via the serial number. In this

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 6:35 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Agree. > > Hence my suggestion that TLS-SNI-0next use a name under the customer's > domain (such as the name used for DNS-01), not a name under .invalid. I thought it had been

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 4:37 PM, Matthew Hardeman wrote: > > In the exact text above, what I meant by "create the proper zone in > .acme.invalid" was to create that web hosting context (or actually set of > web hosting contexts) and bind to the Host names that are the >

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 1:51 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I acknowledge that the TLS-SNI-02 improvements do eliminate certain risks > of the TLS-SNI-01 validation method -- and they do at least restore a > promise that the

Re: DYMO Root CA installed by Label Printing Software

On Wed, Jan 10, 2018 at 3:33 AM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > Ryan Sleevi <r...@sleevi.com> writes: > > >I hope you can see how I responded to precisely the problem provided. > > You responded to that one specific limited instance. I respond

Re: DYMO Root CA installed by Label Printing Software

On Wed, Jan 10, 2018 at 12:42 AM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > Ryan Sleevi <r...@sleevi.com> writes: > > >Of course, if that doesn’t tickle your fancy, there are other ways that > are > >supported that you may not have heard

Re: DYMO Root CA installed by Label Printing Software

On Wed, Jan 10, 2018 at 12:08 AM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > Ryan Sleevi <r...@sleevi.com> writes: > > >Or is your viewpoint that because this happened in the past, one should > >assume that it will forever happen, no matter how much the ecos

Re: DYMO Root CA installed by Label Printing Software

On Tue, Jan 9, 2018 at 11:12 PM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > Ryan Sleevi <r...@sleevi.com> writes: > > >First, there are non-commercial CAs that are trusted. > > By "commercial CAs" I meant external business entities, not an in-house

Re: DYMO Root CA installed by Label Printing Software

On Tue, Jan 9, 2018 at 4:40 PM, Peter Gutmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Nicholas Humfrey via dev-security-policy mozilla.org> writes: > > >What is the correct way for them to achieve what they are trying to do? > > I'm

Re: Serial number length

Or just generate longer serials with random. Which is much simpler. On Fri, Dec 29, 2017 at 11:57 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 29/12/2017 13:55, Nick Lamb wrote: > >> On Fri, 29 Dec 2017 07:24:31 +0100 >> Jakob Bohm via

Re: Serial number length

On Fri, Dec 29, 2017 at 1:24 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > After looking at some real certificates both in the browser and on crt.sh, > I have some followup questions on certificate serial numbers: > > 1. Do all recently issued

Re: On the value of EV

On Mon, Dec 18, 2017 at 4:09 PM, Wayne Thayer wrote: > Thank you Ryan for raising this question, and to everyone who has been > contributing in a constructive manner to the discussion. A number of > excellent points have been raised on the effectiveness of EV in general and

Re: On the value of EV

arly encourage better ecommerce behaviors? > > > On Mon, Dec 18, 2017 at 1:27 PM, Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Mon, Dec 18, 2017 at 1:26 PM, Andrew via dev-security-policy < >> dev-security-policy@li

Re: On the value of EV

On Mon, Dec 18, 2017 at 1:26 PM, Andrew via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, December 15, 2017 at 4:06:02 PM UTC-6, Ryan Sleevi wrote: > > It also perpetuates the myopic and flawed view as a phishing mitigation, > > whose r

Re: Mississuance of EV Certificates

On Mon, Dec 18, 2017 at 9:30 AM, cornelia.enke66--- via dev-security-policy wrote: > > Update on the long-term countermeasures: > At the first point - sorry for the delay. I missed to post my answer on > Fryday. > > We The occurred error caused by a human

Re: CABF Recommendations (was: On the value of EV)

On Sun, Dec 17, 2017 at 6:38 PM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Again I will state that it's in the best interests of CA's to improve > their EV issuing guidelines and practices. While CA's no doubt enjoy > charging a premium for EV

Re: On the value of EV

On Sun, Dec 17, 2017 at 4:45 PM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Second, the actual value in EV as far as I can see is in having that human > readable name in addition to the domain name. A successful plan of attack > will need convincing

Re: On the value of EV

On Fri, Dec 15, 2017 at 5:38 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, December 15, 2017 at 4:06:02 PM UTC-6, Ryan Sleevi wrote: > > > It also perpetuates the myopic and flawed view as a phishing mitigation, > >

Re: On the value of EV

I agree. Just like "could" repel tigers is different than "does" repel tigers. On Fri, Dec 15, 2017 at 5:30 PM, Tim Shirley <tshir...@trustwave.com> wrote: > I’m saying “can” be spoofed is different than “is” being spoofed. > > > > *From: *Ryan

Re: On the value of EV

nts phishing or > that the UI is providing me a guarantee. I’m saying it’s giving me a > signal to pay closer attention, and I’m describing a scenario where that > signal will help keep me safe; a time when the seatbelt works, even if you > think I’m putting too much trust in it. > &

Re: CAA records checked against immediate issuer or root?

On Fri, Dec 15, 2017 at 5:05 PM, Jan Schaumann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello, > > I'm seeking clarification on the meaning of the CAA records: > > RFC6844 notes that the 'issue' property entry "authorizes the holder of > the domain name *or a

Re: On the value of EV

On Fri, Dec 15, 2017 at 4:50 PM, Tim Shirley wrote: > I don’t see how you can argue that the EV “seatbelt” breaks 100% of the > time. I know my bank uses an EV cert. Any time I come across a site > claiming to be my bank but lacking an EV cert, and my browser shows me

Re: On the value of EV

On Fri, Dec 15, 2017 at 4:26 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, December 15, 2017 at 3:08:32 PM UTC-6, Ryan Sleevi wrote: > > > Respectfully, this is the tiger-repelling rock. We can't show that any &

Re: On the value of EV

On Fri, Dec 15, 2017 at 2:34 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, December 15, 2017 at 8:08:44 AM UTC-6, Ryan Sleevi wrote: > > > James’ research has showed the ease at which it is possible to use the

Re: On the value of EV

On Fri, Dec 15, 2017 at 2:34 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 15/12/2017 02:30, Ryan Sleevi wrote: > > Some participants have pointed out correlation is not causation - that > you > > can’t infer that never being a

Re: On the value of EV

On Thu, Dec 14, 2017 at 5:01 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 14/12/2017 00:23, Peter Gutmann wrote: > > Tim Shirley via dev-security-policy < > dev-security-policy@lists.mozilla.org> writes: > > > >> But regardless of which (or neither)

Re: On the value of EV

3, 2017 2:41 PM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: On the value of EV > > > > On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote: > > > > > Yes. This is the foundation and limit of Web Security. &

Re: On the value of EV

On Wed, Dec 13, 2017 at 6:23 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I realize I'm doing a poor job at articulating the profound risks, > perhaps > > because they're best not for e-mail discussions, but these problems are > not > > unique

Re: On the value of EV

ter never. I’ve > never heard of any, so it’s possible it really is never. But I’m pretty > confident in at least the “rare” part because I’m sure if you knew of any > you’d be sharing examples. ;) > > > > > > *From: *Ryan Sleevi <r...@sleevi.com> > *Reply-To:

Re: On the value of EV

On Wed, Dec 13, 2017 at 5:19 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > There are also the really cool hash-based revocation ideas that actually > do help > even against active attackers on the same network. I really wish those > ideas got > more

Re: On the value of EV

On Wed, Dec 13, 2017 at 4:46 PM, Tim Shirley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > As I understand it, Adam’s argument there was that to get value out of a > revoked certificate, you need to be between the user and the web server so > you can direct the traffic

Re: On the value of EV

On Wed, Dec 13, 2017 at 4:40 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote: > > > Yes. This is the foundation and limit of Web Security. > > > > http

Re: On the value of EV

On Wed, Dec 13, 2017 at 4:28 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, December 13, 2017 at 2:46:10 PM UTC-6, Gervase Markham wrote: > > > My concern with this argument is that it's susceptible to the criticism > > that Adam

Re: On the value of EV

On Wed, Dec 13, 2017 at 4:14 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, December 11, 2017 at 6:01:25 PM UTC-6, Ryan Sleevi wrote: > > > > Not really - what matters is that the user insists they got had via

Re: On the value of EV

On Wed, Dec 13, 2017 at 3:50 PM, Tim Shirley wrote: > I’m not looking for a guarantee. Nothing is ever going to meet that > standard. What I’m looking for is something that’s going to improve my > odds. What I see in Ian’s and James’s research is some ways that it’s >

Re: On the value of EV

n the CA business, so if > I was “conditioned” it must have been by the outside world. ☺ > > > > *From: *Ryan Sleevi <r...@sleevi.com> > *Reply-To: *"r...@sleevi.com" <r...@sleevi.com> > *Date: *Wednesday, December 13, 2017 at 1:18 PM > *To: *Ti

Re: CA generated keys

On Wed, Dec 13, 2017 at 1:24 PM, Matthew Hardeman wrote: > As I pointed out, it can be demonstrated that quality ECDHE exchanges can > happen assuming a stateful DPRNG with a decent starting entropy corpus. > Agreed - but that's also true for the devices Tim is mentioning.

Re: On the value of EV

On Wed, Dec 13, 2017 at 1:19 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I would be sorely disappointed Prepare to be sorely disappointed > and consider it a security bug It is not a bug. It is not part of the security boundary of the Web, thus

Re: On the value of EV

On Wed, Dec 13, 2017 at 12:58 PM, Tim Shirley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > As an employee of a CA, I’m sure many here will dismiss my point of view > as self-serving. But when I am making trust decisions on the internet, I > absolutely rely on both

Re: CA generated keys

t; if we’ve seen the last major security breach based on poor RSA key > generation by resource constrained devices. > > > > Given that there exist IETF approved alternatives that could help with > that problem, they’re worth considering. I’ve been spending a lot of time > recently looki

Re: CA generated keys

On Wed, Dec 13, 2017 at 11:06 AM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Wayne, > > For TLS/SSL certificates, I think PKCS #12 delivery of the key and > certificate > at the same time should be allowed, and I have no problem with a > requirement

Re: On the value of EV

On Wed, Dec 13, 2017 at 6:29 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Yes. This is the foundation and limit of Web Security. > > > > https://en.wikipedia.org/wiki/Same-origin_policy > > > > This is what is programatically enforced. Anything else

Re: On the value of EV

On Tue, Dec 12, 2017 at 3:44 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > What you are writing below, with far too many words is that you think > that URLs are the only identities that matter in this world, and > therefore DV certificates are enough

Re: On the value of EV

On Tue, Dec 12, 2017 at 1:11 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > The overall thing is that the current thread seems to be a major case of > throwing the baby out with the bathwater. > That is overly reductive and may demonstrate a lack of

Re: On the value of EV

On Tue, Dec 12, 2017 at 8:36 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 12/12/2017 01:08, Adam Caudill wrote: > >> Even if it is, someone filed the paperwork. Court houses have clerks, > guards, video cameras, etc... It still may present a

Re: Mississuance of EV Certificates

On Tue, Dec 12, 2017 at 10:18 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > The implemented controls detected the misconfiguration within 24 > > hours. The incorrect configuration was nevertheless recorded as a > > security incident. The handling of

Re: OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)

No. It has been prohibited for years in the Baseline Requirements. With an expectation that CAs monitor such requests in light of DigiNotar On Mon, Dec 11, 2017 at 8:54 PM Peter Gutmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Rob Stradling via

Re: On the value of EV

On Mon, Dec 11, 2017 at 6:46 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, December 11, 2017 at 5:00:14 PM UTC-6, Ryan Sleevi wrote: > > > That Kentucky registration for Stripe, Inc. -- Is it compl

Re: On the value of EV

On Monday, December 11, 2017 at 4:03:41 PM UTC-5, Matthew Hardeman wrote: > I think it will be a difficult sell to remove EV certificate UI handling, > as nothing is proposed to replace it. I think this is flawed. If EV doesn't provide value, and adds confusion, it absolutely should go, and

Re: On the value of EV

On Monday, December 11, 2017 at 4:01:21 PM UTC-5, Paul Wouters wrote: > On Mon, 11 Dec 2017, Ryan Hurst via dev-security-policy wrote: > > > The issues with EV are much larger than UI. It needs to be revisited and a > > honest and achievable set of goals need to be established and the processes

Re: On the value of EV

On Mon, Dec 11, 2017 at 3:43 PM, Matthew Hardeman wrote: > I don't denigrate the recent work done. Not at all. > > This "exploit" is long known to those in the know. > > My key objection is that there needs to be a way to validate that the > brick and mortar bank you've

Re: On the value of EV

On Mon, Dec 11, 2017 at 3:12 PM, Tim Hollebeek wrote: > > > On the contrary, everything needs to be improved with time. Just because > it could be made better doesn’t make it useless or bad. > > > > -Tim > I didn't say that its ability to be improved made it bad -

Re: On the value of EV

On Mon, Dec 11, 2017 at 3:06 PM, Matthew Hardeman wrote: > > The EV guidelines already encompass this information - the jurisdiction >> fields, combined with the serialNumber, which is the unique identifying >> number for that entity within the jurisdictional registry, which

Re: On the value of EV

On Mon, Dec 11, 2017 at 2:50 PM, Tim Hollebeek wrote: > > > Certainly, as you noted, one option is to improve EV beyond simply being > an assertion of legal existence. > Does this mean we're in agreement that EV doesn't provide value to justify the UI then? ;-) I

Re: On the value of EV

us.com] > Sent: Monday, December 11, 2017 12:34 PM > To: Tim Hollebeek <tim.holleb...@digicert.com> > Cc: Ryan Sleevi <r...@sleevi.com>; mozilla-dev-security-policy@ > lists.mozilla.org > Subject: Re: On the value of EV > > > > On Dec 11, 2017, at 14:14, Tim Hollebe

Re: On the value of EV

On Mon, Dec 11, 2017 at 2:31 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > (Reposting as I accidentally replied directly to OP ). > > Part of this discussion will necessarily have to include who the intended > and potential beneficiaries of EV

Re: On the value of EV

On Mon, Dec 11, 2017 at 2:23 PM, Paul Wouters via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, 11 Dec 2017, Ryan Sleevi via dev-security-policy wrote: > > I suppose this is both a question for policy and for Mozilla - given the >> abilit

Re: On the value of EV

On Mon, Dec 11, 2017 at 2:14 PM, Tim Hollebeek wrote: > > It turns out that the CA/Browser Validation working group is currently > looking into how to address these issues, in order to tighten up validation > in these cases. We discussed it a bit last Thursday, and

<    3   4   5   6   7   8   9   10   11   12   >