20151015 - Meeting minutes, Thursday, October 15th, 2015 - OpenNCP integration with SMP

Owned by Joao Cunha
Last updated: Oct 19, 2015
4 min read

OpenNCP integration with SMP

 

Estimated - 15:30 to 17:30 CEST

Performed - 15:30 to 17:30 CEST

AGENDA

1. Discussion about open issues that are halting us from progressing with this e-SENS BB

 

LOCATION
  •   DG-DIGIT office: DIGIT ROOM B-28 2/SDR1 AUDIO

PARTICIPANTS


Today's Meeting Participants:

Rui Alves (Unlicensed) 

Joao Cunha

Alexandre Santos

S

Adrien Ferial (DG DIGIT)

Sandro D'Orazio (DG DIGIT)

Massimiliano Masi

 

Invited Members List:

Uwe Roth

MEETING NOTES

1. Discussion

  • Each NI trusts its own NCP
    • 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:

  1. Try to change the FWA (DG-SANTE)
  2. Have multiple signatures on the SMP files (OASIS to change the SMP spec)
    1. Would conflict with other domains due to changes in the XSD
  3. Try to use extensions, putting the signature in the extension
    1. No need to change the SMP spec (but we should confirm with OASIS)
    2. Predicted workflow:
      1. NCP-A signs SMP file with trusted certificate and PUTs it in SMP
      2. SMP verifies signature of SMP file
      3. SMP puts the NCP signature in the extension
      4. SMP signs the SMP file with its own certificate
      5. NCP-B fetches SMP file
      6. NCP-B verifies SMP signature
      7. NCP-B changes the SMP file to replace the SMP signature with the NCP-A signature that is stored in the extension
      8. 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:
    1. e-SENS extended
      1. We can try to have a full stack SMP to be tested in April's Connectathon
    2. e-SENS not extended
      1. We go for EXPAND (EXPANDATHON)
      2. We should implement using the current SMP implementation and inform what requirements should implemented later
      3. We won't have DNSSEC in DIGIT's DNS for EXPANDATHON
        1. 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)
        2. 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)
        3. Adrien suggests to forget about DNSSEC. PEPPOL doesn't have it.
      4. SMP: has lack of documentation
        1. It's almost done for SML but for SMP still has to be done
        2. Ask IHE for support for SMP/SML
      5. Regarding the developments to be made in OpenNCP:
        1. Change TSL-Editor to add a TSL-to-SMP transformator (e.g. XSLT)
        2. 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
        3. Without DNSSEC, we can be provided a specific SMP user with sufficient rights to PUT the SMP files
        4. DIGIT has a SMP client JAR file to do the GET that they can provide
        5. PUT takes an unsigned SMP file
        6. SMP signs the SMP file
        7. 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)
        8. Then we can consume the data
        9. We will need to have the SMP certificate in the NCP truststore
        10. As for the caching:
          1. Which component should host it? Study this with Kostas Karkaletsis
          2. We need to move some properties from the epsos properties DB to the cache
          3. Cache should be in TZ2 (NCP-B), not in the NI
          4. Study which properties are fetched from the DB and which components are responsible for that
        11. For now, the developments should focus on using SMP for endpoints, certificates and search masks
        12. How do we expect to access the information of TRC-STS in LAM?
          1. 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
          2. If we need more than just the URL (more metadata): we'll need to use the normal SMP/SML workflow
        13. When TSL/SMP file is signed by a scheme operator, the signature should be a XaDES. But its adoption depends on the Actions agreed:
          1. In #1: we don't need
          2. 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.
          3. XaDES = XMLDSIG that as a MANIFEST with some properties

 

Photos of the whiteboard: