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

2019-08-28 Thread Matt Palmer via dev-security-policy
On Wed, Aug 28, 2019 at 11:51:37AM -0700, Josef Schneider via 
dev-security-policy wrote:
> Am Dienstag, 27. August 2019 00:48:38 UTC+2 schrieb Matt Palmer:
> > On Mon, Aug 26, 2019 at 05:39:14AM -0700, Josef Schneider via 
> > dev-security-policy wrote:
> > > Sure I can register a company and get an EV certificate for that company. 
> > > But can I do this completely anonymous like getting a DV cert?
> > 
> > Yes.
> 
> Not legally probably

Someone planning to commit fraud is unlikely to be deterred by the need to
commit fraud in order to commit fraud.

> and this also depends on the jurisdiction.  Since an
> EV cert shows the jurisdiction, a user can draw conclusions from that.

You're suggesting that Relying Parties need to familiarise themselves with
the validation procedures of every jurisdiction which is listed in an EV
certificate they are presented with, in order to establish the
trustworthiness of that EV certificate?

I'm just going to leave that there.  For posterity.

> > > Nobody is arguing that EV certificates are perfect and everything is good
> > > if you use them.  But they do raise the bar for criminals.  And in my
> > > opinion, significantly.
> > 
> > Except criminals don't need them.  Raising the bar doesn't help if you don't
> > need to go over the bar.
> 
> But removing the bar is also not the correct solution.  If you find out
> that the back door to your house is not secured properly, will you remove
> the front door because it doesn't matter anyway or do you strengthen the
> back door?

The problem with your analogy is that, in the case under discussion, there
is no known way to secure the back door, and it's the broken and unfixable
back door, not the front door, that is being removed.

So yes, if my back door was insecure, and the best information available
indicated that it couldn't be secured, and it was causing me time and money
to maintain in its current, insecure, state, I would absolutely remove it. 
I expect you would, too.  Although I can certainly understand that if you
were making money by allowing people to use my broken back door, you might
want to encourage me not to remove it.

