[cabfpub] eIDAS meeting presentations

[Ryan Sleevi]

On Fri, Apr 1, 2016 at 10:20 PM, Dimitris Zacharopoulos <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).

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.


> 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/20160401/66e4a2b0/attachment-0003.html>