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

2019-08-29 Thread Ian Carroll via dev-security-policy
On Thursday, August 29, 2019 at 11:49:16 AM UTC-7, Kirk Hall wrote:
> On Thursday, August 29, 2019 at 11:01:27 AM UTC-7, Jonathan Rudenberg wrote:
> > On Thu, Aug 29, 2019, at 13:39, Kirk Hall via dev-security-policy wrote:
> > > This string is about Mozilla’s announced plan to remove the EV UI from 
> > > Firefox in October.  Over time, this will tend to eliminate confirmed 
> > > identity information about websites from the security ecosystem, as EV 
> > > website owners may decide it’s not worth using a n EV certificate if 
> > > browsers decide to hide the data from users.  As noted in my last 
> > > message, this will be a tragedy for users, as browser phishing filters 
> > > and other anti-phishing services currently rely on website EV data in 
> > > their algorithms for protecting users.
> > 
> > Can you provide more detail (preferably with citations) about how browser 
> > phishing filters, and specifically Google Safe Browsing (used by Firefox), 
> > rely on EV data?
> > 
> > It's not clear to me how this could possibly be useful in detecting 
> > phishing given the data that you've previously published[1] showing that an 
> > extremely small number sites with EV certificates were detected as phishing.
> > 
> > Jonathan
> > 
> > [1] 
> > https://casecurity.org/wp-content/uploads/2018/06/Summary-Report-Incidence-of-Phishing-04-16-2018.pdf
> 
> 
> Sure, I’m happy to explain, using Bank of America as an example.
> 
> The EV data securing the domain www.bankofamerica.com is as follows:
> 
> CN = www.bankofamerica.com
> SERIALNUMBER = 2927442
> OU = eComm Network Infrastructure
> 2.5.4.15 = Private Organization
> O = Bank of America Corporation
> 1.3.6.1.4.1.311.60.2.1.2 = Delaware
> 1.3.6.1.4.1.311.60.2.1.3 = US
> L = Chicago
> S = Illinois
> C = US
> 
> This data uniquely and unambiguously identifies the owner of the domain as 
> “Bank of America Corporation”, a Delaware, US corporation with the Delaware 
> registry serial number 2927442 – no other corporation in the world can get 
> that place of incorporation and serial number.  There’s no “Stripe” problem 
> here – even if a phisher or academic could create a new corporation in 
> another state (e.g., Kentucky) in the name of “Bank of America Corporation” 
> and then get an EV cert, it would show state of incorporation as Kentucky and 
> show a different serial number –it’s easy for phishing algorithms to notice 
> the difference and know these are not the same organization who own the 
> websites.
> 
> Phishing services tend to capture and retain this kind of website identity 
> information and use it in their algorithms to create a “reputation” for 
> specific domains and for specific organizations named in EV certificates that 
> they re-use later.  
> 
> Now, suppose a new website appears, “bankofamerica-alerts.com” and suppose 
> it’s only secured by a DV certificate.  In that case, this is the only 
> certificate information available to the anti-phishing service:
> 
> CN = bankofamerica-alerts.com
> 
> That could be a site owned by the real Bank of America, or owned by a phisher 
> – who knows, as there is no identity information available about the site.  
> So a phishing service would be very cautious.
> 
> Now suppose the new website “bankofamerica-alerts.com” is instead secured by 
> an EV certificate.  The certificate identity information for that site would 
> be as follows:
> 
> CN = bankofamerica-alerts.com
> SERIALNUMBER = 2927442
> OU = eComm Network Infrastructure
> 2.5.4.15 = Private Organization
> O = Bank of America Corporation
> 1.3.6.1.4.1.311.60.2.1.2 = Delaware
> 1.3.6.1.4.1.311.60.2.1.3 = US
> L = Chicago
> S = Illinois
> C = US
> 
> Only the CN field would be different from the EV certificate securing 
> www.bankofamerica.com.  Anti-phishing services will notice this similarity, 
> and will likely rely on the “reputation” already established for the site 
> www.bankofamerica.com (and for the organization “Bank  of America 
> Corporation, Delaware serial number 2927442”) and so feel confident based on 
> that good reputation that the new EV website “bankofamerica-alerts.com” is 
> unlikely to be a phishing site.  This helps speed up decisions on which sites 
> are likely safe for users and which should be flagged for phishing.
> 
> Anti-phishing algorithms like lots of data, particularly strongly confirmed 
> data like EV data.  Website owners who use EV certificates today do so 
> because they believe EV certs protect their customers and their brands, 
> chiefly through the EV UI.  If the browsers eliminate the EV UI and hide 
> identity data from users, over time website owners may stop using EV 
> certificates, and the EV identity data will disappear from the security 
> ecosystem – a real loss.