> > > What I propose is for mozilla to not say "Fuck it, it's not working, just
> > > remove it!" but instead try to focus on finding a better UX solution to
> > > the problem that end users are not aware if a site that should have an EV
> > > certificate is not presenting one.
> > 
> > Why should Mozilla do all this work?  So far, all the evidence suggests that
> > EV certs do not do what their advocates say they do, and have a significant
> > cost to browsers (code complexity, administration of EV bits, etc) and
> > relying parties (need to learn what the EV UI means, what it does and
> > doesn't claim, etc).
> 
> Why should Mozilla do work to make the situation worse?  The current EV
> validation information in the URL works and is helpful to some users
> (maybe only a small percentage of users, but still...).  Why is mozilla
> interested in spending money making the situation worse.  If mozilla
> doesn't care about the empowerment of their users, the default would be to
> not change anything, not actively making it worse.

Not being Mozilla, I wouldn't presume to speak for them, but two
possibilities leap immediately to mind:

* It costs time and money to maintain the list of trust anchors approved for
  EV treatment -- OID mappings, evaluating EV sections of CP/CPSes, chasing
  audit reports, dealing with incident reports relating to EV validation
  failures, and discussing and evaluating proposed changes to the EVGLs.

* EV-related code in Mozilla software requires maintenance as other changes
  in surrounding code are made.  Less code == ess things to change, so
  gutting the EV support reduces maintenance costs.

> EV certificates do make more assurances about the certificate owner than
> DV certificates.  This is a fact.  This information can be very useful for
> someone that understands what it means.  Probably most users don't
> understand what it means.  But why not improve the display of this
> valuable information instead of hiding it?

Because there is no indication of what an improved EV UI would look like.

I note that you've neglected to answer the question I posed.  If CAs sat
down and did some research into what an actual, useful EV UI would involve,
then Mozilla would have something to work from.  But it would appear that
CAs -- the organisations, I'll reiterate, that benefit financially from the
continued special UI treatment of EV certificates -- are not interested in
making such a contribution.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

2019-08-28 Thread Ryan Sleevi via dev-security-policy
(Posting in a personal capacity)

On Wed, Aug 28, 2019 at 7:01 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Most of the comments against EV certificates on this list have been
> focused on whether or not the current Firefox EV UI is relied on by Firefox
> users to make security decisions.  (Actually, I have only seen a Google
> paper on this issue in Chrome, no research from Firefox.)
>
> But there is an ecosystem of anti-phishing browser filters (e.g., Google
> Safe Browsing, Microsoft Smart Screen) and services (e.g., PhishLabs) as
> well as others that use the current identity information in EV certs to
> make better determinations of positive and false positive phishing sites
> and thereby protect users, as well as for other user security purposes.
>
> Many on this discussion would like to see EV certs disappear entirely and
> move all websites to DV certs.  But remember, if EV certs disappear, so
> does all the EV identity information that’s being used today by security
> software to protect users.
>
> So my question to those who want EV certificates to disappear is this: OK,
> then what is *your* plan for protecting users?  Browser filters will be
> weaker without EV information (and some browser filters today miss 20% of
> phishing sites at zero hour, according to NSS studies).  How will you
> replace the EV information that’s being used today by phishing filters and
> services to protect users?
>

These are very reasonable concerns, and a very valid question to ask.
However, with respect to Mozilla's original posting here, or the
announcements from the Chrome team, it does not sound as if any of the
browsers are presently proposing removing EV.

So perhaps that's worthy of a separate conversation?


> Any decision on removing the EV UI in Firefox should consider all the
> related impacts on user security, and not just focus on a single issue
> (namely, “Do users rely on the EV UI?”), especially when the current
> Firefox EV UI is doing no harm.
>

I may have missed something in the hundred messages in this thread, but
could you highlight what other "impacts on user security" were identified
that are specific to the UI, and that are not intrinsically linked to the
question of "Do users rely on the EV UI"? Perhaps it might be worth
exploring Peter Bowen's questions, in
https://groups.google.com/d/msg/mozilla.dev.security.policy/iVCahTyZ7aw/TaXQb7VcAQAJ
, or those offered in
https://groups.google.com/d/msg/mozilla.dev.security.policy/iVCahTyZ7aw/gBqfc3XPAAAJ
, which seemed to identify both the question of harm and how this change
would not negatively impair other improvements.

With respect to "doing no harm," a position others on the thread have also
mentioned, I don't know that conclusion has been demonstrated. Could you
point to any peer-reviewed research or literature that suggests it does no
harm? There appears to be a sizable and growing body with respect to
Human-Computer Interaction, as well as within the broader behavioural
sciences, that the studies around EV have referenced or mentioned in terms
things like "alarm fatigue" and "information overload".

Much like the discussion around correlation versus causation, it seems like
there might be two separable pieces:
1) A question about whether users rely on EV UI
2) A question about whether the EV UI causes harm

With respect to the second question, it seems folks have identified that if
the answer to 1 is yes, then the answer to 2 is also yes - for example, the
mentioned-in-the-original-post Stripe example causing user confusion, or
situations like the organization "Identity Verified".
If the answer to 1 is no, then is it reasonable to infer that it causes
harm both in terms of software maintenance costs to support that UI, but
also in that it may lead users to believe the answer to 1 is or should be
yes, thus bringing us back to the harm caused when users rely upon it.

Perhaps I've missed some research on it doing no harm? Given the issues
identified, that would seem to be the burden to demonstrate: folks have
provided example of it doing harm, so it doesn't seem the conclusion is
there?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

2019-08-28 Thread Kirk Hall via dev-security-policy
Most of the comments against EV certificates on this list have been focused on 
whether or not the current Firefox EV UI is relied on by Firefox users to make 
security decisions.  (Actually, I have only seen a Google paper on this issue 
in Chrome, no research from Firefox.)   

But there is an ecosystem of anti-phishing browser filters (e.g., Google Safe 
Browsing, Microsoft Smart Screen) and services (e.g., PhishLabs) as well as 
others that use the current identity information in EV certs to make better 
determinations of positive and false positive phishing sites and thereby 
protect users, as well as for other user security purposes.

