Letter from US House of Representatives

[Richard Barnes]

Dear dev.security.policy,

I wanted to let you all know of some correspondence that happened recently
between Mozilla and the US Congress.

On June 9, the House of Representatives Committee on Energy and Commerce
sent a letter [1] to Mozilla asking for our opinion on the "restricting CAs
run by governments to issuing certificates for their own properties within
their ccTLDs".

Mozilla security and policy staff wrote a reply [2] to this letter,
highlighting the importance of our open process, and outlining some of the
arguments on both sides of the question that were raised in earlier threads
on this mailing list. Our reply was delivered June 23.

Obviously, we can't change the letter now, but if you have any thoughts or
concerns about this interaction, please feel free to reply in this thread.

--Richard

[1]
https://energycommerce.house.gov/sites/republicans.energycommerce.house.gov/files/114/Letters/20150609Mozilla.pdf
[2]
http://blog.mozilla.org/netpolicy/files/2015/06/Mozilla-Response-to-Congressional-letter-on-CAs-signed.pdf

[Peter Kurrasch]

Thanks for sharing this correspondence, Richard. I'm not sure the committee fully appreciates the scope of the problem but it's good to see them make an effort. I was actually surprised that the committee seems to understand as much as they do so perhaps this will be just a first step in a process. 

Regarding the specific questions asked and answered I would have liked to see the idea of compatibility addressed in a more straightforward fashion. (I'm assuming this is what the letter had in mind when talking about stability?)

As you know, the root store is a fixed component with the browser and the only way to change it is to update your browser. Not everyone updates his or her browser, for reasons good, bad, understandable, and so forth. This situation creates certain challenges for website owners when an important behavioral difference appears between versions.

If the different browser versions also contain contradictory information in terms of the trusted roots, the software which validates certs, and compliance with government regulations, the potential exists for "good" websites to become inaccessible. It certainly doesn't benefit anyone when that happens.

Obviously this stuff comes up all the time when we discuss the roots and such, but the committee might not have considered it. The extent to which the committee might like to implement regulations or make changes to them over time, they should keep this in mind. I'm not sure it's a technical limitation but it is a limitation nonetheless.

Just some thoughts....


  Original Message  
From: Richard Barnes
Sent: Tuesday, June 30, 2015 1:37 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Letter from US House of Representatives
‎

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

[Eric Mill]

> As you know, the root store is a fixed component with the browser and the
only way to change it is to update your browser.

That may be true for Firefox, but I don't think that's universally true. I
believe some browsers look to the underlying OS trust store, which can be
updated separately from the browser.

-- Eric

--
konklone.com | @konklone <https://twitter.com/konklone>

[Tom Ritter]

On 30 June 2015 at 13:36, Richard Barnes <rba...@mozilla.com> wrote:
> Obviously, we can't change the letter now, but if you have any thoughts or
> concerns about this interaction, please feel free to reply in this thread.

I guess I feel like there was a lot more things that could be put under #4.

- I understand Mozilla is still evaluating CT, but it seems odd not to
mention it.
- The deployment of HSTS/HPKP
- Deployment of OCSP Stapling to enable a move to hard-fail... so
revocation actually works
- Investment in "Core Infrastructure" and testing methodologies to
enable more secure software
so on and so forth...

-tom

[Gervase Markham]

On 06/07/15 15:34, Ben Wilson wrote:
> =P7-TA-2014-0282> &language=EN&reference=P7-TA-2014-0282, I was asked (by
> someone in the audience and not by anyone specifically representing EU
> governments) to relay a message that some European supervisory bodies would
> like browsers and OS providers to enable and support an additional trust
> list or trust store, specific to the EU, for those Trust Service Provider-CA
> entities that are accredited to issue digital certificates in the EU.

Hi Ben,

I realise you are just passing on a message, so this should not be taken
as shooting the messenger! I will outline briefly why this request would
be, er, problematic:

* "specific to the EU" - how do we tell if a particular connection is
going to a website in the EU? On-the-fly IP-based geolocation? This
isn't really possible. Not all websites in EU country TLDs are EU-based,
and many in e.g. .com are EU-based. There is no way to do this; the new
CAs would have to be trusted universally for certs with whatever special
marking the EU has in mind.

* This proposal would involve Mozilla delegating responsibility for who
Firefox trusts to whoever makes the list of accredited EU TSPs. As we
noted in our letter to the US committee, we value our transparent and
open process for deciding who we trust, and our control of that process
is very important to us.

Gerv

[Peter Bowen]

Thinking about this from a technical perspective, rather than a
political one, this seems very similar to a user deciding to add
additional certificates to their trust store. I think the primary
differences are the need to add a set of certificates and possibly
automatically update the list.

If there was a standard for publishing trust lists where the list
comes in one file and is signed, then I can imagine an option to
"import list" and the list could contain a URL to fetch new versions.
Then the user could simply select to use the "EU Trust List", the
"China Trust List", or the "US Government Trust List". The browser
would periodically fetch new versions of the list, validate the
signature (using the key of the previous list), and switch to that
list. Microsoft already has their SST format; possibly this could be
the starting point for an open format usable by all.

This would avoid the need for a vendor to maintain hundreds of trust
lists and allow customers to deploy their own trust list policies.

Thanks,
Peter

On Mon, Jul 6, 2015 at 5:30 PM, Richard Wang <ric...@wosign.com> wrote:
> According to this clues, as I said in Zurich CABF meeting, China will also come out a trust list that request browser and OS support.
> And other countries will come a list, then Browser and OS need to maintain hundreds trust list.
> Is it a good idea?
>
>
> Best Regards,
>
> Richard
>
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Ben Wilson
> Sent: Tuesday, July 7, 2015 12:45 AM
> To: Gervase Markham; mozilla-dev-s...@lists.mozilla.org
> Cc: Tom Ritter; Peter Kurrasch; Eric Mill; Richard Barnes
> Subject: RE: Letter from US House of Representatives
>
> Gerv,
>
> Thanks. I realize/think that this would require a separate root program. If you think of it as a Venn diagram there would be Set A and Set B. The user would then select A, B, A U B or A ∩ B. From a U.S. Government perspective, I have been told that this is accomplished with a Certificate Validation Service (CVS) that is maintained by the government, but elsewhere in the world, there might be the need for multiple Mozilla-distributed trust lists instead of just one (Sets C, D, E, ...). It's more work, but it avoids having to address your issues, I think.
>
> Cheers,
>
> Ben

[Rob Stradling]

On 07/07/15 02:02, Peter Bowen wrote:
> Thinking about this from a technical perspective, rather than a
> political one, this seems very similar to a user deciding to add
> additional certificates to their trust store. I think the primary
> differences are the need to add a set of certificates and possibly
> automatically update the list.
>
> If there was a standard for publishing trust lists where the list
> comes in one file and is signed, then I can imagine an option to
> "import list" and the list could contain a URL to fetch new versions.
> Then the user could simply select to use the "EU Trust List", the
> "China Trust List", or the "US Government Trust List". The browser
> would periodically fetch new versions of the list, validate the
> signature (using the key of the previous list), and switch to that
> list. Microsoft already has their SST format; possibly this could be
> the starting point for an open format usable by all.

Before adopting any vendor's proprietary format, it's probably worth at
least looking at this Standards Track RFC...

"Trust Anchor Management Protocol (TAMP)"
https://tools.ietf.org/html/rfc5934

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Kurt Roeckx]

