How this is established is not defined by epSOS but by national infrastructure of each country (each MS is sovereign)
The Framework Agreement (FWA) states that the only trusted actors are the NCPs
Each country has a Trusted List (TL-A and TL-B) that directly trust themselves
Each TL has a list of CAs
IdA is signed by the certificate issued by CA in TL
TSL has been defined to be signed by a certificate issued by CA in TL
TSL file integrity is verified by checking the signature
TSL file authentication is verified since it is signed with a certificate being issued by CA in TL
Current TSL file has a digital signature (that is not an aDES) because it's currently signed by NCP Signature certificate
Each NI trusts its own NCP as a data processor, not the SMP (by the FWA). From a technical point of view, it is acceptable that the SMP signs the SMP files (there's no security degradation) but not from a legal point of view
A single PKI model doesn't fit eHealth because some countries need their certificates to be issued by specific national CAs
To go for a PKI model we have to reach a consensus among the MS
SMP files can only have one signature (one single <Signature> element), by SMP spec
Can we redefine the FWA to include SMP as a trusted node? Can we do that within the timeframe of e-SENS? DIGIT has someone that can help...
New information: HTTP GET can be done via HTTPS (1-one way SSL). (PUT is done via 2-way SSL)
If FWA changes, SMP would be kept in Trust Zone II
2. Actions agreed
In order to keep the epSOS trust model we have 3 possibilities:
Try to change the FWA (DG-SANTE)
Have multiple signatures on the SMP files (OASIS to change the SMP spec)
Would conflict with other domains due to changes in the XSD
Try to use extensions, putting the signature in the extension
No need to change the SMP spec (but we should confirm with OASIS)
Predicted workflow:
NCP-A signs SMP file with trusted certificate and PUTs it in SMP
SMP verifies signature of SMP file
SMP puts the NCP signature in the extension
SMP signs the SMP file with its own certificate
NCP-B fetches SMP file
NCP-B verifies SMP signature
NCP-B changes the SMP file to replace the SMP signature with the NCP-A signature that is stored in the extension
NCP-B verifies the SMP file (now signed with NCP-A certificate)
We can try to address #1 and #2 in parallel and leave option #3 as a fallback solution if #1 or #2 fail.
We'll have SMP/SML centralized in September 2016 in Production environment (DIGIT)
None of the actions previously agreed will be ready until the end of this year (DIGIT)
As for the pilot, we have 2 scenarios:
e-SENS extended
We can try to have a full stack SMP to be tested in April's Connectathon
e-SENS not extended
We go for EXPAND (EXPANDATHON)
We should implement using the current SMP implementation and inform what requirements should implemented later
We won't have DNSSEC in DIGIT's DNS for EXPANDATHON
If we define DNSSEC as a MUST we need to have our own SMP/SML/DNS with DNSSEC in EXPANDATHON. Otherwise we can use the current infrastructure (we need an agreement with Jerry from UNIPI)
Joao Cunha and Uwe Roth to discuss if we can relax the DNSSEC requirement (at least for the pilot, but state it as mandatory for the future)
Adrien suggests to forget about DNSSEC. PEPPOL doesn't have it.
SMP: has lack of documentation
It's almost done for SML but for SMP still has to be done
Ask IHE for support for SMP/SML
Regarding the developments to be made in OpenNCP:
Change TSL-Editor to add a TSL-to-SMP transformator (e.g. XSLT)
We can use the current SMP/SML if we decide to discard DNSSEC. Otherwise we'll need to have a local development environment with SMP/SML and a DNS server with DNSSEC
Without DNSSEC, we can be provided a specific SMP user with sufficient rights to PUT the SMP files
DIGIT has a SMP client JAR file to do the GET that they can provide
PUT takes an unsigned SMP file
SMP signs the SMP file
Validation of SMP signature is made by the client JAR file in NCP-B. In case we have multiple signatures (scenario #2), we can use Apache Santuario (Massimiliano Masi)
Then we can consume the data
We will need to have the SMP certificate in the NCP truststore
We need to move some properties from the epsos properties DB to the cache
Cache should be in TZ2 (NCP-B), not in the NI
Study which properties are fetched from the DB and which components are responsible for that
For now, the developments should focus on using SMP for endpoints, certificates and search masks
How do we expect to access the information of TRC-STS in LAM?
If we just need the URL: we can do a nslookup directly in the DNS for the specific NAPTR record that will save the address of each country TRC-STS
If we need more than just the URL (more metadata): we'll need to use the normal SMP/SML workflow
When TSL/SMP file is signed by a scheme operator, the signature should be a XaDES. But its adoption depends on the Actions agreed:
In #1: we don't need
In #2 or #3: e-SENS e-Signature BB says that we should use a XaDES since we have a qualified signature. In scenario #2 SMP can have a XMLDSIG, while NCP will have a XaDES.
XaDES = XMLDSIG that as a MANIFEST with some properties