Many on this discussion would like to see EV certs disappear entirely and move 
all websites to DV certs.  But remember, if EV certs disappear, so does all the 
EV identity information that’s being used today by security software to protect 
users.

So my question to those who want EV certificates to disappear is this: OK, then 
what is *your* plan for protecting users?  Browser filters will be weaker 
without EV information (and some browser filters today miss 20% of phishing 
sites at zero hour, according to NSS studies).  How will you replace the EV 
information that’s being used today by phishing filters and services to protect 
users?

Any decision on removing the EV UI in Firefox should consider all the related 
impacts on user security, and not just focus on a single issue (namely, “Do 
users rely on the EV UI?”), especially when the current Firefox EV UI is doing 
no harm.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Symantec migration update

2019-08-28 Thread Jeremy Rowley via dev-security-policy
Hey – I realized it’s been a long time since I posted an update about where we 
are at on shutting down the legacy Symantec systems. I thought the community 
might find it interesting on what we’re doing to consolidate all the system.


When we bought the Symantec CA business, we promised to bring the systems up to 
modern compliance standards and deprecate systems or improve the customer 
experience by consolidating storefronts. We soon realized that we may have 
underestimate the  scope of this promise as the systems were a bit old. As soon 
as we gained access to the legacy Symantec systems, we audited the systems for 
features use and functionality and the legal business agreements requiring 
certain things. From this list, we created a migration roadmap that ensured we 
could support customer needs and maintain their certificate landscapes without 
extensive interference, prioritizing systems based on complexity and risk.



Once we had a preliminary list, engineering started developing solutions to to 
migrate customers to our primary certificate management system, CertCentral. 
This was a necessary foundational step to moving customers off legacy Symantec 
storefronts and APIs, so that we can shut down the old Symantec systems.  As 
everyone knows, we did the migration of all validation first (per the browser 
requirements), followed by the migration of org details, and other information. 
We are still working on some  migration tools.



Migration to a new system is complicated for customers, and we’ve tried to take 
an approach that would accommodate their needs. To do this, we’re migrating 
customers in a staged approach that allows us to target groups as soon as we 
have system readiness for different customer subsets. We began migration 
efforts with small accounts and accounts who had outgrown the performance of 
their old Symantec console. Moving these customers first allowed us to learn 
and adapt our migration plan. Next, we began targeting larger enterprise 
customers and partners with more complicated, business integrations. Finally, 
we have begun targeting API integrated customers with the most difficult 
migration plans. We’re working with these customers to provide them the 
resources they need to update integrations as soon as possible.



Of course, on the backend, we already migrated all legacy Symantec customers to 
the DigiCert validation and issuance systems for TLS and most code signing. 
We’re still working on it for SMIME.



To date, we’ve migrated a total of about 50,000 legacy accounts. This is 
important progress towards our goal of system consolidation since we need to 
move customers off legacy systems before we turn them off.   This isn’t the 
half-way point, but we’ve been ramping up migration as new portions of the code 
come into completion. Most of the migration has completed since June.



Now that we’re nearly product ready for all customer types to migrate, we have 
a line of sight for end of life of the Symantec systems that I thought would be 
useful to share:



**Timeline of migration events**

November 2017: purchased Symantec

December 1 2017: Began revalidation of Symantec certificates

December 2017-December 2018: Symantec business migration (transition service 
agreement exits)

January 2018: Symantec product audit

February-November 2018: Required TSA exits and internal process updates to 
absorb additional business

February 2018: Began planning massive effort to shut down legacy systems

February 2018-December 2019: Developing required customer functionality for all 
markets

January 2018? -April 2019: Data center migrations

February 2019 -November 2019: Developing a means to migrate active certificate 
data into

April 2019: Began migrating retail customers

June 2019: Began migrating Enterprise customers and Partners

August 2019: Completed DigiCert MPKI migration

August 2019: Begin DigiCert Retail migration for domain validation 
consolidation (target completion Oct 31)



