Estimated - 14:00 to 15:00 CEST
Performed - 14:00 to 16:00 CEST (appologies for the delay)
0. Overview
1. Document on SMP and Open Questions
2. AOB
- Wiki+ WorkBench + AdobeConnect
http://ec-wacs.adobeconnect.com/openncp/
Room Passcode: ask Rui Alves (Unlicensed) or markus.kalliola
----------------
If you have never attended an Adobe Connect meeting before:
Test your connection: http://ec-wacs.adobeconnect.com/common/help/en/support/meeting_test.htm
Get a quick overview: http://www.adobe.com/products/adobeconnect.html
Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
----------------
Today's Meeting Participants:
@Uwe Roth
Adrien Ferial (DG DIGIT),
João (DG Digit),
[Appologizes] Heiko Zimmermann
Invited Members List:
@Gwenaelle Quivy
@François
New release OpenNCP 2.3.0-RC0 Released in August.
Draft version shared for comments: e-SENS-eHealth-SMP_SML-v02-Draft_ForComments.doc
Questions from Last Meeting (Q1 to Q5): https://openncp.atlassian.net/wiki/x/ZACqAw
6) In the document where you propose a mapping for the SMP file there's this comment under the ServiceMetadataCollectionReference tag: "For the 1,2 transaction: should we group them, or we allow to have different endpoints for the same service?". I couldn't understand what you were talking about. For example, the epSOS consent service has two operations: Put and Discard. For that I created two pointers to ServiceMetadata, epSOS-51 and epSOS-52. Should we use just one instead? The question is: do we think that we may have different SMP configuration for the Put and Discard?
Answer: We should keep them separated, it prevents future problems in case a MS wants to provide different endpoints for those two operations.
7) In the EXPAND CP document, there's an example of how to use SMP to store information about the International Search Masks (1.1.6). That example makes use of the <Extension> element in order to share the XML file of the search mask. The SMP spec states that "SMP publishing services MUST NOT produce metadata that contain extensions necessary for a Client to understand in order to make use of this metadata." (2.3.2) If we analyze this as "the international search masks' metadata (inside its own <Process> element) must not contain extensions necessary for a client to understand in order to make use of it" then it's ok: a client doesn't need to know the XML extension of the search mask in order to make use of its metadata (identifiers, begin/end date, description). But if we analyze this in a broader scope and read it as "none of the metadata in a SMP can have extensions necessary for a Client to understand in order to make use of this metadata.", and reading this statement from SMP specification "The ability to parse and adjust client behavior based on an extension element MUST NOT be a prerequisite for a client to locate a service, or to make a successful request at the referenced service", then I believe there's a dependency between making a XCPD request to a country and its search mask: you can only perform the XCPD request if you know the search masks beforehand to provide the input fields. What do you think of this?
Answer: Correct, and I consider it a mistake of the SMP. The MUST NOT should become a MAY NOT, and then let the specification to profile the standard as needed (as all the other WS-* does). This is clear: the MUST NOT seems to be there to avoid the usage of SMP in other context. I asked Sven Rostgaard (the SMP editor) by Skype today, I will initiate a channel with him and the BDX TC.
ABBs in eSENS says that Extension semantics must be agreed by participants.
SMP extensions should not be abused.
It only has impact on search masks.
DIGIT supports extensions.
8) Regarding SMP Redirects, the specification states the following about their CertificateUID element (2.3.4.4): "Holds the Subject Unique Identifier of the certificate of the destination SMP. A client SHOULD validate that the Subject Unique Identifier of the certificate used to sign the resource at the destination SMP matches the Subject Unique Identifier published in the redirecting SMP."
If we look at epSOS D3.4.2 - 5.4.1 - Certificate Profiles - General Stipulations for epSOS compliant certificates, we see that: "The field "SubjectUniqueID" MUST NOT be used.". Do you agree that we have a conflict between the specifications here? If so, how are we going to deal with it? Can the two specifications coexist?
Answer: The situation here is clear: we do use another trust model, so the optional value check of the certificate should be discarded.
9) In the "e-SENS: ABB and Configuration Services (into CS)" page from OpenNCP (https://openncp.atlassian.net/wiki/pages/viewpage.action?pageId=49447055), when asked about "Is service locator aware of the status of the service (up-down)?", you answered "Yes". Do you mean that the SML/DNS server is aware of the status of the SMP server?
Answer: I think there is a misunderstanding: I said yes to the question “Is service Locator aware of the status of the service” by saying the ServiceStatus entry of the TSL.
10) Will the central services (SMP server) support VPN connection?
Answer: DIGIT: can't tell. Marked as a requirement.
11) Is there any need for private information? Regarding the need to have the VPN config as private data in SMP server (Stéphane: "not mandatory but recommended"), Marcello stated: Central Services must have the same level of technical and organisational security of the NCP. They must pass the initial audit." Some countries place private IP addresses for the VPN in the TSL-file (ex: LU)
Answer: VPN info is sensitive. Security by hiding info is not security. Limiting access is good but not a prerequisite. As long as adequate security measures are put in place in the OpenNCPs, we can have VPN info in the SMP.
12) Should the DNS server be a secure node? And SMP?
Answer: Massi (about the DNS server): "Maybe not, since it does not contain PHI, and the configuration changes will be audited by the NCP."
Massi (about the SMP server): "not in my opinion: An ATNA SN is defined by IHE, thus IHE puts under its umbrella everything which involves PHI. The configuration change is an event with security relevance, and it is thus audited by the OpenNCP, not by the SMP: why the SMP should audit “the german NCP asked for the ISM of the Portuguese NCP”. But it is important that the German NCP audits something like “I changed the ISM for portugal”. Why, it is not important. Check also this post: http://healthcaresecprivacy.blogspot.it/2015/08/dont-disassemble-atna-what-you-are.html from John, the guy behind ATNA."
The NCP, as the PHI holder, should be an ATNA secure node, but the SMP not.
We should ask Marcello for clarification (by email) (Stéphane: "Marcello stated that the CS must be in the same circle of trust of the NCPs")
12.1) Will we have an audit trail in SMP server?
Answer: No: the SMP server does not contain PHI, thus the audit “Security Event / Security Alert” should only be sent by the NCP according with ATNA.
13) DNS Security (Uwe) - Chapter 5 from the document e-SENS-eHealth-SMP_SML-v02-Draft_ForComments.docx
Answer:
- DNSSEC should be implemented
- Client code can obtain certificate of DNSSEC with a DNS lookup
- DIGIT: it's still unknown if the NCP has to be changed to communicate with DNSSEC
- Query made with DIGIT's client (it has to be DNSSEC-aware)
14) OpenNCP as ATNA Secure node
14.1 (Heiko): There is also nowadays a point related to the creation of the ATNA logfiles format. Since the specification from IHE has been modified and now requests the implementation of the logfiles in compliance to the DICOM format, which OpenNCP is currently not capable of.
Answer: epSOS log files were based on RFC 3881, which is deprecated ("The use of RFC3881 has been deprecated by IHE and IETF." - IHE IT Infrastructure Technical Framework Supplement - Add RESTful Query to ATNA, section 3.20.4.1.3.2). Audit log is now based on DICOM audit schema. That affects the whole epSOS specification. We depend on EXPAND's work to update the specifications (syntactical change, not semantic). More info can be checked in the minutes from a Non-repudiation meeting.
14.2 TSL Sync has quartz job (WAR. JAR doesn't - should it be run with cron?). Does it work like the syncapp then? Does it do all the needed tasks like rebooting for creating the start & stop audit log (mandatory - Massi)? Does it make OpenNCP a secure node? What about sharing the search masks?
Answer: We should address this issue in an OpenNCP specific meeting.
15) Mapping TSL-SMP (Massi's doc EXPAND CP)
- EndpointURI
Section 1.1.4: VPN endpoint must be an URI (xs:anyURI) but all we have is an IP address or domain name. Possible solution: use a non-standard scheme (e.g. "ipsec:")
Masi agrees with Uwe’s and João’s suggestion to go with the non-standard.
Signature certificate is used separately in NCP-B STS (IdP) endpoint configuration.
In each endpoint we use the TLS certificate.
This doesn't restrict the provision of epSOS compliant certificates by the MS.
If such records are considered, they SHOULD be part of the ServiceGroup (as Extensions).
- Should it be removed? It addresses epSOS pilot phase 1. If is not in accordance, then the activation date is less than now, or the SMP record should not be there. This decision should be taken in a broader scope:
- Put in comments and let EXPAND discuss.
- RequireBusinessLevelSignature (not needed for us)
- MinimumAuthenticationLevel (useful in eID level 2?)
- Advanced signature -- EXPAND to discuss
- Should we use for the type of VPN?
16) Relaxations that still exist:
Answer:
i) SHA1 vs SHA2 certificate relaxation;
ii) CA problem (not Trusted Third Party, but ministry or national level CA) and the certificate profiles
17) Is eID dependent (completely or partially) on SMP/SML?
Answer: Completely dependent I would say no, but using SMP will help a lot the deployments and its usability. LAM needs additional info (in comparison with LARMS)
- Patient consent (TRCA signed by patient)
- Where is TRC-STS?
- Which auth plan (is this patient allowed to sign the TRCA, or the stork IT (which one? STORK, eIDAS, etc?))
- Which certificates to use to validate TLS connection?
- In order to avoid configuration entries in the hospital or PoC
- Use SMP to bring info from the country of treatment
- LAM contacts SMP. NPC-B is not touched
- Portal init() triggers transaction and tells LAM who is the caller
- LAM builds SML query
18) Building domain name of country (Uwe)
Answer:
SML domain (comes from DIGIT)
- A NAPTR entry for each service
- SAML NameID of the remote's issuer
- HCID or STS -- unique fields of each NCP
2. AOB
Today's meeting actions and next meeting: