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

[Peter Gutmann via dev-security-policy]

Daniel Marschall via dev-security-policy 
 writes:

>I share the opinion with Jakob, except with the CVE. Please remove this
>change. It is unnecessary and kills the EV market.

And that was my motivation for the previous question: We know from a decade of
data that EV certs haven't made any difference to security.  The only thing
they've affected is CA's bottom line, since they can now go back to charging
1990s prices for EV certs rather than $9.95 for non-EV certs.  Removing the UI
bling for the more expensive certs makes sense from a security point of view,
but not from a business point of view: "it kills the [very lucrative] EV
market".

It'd be interesting to hear what CAs think of this.  Will the next step be EEV
certs and a restart of the whole cycle, as was predicted when EV certs first
came out?

Peter.
___
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

[Daniel Marschall via dev-security-policy]

I share the opinion with Jakob, except with the CVE. Please remove this change. 
It is unnecessary and kills the EV market.
But if you insist on keeping that UI change, maybe you can at least give the 
lock symbol a different color if it is an EV cert?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Request to Include 4 Microsoft Root CAs

[Wayne Thayer via dev-security-policy]

This request is for inclusion of the Microsoft RSA Root Certificate
Authority 2017, Microsoft ECC Root Certificate Authority 2017, Microsoft EV
RSA Root Certificate Authority 2017, and Microsoft EV ECC Root Certificate
Authority 2017 trust anchors as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448093

* BR Self Assessment is
https://bugzilla.mozilla.org/attachment.cgi?id=8989260

* Summary of Information Gathered and Verified:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0275

* Root Certificate Download URL:
https://www.microsoft.com/pkiops/docs/repository.htm

* CP/CPS:
** CP:
https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CP_v3.1.2.pdf
** CPS:
https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.1.3.pdf

* This request is to include the roots with the websites trust bit enabled,
and with EV treatment.

* Test Websites
** Valid: https://actrsaevroot2017.pki.microsoft.com/,
https://actrsaroot2017.pki.microsoft.com/,
https://acteccevroot2017.pki.microsoft.com/,
https://acteccroot2017.pki.microsoft.com/
** Expired: https://exprsaevroot2017.pki.microsoft.com/,
https://exprsaroot2017.pki.microsoft.com/,
https://expeccevroot2017.pki.microsoft.com/,
https://expeccroot2017.pki.microsoft.com/
** Revoked: https://rvkrsaevroot2017.pki.microsoft.com/,
https://rvkrsaroot2017.pki.microsoft.com/,
https://rvkeccevroot2017.pki.microsoft.com/,
https://rvkeccroot2017.pki.microsoft.com/

* CRL URLs:
** ECC:
http://www.microsoft.com/pkiops/crl/Microsoft%20ECC%20Root%20Certificate%20Authority%202017.crl
** RSA:
http://www.microsoft.com/pkiops/crl/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crl
** EV ECC:
http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20ECC%20Root%20Certificate%20Authority%202017.crl
** EV RSA:
http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20RSA%20Root%20Certificate%20Authority%202017.crl

* OCSP URL:http://ocsp.msocsp.com

* Audit: Annual audits are performed by BDO according to the WebTrust for
CA, BR, and EV audit criteria.
** WebTrust for CA: https://bugzilla.mozilla.org/attachment.cgi?id=9083810
** BR: https://bugzilla.mozilla.org/attachment.cgi?id=9083812
** EV: https://bugzilla.mozilla.org/attachment.cgi?id=9083813

I’ve reviewed the CP, CPS, BR Self Assessment, and related information for
inclusion of the Microsoft roots that are being tracked in this bug and
have the following comments:

==Good==
* A root key generation ceremony audit report has been provided [1].