**Coming next**

Q4 2019: End of sale of Symantec Enterprise solutions

Q4 2019: End of life of Symantec Encryption Everywhere, a service for hosting 
providers

Q1 2020: We will begin the shutdown process for legacy systems

Q3 2020: Target completion for all account migrations

Q3 2020: Target for system shut down for legacy storefronts, including 
migration of legacy DigiCert and Symantec systems. We aim to shut down systems 
sooner, but this largely depends on how the shutdown process proceeds.



We’re currently evaluating any additional time required to migrate API 
customers.



We are constantly working towards these dates and will post updates as things 
change.



** Note that this plan excludes QuoVadis; we will be posting updates on the 
QuoVadis system migration later once we free up resources from the Symantec 
migration.



Looking forward to the questions!



Jeremy






___
dev-security-policy mailing list

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

2019-08-28 Thread Josef Schneider via dev-security-policy
Am Dienstag, 27. August 2019 00:48:38 UTC+2 schrieb Matt Palmer:
> On Mon, Aug 26, 2019 at 05:39:14AM -0700, Josef Schneider via 
> dev-security-policy wrote:
> > Sure I can register a company and get an EV certificate for that company. 
> > But can I do this completely anonymous like getting a DV cert?
> 
> Yes.

Not legally probably and this also depends on the jurisdiction. Since an EV 
cert shows the jurisdiction, a user can draw conclusions from that.

> > Nobody is arguing that EV certificates are perfect and everything is good
> > if you use them.  But they do raise the bar for criminals.  And in my
> > opinion, significantly.
> 
> Except criminals don't need them.  Raising the bar doesn't help if you don't
> need to go over the bar.
> 
But removing the bar is also not the correct solution. If you find out that the 
back door to your house is not secured properly, will you remove the front door 
because it doesn't matter anyway or do you strengthen the back door?