On 2015-07-06 16:34, Ben Wilson wrote:
> I was asked (by
> someone in the audience and not by anyone specifically representing EU
> governments) to relay a message that some European supervisory bodies would
> like browsers and OS providers to enable and support an additional trust
> list or trust store, specific to the EU, for those Trust Service Provider-CA
> entities that are accredited to issue digital certificates in the EU.

So I'm wondering who exactly the customers of those trust list and/or
stores are going to be and how they will use it. I have a feeling this
isn't useful for the general public but rather for specific
applications. In such a case I think it should not be a problem for
them to use only the list of CAs that are they wish to trust.

So I guess it comes down to who maintains and distributes such list,
and how does it get updated. I'm not sure that browsers and OS vendors
are the right place for that.

One way to implement this would be adding more trust settings for each
CA and you could filter out the CAs that don't have the right trust
settings to create the list for the application. Or the application
could indicate that it requires those trust settings.

But then I start to wonder who is going to determine which CAs gets
those trust settings. Is this going to require an extra audit for those
CA and will we then to ask for those audit reports too? Or is the
government just going to publish a list that we can import?


Kurt

[Moudrick M. Dadashov]

+1

Thanks,
M.D.

On 7/7/2015 4:02 AM, Peter Bowen wrote:
> Thinking about this from a technical perspective, rather than a
> political one, this seems very similar to a user deciding to add
> additional certificates to their trust store. I think the primary
> differences are the need to add a set of certificates and possibly
> automatically update the list.
>
> If there was a standard for publishing trust lists where the list
> comes in one file and is signed, then I can imagine an option to
> "import list" and the list could contain a URL to fetch new versions.
> Then the user could simply select to use the "EU Trust List", the
> "China Trust List", or the "US Government Trust List". The browser
> would periodically fetch new versions of the list, validate the
> signature (using the key of the previous list), and switch to that
> list. Microsoft already has their SST format; possibly this could be
> the starting point for an open format usable by all.
>