==Meh==
* CPS section 3.2.4 stated that OU is not verified, however, BR section
7.1.4.2.2(i) does place requirements on this field, and the CPS made it
unclear if these requirements are met. This was clarified in the latest
version of the CPS.
* CPS section 3.2.5 stated that Microsoft PKI Services shall verify
authority for all certificate requests, and that for Domain Validated
requests, this is done using one of the methods described in the BRs.
Section 3.2.5 of the BRs only describes validation of authority for OV
certificates using a reliable method of communication. This was clarified
in the latest version of the CPS.
* CPS section 6.1.5 indicated that P-512 keys may be used, which would
violate Mozilla policy. This was corrected in the latest version of the CPS.
* The content-type header in CRL responses is not set to
'application/pkix-crl' but to 'application/octet-stream' (RFC 5280, section
4.2.1.13). Microsoft explanation: the reason for the content-type being set
to octet-stream is that we use a content upload service at Microsoft that
hosts different types of content. All of the content in the service is
hosted in Azure’s BLOB storage and the content type by default is octet
stream. This has not been an issue because the browsers will resolve the
file type based on the extension in the file name. It should also be noted
that the RFC 5280 shows SHOULD rather than MUST.

==Bad==
* It had been more than a year since the CP was updated when I reviewed
this request. CPS and BR section 2 require annual updates. The CP was
updated on 5-August.
* CP/CPS section 1.5.2 did not meet the BR 4.9.3 requirement to provide
clear problem reporting instructions. This was corrected in the latest
versions of the CP and CPS.
* A number of unrevoked certificates chaining to the Microsoft RSA Root
Certificate Authority 2017 have recently been issued with BR violations [2]

This begins the 3-week comment period for this request [3].

I will greatly appreciate your thoughtful and constructive feedback on the
acceptance of these roots into the Mozilla CA program.

- Wayne

[1] https://bug1448093.bmoattachments.org/attachment.cgi?id=8986854
[2]
https://crt.sh/?caid=109424=cablint,zlint,x509lint=2019-05-01
[3] https://wiki.mozilla.org/CA/Application_Process
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: Extending Audit Letter Validation to Intermediate Cert records in CCADB

[Kathleen Wilson via dev-security-policy]

On 8/8/19 9:03 AM, Ryan Sleevi wrote:

On Wed, Aug 7, 2019 at 6:28 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


I have been working towards extending Audit Letter Validation (ALV) to
intermediate certificate records in the CCADB. This is involving some
changes.

I will appreciate input on how to make that more clear.




Ryan, thank you for your input.

All, The following changes have been made to the CCADB. Your input is 
still welcome.


1) Changed the help text on intermediate cert pages for ‘Subordinate CA 
Owner' to:
"Enter Subordinate CA’s name as it appears in the provided audit 
statements. Leave blank if BOTH control of the private key AND 
domain/IP/email validation activities are performed by the organization 
listed in the audit statement of the parent certificate."


Notes:
Help text can be up to 255 characters.
ALV only accepts one CA Name (or in this case Subordinate CA Name) to 
look for in the provided audit statements



2) Added item/section/instructions to CA Task List on Homepage:
Item:
"Intermediate Certs missing Subordinate CA Owner or Auditor Info: 10"

Corresponding section if non-zero:
"Provide missing Subordinate CA Owner or Auditor Info for these 
Intermediate Certs"


Instructions:
When an intermediate certificate record in the CCADB corresponds to a 
certificate which has an audit for the operational and issuance 
activities that names an organization different than the organization 
named in the audit statement of the parent record in CCADB, then fill in 
the 'Subordinate CA Owner' field to indicate the name of the 
organization as it appears in the intermediate certificate's operational 
audit. Also fill in the Auditor name as it appears in the audit statements.


Note: This new Task List item currently filters out intermediate certs 
that are revoked, expired, technically-constrained, or don't chain up to 
a root in Mozilla's program.



3) Added ‘Subordinate CA Owner’ column to the public facing reports 
IntermediateCertsSeparateAudits and IntermediateCertsSeparateAuditsCSV
and changed the heading of the existing 'CA Owner' column to 'Parent CA 
Owner'.

https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAudits
https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAuditsCSV

CAs, I will greatly appreciate it if you will use the new Task List item 
on your homepage in the CCADB to provide 'Subordinate CA Owner' and 
'Auditor' for each intermediate certificate that has their own audit 
statements.


Thanks,
Kathleen


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

Re: Use of Certificate/Public Key Pinning

[Matthew Hardeman via dev-security-policy]