EV code signing certificates do not display any trusted UI -- their chief 
purpose is to inform Smartscreen and other relying parties of identity 
information, similar to the anti-phishing services you mention. UAC/etc will 

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

2019-08-15 Thread Ian Carroll via dev-security-policy
On Thursday, August 15, 2019 at 10:59:32 AM UTC-7, Doug Beattie wrote:
> So far I see is a number of contrived test cases picking apart small 
> components of EV, and no real data to back it up.  Mostly academic or 
> irrelevant research, imho.  Here are a couple of links posted in this thread:
> 
>  
> 
> https://www.typewritten.net/writer/ev-phishing/: This post is intended for a 
> technical audience interested in how an EV SSL certificate can be used as an 
> effective phishing device  concern>
> 
>  
> 
> https://stripe.ian.sh/: EV certificates with colliding entity names can be 
> generated, but to date, I don’t know of any real attacks, just this academic 
> exercise. And how much did it cost and how long did it Ian to get 
> certificates to perform this experiment?  Way more time and money that a 
> phisher would invest. 

To be clear, I obtained this certificate during lunch while I was in high 
school, but I'm sure you read the post explaining the cost/time already. I hope 
we can agree our bar for security is higher than "a kid who got bored".

> 
>  
> 
> https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-to-page-info.md
>  references a number of studies. But none of them indicated that EV was bad 
> or misleading or was a detriment to security, and a number of the references 
> weren’t even related to EV (including irrelevant research links to bolster 
> their claims to the uninformed)
> 
>  
> 
> I haven’t been counting the number of pro and cons emails, but there are a 
> significant number of organizations questioning the changes by Google and 
> Mozilla.  Mozilla and Google should reconsider their proposed changes.
> 
>  
> 
> Yes, I work for a CA that issues EV certificates, but if there was no value 
> in them, then our customers would certainly not be paying extra for them.  
> Shouldn’t the large enterprises that see a value in identity (as does 
> GlobalSign) drive the need for ending EV certificates?  With Google and 
> Mozilla being prominent Lets Encrypt sponsors we know their intent is to 
> drive business to them vs. any of the commercially respectable CAs.  It’s 
> actually counter productive to security to sponsor a CA that issues so many 
> certificates to phishing and malware sites without any consequences.  Is this 
> to increase the value of their malware site detection services?  Maybe..

It is not worth it to respond to this bizarre theory. Sponsors of Let's Encrypt 
obviously have nothing to gain from more people using it; it's not like they 
pay dividends! You can slander them all you want, but it's not going to make 
anyone respect your opinion in the future.

> 
> * https://www.usenix.org/system/files/soups2019-drury.pdf
> * 
> https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf 
> 
>  
> 
> Baffled…
> 
>  
> 
>  
> 
>  
> 
> From: Tom Ritter  
> Sent: Thursday, August 15, 2019 1:13 PM
> To: Doug Beattie 
> Cc: Peter Gutmann ; MozPol 
> 
> Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out of 
> the URL bar
> 
>  
> 
>  
> 
> On Thu, Aug 15, 2019, 7:46 AM Doug Beattie via dev-security-policy 
>   > wrote:
> 
> Peter,
> 
> Do you have any empirical data to backup the claims that there is no benefit
> from EV certificates?  From the reports I've seen, the percentage of
> phishing and malware sites that use EV is drastically lower than DV (which
> are used to protect the cesspool of websites).
> 
>  
> 
> I don't doubt that at all. However see the first email in this thread citing 
> research showing that users don't notice the difference.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Request to Include Hongkong Post Root CA 3

2019-01-14 Thread Ian Carroll via dev-security-policy
I do not usually comment on new CA applications, so take this with whatever
grain of salt you'd like, but from looking at [3] I think it should be a
very negative mark against a CA to have to OneCRL one of their
intermediates. If the CA is not committed to closely following web PKI
standards, it's not clear to me that they should be allowed to be trusted
in the web PKI. Combined with the lack of incident reports, I'd hope the
impact this organization could have in the future is considered.