>>> =P7-TA-2014-0282> &language=EN&reference=P7-TA-2014-0282, I was asked

>>> (by someone in the audience and not by anyone specifically
>>> representing EU
>>> governments) to relay a message that some European supervisory bodies
>>> would like browsers and OS providers to enable and support an
>>> additional trust list or trust store, specific to the EU, for those
>>> Trust Service Provider-CA entities that are accredited to issue digital certificates in the EU.

>> Hi Ben,
>>
>> I realise you are just passing on a message, so this should not be taken as shooting the messenger! I will outline briefly why this request would be, er, problematic:
>>
>> * "specific to the EU" - how do we tell if a particular connection is going to a website in the EU? On-the-fly IP-based geolocation? This isn't really possible. Not all websites in EU country TLDs are EU-based, and many in e.g. .com are EU-based. There is no way to do this; the new CAs would have to be trusted universally for certs with whatever special marking the EU has in mind.
>>
>> * This proposal would involve Mozilla delegating responsibility for who Firefox trusts to whoever makes the list of accredited EU TSPs. As we noted in our letter to the US committee, we value our transparent and open process for deciding who we trust, and our control of that process is very important to us.
>>
>> Gerv
>>
>>

[Gervase Markham]

On 06/07/15 17:44, Ben Wilson wrote:
> Thanks. I realize/think that this would require a separate root
> program. If you think of it as a Venn diagram there would be Set A
> and Set B. The user would then select A, B, A U B or A ∩ B.

The trouble with this is that, while it makes sense to you or I, Mozilla
is not keen to ask users to make decisions where they have no meaningful
understanding or basis on which to make that decision. I cannot imagine
a UI for "select the lists of CAs you trust" which would enable a user
to make a meaningful decision, or realise when something breaks that it
was a consequence of their previous decision.

This is why we have a root program, rather than a startup wizard with
100 CA checkboxes to review :-)

Gerv

[Richard Barnes]

Well, for one thing, it would be the browser asking, not the page.
And the cookie UX for these EU sites seems like an anti-pattern
anyway.

To echo Gerv's point: How is the user supposed to evaluate whether to
trust the EU list?

Sent from my iPhone. Please excuse brevity.

> On Jul 7, 2015, at 05:46, Ben Wilson <ben.w...@digicert.com> wrote:
>
> But how different would it be for the end user to accept a single pop-up for an EU trust list (based on IP address) from the multiple EU cookie pop-ups that web sites present?

>
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On Behalf Of Gervase Markham
> Sent: Tuesday, July 7, 2015 6:13 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Letter from US House of Representatives
>

[Peter Bowen]

On Tue, Jul 7, 2015 at 7:51 AM, Richard Barnes <rba...@mozilla.com> wrote:
> To echo Gerv's point: How is the user supposed to evaluate whether to
> trust the EU list?

I was not imaging a first-launch UI to choose, rather an option
similar to what is available today for adding CAs. There is a special
mime type that triggers a UI in Firefox to ask the user to trust the
certificate. There could be a similar mime type for a trust list.

However, I would imagine the common use case would not be the end
user, rather would be adding trust lists through central management.
That could be via the CCK or via a similar mechanism. I don't think
that the average individual user is going to be adding trust lists.

Thanks,
Peter

[Richard Barnes]

Sent from my iPhone. Please excuse brevity.