> > What I propose is for mozilla to not say "Fuck it, it's not working, just
> > remove it!" but instead try to focus on finding a better UX solution to
> > the problem that end users are not aware if a site that should have an EV
> > certificate is not presenting one.
> 
> Why should Mozilla do all this work?  So far, all the evidence suggests that
> EV certs do not do what their advocates say they do, and have a significant
> cost to browsers (code complexity, administration of EV bits, etc) and
> relying parties (need to learn what the EV UI means, what it does and
> doesn't claim, etc).

Why should Mozilla do work to make the situation worse? The current EV 
validation information in the URL works and is helpful to some users (maybe 
only a small percentage of users, but still...). Why is mozilla interested in 
spending money making the situation worse. If mozilla doesn't care about the 
empowerment of their users, the default would be to not change anything, not 
actively making it worse.

EV certificates do make more assurances about the certificate owner than DV 
certificates. This is a fact. This information can be very useful for someone 
that understands what it means. Probably most users don't understand what it 
means. But why not improve the display of this valuable information instead of 
hiding it?

Certificates cannot magically bring security. Certificates are about identity. 
But the fact that the owner of the website somebank.eu is the owner of the 
domain somebank.eu is not that helpful in determining the credibility. But the 
information that the owner of somebank.eu is a incorporated company from 
Germany officially called "Somebank AG" is more valuable. 
Maybe some people don't care and enter their account data happily at 
s0m1b4nk.xyz, maybe most people do. We don't know and we probably can't know 
how many people stopped and thought if they are actually at the correct website 
because the green bar was missing. But I am certain that it was more than zero. 

What mozilla now is proposing is: EV certificates have no use in any situation 
so basically remove them. I don't think that's true.

I am not a UX designer, but I am sure there are methods to incorporate this 
valuable information from EV certificates in a way that it is helpful to users.

Why not for example always open a small overlay with information when someone 
starts entering data in a password field? Something like "You are entering a 
password at web.page. You visited this page 5 times before, first on August 4th 
2019. We don't know anything about the owner" or for EV "You are entering a 
password at web.page. You visited this page 5 times before, first on August 4th 
2019. This server is run by "WebPage GmbH" from Vienna, Austria [fancy flag 
picture]".

As said, I am not a UX designer (or any graphical type of designer) so probably 
this idea is stupid. But my point is that the information in an EV certificate 
is useful **to the user** and should be presented in a way to empower the user 
and not be hidden.

- Josef
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov

2019-08-28 Thread Ryan Sleevi via dev-security-policy
On Wed, Aug 28, 2019 at 12:36 PM Jeremy Rowley 
wrote:

> I've always thought the reason OV/EV ballots haven't been proposed/passed
> is combination of a lack of interest from the browsers and the fact that
> governance reform seems to get in the way of everything else.  I've for
> proposed tons of things over the years that simply fail because I can't get
> enough interest because they aren't shiny enough to capture attention. I
> don't think CAs would actually oppose a clean up ballot - and Hurst's
> proposal to require the BR OIDs for OV/DV wasn't opposed by all CAs.
>

Not all CAs and no true Scots, but it's true that when Microsoft attempted
to require this via policy, there were significant enough concerns that led
them to withdraw some of these elements.


> A ballot standardizing on abbreviated states (for example) would probably
> pass. I think any ballot requiring a standard format of cert profiles would
> actually pass. And I think they are talking about standardizing a list of
> allowed sources for verifying incorporation on the validation working
> group. The CAB Forum just moves more slowly than it used to. We can speed
> it up by simply proposing more ballots. There's nothing that requires long
> waiting periods.


I mean, I think we're more in agreement than disagreement. Browsers have
higher priorities, generally focused on ensuring their existing members are
compliant and actually following the rules set out by the contracts and
root policy expectations, and that the issues that the CAs have are getting
addressed meaningfully and in a timely fashion. I can assure you, it's a
full time job and then some - between Kathleen handling the additions,
Wayne doing CP/CPS reviews and supporting Mozilla, and myself doing many of
the incident investigations, there's very little time for much else. CAs,
as a collective (although there are of course individual exceptions),
haven't really taken to improving things for relying parties. It may be
that CAs don't understand the challenges RPs face, or it may be that they
don't recognize the innate value in consistency.

I've had conversations with CAs, about allowlists, and I've gotten enough
pushback from enough CAs to say "OK, it's a better use of time to focus on
the things of immediate concern - like SC22 - than to try and fight a
battle on two fronts". We know some members of the CA/Browser Forum were so
vociferously opposed to improved requirements of RAs that the amount of
time it would take to improve things was simply not proportionate to the
value browsers would receive; after all, it'd only apply to OV/EV, and as
we see, if CAs are willing to let those go fallow, so be it.

It's worth noting that GLEIF itself made it clear that they saw many of
these issues and designed both the administrative structure and the
requirements to learn from these mistakes. Conceptually, an LOU recognized
by GLEIF is doing the same thing a CA recognized by a browser is doing for
OV/EV - vetting organizational information. It's conceptually similar to
eIDAS, in that there's multiple legal frameworks incorporating those
results, but very distinct from eIDAS, in that it's independent and
non-profit. Structurally, decisions are not made by the LOUs (aka CAs),
they're made by the LEI ROC (aka Browsers) - those who depend on the
stability and correctness of the system. GLEIF acts as a caretaker, but
itself remains independent from the LOUs and the system itself. You can
read more
https://www.gleif.org/en/about/governance/mou-between-gleif-and-lei-roc# ,
but I highlight it to emphasize that, structurally, the answer for why
hasn't much been done has been that the incentives are misaligned for CAs
to do this, the value to browsers is commensurately low (e.g. why browsers
don't recognize OV and have expressed concerns with EV, among other things).

Anyways, that's my pitch for why
1) Folks should file Moz Policy issues first and foremost, because that's a
direct way you have to raise and highlight concerns
2) Care needs to be taken to "do it right" - this is true of all standards
work, and doesn't come overnight, but it can start by just making sure
there's a clear description of the problem and a clear description of the
considerations made
3) Either Mozilla may bring these issues to the Forum (if they are
priorities for Mozilla), or CAs may want to consider doing so (if it
impacts the value proposition to Relying Parties)

