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: OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)

Rob Stradling via dev-security-policy writes: >CAs / Responder URLs that are in scope for, but violate, the BR prohibition >on returning a signed a "Good" response for a random serial number Isn't that perfectly valid? Despite the misleading name,

Re: On the value of EV

On Monday, December 11, 2017 at 5:37:34 PM UTC-6, Ryan Sleevi wrote: > Yes. > > If something is not valuable for billions of users, if it is not > trustworthy for billions of users, it should not occupy the cognitive or > visual model billions of users rely on. > Perish the thought that a UI

Re: On the value of EV

> > > Even if it is, someone filed the paperwork. Court houses have clerks, > > > guards, video cameras, etc... It still may present a real physical point > > > from which to bootstrap an investigation. > > > > Court houses also have online systems. I think if you read both Ian and James' work,

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 completely > fraudulent > > > as to

Re: On the value of EV

On Monday, December 11, 2017 at 5:00:14 PM UTC-6, Ryan Sleevi wrote: > > That Kentucky registration for Stripe, Inc. -- Is it completely fraudulent > > as to registered agent, business address, etc? If it's not, then the > > certificate and underlying entity serve as an archived investigative

Re: On the value of EV

What I dislike about this particular rationale is that I presupposes we should architect web security such as to avoid enhancements which have value to anyone the least common denominator. Is the average user (actually, the bottom rung of the concentration of values around the average, I suppose)

Re: On the value of EV

Hi, On Mon, 11 Dec 2017 11:01:10 -0800 (PST) Ryan Sleevi via dev-security-policy wrote: > I suppose this is both a question for policy and for Mozilla - given > the ability to provide accurate-but-misleading information in EV > certificates, and the effect

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

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

Inspired by Paul Kehrer's research a few months ago, I've added a continuous OCSP Monitoring feature to crt.sh: https://crt.sh/ocsp-responders This page shows the latest results of 3 OCSP checks (performed hourly) against each CA / Responder URL that crt.sh has ever encountered: 1. a GET

Re: On the value of EV

