-
Notifications
You must be signed in to change notification settings - Fork 7
"Trust Central"
Priit Parmakson
Estonian Information System Agency, [email protected]
20.04.2018
URL: https://github.com/e-gov/TARA-Doku/wiki/%22Trust-Central%22
"The node operator shall communicate the metadata of the node management in a standardised machine processable manner and in a secure and trustworthy way." (EU) 2015/1501, Art 9-1
Implementation regulation is not very specific about what the "secure and trustworthy way" should be. In present practice eIDAS nodes are made known to each other and trust relationship established between them in informal, non-mechanised way.
While maybe not so big problem today, with growth of eIDAS network, this becomes burdensome, costly and error-prone. Even now, at least some Member States are not sure how exactly trust will be established. A more detailed procedure has been called.
"Trust Central" is a concept for a more scalable system.
Please note that this is a writeup from the basis of incomplete knowledge. Certainly I do not want to propose something different from Stefan's [1]. Neither do I want to bring in different terminology. And I am not in position to comment on Stefan's proposal without thinking on the problem first myself. Therefore, please take this just as an envisioning exercise - a story that can and probably should be rewritten and/or merged with other stories.
Let us start from the stipulation of 2015/1501 Art 9-1: "The node operator shall communicate the metadata [..]". There are things that node operator can say and assert - and things that he can say but can not assert. He can advertise his cryptocapabilities, but he himself neither can declare himself node operator, nor declare his public/private type value nor his node type (proxy or connector).
Only national eIDAS authority can say who is legitimate node operator. (But see remarks 1 and 2 below). National eIDAS authority also must have a procedure to revoke a node operator from his status.
We can envisage a system, resembling CEF eDelivery PKI Service [2], where:
- each national eIDAS authority has an account
- and using a secure web browser interface, enters metadata about nodes:
- node operator name
- node metadata URL
- node country
- node name (if different from node URL)
- node type (proxy or connector)
- node sector (public, private, mixed(?))
- node metadata signature certificate (public key in X.509 format)
(See remark 3).
The system can be named "eIDAS Trust Central" or something like that (many names possible). (Names are extremely important but finding the best name is not my focus here).
"Trust Central" has to operate strictly by a detailed, exact policy (similar to certification policy).
"Trust Central" has to be governed by interested Member States (represented by national eIDAS authorities). Charter. Management Board, with equal representation of Member States. Open to admit new countries. (See remark 4).
"Trust Central" can be operated by a public or even private body, under contract with Management Board. Compare with CEF eDelivery PKI Service, where EC has contracted private companies to provide technical certification services.
"Trust Central", adhering to the principle of single responsibility, focuses on solving a single problem - scalable, mechanised trust establishment in eIDAS network (among eIDAS nodes). Accordingly, data gathered in "Trust Central" is minimal data required to establish trust in the growing eIDAS network.
"Trust Central", in secondary role, functions as node discovery service.
"Trust Central" does not gather complete metadata about nodes. Node operators will still publish metadata, according to eIDAS SAML protocol.
"Trust Central" compiles a daily machine-readable list of aforementioned trust data ("Trust Data") and makes it publicly available.
- Alternative: makes it available only to node operators and national eIDAS authorities. Analysis is needed to establish if hiding of that data is necessary and feasible. Nodes publish some data in any case.
Node operators use "Trust Data" as follows:
- connector service operator discovers from "Trust Data" available proxy services and learns about their essential characteristics. To get detailed metadata, operator makes a SAML request to proxy service, using "Trust Data" as an instrument.
- proxy service operator uses "Trust Central" to verify legitimacy and authenticity of incoming authentication requests.
A simple, yet secure technical system, offering the following functionalities, will be developed to enable "Trust Central" operation:
- accounts of national eIDAS authorities
- entering node metadata
- publishing node metadata
The technical system must be so simple that a new operator of "Trust Central" could install it with no significant effort or even rewrite it from scratch. (Still, operator presumably has to have significant resources to provide for highly dependable and secure environment for technical system operation).
"Trust Central" signs the "Trust Data" and publishes the signing public key. That key functions as trust anchor and is brought to the attention of node operators by national eIDAS authorities (presumable already in node registration process).
Effect from the system would be significant. In eIDAS network of P proxy services and C connectors, proxy service node would need establish C trust anchors (20..100 or more). Connector service node would need to set P trust anchors (20..30).
Remarks
(1) eIDAS law has no term "national eIDAS authority", but speaks about "Member States". But "Member State" is too abstract for mechanised procedure. There is the legal term "national point of single contact":
"each Member State shall designate a point of single contact." (EU) 2015/296.
Implementation act 2015/296 does not detail responsibilities of national point of single contact. In practice, however, it certainly is meant to be a national agency with single authority define who is node operator. ("National eIDAS authority")
(2) Compare this to eDelivery model, where there are many "domain network" and no single national authority. Instead, "domain networks" are governed by EC directorates. That is, an entity is admitted to network by a "domain manager" from EC directorate. Domain networks governed by other principles are possible.
(3) When it comes to technical format, should EC always choose the most dinosauric technology? JSON + JWK instead of XML, al least in proof-of-concept stage?
(4) Nordic Institute for Interoperability Solutions https://www.niis.org/ might be one model. However, there are certainly other, possibly much better models.
(5) Current eIDAS trust establishment procedures - and these are spelled out on abstract level only - and partly mismatch with current software (1.4) - which has been unsufficiently documented as well - perhaps do not separate clearly national eIDAS authority and node operator roles. Understandably, in many cases national eIDAS authority itself is operator of node.
(6) However, slamming proxy and connector services into one node software installation is questionable. Gains from common components may not outweigh more complex configuration.
(7) There is no convincing, generally applicable justification for the "1 connector per country" model. Meant to protect proxy service operators from help requests. Meant to solve the trust problem. Meant to protect national e-services from SAML protocol. However, there must be a secure protocol anyway to connect national e-services to national connector. SAML SSO is not that much different from OpenID Connect from implementation effort point of view. Therefore, if a mechanised solution to trust problem become available, there is no need for middleman.
(8) Compare this to evolution of eDelivery. When eDelivery started, in 2013, in e-SENS project, all participating countries, except Estonia, saw the "4-corner model" as the only viable model of cross-border public sector data exchange. (4-corner means a single concentrator node per country). However, very soon eDelivery philosophy evolved - first to a view that each ministry could have a e-Delivery node, then to the view that private entities could have their eDelivery nodes as well. (Why not, indeed?) This means ultimately 10,000s of nodes.
(9) Our experience in operating similar networks (X-Road and DHX, the national document exchange layer) is that as national authority we should limit our role to definition of technical protocols and a minimal set trust establishment activities. We are willing to operate as a "Registration Authority". This involves admitting entities to network. Certification Authority function is outsourced to a joint venture of banks and telecoms. But we do not want actual data traffic go through our systems. In this respect, multiplication of connectors is a good trend.
(10) If CEF developed connector sofware could be made so simple, that e-service operators could integrate it directly, then the need for intra-country protocol disappears. However, this would mean 100s or 1000s of connector nodes - and a mechanised trust management solution.
(11) Some PKI and trust management expert has written that every tenfold increase in number of parties necessitates a completely different trust architecture. This supports the need to work out a more scalable trust management solution, even if the community size could be still manageable today.
(12) Of course, there are - and remain - philosophical concerns against a centralised system. However, no system can be fully decentralised. Central element should be kept to minimum and a defined, limited purpose. Unrealistic expectations should not be put on the centralised system. For example, a mechanised central system does not eliminate the need for out-of-band communication among eIDAS network participants.
References
[1] Trust configuration for eIDAS nodes. Study report by Stefan Santesson. V 0.1, 2018-03-28
[2] CEF PKI Service