On Mon, Jan 14, 2019 at 4:19 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This request is for inclusion of the Government of Hong Kong, Hongkong
> Post, Certizen Hongkong Post Root CA 3 trust anchor as documented in the
> following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464306
>
> * BR Self Assessment is here:
> https://bug1464306.bmoattachments.org/attachment.cgi?id=8980480
>
> * Summary of Information Gathered and Verified:
> https://bug1464306.bmoattachments.org/attachment.cgi?id=9004396
>
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8980482
>
> * CP/CPS:
> CP: there is no CP
> CPS: https://www.ecert.gov.hk/ev/e-Cert%20(Server)%20CPS-Eng-1.7.4.pdf
>
> * This request is to include the root with the websites trust bit enabled
> and EV treatment.
>
> * EV Policy OID: 2.23.140.1.1
>
> * Test Websites
> https://valid-ev.ecert.gov.hk/
> https://expired-ev.hongkongpost.gov.hk
> https://revoked-ev.hongkongpost.gov.hk
>
> * CRL URLs:
> http://crl1.hongkongpost.gov.hk/crl/RootCA3ARL.crl
> http://crl1.hongkongpost.gov.hk/crl/eCertESCA3-17CRL1.crl
>
> * OCSP URL:
> http://ocsp1.hongkongpost.gov.hk
>
> * Audit: Annual audits are performed by PricewaterhouseCoopers Hong Kong
> according to the WebTrust for CA, BR, and EV audit criteria.
> WebTrust: https://www.cpacanada.ca/webtrustseal?sealid=2405
> BR: https://www.cpacanada.ca/webtrustseal?sealid=2406
> EV:
>
> https://www.ecert.gov.hk/ev/Webtrust%20EV%20SSL%20Report%2020181219_FINAL%20(with%20Management%20Assertion%20Letter).pdf
>
> I’ve reviewed the CPS, BR Self Assessment, and related information for
> inclusion of the Certizen Hongkong Post Root CA 3 that is being tracked in
> this bug and have the following comments:
>
> ==Good==
> This root is relatively new, has continuous BR audit coverage, and appears
> to have only signed certificates for the required test websites.
>
> ==Meh==
> * The first EV audit was a point-in-time dated March 31, 2018 [1]. Given
> that EV certificates for the test sites were issued in May 2018, one can
> argue that EVGL section 17.4 required a period-of-time audit to have been
> completed in October rather than December as was the case. However, it has
> been common for CAs to argue that certificates for test websites don’t
> count and I have not yet published clear guidance on this issue.
> * There is no document referenced as a CP. Hongkong Post says that the
> document is a combined CP/CPS.
> * In 2016, it was discovered that Hongkong Post was issuing SHA-1
> certificates with non-random serial numbers that could be used for TLS in
> Firefox [2] [3]. The problem was resolved by adding the problematic
> intermediate certificate to OneCRL.
> * The CPS permits external RAs, but according to Appendix E, there are none
> at present. I would prefer that the CPS clearly state that domain
> validation functions are never delegated.
> * Hongkong Post has attached unpublished versions 2 and 3 of their CPS to
> the bug that differ from the published versions 2 and 3 in their
> repository. The latest version “4” is marked as a “Pre-production CPS”.
> They state that “…we cannot issue EV certificate to customers until
> Mozilla, or at least some other root certificate programs, have granted EV
> treatment to our root certificate. So, we do not yet publish the CPS in
> order to avoid confusion to customers.”
>
> ==Bad==
> * Fairly recent misissuance under the currently included Hong Kong Post
> Root CA 1: O and OU fields too long [4]. These certificates have all been
> revoked, but no incident report was ever filed.
> * CPS section 3.4 indicates that certificates may be suspended. This would
> violate BR 4.9.13. This has been corrected in the “Pre-production” CPS but
> not the current CPS for their existing root [5].
> * CPS section 4.9.1 does not appear to include all the revocation reasons
> required by BR 4.9.1.1. This has been corrected in the “Pre-production” CPS
> but not the current CPS for their existing root [5].
>
> This begins the 3-week comment period for this request [6].
>
> I will greatly appreciate your thoughtful and constructive feedback on the
> acceptance of this root into the Mozilla CA program.
>
> - Wayne
>
> [1] https://bug1464306.bmoattachments.org/attachment.cgi?id=8980478
> [2]
>
> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/Ng99HcqhZtI/bkcimGlECAAJ
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1267332
> [4]

Re: Concerns with Dun & Bradstreet as a QIIS

