Hello everyone,
I believe this issue does not have many options. The meeting notes from
F2F 36
<https://cabforum.org/2015/10/07/2015-10-07-face-to-face-meeting-minutes-meeting-36-istanbul/#Guest-Speaker-Session-Andreas-from-eIDAs>
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.
Dimitris Zacharopoulos.
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 <[email protected]
<mailto:[email protected]>> 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
<[email protected]> 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.
Dean
*From:*[email protected][mailto:[email protected]]*On
Behalf Of*Ryan Sleevi
*Sent:*Friday, April 01, 2016 2:29 PM
*To:*Gervase Markham <[email protected] <mailto:[email protected]>>
*Cc:*CABFPub <[email protected]>
*Subject:*Re: [cabfpub] eIDAS meeting presentations
On Fri, Apr 1, 2016 at 2:17 PM, Gervase Markham
<[email protected]> 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
[email protected] <mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