While I understand that it may formally be beyond the scope formally to consider this in discussion with EV UI handling, I think some consideration to ecosystem harm is appropriate here. If we eliminate EV UI, we have reduced the scope of WebPKI to domain validated certificates (in any pragmatic

Re: On the value of EV

On Mon, Dec 11, 2017 at 2:53 PM, Ryan Sleevi wrote: > > > It feels like, to some extent, this is a question about whether we should > point out the Emperor has no clothes if we don't have clothes to offer him. > It'd be great if they was wearing some, I agree - the Emperor does

Re: On the value of EV

- If the fundamental certificate does deserve the UI treatment, then > demonstrate why it does. You seem to be in agreement that the present form > of legal identity is insufficient for the presumed use case, so I'm hoping > you can close the gap in my understanding on why something is >

Re: On the value of EV

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 and procedures used pre-issuance and post-issuance need to be defined in

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 Monday, December 11, 2017 at 12:41:02 PM UTC-8, Paul Wouters wrote: > On Mon, 11 Dec 2017, James Burton via dev-security-policy wrote: > > > EV is on borrowed time > > You don't explain why? > > I mean domain names can be confusing or malicious too. Are domain names > on borrowed time? > >

Re: On the value of EV

On Mon, 11 Dec 2017, James Burton via dev-security-policy wrote: EV is on borrowed time You don't explain why? I mean domain names can be confusing or malicious too. Are domain names on borrowed time? If you remove EV, how will the users react when paypal or their bank is suddenly no longer

Re: On the value of EV

Stripe, Inc could very well be a road striping company. This may have situationally been the equivalent of a misleading certificate but the scenario of name collisions is real. Ryan Hurst On Monday, December 11, 2017 at 11:39:57 AM UTC-8, Tim Hollebeek wrote: > Nobody is disputing the fact that

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

EV is on borrowed time and deprecating EV is the most logical viable solution right now and brings us one step forward in vanishing the old broken web security frameworks of the past. Now that both me and Ian have demonstrated the fundamental issues with EV and the way its displayed in the UI,

Re: On the value of EV

The question that I have is whether the community might consider it in-scope to discuss enhancements (even fixes) to EV to arrive at assurance commensurate to its handling. Matt Hardeman On Mon, Dec 11, 2017 at 2:09 PM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org>

RE: On the value of EV

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 From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, December 11, 2017 1:09 PM To: Tim Hollebeek Cc: r...@sleevi.com;

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

On Mon, Dec 11, 2017 at 1:37 PM, Ryan Sleevi wrote: > > > On Mon, Dec 11, 2017 at 2:31 PM, Matthew Hardeman via dev-security-policy > wrote: > >> (Reposting as I accidentally replied directly to OP ). >> >> Part of this discussion will

Re: On the value of EV

> However, I don't believe "technically correct, but intentionally misleading" information should be included in certificates. The question is how best to accomplish that. How would you determine what's misleading, and what isn't? As mentioned, the Stripe, Inc of Kentucky could present an image

RE: On the value of EV

Certainly, as you noted, one option is to improve EV beyond simply being an assertion of legal existence. -Tim From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, December 11, 2017 12:46 PM To: Tim Hollebeek Cc: Jonathan Rudenberg

Re: On the value of EV

On Mon, Dec 11, 2017 at 2:39 PM, Tim Hollebeek wrote: > Nobody is disputing the fact that these certificates were legitimate given > the rules that exist today. > > However, I don't believe "technically correct, but intentionally > misleading" information should be

RE: On the value of EV

Nobody is disputing the fact that these certificates were legitimate given the rules that exist today. However, I don't believe "technically correct, but intentionally misleading" information should be included in certificates. The question is how best to accomplish that. -Tim -Original

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 Dec 11, 2017, at 14:14, Tim Hollebeek via dev-security-policy > 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.

RE: On the value of EV

Happy to share the details. We only had about 10 minutes on the agenda, so the discussion hasn’t been too detailed so far (there is still a lot of fallout from CAA that is dominating many validation discussions). There was a general consensus that companies with intentionally misleading

Fwd: On the value of EV

(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 certificate status are: 1. Is it the common web end user? If so, EV either needs to go or be massively changed. 2. Is it for the

Re: On the value of EV

That's not clear at all. Someone other than the famous Stripe, Inc. has -- without violating BR rules or requirements -- a proper EV certificate showing (correctly) entity name Stripe, Inc. That this exists suggests that EV is harmful if the target is normal everyday people. Making the abstract

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 >> ability to provide

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

Re: On the value of EV

Can you share what the working group has been brainstorming on? Near as I can tell, this is a validly issued EV cert, for a valid KY company. If "Stripe, Inc of Kentucky" were in a distinct industry from this Stripe there wouldn't even be a trademark claim (I'm not a lawyer, etc.). Lest anyone

RE: On the value of EV

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 will be continuing the discussion on the 21st. If anyone has any good ideas, we'd be more

On the value of EV

Recently, researchers have been looking into the value proposition of EV certificates, and more importantly, how easy it is to obtain certificates that may confuse or mislead users - a purpose that EV is supposedly intended to avoid. James Burton was able to obtain a certificate for "Identity

RE: CA generated keys

> The more I think about it, the more I see this is actually a interesting question :-) I had the same feeling. It seems like an easy question to answer until you start thinking about it. > I suspect the first thing Mozilla allowing this would do would be to make it much more common. (Let's

RE: CA generated keys

Loosen the interpretation of escrow from a box surrounded by KRAs, KROs, and access controls with a rolling LTSK and escrow could describe what many white glove and CDN tier hosting operations do. The CDN has written consent, but the end customer never touches the TLS cert. > -Original

RE: CA generated keys

I think key escrow services are pretty rare related to TLS certs. However, there's lots of CAs and services that escrow signing keys for s/MIME certs. Although, I'm not sure how companies can claim non-repudiation if they've escrowed the signing key, a lot of enterprises use dual-use keys and want

Re: CA generated keys

On Sat, 9 Dec 2017 18:20:56 + Tim Hollebeek via dev-security-policy wrote: > First, third parties who are *not* CAs can run key generation and > escrow services, and then the third party service can apply for a > certificate for the key, and deliver the

Re: Certigna Root Renewal Request

Just to let you know that CPSs for certificates that are not used for website authentication will be available by January 15, 2018. CPS for SSL / TLS certificates are already available in French and English versions. Best regards ___