2018-10-02 Thread Ian Carroll via dev-security-policy
On Tuesday, October 2, 2018 at 7:02:32 AM UTC-7, Dimitris Zacharopoulos wrote:
> On 1/10/2018 8:15 μμ, Ryan Sleevi via dev-security-policy wrote:
> > On Mon, Oct 1, 2018 at 9:21 AM Dimitris Zacharopoulos 
> > wrote:
> 
> > [...]
> >
> >
> >> I am certainly not suggesting that CAs should put inaccurate and
> >> misleading information in certificates :-) I merely said that if the
> >> Subscriber introduces misleading or inaccurate information in certificates
> >> via a reliable information source, then there will probably be a trail
> >> leading back to the Subscriber. This fact, combined with the lack of clear
> >> damage that this can cause to Relying Parties, makes me wonder why doesn't
> >> the Subscriber, that wants to mislead Relying Parties, just use a DV
> >> Certificate where this probably doesn't leave so much evidence tracing back
> >> to the Subscriber?
> >>
> > "The lack of clear damage" - I'm not sure how better to communicate, since
> > we're discussing fundamental damage to the value that OV and EV are said to
> > provide. The only way we can say "lack of clear damage" is to say that OV
> > and EV are worthless - otherwise, it's incredibly damaging.
> 
> I'm actually still waiting for Ian to elaborate if the "attack" was just 
> the insertion of an intentionally wrong address in an EV Certificate or 
> if he was attempting something else. Although his attempt failed (no 
> Certificate was issued with that wrong Street Address), I consider the 
> discussion that followed very useful (at least to me).

Yes, that was the attack. As Ryan has said, if the organizational data in the 
certificate is not reliable, then EV brings no value-add. Of note, given the 
location of this forum, is that Firefox shows locality information in its 
expanded EV indicator, so this false data has a clear impact to the (likely 
very) small subset of users who click on it.

I can appreciate that HARICA validates the data sources it uses for certificate 
issuance, but this is clearly not happening with US-based CAs, as the usage of 
D should be plainly demonstrating. 

It also seems like a stretch to me that CAs should be relying on third-parties 
to self-attest, in contracts or otherwise, that this validation occurs. As one 
would expect, D has a strong incentive to assert that they perform whatever 
validation the CA expects, regardless of their actual procedure. It makes no 
sense that QIISes are not audited along with the CA for their own 
record-keeping.

The relationship between CAs and D is a bit weird, from what I've seen. A 
Comodo validation agent actually emailed me a screenshot of the UI they were 
using to search D, and it was a public site anyone could use to make an 
account. It's unclear to me if there is any sort of payment or actual 
contractual obligations between CAs and D
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Concerns with Dun & Bradstreet as a QIIS

2018-09-28 Thread Ian Carroll via dev-security-policy
hat the rest of the information is also unreliable. 
> For example, an Information Source might describe in their documentation 
> practices how they verify each piece of information, for example:
> 
>   * the Jurisdicion of Incorporation (they check official government
> records),
>   * registry number (they check official government records),
>   * the name of legal representative (they check official government
> records),
>   * the official name of the legal entity (they check official
> government records),
>   * street address (they check the address of a utility bill issued
> under the name of the legal entity),
>   * telephone numbers (self-reported),
>   * color of the building (self-reported),
> 
> and the CA, during evaluation, might decide to accept only the first 5 
> as Reliable/Qualified Information as they have higher level of 
> assurance. That would be the right thing to do. For the rest of the 
> information, the CA should probably request additional validation 
> information from the Applicant.
> 
> Sorry for the long email, quoting requirements always does that :)
> 
> 
> Dimitris.
> 
> On 27/9/2018 2:52 πμ, Ian Carroll via dev-security-policy wrote:
> > Hi,
> >
> > In April and May of this year, I attempted to change the address listed in 
> > Dun & Bradstreet of my (Kentucky-incorporated) company "Stripe, Inc" to an 
> > address in Toledo, Ohio that did not exist (185 Berry Street Toledo Ohio). 
> > I was wondering the extent of validation Dun & Bradstreet would do on the 
> > data.
> >
> > To my surprise, they accepted my change request a couple days later. This 
> > is concerning, of course, because D is a QIIS backing most EV certificate 
> > requests in the United States.
> >
> > After this worked, I realized this was probably worth exploring more, so I 
> > took my "Cloudflare, Inc" company (also incorporated in Kentucky) and 
> > requested that Dun & Bradstreet change its address to "102 Townsend St San 
> > Francisco CA". You might notice that this is the same address as the real 
> > Cloudflare, but with the street number incremented by one.
> >
> > D accepted that change request as well. This meant I controlled a DUNS 
> > number that would resolve to a very similar address to CF, with my phone 
> > number on it.
> >
> > I ordered two EV certificates from Comodo (order #s 136665865 and 
> > 141269115) with these fake DUNS numbers. I successfully completed the 
> > validation and callback process for the Cloudflare order, and Comodo was 
> > about to issue the certificate, but both of my orders were silently deleted 
> > before they were about to be issued.
> >
> > Comodo would not give me any information about why they (silently) rejected 
> > my orders, but Dun & Bradstreet banned my account shortly after, so it is 
> > safe to say they reported me after they realized something went wrong.
> >
> > I think this is a strong indictment of D as a QIIS. The definition of a 
> > QIIS, in my opinion, is incredibly lax, but "which is generally recognized 
> > as a dependable source of such information" is hard to meet here.
> >
> > I am also, frankly, annoyed that Comodo seems to have silently discovered 
> > that D was unreliable and then ignored it without reporting it further. I 
> > myself have been meaning to send this for a while, given I did this in May, 
> > but various things have made it difficult for me to find the time.
> >
> > Let me know if I can provide any further information.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Concerns with Dun & Bradstreet as a QIIS