I feel that there's a great deal of consultancy and assistance that CAs and
PKI professionals could bring to their more sophisticated customers with
scenarios such as these where public key pinning an a field-deployed
application may present problems for certificates being revoked.

A best practices document explaining to the application developers and
server-side teams that:

1.  An app which calls a server-side API under your control should _always_
do so on a TLS endpoint at a different hostname & SNI label than any
browser-facing websites.
2.  Following step 1's guidance means that you can control the lifecycle of
the certificate for the services accessed by your own application(s)
separate from WebPKI facing certificates meant to facilitate a TLS
authenticated session to a modern browser.
3.  It also means that the endpoints serving the application CAN but don't
have to be from a publicly trusted PKI.  For compatibility reasons, they
generally should be, if there are any external consumers of the API, but
ultimately if their own application wishes to PIN, they should pre-create
several certificates with distinct keys and write their app to override the
platform trust decisioning and pin on the set of keys that their API
endpoint certificates will have, ignoring revocation and requiring that the
presented leaf certificate be a signature over one of the set of pinned
public keys.

This is essentially free in virtually all deployment models today.

Oversubscribing TLS endpoints (for our purposes let's say a DNS based
hostname and TLS SNI label define a TLS endpoint) for different target
audiences, especially when those audiences are modern browsers in
combination with anything else, is one of the most significant causes of
compatibility issues and legacy cruft which have historically hindered the
agility of the WebPKI.

On Tue, Aug 13, 2019 at 10:12 AM Nuno Ponte via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Dear m.d.s.p.,
>
> I would like to bring into discussion the use of certificate/public key
> pinning and the impacts on the 5-days period for certificate revocation
> according to BR §4.9.1.1.
>
> Recently, we (Multicert) had to rollout a general certificate replacement
> due to the serial number entropy issue. Some of the most troubled cases to
> replace the certificates were customers doing certificate pinning on mobile
> apps. Changing the certificate in these cases required configuration
> changes in the code base, rebuild app, QA testing, submission to App
> stores, call for expedited review of each App store, wait for review to be
> completed and only then the new app version is made available for
> installation by end users (which is turn are required to update the app the
> soonest).
>
> Meeting the 5-days deadline with this sort of process is “challenging”, at
> best.
>
> A first approach is to move from certificate pinning to public key pinning
> (PKP). This prevents the need to update the app in many of the certificate
> replacement operations, where the public key is reused and the certificate
> can be replaced transparently to the app (generically, an “User Agent”
> doing PKP).
>
> However, in the event of a serious security incident that requires re-key
> (such as key compromise), the certificate must be revoked in less than 24
> hours (for the benefit of everyone – subscriber, relying parties, issuing
> CA, etc). It’s virtually impossible to release a new app version within
> this timeframe. And this, I think, make a very strong point against the use
> of PKI.
>
> On the other side, PKP is a simple yet powerful and effective technique to
> protect against MITM and other attacks. It seems to be widely used in apps
> with advanced threat models (mobile banking, sensitive personal
> information, etc) and there are many frameworks available (including native
> support in Android via Network Security Configuration [1]).
>
> There are several possible mitigation actions, such as pinning more than
> one public key to have more than one certificate to quickly rollover in
> case of a revocation. Even then, it is very likely that all the redundant
> key pairs were generated and maintained by the same systems and procedures,
> and thus all of them will become effectively compromised.
>
> Ultimately, it may become common practice that 1) PKP frameworks are set
> to bypass revocation checks or 2) PKP is done with private certificates
> (homemade, self-signed, managed ad-hoc with no CRL/OCSP services). Does any
> of this leads to a safer Internet?
>
> I don’t expect this thread to end up into an absolute conclusion
> advocating for or against, but opening it to discussion and contributions
> may help to document possible strategies, mitigations, alternatives, pros &
> cons, and hopefully provide guidance for an educated decision.
>
> Best regards,
>
> Nuno Ponte
> Multicert SA
>
> [1] https://developer.android.com/training/articles/security-config
>
>
>
>
>
> 

Re: Use of Certificate/Public Key Pinning