> On Jul 7, 2015, at 08:01, Peter Bowen <pzb...@gmail.com> wrote:
>
>> On Tue, Jul 7, 2015 at 7:51 AM, Richard Barnes <rba...@mozilla.com> wrote:
>> To echo Gerv's point: How is the user supposed to evaluate whether to
>> trust the EU list?
>
> I was not imaging a first-launch UI to choose, rather an option
> similar to what is available today for adding CAs. There is a special
> mime type that triggers a UI in Firefox to ask the user to trust the
> certificate.

Speaking of anti-patterns...

> There could be a similar mime type for a trust list.
>
> However, I would imagine the common use case would not be the end
> user, rather would be adding trust lists through central management.
> That could be via the CCK or via a similar mechanism. I don't think
> that the average individual user is going to be adding trust lists.

For central management (and many other cases), it's already possible
to install certificates via add-ons.

IIUC, the entire point of these asks is to cover general users.

--Richard

>
> Thanks,
> Peter

[Erwann Abalea]

Bonjour,

Le mardi 7 juillet 2015 03:02:48 UTC+2, Peter Bowen a écrit :
> Thinking about this from a technical perspective, rather than a
> political one, this seems very similar to a user deciding to add
> additional certificates to their trust store. I think the primary
> differences are the need to add a set of certificates and possibly
> automatically update the list.
>
> If there was a standard for publishing trust lists where the list
> comes in one file and is signed, then I can imagine an option to
> "import list" and the list could contain a URL to fetch new versions.

You mean, like the ETSI TS 102231 standard? It is used today by European members, and European Commission.
The first list of lists is located at
https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml
and references 31 national lists of trust services.

The standard defines both a (somewhat obsolete) ASN.1 encoding, and a (currently used) XML encoding for this list.

> Then the user could simply select to use the "EU Trust List", the
> "China Trust List", or the "US Government Trust List". The browser
> would periodically fetch new versions of the list, validate the
> signature (using the key of the previous list), and switch to that
> list. Microsoft already has their SST format; possibly this could be
> the starting point for an open format usable by all.
>
> This would avoid the need for a vendor to maintain hundreds of trust
> lists and allow customers to deploy their own trust list policies.

I don't like it, but I'm afraid european users will be more or less supposed to trust what is declared in a TSL. Because of eIDAS.

[Peter Bachman]

On Tuesday, June 30, 2015 at 2:36:57 PM UTC-4, Richard Barnes wrote:
> Dear dev.security.policy,
>
> I wanted to let you all know of some correspondence that happened recently

I understand root certificate bundles that are managed by the browser either as part of the OS keybag, or software keybag. I see that the software, either through pinning, reference to a Markle hash tree, or reference to an authoritative list, or even a well known list, can enable the software to identify self signed roots. In addition any user can add their own root and set the trust bits for themselves. So it appears the users have the ultimate decision in regards to evaluation of trust, and some tools that aid them in that decision.

I have also read the Certificate Policy and Practices statements by many of the CA that would typically be found in a browser store.

The question to me is how does this scale in terms of the trust model when there is obvious manipulation of code signing certificates with state level use case actor malware threats?

I have seen this brought up in terms of the discussion of domain constraints and the implementation in the code.

I think this brings us squarely back to 1996 when included bundles were the logical choice for browser users. Make it simple, and don't require mutual TLS, which would then also require client based certificates.

Then with the industry groups like CAB promoting enhanced identity verification for the added green indicator, a step in the right direction.

But this was already part of X.509v1, previous to the RFC-5280 extensions. However unwieldy the X.509v1 model was for the Internet, in that there was very close binding between a X.500 Directory model, and the authentication to the Directory, e.g. X.509 in the original form...there already was established identity in the Directory.

Here in the U.S. that organizational identity is supplied by ANSI which registers Administrative Domains, as opposed to DNS domains. The door that was left open in the security of binding the DNS domain to the certificate, say in the subject alternative field lacked this functionality of the original model in which there was a 1:1 relationship between the identity of the X.500 object, and the user certificate that was bound to that object.

Many organizations don't try to bite off the entire internet in terms of scope. We see constraints applied everywhere, and they all feed back to enabling legislation, such as the EU trust list example. We are seeing an unprecedented disruption of the CA PKI model with Let's Encrypt, which does fit the bill of enabling every site that wants to do TLS, the ability to do so.

