[cabfpub] eIDAS meeting presentations
jimmy at it.auth.gr
Sat Apr 2 05:20:05 UTC 2016
I believe this issue does not have many options. The meeting notes from
captures the essence of it all. I think it is fair to say that browsers
will not rely on any "external" trust-list and IMO, they are very right
to do so. But I don't think that was ever officially requested or was
the intension of the EU TSL (I could be wrong, wasn't at the eIDAS meeting).
As I stated in F2F 36, a feasible solution would be to continue to rely
only on the browsers Trust-list to establish the TLS client-server
communication and ADDITIONALLY, if the server certificate chains to a
Root or Intermediate Certificate that is also in the EU TSL, make a
discrete UI change to indicate this additional information. This UI
change could easily happen through a plugin, AFTER the TLS handshake is
complete with the current browser code.
Now, if the EU officials want to "simulate" the EV policy for the QWACs,
then this additional UI change would occur only if the server
certificate gets an EV status.
Delivering the list with integrity so that it is not susceptible to MiTM
attacks, is another issue but perhaps easier to resolve.
On 2/4/2016 1:30 πμ, Ryan Sleevi wrote:
> The specific request was for an extension API to allow extensions to
> determine if a certificate is trusted or not, rather than the browser,
> and to allow extensions to change the UI state to whatever the
> extension requests.
> Understandably, this would be a disaster security wise.
> On Fri, Apr 1, 2016 at 3:27 PM, Peter Bowen <pzb at amzn.com
> <mailto:pzb at amzn.com>> wrote:
> From the slides it looks like the presenter was more requesting
> that browsers use SCVP or support Authorization Validation Lists.
> This would mean the browser “outsources” validation of
> certificates to another entity which returns the validation
> result. The result could possibly include an image to show the
> user in addition to a boolean valid/not valid.
>> On Apr 1, 2016, at 3:19 PM, Dean_Coclin
>> <Dean_Coclin at symantec.com> wrote:
>> I think what the presenter had in mind were “hooks” into the
>> trust store such that an alternate trust source (i.e. eIDAS Trust
>> List) could be selected by a user. I believe Ryan said this type
>> of “hook” exposes the browser to potential malicious intent. One
>> question I had (and I really don’t know how this works) is that I
>> know Microsoft provides the capabilities for Enterprises to add
>> or push roots out to users in their groups. Perhaps Dr. Poesch
>> had that in mind when he was brainstorming his hook idea.
>> *From:*public-bounces at cabforum.org[mailto:public-bounces at cabforum.org]*On
>> Behalf Of*Ryan Sleevi
>> *Sent:*Friday, April 01, 2016 2:29 PM
>> *To:*Gervase Markham <gerv at mozilla.org <mailto:gerv at mozilla.org>>
>> *Cc:*CABFPub <public at cabforum.org>
>> *Subject:*Re: [cabfpub] eIDAS meeting presentations
>> On Fri, Apr 1, 2016 at 2:17 PM, Gervase Markham
>> <gerv at mozilla.org> wrote:
>> On 30/03/16 01:03, Adriano Santoni wrote:
>> > Especially, I would like to understand whether browsers are
>> > willing/planning to integrate the EU trust lists....
>> We remain to be convinced of the value of doing so. We see direct
>> control of our own trust list as an important factor in our
>> ability to
>> drive positive change in the CA industry and the security of
>> the web.
>> And how do you feel about exposing programattic access to modify
>> or affect certificate validation, certificate UI, or certificate
>> trust lists, as proposed during the meeting (and as captured in
>> the Summary and in the slides by Reinhard Posch)
>> I will echo on list what I had previously stated during the
>> meeting, as it was not captured in the summary, which is on the
>> balance, we see a far greater incidence of malware abusing such
>> APIs compared to legitimate uses, and have no intent or desire to
>> support such programatic access. We've seen malware campaigns
>> extensively abuse command-line flags intended for debugging and
>> diagnostics, and we've seen malware and malvertising campaigns
>> significantly abuse both sanctioned and unsanctioned APIs, such
>> that the use of such APIs is a strong indicator of Potentially
>> Unwanted Software, and will be blocked through means such as
>> Google SafeBrowsing and the Chrome Cleanup Tool. We believe other
>> vendors have seen similar results.
>> Further, we remain deeply concerned about proposals that it would
>> be beneficial to have other countries and legal entities provide
>> or require similar Trust Lists, as also captured on Dr. Posch's
>> slides, for many of the same reasons that Gerv spoke of.
>> Public mailing list
>> Public at cabforum.org <mailto:Public at cabforum.org>
> Public mailing list
> Public at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public