[Tom Ritter via dev-security-policy]

PKP is a footgun. Deploying it without being prepared for the
situations you've described is ill-advised.  There's a few options
available for organizations who want to pin, in increasing order of
sophistication:


Enforce Certificate Transparency. You're not locked into any CA or
key, only that the certificate has been published publicly.

Pin to a CA or a couple of CAs - this reduces the
operational/availability risk while increasing the security risk.
(Although still a reduction from the entire set of CAs of course.)

Pin to leaf *keys*, as you suggest, and ensure that they cannot all be
compromised at once through the use of offline storage and careful key
mangement. Use the keys to get certificates when needed. As you note,
if you can't manage these keys securely and separately, you need to go
to something less sophisticated, like pinning to CAs.

Pin to a locally managed trust anchor, and operate a root CA oneself,
managing it as one would a public CA (offline root, possibly offline
intermediates, etc)


-tom

On Tue, 13 Aug 2019 at 15:12, Nuno Ponte via dev-security-policy
 wrote:
>
> Dear m.d.s.p.,
>
> I would like to bring into discussion the use of certificate/public key 
> pinning and the impacts on the 5-days period for certificate revocation 
> according to BR §4.9.1.1.
>
> Recently, we (Multicert) had to rollout a general certificate replacement due 
> to the serial number entropy issue. Some of the most troubled cases to 
> replace the certificates were customers doing certificate pinning on mobile 
> apps. Changing the certificate in these cases required configuration changes 
> in the code base, rebuild app, QA testing, submission to App stores, call for 
> expedited review of each App store, wait for review to be completed and only 
> then the new app version is made available for installation by end users 
> (which is turn are required to update the app the soonest).
>
> Meeting the 5-days deadline with this sort of process is “challenging”, at 
> best.
>
> A first approach is to move from certificate pinning to public key pinning 
> (PKP). This prevents the need to update the app in many of the certificate 
> replacement operations, where the public key is reused and the certificate 
> can be replaced transparently to the app (generically, an “User Agent” doing 
> PKP).
>
> However, in the event of a serious security incident that requires re-key 
> (such as key compromise), the certificate must be revoked in less than 24 
> hours (for the benefit of everyone – subscriber, relying parties, issuing CA, 
> etc). It’s virtually impossible to release a new app version within this 
> timeframe. And this, I think, make a very strong point against the use of PKI.
>
> On the other side, PKP is a simple yet powerful and effective technique to 
> protect against MITM and other attacks. It seems to be widely used in apps 
> with advanced threat models (mobile banking, sensitive personal information, 
> etc) and there are many frameworks available (including native support in 
> Android via Network Security Configuration [1]).
>
> There are several possible mitigation actions, such as pinning more than one 
> public key to have more than one certificate to quickly rollover in case of a 
> revocation. Even then, it is very likely that all the redundant key pairs 
> were generated and maintained by the same systems and procedures, and thus 
> all of them will become effectively compromised.
>
> Ultimately, it may become common practice that 1) PKP frameworks are set to 
> bypass revocation checks or 2) PKP is done with private certificates 
> (homemade, self-signed, managed ad-hoc with no CRL/OCSP services). Does any 
> of this leads to a safer Internet?
>
> I don’t expect this thread to end up into an absolute conclusion advocating 
> for or against, but opening it to discussion and contributions may help to 
> document possible strategies, mitigations, alternatives, pros & cons, and 
> hopefully provide guidance for an educated decision.
>
> Best regards,
>
> Nuno Ponte
> Multicert SA
>
> [1] https://developer.android.com/training/articles/security-config
>
>
>
>
>
> ___
> 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: Entrust Root Certification Authority - G4 Inclusion Request

[Bruce via dev-security-policy]

On Friday, July 26, 2019 at 1:25:13 PM UTC-4, Wayne Thayer wrote:

> ==Bad==

> * The most recent BR audit report lists two additional qualifications
> related to the Network Security requirements:
> ** During the Period, there were instances of some Certificate Systems not
> undergoing a Vulnerability Scan at least every three (3) months.
> ** During the Period, there were instances where a technical control to
> restrict remote access to only those devices owned or controlled by Entrust
> did not operate effectively.