I respect Mozilla's commitment to develop policy artifacts in this difficult area and the work of industry fora to build trusted communities. I do think the problem has to be constrained in some shape or manner, and what has existed as the "internet death for CA's that don't do adequate protection of private signing keys" discussion is a valid lever that the community can use. Or even put that into the hands of the end user. I don't typically go to web sites that fully leverage the full power of the Internet to connect me to 1:* possible connections. Sometimes.

I do know when I tried to engineer in a no-sub CA clause my CA balked. They would not put it into the contract. I do think the DNS is inadequate compared to the original X.509v1 model in establishing identity bound to the subject of the certificate. Does that mean that Mozilla should allow for dynamic updating of certificates in Firefox via LDAP? Or DNS?That seems to already be available through DISA X.500, but I am restrained from using that software add on from Milforge. Or is this already built in?

[Peter Kurrasch]

‎This is an interesting topic. Setting aside politics and technical considerations and instead focusing on just security implications I'd like to share the following thoughts. I admit readily that I have not done much research on this topic so I hope people will make corrections or otherwise let me know if I'm missing important information. 

* I don't think calling it a Trust List is appropriate and perhaps is better called "I Hope We Can Trust This" List. ‎Or perhaps call it a "Mandatory Recognition of Authority" List. I didn't come across anything that leads me to conclude that this list is any more trustworthy than other list I might generate, sign, and distribute. 

* Perhaps unintentionally (and in a counter-intuitive sense) this legislation increases the attack surface that a bad actor might use. I took only a brief look at the list that Erwann pointed us to below and it seemed to me there are new authorities that are not already included in the Mozilla trust store. This means that if I don't feel like attacking one of the trust store CAs, I know have a whole slew of other places to go after. Just how much damage I might cause was not immediately clear to me but that's almost secondary: the legislation could actually improve my chances of success as a bad actor.

* At the most basic level, it's not clear to me to whom this legislation is directed. Is it citizens within the EU? Users of any web sites hosted within the EU? People outside the EU who might wish to conduct business with other people and businesses who happen to be located within the EU? Note that in addition to being a basic question this also goes to my previous point about how much larger does the threat landscape (and potential for harm) become?

* One of the more fascinating ideas for me was actually paragraph 61 of the WHEREAS portion of the legislation: that electronic identities should be viable into the future. This opens up the possibility (again, perhaps unintentionally) that revocation of a person's certificate or other "signature materials" might need to be specifically addressed.

* That previous point leads to what I think might be a major gap in the legislation: policies and regulations for when an individual loses control of his or her electronic identity. We know this will happen and I think we have to assume that it will happen a lot. What are the implications to that, from the standpoint of the legislation and it's intended application? And any legal ramifications?

* Regarding Mozilla's support of any such lists, I think any proposal that requires a user to decide to accept/decline the list or an authority must be disqualified from further consideration. People make the wrong choices all the time so if you are dependent on a user making the right choice in order to establish/preserve a chain of trust it seems to me your chances of success are no better than a coin toss.

For me the bottom line in all this is that it seems the legislation is well intentioned but by creating a parallel universe of trust anchors outside of the existing PKI system (that has all the same issues and problems of the existing system)‎ it actually does little to further the cause of making the internet safer and more trustworthy. 

For whatever it's worth.

From: Erwann Abalea Sent: Tuesday, July 7, 2015 4:24 PM To: mozilla-dev-s...@lists.mozilla.org Subject: Re: Letter from US House of Representatives

Bonjour,

Le mardi 7 juillet 2015 03:02:48 UTC+2, Peter Bowen a écrit :

> Thinking about this from a technical perspective, rather than a
> political one, this seems very similar to a user deciding to add
> additional certificates to their trust store. I think the primary
> differences are the need to add a set of certificates and possibly
> automatically update the list.
>
> If there was a standard for publishing trust lists where the list
> comes in one file and is signed, then I can imagine an option to
> "import list" and the list could contain a URL to fetch new versions.

You mean, like the ETSI TS 102231 standard? It is used today by European members, and European Commission.
The first list of lists is located at
https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml
and references 31 national lists of trust services.

The standard defines both a (somewhat obsolete) ASN.1 encoding, and a (currently used) XML encoding for this list.

