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