Deloitte has issued a Specified Procedures Report to address the above 
qualified items. The report has been added to 
https://bugzilla.mozilla.org/show_bug.cgi?id=1480510.


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

Re: Use of Certificate/Public Key Pinning

[Paul Wouters via dev-security-policy]

On Mon, 12 Aug 2019, Nuno Ponte via dev-security-policy wrote:


Recently, we (Multicert) had to rollout a general certificate replacement due 
to the serial number entropy issue. Some of the most troubled cases to replace 
the certificates were customers doing certificate pinning on mobile apps. 
Changing the certificate in these cases required configuration changes in the 
code base, rebuild app, QA testing, submission to App stores, call for 
expedited review of each App store, wait for review to be completed and only 
then the new app version is made available for installation by end users (which 
is turn are required to update the app the soonest).

Meeting the 5-days deadline with this sort of process is “challenging”, at best.


The OS and/or App should look at Certificate Transparency, instead of
hacks that hardcode the certificate serial number.

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

Use of Certificate/Public Key Pinning

[Nuno Ponte via dev-security-policy]

Dear m.d.s.p.,

I would like to bring into discussion the use of certificate/public key pinning 
and the impacts on the 5-days period for certificate revocation according to BR 
§4.9.1.1.

Recently, we (Multicert) had to rollout a general certificate replacement due 
to the serial number entropy issue. Some of the most troubled cases to replace 
the certificates were customers doing certificate pinning on mobile apps. 
Changing the certificate in these cases required configuration changes in the 
code base, rebuild app, QA testing, submission to App stores, call for 
expedited review of each App store, wait for review to be completed and only 
then the new app version is made available for installation by end users (which 
is turn are required to update the app the soonest).

Meeting the 5-days deadline with this sort of process is “challenging”, at best.

A first approach is to move from certificate pinning to public key pinning 
(PKP). This prevents the need to update the app in many of the certificate 
replacement operations, where the public key is reused and the certificate can 
be replaced transparently to the app (generically, an “User Agent” doing PKP).

However, in the event of a serious security incident that requires re-key (such 
as key compromise), the certificate must be revoked in less than 24 hours (for 
the benefit of everyone – subscriber, relying parties, issuing CA, etc). It’s 
virtually impossible to release a new app version within this timeframe. And 
this, I think, make a very strong point against the use of PKI.

On the other side, PKP is a simple yet powerful and effective technique to 
protect against MITM and other attacks. It seems to be widely used in apps with 
advanced threat models (mobile banking, sensitive personal information, etc) 
and there are many frameworks available (including native support in Android 
via Network Security Configuration [1]).

There are several possible mitigation actions, such as pinning more than one 
public key to have more than one certificate to quickly rollover in case of a 
revocation. Even then, it is very likely that all the redundant key pairs were 
generated and maintained by the same systems and procedures, and thus all of 
them will become effectively compromised.

Ultimately, it may become common practice that 1) PKP frameworks are set to 
bypass revocation checks or 2) PKP is done with private certificates (homemade, 
self-signed, managed ad-hoc with no CRL/OCSP services). Does any of this leads 
to a safer Internet?

I don’t expect this thread to end up into an absolute conclusion advocating for 
or against, but opening it to discussion and contributions may help to document 
possible strategies, mitigations, alternatives, pros & cons, and hopefully 
provide guidance for an educated decision.

Best regards,

Nuno Ponte
Multicert SA

[1] https://developer.android.com/training/articles/security-config 

 



___
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

[Jakob Bohm via dev-security-policy]

DO NOT SHIP THIS.  Revert the change immediately and request a CVE
number for the nightlies with this change included.

That Chrome does something harmful is not surprising, and is no
justification for a supposedly independent browser to do the same.

A policy of switching from positive to negative indicators of security
differences is no justification to switch to NO indication.  And it
certainly doesn't help user understanding of any indicator to
arbitrarily change it with 3 days of no meaningful discussion.

The only thing that was insecure with Firefox EV has been that the
original EV indicator only displayed the O= and C= field without enough
context (ST, L).  This was used to create tons of uninformed debate
in order to later present that noise as "extensive discusison [SIC] in
the security community about the usefulness of EV certificates".