Nothing prevents change, except for the number of hours in a day :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


RE: GlobalSign: SSL Certificates with US country code and invalid State/Prov

2019-08-28 Thread Jeremy Rowley via dev-security-policy
I've always thought the reason OV/EV ballots haven't been proposed/passed is 
combination of a lack of interest from the browsers and the fact that 
governance reform seems to get in the way of everything else.  I've for 
proposed tons of things over the years that simply fail because I can't get 
enough interest because they aren't shiny enough to capture attention. I don't 
think CAs would actually oppose a clean up ballot - and Hurst's proposal to 
require the BR OIDs for OV/DV wasn't opposed by all CAs.

A ballot standardizing on abbreviated states (for example) would probably pass. 
I think any ballot requiring a standard format of cert profiles would actually 
pass. And I think they are talking about standardizing a list of allowed 
sources for verifying incorporation on the validation working group. The CAB 
Forum just moves more slowly than it used to. We can speed it up by simply 
proposing more ballots. There's nothing that requires long waiting periods. 

Heck, if interested parties want to work on ballots with me, I'd be happy to 
propose them at the CAB Forum.  That'd be really fun actually - propose a bunch 
of relying party ballots from the Mozilla community that we put 
forward/sponsor. LMK

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Wednesday, August 28, 2019 9:02 AM
To: Corey Bonnell 
Cc: mozilla-dev-security-policy 
Subject: Re: GlobalSign: SSL Certificates with US country code and invalid 
State/Prov

On Wed, Aug 28, 2019 at 7:13 AM Corey Bonnell via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Anyhow, judging from censys.io, it looks like there are far bigger 
> offenders of this particular quirky rule than Digicert and GlobalSign. 
> I'd love to know why the BRs/EVGs are inconsistent with this 
> requirement for jurisST having to be a full name, but ST can seemingly 
> be either. It looks like the existing language in the BRs for ST 
> stemmed from Ballot 88, but unfortunately there was little discussion 
> on the mailing list that I could find about the rationale for this 
> inconsistency.
>
> Ideally, the requirements would be identical so that Relying Parties 
> can more easily extract identity information from these certificates 
> to aid in trust decisions.
>

There's a long list of things that CAs that advocate for OV/EV information 
could be doing to make it reliable and useful to Relying Parties.

Consider this post, from Ryan Hurst in 2012 -
https://unmitigatedrisk.com/?p=203 - talking about the 'simple' challenges just 
in distinguishing DV vs OV certificates. The proliferation of CA-specific 
policy OIDs has, functionally, made this a non-trivial task.
While the Baseline Requirements provide a series of policy OIDs that CAs may 
assert, the use is not mandatory nor widespread.

With respect to OV/EV information, it's clear that in the absence of an 
allowlist, and more explicit profiles, the functional value to Relying Parties 
is going to be greatly limited. This is not an exclusive criticism of OV/EV 
either; the lack of technical profiles for both CRLs and OCSP represent 
significant challenges.

The problem, as with all things in the Forum, is that the incentive structures 
are misaligned. There is questionable benefit, to a CA, to develop a ballot to 
normatively specify a requirement on the information sources or the formatting 
of certificates. While some have suggested the costs in determining adequate 
information sources (e.g. "does X meet the criteria of the BRs?") might be 
reduced by such a shared list, most of that cost has already been sunk by the 
extant CAs, so it only benefits new upstarts or those entering new 
jurisdictions. With profiles for certificates, it's even more marked - every 
profile represents a chance for the CA to be accused of violating them, and 
represents additional controls all CAs would need to implement. It's naturally 
in their own self-interest to not only not propose such changes, but oppose 
them when proposed, because it's all risk for benefit that they and their 
Subscribers do not realize.

So it's left to browsers to normatively require things, much as it was with the 
Baseline Requirements. And we know the browsers are a busy lot, in part due to 
the influx of issues and the woeful responses and/or remediations.

So what can be done?