2018-09-27 Thread Ian Carroll via dev-security-policy
On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi wrote:
> Thanks for raising this, Ian.
> 
> The question and concern about QIIS is extremely reasonable. As discussed
> in past CA/Browser Forum activities, some CAs have extended the definition
> to treat Google Maps as a QIIS (it is not), as well as third-party WHOIS
> services (they’re not; that’s using a DTP).
> 
> In the discussions, I proposed a comprehensive set of reforms that would
> wholly remedy this issue. Given that the objective of OV and EV
> certificates is nominally to establish a legal identity, and the legal
> identity is derived from State power of recognition, I proposed that only
> QGIS be recognized for such information. This wholly resolves differences
> in interpretation on suitable QIIS.
> 
> However, to ensure there do not also emerge conflicting understandings of
> appropriate QGIS - and in particular, since the BRs and EVGs recognize a
> variety of QGIS’s with variable levels of assurance relative to the
> information included - I further suggested that the determination of a QGIS
> for a jurisdictional boundary should be maintained as a normative whitelist
> that can be interoperably used and assessed against. If a given
> jurisdiction is not included within that whitelist, or the QGIS is not on
> it, it cannot be used. Additions to that whitelist can be maintained by the
> Forum, based on an evaluation of the suitability of that QGIS for purpose,
> and a consensus for adoption.
> 
> This would significantly reduce the risk, while also further reducing
> ambiguities that have arisen from some CAs attempting to argue that
> non-employees of the CA or QGIS, but which act as intermediaries on behalf
> of the CA to the QGIS, are not functionally and formally DTPs and this
> subject to the assessment requirements of DTPs. This ambiguity is being
> exploited in ways that can allow a CA to nominally say it checked a QGIS,
> but is relying on the word of a third-party, and with no assurance of the
> system security of that third party.
> 
> Do you think such a proposal would wholly address your concern?

I think I'll always agree with removing intermediaries from the validation 
process. Outside of practical concerns, a whitelist of QGIS entities sounds 
like a good idea.

I would wonder what the replacement for D is in the United States. You can 
normally get an address for a company from a QGIS but not (from the states I've 
seen) a phone number for callback verification.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Concerns with Dun & Bradstreet as a QIIS

2018-09-26 Thread Ian Carroll via dev-security-policy
Hi,

In April and May of this year, I attempted to change the address listed in Dun 
& Bradstreet of my (Kentucky-incorporated) company "Stripe, Inc" to an address 
in Toledo, Ohio that did not exist (185 Berry Street Toledo Ohio). I was 
wondering the extent of validation Dun & Bradstreet would do on the data.

To my surprise, they accepted my change request a couple days later. This is 
concerning, of course, because D is a QIIS backing most EV certificate 
requests in the United States. 

After this worked, I realized this was probably worth exploring more, so I took 
my "Cloudflare, Inc" company (also incorporated in Kentucky) and requested that 
Dun & Bradstreet change its address to "102 Townsend St San Francisco CA". You 
might notice that this is the same address as the real Cloudflare, but with the 
street number incremented by one.

D accepted that change request as well. This meant I controlled a DUNS number 
that would resolve to a very similar address to CF, with my phone number on it.

