[cabfpub] eIDAS meeting presentations
Dimitris Zacharopoulos
jimmy at it.auth.gr
Sat Apr 2 07:41:56 UTC 2016
On 2/4/2016 8:49 πμ, Ryan Sleevi wrote:
>
>
> On Fri, Apr 1, 2016 at 10:20 PM, Dimitris Zacharopoulos
> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> wrote:
>
> 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).
>
>
> Depends on your definition of requested - there's clearly a
> multi-stakeholder involvement here, and so I don't want to speak for
> "eIDAS" (that is, as the Task Force "Legislation Team" of the European
> Commission), as Andrea will or would readily chime in that he made no
> such request. However, multiple parties at the event did request this,
> as the only viable means to achieve the vision set forward by ENISA
> (which is a proper European agency).
>
I checked the notes and read the presentations and did not see any EU
officials even suggesting that they would like to add an alternative
trust-list for the users to choose from, to establish SSL/TLS trust. But
you made it clear that this was in fact suggested at the eIDAS meeting
from multiple parties.
> Similarly, multiple parties expressed a belief that, either under the
> current legislation or potential future legislation, browsers could be
> obligated to do so. This matches the discussion during Istanbul from a
> number of browser participants over concerns about the language.
>
> I think, as such, while it's important to note things like "official"
> or "intention" as special qualifiers that make broad statements
> difficult, there is also a reasonable discussion of zietgiest and
> possibilities, which would not rule out such a request being made.
I guess what I'm trying to say is that it's better to start with
something "soft" and acceptable for everyone. This is trust we are
talking about and trust is not automatically applied through
legislation, especially not in the case of "global trust". Browsers and
qualified auditors have already established a trust relationship (with a
few glitches along the way). This is just expanding the trust circle to
include regulatory bodies and EU operators/admins (of the EU TSL) in the
equation. Trust also takes time to establish so I think that forcing
browsers to do things through legislation would send the wrong message.
The timeframe for eIDAS is very short for the EU to get into legal
debates with browsers that will take years to resolve.
Once things get started with something acceptable, there will be plenty
of time for future improvements and things will gradually mature, much
further than what we see today.
Dimitris.
> 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.
>
>
> That was indeed among the suggestions presently being discussed.
>
> Delivering the list with integrity so that it is not susceptible
> to MiTM attacks, is another issue but perhaps easier to resolve.
>
>
> I'm sure Arno, Inigo, or Moudrick will chime in with the relevant
> specification, but previously, the list format and structure was
> covered by ETSI TS 119 612 (as linked to in https://cabforum.org/etsi/
> ). The scheme itself is XML with the use of XAdES BES or EPES.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160402/9325fbc4/attachment-0003.html>
More information about the Public
mailing list