> Then the user could simply select to use the "EU Trust List", the
> "China Trust List", or the "US Government Trust List". The browser
> would periodically fetch new versions of the list, validate the
> signature (using the key of the previous list), and switch to that
> list. Microsoft already has their SST format; possibly this could be
> the starting point for an open format usable by all.
>
> This would avoid the need for a vendor to maintain hundreds of trust
> lists and allow customers to deploy their own trust list policies.

I don't like it, but I'm afraid european users will be more or less supposed to trust what is declared in a TSL. Because of eIDAS.

[Moudrick M. Dadashov]

Its hard not to agree with you.

>At the most basic level, it's not clear to me >to whom this legislation is directed. Is it >citizens within the EU?

This is funniest part of the game, in fact member states supposed to maintain their TSLs but to my best knowledge, there is no obligation to anybody or any public service to rely on those lists.
Also according to the legislation those lists are maintained primarily by the agencies (so called supervising bodies) that are responsible for the legal recognition of of TSPs (CAs), which in practice leads to even more confuse and contraversy. Don't be suprised if you find the same supervisors adopting their own rules (for legal recognition of TSPs) which turns out to be an alternative to an applicable audit.
So I'd say your concerns are quite close to real picture.
At the same time IMHO the use of harmonized  trust anchor containers (in technical sense) at the OS level or even by the browsers should have been welcomed by many application developers.
Thanks,M.D.
Sent from my Samsung device

-------- Original message --------
From: Peter Kurrasch <fhw...@gmail.com>
Date: 10/07/2015 21:57 (GMT+02:00)
To: mozilla-dev-s...@lists.mozilla.org
Subject: EU Trust-lists (was: Letter from US House of Representatives)

‎This is an interesting topic. Setting aside politics and technical considerations and instead focusing on just security implications I'd like to share the following thoughts. I admit readily that I have not done much research on this topic so I hope people will make corrections or otherwise let me know if I'm missing important information. 
* I don't think calling it a Trust List is appropriate and perhaps is better called "I Hope We Can Trust This" List. ‎Or perhaps call it a "Mandatory Recognition of Authority" List. I didn't come across anything that leads me to conclude that this list is any more trustworthy than other list I might generate, sign, and distribute. 
* Perhaps unintentionally (and in a counter-intuitive sense) this legislation increases the attack surface that a bad actor might use. I took only a brief look at the list that Erwann pointed us to below and it seemed to me there are new authorities that are not already included in the Mozilla trust store. This means that if I don't feel like attacking one of the trust store CAs, I know have a whole slew of other places to go after. Just how much damage I might cause was not immediately clear to me but that's almost secondary: the legislation could actually improve my chances of success as a bad actor.
* At the most basic level, it's not clear to me to whom this legislation is directed. Is it citizens within the EU? Users of any web sites hosted within the EU? People outside the EU who might wish to conduct business with other people and businesses who happen to be located within the EU? Note that in addition to being a basic question this also goes to my previous point about how much larger does the threat landscape (and potential for harm) become?
* One of the more fascinating ideas for me was actually paragraph 61 of the WHEREAS portion of the legislation: that electronic identities should be viable into the future. This opens up the possibility (again, perhaps unintentionally) that revocation of a person's certificate or other "signature materials" might need to be specifically addressed.
* That previous point leads to what I think might be a major gap in the legislation: policies and regulations for when an individual loses control of his or her electronic identity. We know this will happen and I think we have to assume that it will happen a lot. What are the implications to that, from the standpoint of the legislation and it's intended application? And any legal ramifications?
* Regarding Mozilla's support of any such lists, I think any proposal that requires a user to decide to accept/decline the list or an authority must be disqualified from further consideration. People make the wrong choices all the time so if you are dependent on a user making the right choice in order to establish/preserve a chain of trust it seems to me your chances of success are no better than a coin toss.

For me the bottom line in all this is that it seems the legislation is well intentioned but by creating a parallel universe of trust anchors outside of the existing PKI system (that has all the same issues and problems of the existing system)‎ it actually does little to further the cause of making the internet safer and more trustworthy. 
For whatever it's worth.

From: Erwann AbaleaSent: Tuesday, July 7, 2015 4:24 PMTo: mozilla-dev-s...@lists.mozilla.orgSubject: Re: Letter from US House of Representatives