OpenNCP integration with SMP
...
LOCATION
- DG-DIGIT office: DIGIT ROOM B-28 2/SDR1 AUDIO
PARTICIPANTS
Today's Meeting Participants:
...
- 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 certcertificate)
We can try to address #1 and #2 in parallel and leave option #3 as a fallback solution if #1 or #2 fail.
...
- 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
- As for the caching:
- Which component should host it? Study this with Kostas Karkaletsis
- 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
- e-SENS extended
6. AOB
...