[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.


>     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