Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov
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
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
RE: GlobalSign: SSL Certificates with US country code and invalid State/Prov
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: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar
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
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: Intent to Ship: Move Extended Validation Information out of the URL bar
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
Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar
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
Symantec migration update
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: Intent to Ship: Move Extended Validation Information out of the URL bar
(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