If folks joined the CA/Browser Forum as Interested Parties (and thus executed 
the IP agreement), it's a much quicker path towards writing technical changes 
which browsers might then be able to propose as draft ballots to then place 
into the BRs. Alternatively, folks here could open issues with Mozilla Policy, 
wholly ignoring the CA/Browser due to its many issues, proposing changes to 
Mozilla Policy. Mozilla could eventually propose these as ballots or, more 
pragmatically, CAs who have to follow these rules anyways might be inclined to 
formalize them into the BRs, rather than run the risk of 

Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov

2019-08-28 Thread Matthew Hardeman via dev-security-policy
I'd particularly like to see the memes directly within the certificate,
maybe an extension to RFC 6170.

On Wed, Aug 28, 2019 at 6:13 AM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, August 22, 2019 at 11:08:03 PM UTC-4, Jeremy Rowley wrote:
> > It's a trap. I do wish memes showed up here
> >
> > Censys shows something like 130 globalsign certs with abbreviated joi
> info. I think we show 16?
> > 
> > From: dev-security-policy 
> on behalf of Corey Bonnell via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> > Sent: Thursday, August 22, 2019 8:57:42 PM
> > To: Doug Beattie ;
> mozilla-dev-security-pol...@lists.mozilla.org <
> mozilla-dev-security-pol...@lists.mozilla.org>
> > Subject: Re: GlobalSign: SSL Certificates with US country code and
> invalid State/Prov
> >
> > Hi Doug,
> > Thank for you for posting this incident report to the list. I have one
> clarifying question in regard to the correctness criteria for the jurisST
> field when performing the scanning for additional problematic certificates.
> Is GlobalSign allowing state abbreviations in the jurisST field, or only
> full state names?
> > Thanks,
> > Corey
> >
> > 
> > From: dev-security-policy 
> on behalf of Doug Beattie via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> > Sent: Thursday, August 22, 2019 11:35
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: GlobalSign: SSL Certificates with US country code and invalid
> State/Prov
> >
> > Today we opened a bug disclosing misissuance of some certificates that
> have
> > invalid State/Prov values:
> >
> >
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1575880data=02%7C01%7C%7Ceba31d5add5949261f1508d7271662df%7C84df9e7fe9f640afb435%7C1%7C0%7C637020849406465940sdata=sgDFjHsrYMjJMl02%2Bj3BH7Hw%2FUPNR3O8q6r8nr3OgZE%3Dreserved=0
> >
> >
> >
> > On Tuesday August 20th 2019, GlobalSign was notified by a third party
> > through the report abuse email address that two certificates were
> discovered
> > which contained wrong State information, either in the
> stateOrProvinceName
> > field or in the jurisdictionStateOrProvinceName field.
> >
> >
> >
> > The two certificates in question were:
> >
> >
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrt.sh%2F%3Fid%3D1285639832data=02%7C01%7C%7Ceba31d5add5949261f1508d7271662df%7C84df9e7fe9f640afb435%7C1%7C0%7C637020849406465940sdata=jXC4T%2BbvYYNdPJhXUukJT7cGEYgv0Lyg3qFO81S9xPE%3Dreserved=0
> >
> >
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrt.sh%2F%3Fid%3D413247173data=02%7C01%7C%7Ceba31d5add5949261f1508d7271662df%7C84df9e7fe9f640afb435%7C1%7C0%7C637020849406465940sdata=KJ7FfggP5XKliFv%2FL2VLwpRtG8bcg7Eq%2FzFG6qx8ndQ%3Dreserved=0
> >
> >
> >
> > GlobalSign started and concluded the investigation within 24 hours.
> Within
> > this timeframe GlobalSign reached out to the Certificate owners that
> these
> > certificates needed to be replaced because revocation would need to
> happen
> > within 5 days, following the Baseline Requirements. As of the moment of
> > reporting, these certificates have not yet been replaced, and the
> offending
> > certificates have not been revoked. The revocation will happen at the
> latest
> > on the 25th of August.
> >
> >
> >
> > Following this report, GlobalSign initiated an additional internal review
> > for this problem specifically (unexpected values for US states in values
> in
> > the stateOrProvinceName or jurisdictionStateOrProvinceName fields).
> Expected
> > values included the full name of the States, or their official
> abbreviation.
> > We reviewed all certificates, valid on or after the 21st of August, that
> > weren't revoked for other unrelated reasons.
> >
> >
> >
> > To accommodate our customers globally, the stateOrProvinceName field or
> in
> > the jurisdictionStateOrProvinceName are text fields during our ordering
> > process. The unexpected values were not spotted or not properly
> corrected.
> > We have put additional flagging in place to highlight unexpected values
> in
> > both of these fields, and are looking at other remedial actions. None of
> > these certificates were previously flagged for internal audit, which is
> > completely randomized.
> >
> >
> >
> > We will update with a full incident report for this and also disclose all
> > other certificates found based on our research.
> >
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
>
> At the risk of turning this place into Reddit, I agree that a meme feature
> is needed.
>
> Anyhow, judging from censys.io, it looks like there are far bigger
> offenders of this particular quirky rule than 

Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov

