<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 1, 2016 at 10:20 PM, Dimitris Zacharopoulos <span dir="ltr"><<a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>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).<br></div></div></blockquote><div><br></div><div>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).<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
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.<br>
<br>
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.<br></div></div></blockquote><div><br></div><div>That was indeed among the suggestions presently being discussed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
Delivering the list with integrity so that it is not susceptible
to MiTM attacks, is another issue but perhaps easier to resolve.</div></div></blockquote><div><br></div><div>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 <a href="https://cabforum.org/etsi/">https://cabforum.org/etsi/</a> ). The scheme itself is XML with the use of XAdES BES or EPES.</div></div></div></div>