The change fixes nothing, but instead removes the direct indication of
the validation strength (low-effort DV vs. EV) AND removes the one piece
of essential context that was previously there (country).

If something should be done, it would be to merge the requirements for
EV and OV with an appropriate transition period to cause the distinction
to disappear (so at least 2 years from new issuance policy).  UI
indication should continue to distinguish between properly validated OV
and the mere "enable encryption with no real checks" DV certificates.

On 12/08/2019 20:30, Wayne Thayer wrote:

Mozilla has announced that we plan to relocate the EV UI in Firefox 70,
which is expected to be released on 22-October. Details below.

If the before and after images are stripped from the email, you can view
them here:

Before:
https://lh4.googleusercontent.com/pSX4OAbkPCu2mhBfeleKKe842DgW28-xAIlRjhtBlwFdTzNhtNE7R43nqBS1xifTuB0L8LO979yhpPpLUIOtDdfJd3UwBmdxFBl7eyX_JihYi7FqP-2LQ5xw4FFvQk2bEObdKQ9F

After:
https://lh5.googleusercontent.com/kL-WUskmTnKh4vepfU3cSID_ooTXNo9BvBOmIGR1RPvAN7PGkuPFLsSMdN0VOqsVb3sAjTsszn_3LjRf4Q8eoHtkrNWWmmxOo3jBRoEJV--XJndcXiCeTTAmE4MuEfGy8RdY_h5u

- Wayne

-- Forwarded message -
From: Johann Hofmann 
Date: Mon, Aug 12, 2019 at 1:05 AM
Subject: Intent to Ship: Move Extended Validation Information out of the
URL bar
To: Firefox Dev 
Cc: dev-platform , Wayne Thayer <
wtha...@mozilla.com>


In desktop Firefox 70, we intend to remove Extended Validation (EV)
indicators from the identity block (the left hand side of the URL bar which
is used to display security / privacy information). We will add additional
EV information to the identity panel instead, effectively reducing the
exposure of EV information to users while keeping it easily accessible.

Before:


After:


The effectiveness of EV has been called into question numerous times over
the last few years, there are serious doubts whether users notice the
absence of positive security indicators and proof of concepts have been pitting
EV against domains  for
phishing.

More recently, it has been shown  that EV
certificates with colliding entity names can be generated by choosing a
different jurisdiction. 18 months have passed since then and no changes
that address this problem have been identified.

The Chrome team recently removed EV indicators from the URL bar in Canary
and announced their intent to ship this change in Chrome 77
.
Safari is also no longer showing the EV entity name instead of the domain
name in their URL bar, distinguishing EV only by the green color. Edge is
also no longer showing the EV entity name in their URL bar.



On our side a pref for this
(security.identityblock.show_extended_validation) was added in bug 1572389
 (thanks :evilpie for
working on it!). We're planning to flip this pref to false in bug 1572936
.

Please let us know if you have any questions or concerns,

Wayne & Johann




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Man Ho via dev-security-policy]

For EV certificate being useful in email, email client software should 
give a special EV treatment to such certificate.  I am not aware of any 
email client software that support any special EV treatment at all.  Do 
you have more information to share with us?

-- Man Ho

On 13-Aug-19 5:12 PM, Kurt Roeckx via dev-security-policy wrote:
> But EV is still useful for things like code signing and email. And I 
> would argue that EV should be the only option for such certificates.

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

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

[Kurt Roeckx via dev-security-policy]

On 2019-08-13 05:27, Peter Gutmann wrote:

Wayne Thayer via dev-security-policy  
writes:


Mozilla has announced that we plan to relocate the EV UI in Firefox 70, which
is expected to be released on 22-October. Details below.


Just out of interest, how are the CAs taking this?  If there's no more reason
to pay a substantial premium to enable additional UI bling in browsers, isn't
this going to kill the market for EV certs?


See the original mail for why the indication has been removed in browsers.

But EV is still useful for things like code signing and email. And I 
would argue that EV should be the only option for such certificates.



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