On 2/4/2016 8:49 πμ, Ryan Sleevi wrote:
On Fri, Apr 1, 2016 at 10:20 PM, Dimitris Zacharopoulos
<[email protected] <mailto:[email protected]>> 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.
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