2019-08-28 Thread Ryan Sleevi via dev-security-policy
On Wed, Aug 28, 2019 at 7:13 AM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Anyhow, judging from censys.io, it looks like there are far bigger
> offenders of this particular quirky rule than Digicert and GlobalSign. I'd
> love to know why the BRs/EVGs are inconsistent with this requirement for
> jurisST having to be a full name, but ST can seemingly be either. It looks
> like the existing language in the BRs for ST stemmed from Ballot 88, but
> unfortunately there was little discussion on the mailing list that I could
> find about the rationale for this inconsistency.
>
> Ideally, the requirements would be identical so that Relying Parties can
> more easily extract identity information from these certificates to aid in
> trust decisions.
>

There's a long list of things that CAs that advocate for OV/EV information
could be doing to make it reliable and useful to Relying Parties.

Consider this post, from Ryan Hurst in 2012 -
https://unmitigatedrisk.com/?p=203 - talking about the 'simple' challenges
just in distinguishing DV vs OV certificates. The proliferation of
CA-specific policy OIDs has, functionally, made this a non-trivial task.
While the Baseline Requirements provide a series of policy OIDs that CAs
may assert, the use is not mandatory nor widespread.

With respect to OV/EV information, it's clear that in the absence of an
allowlist, and more explicit profiles, the functional value to Relying
Parties is going to be greatly limited. This is not an exclusive criticism
of OV/EV either; the lack of technical profiles for both CRLs and OCSP
represent significant challenges.

The problem, as with all things in the Forum, is that the incentive
structures are misaligned. There is questionable benefit, to a CA, to
develop a ballot to normatively specify a requirement on the information
sources or the formatting of certificates. While some have suggested the
costs in determining adequate information sources (e.g. "does X meet the
criteria of the BRs?") might be reduced by such a shared list, most of that
cost has already been sunk by the extant CAs, so it only benefits new
upstarts or those entering new jurisdictions. With profiles for
certificates, it's even more marked - every profile represents a chance for
the CA to be accused of violating them, and represents additional controls
all CAs would need to implement. It's naturally in their own self-interest
to not only not propose such changes, but oppose them when proposed,
because it's all risk for benefit that they and their Subscribers do not
realize.

So it's left to browsers to normatively require things, much as it was with
the Baseline Requirements. And we know the browsers are a busy lot, in part
due to the influx of issues and the woeful responses and/or remediations.

So what can be done?

If folks joined the CA/Browser Forum as Interested Parties (and thus
executed the IP agreement), it's a much quicker path towards writing
technical changes which browsers might then be able to propose as draft
ballots to then place into the BRs. Alternatively, folks here could open
issues with Mozilla Policy, wholly ignoring the CA/Browser due to its many
issues, proposing changes to Mozilla Policy. Mozilla could eventually
propose these as ballots or, more pragmatically, CAs who have to follow
these rules anyways might be inclined to formalize them into the BRs,
rather than run the risk of future Root Store divergence.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy