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
___
dev-security-polic
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 certificate and the key to a
> customer
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
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 Mes
> 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 ass
The (I believe) meritorious point that Mr. Hollebeek raises mainly pertains
to embedded devices.
As the IoT craze heats up, I keep seeing platforms ship with unfinished OS
stacks, missing drivers, etc. A lot of hardware in the field is shipping
with decent dedicated entropy sources on board coupl
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 V
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 th
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 accurate-but-misleading information in EV certificates, and
the effect it has on the URL bar (the lone trusted space for security
informa
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 th
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 will be
> continuing
> the dis
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 accurate-but-mi
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
(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 ki
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
> 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.
This isn’t a validation issue. Both certifi
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 certi
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
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 included in certificates. The
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 ; Ryan Sleevi ;
mozilla-dev-security-pol...@list
> 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 o
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 necessarily have to include who the intended
>> and potentia
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 say it loaded and facetiously,
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 is unique
>> per juris
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; Jonathan Rudenberg ;
mozill
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>
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, it's
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 - merely, its
present state is b
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
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
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 done business with for years _is_ the same group as
currenrtly has web domain xyz.
Something
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?
>
> I
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 done business with for ye
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 support
- 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
> simultaneo
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 need
> clothes. But
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 s
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 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
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 doesn
On Monday, December 11, 2017 at 5:47:50 PM UTC-5, Matthew Hardeman wrote:
> 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 h
On Mon, Dec 11, 2017 at 5:03 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Monday, December 11, 2017 at 5:47:50 PM UTC-5, Matthew Hardeman wrote:
> > While I understand that it may formally be beyond the scope formally to
> > consider this in discussi
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 it has on the URL bar (the lone trusted
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)
On Mon, Dec 11, 2017 at 6:31 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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 co
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 ent
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 registered
> > > 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, y
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 el
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, OCSP's "Good" just
means "not revoked", and a
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 dev-security-policy
51 matches
Mail list logo