I ordered two EV certificates from Comodo (order #s 136665865 and 141269115) 
with these fake DUNS numbers. I successfully completed the validation and 
callback process for the Cloudflare order, and Comodo was about to issue the 
certificate, but both of my orders were silently deleted before they were about 
to be issued.

Comodo would not give me any information about why they (silently) rejected my 
orders, but Dun & Bradstreet banned my account shortly after, so it is safe to 
say they reported me after they realized something went wrong.

I think this is a strong indictment of D as a QIIS. The definition of a QIIS, 
in my opinion, is incredibly lax, but "which is generally recognized as a 
dependable source of such information" is hard to meet here.

I am also, frankly, annoyed that Comodo seems to have silently discovered that 
D was unreliable and then ignored it without reporting it further. I myself 
have been meaning to send this for a while, given I did this in May, but 
various things have made it difficult for me to find the time.

Let me know if I can provide any further information.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

2018-04-11 Thread Ian Carroll via dev-security-policy
> an EV certificate issued and fairly promptly revoked by Comodo.


Just to clarify, Comodo revoked it at least four months after it was issued 
(https://crt.sh/?id=273634647). It was not "promptly" revoked.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Trustico code injection

2018-03-02 Thread Ian Carroll via dev-security-policy
(re-sending to list)

> We also asked Trustico to cease offering any tools to generate and/or
retain customer private keys.

Does Comodo intend to standardize a policy against this? GoGetSSL has a
tool like this in their customer panel and I’m sure there are more.

On Fri, Mar 2, 2018 at 12:29 PM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We also asked Trustico to cease offering any tools to generate and/or
> retain customer private keys.  They have complied with this request and
> have confirmed that they do not intend to offer any such tools again in
> the future.
>
> Trustico have also confirmed to us that they were not, and are not, in
> possession of the private keys that correspond to any of the
> certificates that they have requested for their customers through Comodo
> CA.
>
> On 02/03/18 15:25, Rich Smith via dev-security-policy wrote:
> > Comodo CA has investigated the reports posted to this list relating to
> the
> > suspected compromise of the private key corresponding to
> > https://crt.sh/?id=206535041.  Trustico have assured us that the
> private key
> > could not have been compromised.  However, since it will be hard to
> convince
> > everyone that this is the case, Trustico have agreed to obtain a
> replacement
> > certificate with a new keypair.  Once that new certificate has been
> > installed, Comodo CA will revoke https://crt.sh/?id=206535041.
> >
> > Regards,
> > Rich Smith
> > Sr. Compliance Manager
> > Comodo CA
> --
> Rob Stradling
> Senior Research & Development Scientist
> ComodoCA.com
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: On the value of EV

2017-12-18 Thread Ian Carroll via dev-security-policy
On Monday, December 18, 2017 at 4:54:24 PM UTC-5, Andrew wrote:
> On Monday, December 18, 2017 at 3:09:31 PM UTC-6, Wayne Thayer wrote:
> > Thank you Ryan for raising this question, and to everyone who has been
> > contributing in a constructive manner to the discussion. A number of
> > excellent points have been raised on the effectiveness of EV in general and
> > on the practicality of solving the problems that exist with EV.
> > 
> > While we have concerns about the value of EV as well as the potential for
> > EV to actually harm users, Mozilla currently has no definite plans to
> > remove the EV UI from Firefox. At the very least, we want to see
> > Certificate Transparency required for all certificates before making any
> > change that is likely to reduce the use of EV certificates.
> > 
> > Is Google planning to remove the EV UI from desktop Chrome? If so, how does
> > that relate to the plan to mark HTTP sites as ‘Not secure’ [1]? Does this
> > imply the complete removal of HTTPS UI?
> > 
> > While we agree that improvements to EV validation won’t remove many of the
> > underlying issues that have been raised here, we hope that CAs will move
> > quickly to make the EV Subject information displayed in the address bar
> > more reliable and less confusing.
> > 
> > - Wayne
> > 
> > [1]
> > https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
> 
> So, given that Mozilla has no immediate plans to remove the EV UI from 
> Firefox, perhaps the UI should be adjusted to include the state the Subject 
> is registered in on the EV badge. No reason for that text to be any more 
> misleading than necessary. (I assume this is something we can pretty much all 
> agree on, yes?)

I really doubt this would help anyone. As has been mentioned, the state of 
incorporation for larger companies is infrequently connected to the actual 
company's location, and the amount of users who would benefit from seeing the 
state seems quite minimal. And this would expand the EV indicator's screen 
space quite a bit, as there is no shorthand used for the state of incorporation.

I do wonder how many users actually make the connection that the country code 
next to the company name is in fact a country code.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy