Modular Specification Project Recommendations to the Direct Community Office of the National Coordinator for Health Information Technology Version 1.0 December 19 2011 Prepared By: ONC Specification Modularization Team Contents A. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. B. 1. 2. 3. 4. 5. 6. 7. 8. General Recommendations .............................................................................................................................. 3 Certificate Discovery .................................................................................................................................. 3 Type pkcs ................................................................................................................................................... 3 Support of SHA 1 ....................................................................................................................................... 3 confidentialityCodes ................................................................................................................................... 4 Optionality of XDR/XDM Conversions ..................................................................................................... 4 SMTP and S/MIME as Direct compliant baseline ...................................................................................... 4 uniqueId and sourceID should be a UUID that is FORMATTED as an OID............................................. 4 IHE Supplement - Metadata-Limited Document Sources .......................................................................... 5 IHE Change Proposal 524 – authorTelecommunication............................................................................. 5 Message signing and encryption ................................................................................................................. 5 Conversion requiring ‘more significant metadata' ...................................................................................... 5 List of valid MIME Bodies ......................................................................................................................... 6 14 multipart/signed format type.................................................................................................................. 6 Need for Additional MDN Guidance.......................................................................................................... 6 Language clarification ..................................................................................................................................... 7 ‘STA v. Implementation’ ............................................................................................................................ 7 ‘Vouch’ ....................................................................................................................................................... 7 ‘Appropriate Error Notification’ ................................................................................................................. 7 ‘Root CA’ ................................................................................................................................................... 7 ‘Appropriate Audit Logs’ ........................................................................................................................... 8 ‘Any Appropriate Way’ .............................................................................................................................. 8 ‘Chain Back’ ............................................................................................................................................... 8 ‘Appropriate Mechanisms’ ......................................................................................................................... 8 Change Log Version 1.0 Date 12/19/2011 Changed By Deloitte Description Initial documentation A. General Recommendations 1. Certificate Discovery RTM 31 Applicability Statement for Secure Health Transport 2.3 Discovery of Recipient Certificates Prior to Sending “The STA MUST have a method for discovering the certificates of message recipients prior to sending a message in order to fulfill the encryption functions of S/MIME.” Comment: At the close of Mod Spec Phase 2 development the S&I Framework’s Provider Directory Initiative was still working on their certificate discovery solution. We made reference to it in the implementation guidance and suggest that the spec reference their final product(s) upon completion. 2. Type pkcs RTM 35-36 Applicability Statement for Secure Health Transport 2.4 Signed and Encrypted Health Content Containers “…MUST be capable of creating and reading documents that are encrypted as Enveloped Data, as specified by RFC 5751, with media type application/pkcs-mime (although STAs MUST be capable of also recognizing Enveloped Data with media type application/x-pkcs-mime) ….” RTM 40-41 Applicability Statement for Secure Health Transport 2.5.1 Detached Signatures “… and the standard media type (application/pkcs-signature) for the detached signature body part. They MUST be able to accept a media type of application/x-pkcs-signature as well..” Comment: The content-type “pkcs-mime” does not appear in the underlying specifications (RFC 5751 or RFC 2311). The type pkcs only appears with a version number appended, 1,7, or 10 ie "application/pkcs7-mime." This may be confusing to implementers who will look in the underlying specs for the type “pkcs-mime” and only find type “pkcs#-mime.” Mod Spec included the following implementation guidance: “From a DIRECT stand point pkcs7 is applicable since that is used for signing and encryption. Pkcs10 is used for certificate requests which happens out of band and is not part of the spec.” It may be beneficial to include a similar clarification in the Direct specification. 3. Support of SHA 1 RTM 44 Applicability Statement for Secure Health Transport 2.6 Digest Algorithms “The STA MUST support the following Digest Algorithms: SHA1 SHA256” “STAs MUST NOT support less secure Digest Algorithms, including additional algorithms listed as SHOULD- in RFC 5751 section 2.1 (e.g., MD5)” Comment: SHA1 is listed as required in the Direct spec, but is mentioned as SHOULD- in RFC 5751 which indicates that it should not be supported. This contradiction should be clarified in the Direct Spec. Mod Spec included the following implementation guidance: “Direct implementations should follow the guidance in requirement 43 and support SHA1.” 4. confidentialityCodes RTM 140 XDR and XDM for Direct Messaging 6.2.1 Document Entry Metadata confidentialityCode : “Implementations SHOULD NOT use codes that reveal the specific trigger causes of confidentiality (e.g., ETH, HIV, PSY, SDV)” Comment: The list of codes is not exhaustive but may be interpreted as exhaustive by implementers. The Mod Spec appended the list (e.g., ETH, HIV, PSY, SDV, etc) to convey that this is not the complete list. 5. Optionality of XDR/XDM Conversions RTM 90 XDR and XDM for Direct Messaging 3.0 Interaction Patterns “The following table shows the cases of conversion that SHALL be performed. {conversion table}” Comment: The use of the word SHALL implies that an organization needs to implement all 6 conversions to be compliant with the spec. This was left as-is in the Mod Spec, but implementation guidance was added that conversions were dependant on an implementer’s individual use cases. 6. SMTP and S/MIME as Direct compliant baseline RTM 172 Applicability Statement for Secure Health Transport Synopsis In the synopsis of the Applicability Statement spec includes the statement: “This document describes the following REQUIRED capabilities of a Security/Trust Agent (STA), which is a Message Transfer Agent, Message Submission Agent or Message User Agent supporting security and trust for a transaction conforming to this specification: • Use of Domain Names, Addresses, and Associated Certificates • Signed and encrypted Internet Message Format documents • Message Disposition Notification • Trust Verification” Comment: The statement denoting the STA’s SMTP and S/MIME capabilities as REQUIRED may be missed by implementers if it is included in the introductory sections and not explicitly stated in the numbered sections which contain the requirement statements. Also, in reading the XDR/XDM spec it is unclear that implementing STMP and S/MIME is required to be direct compliant. The Mod Spec created a new numbered requirement to make this distinction: “The capabilities described in requirements 1-89 are REQUIRED for a Security/Trust Agent (STA) to be considered DIRECT Project compliant.” 7. uniqueId and sourceID should be a UUID that is FORMATTED as an OID RTM 152 (document entry) and 161 (submission set) XDR and XDM for Direct Messaging 6.2.1 Document Entry Metadata and 6.2.2 Submission Set Metadata uniqueID “Implementations SHOULD use a unique ID extracted from the content, if a single such value can be determined. If not, implementations SHOULD use a UUID URN, generated for the transaction. This value must be different than the uniqueId specified on the Document.” RTM158 XDR and XDM for Direct Messaging 6.2.2 Submission Set Metadata sourceID “Implementations SHOULD use a UUID URN mapped by configuration to sending organization” Comment: During the Mod Spec process, NIST raised the point that IHE requires the uniqueID and sourceID to be an OID while the Direct specs require uniqueID and sourceID to be a UUID. During a call with members of the Direct community on 10/25/2011 consensus was reached that uniqueID and sourceID should be a UUID formatted as an OID. We added the additional highlighted text in our RTM: “… SHOULD use a UUID URN formatted as an OID….” 8. IHE Supplement - Metadata-Limited Document Sources RTM 173, 174 XDR and XDM for Direct Messaging 6.2.1 Document Entry Metadata and 6.2.2 Submission Set Metadata Comment: The IHE supplement for Metadata-Limited Document Sources includes a new attribute limitedMetadata which “Indicates whether the Document Entry was created using the less rigorous requirements of metadata as defined for the Metadata-Limited Document Source. The Document Entry is flagged using an ebRIM Classification with a classificationScheme of urn:uuid:ab9b591b-83ab- 4d03-8f5d-f93b1fb92e85.” Mod spec created two new requirements to include limitedMetadata in the Document Entry and Submission Set Metadata definitions. The supplement can be found at http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_Support-forMetadata-Limited-Doc-Sources_Rev1-1_TI_2011-08-19.pdf 9. IHE Change Proposal 524 – authorTelecommunication RTM 162 XDR and XDM for Direct Messaging 6.3 Special Considerations and Extensions Comment: The CP provides a place for a telecommunications address for the sender and receiver in the metadata through the authorTelecommunication attribute. Mod Spec made reference to this CP in our underlying specs section. The CP can be found at ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2011/CPs/Assigned/CP-ITI-524-05.doc 10. Message signing and encryption RTM 34 - 48 XDR and XDM for Direct Messaging 2.4 Signed and Encrypted Health Content Containers Comment: This section does not explicitly state that a message must be encrypted and signed from the Direct system point of origin to the Direct system recipient. The MDN section of the spec explicitly states that a MDN must be encrypted. Spec team added the requirement “All messages MUST be signed and encrypted, from the original message sender to the original message receiver.” 11. Conversion requiring ‘more significant metadata' RTM 135 & IG XDR and XDM for Direct Messaging 6.1.2 Minimal Metadata Definition The use of Minimal Metadata is required when converting from a transport with minimal metadata, RFC 5322 without an XDM attachment, to a transport requiring more significant metadata. Conversion in the other direction retains all the metadata available by coding the content in an XDM package where the receiver can ignore the metadata if preferred. The use of minimal metadata covers the following cases: The system creating the XDR/XDM transaction does not have access to full XDS metadata, including cases where The original content was created with a system that does not store all relevant metadata items as discrete values (e.g., e-mail client sending a text message with PDF attachment) The original content was received by the XDR creating system encrypted The system creating the XDR/XDM transaction is not able to or by policy prefers not to examine the content to construct available metadata The content payload does not conform to XDS Metadata expectations, including cases where: The payload is not patient specific (e.g., summary level quality reporting) Comment: In this case, a “transport requiring more significant metadata” can only be SOAP+XDR as there is no conversion required between MIME and XDM. Following SME guidance, the Mod Spec called out conversion to XDR as the only transport requiring more data. The highlighted XDM references were removed and the following text was added “…..to a transport requiring more significant metadata, SOAP+XDR.” 12. List of valid MIME Bodies RTM 16 & IG Applicability Statement for Secure Health Transport 2.1 Health Content Containers “The message body prior to signing and encrypting MUST be a valid MIME body. However, nothing in this specification obligates a specific address to handle all valid MIME bodies.” Comment: A list of valid MIME types for Direct would be useful for implementers. 13. 14 multipart/signed format type RTM 40 Applicability Statement for Secure Health Transport 2.5.1 Detached Signatures STAs MUST use detached signatures as specified by RFC 5751. They MUST use a multipart/signed main body part, and the standard media type (application/pkcs-signature) for the detached signature body part. Comment: RFC 5751 describes two signing formats, multipart/signed in section 3.4.3and application/pkcs7-mime with SignedData format in section 3.4.2. There was some questions raised as to whether the Direct specs also allowed the application/pkcs7-mime with SignedData format. The Mod Spec added implementation guidance explicitly stating to restrict to multipart/signed for main body part within the Direct specifications 14. Need for Additional MDN Guidance Applicability Statement for Secure Health Transport - General Comment – During a public call for the Mod Spec Project the issue of MDN guidance was discussed. MDN guidance was identified as a gap in the specification. For example our test team assumed that an MDN was required in response to an unencrypted message, but after discussion this was determined to be a security risk. B. Language clarification 1. ‘STA v. Implementation’ Applicability Statement for Secure Health Transport, general XDR and XDM for Direct Messaging, general The Applicability Statement for Secure Health Transport Spec defines Security/Trust Agent (STA) as a “Message Transfer Agent, Message Submission Agent or Message User Agent supporting security and trust for a transaction conforming to this specification.” Many of the requirement statements in the spec reference the STA by name. The XDR and XDM for Direct Messaging spec does not mention the STA at all. Instead its requirement statements include reference to "Implementations." The term implementation is not defined. Comment: It is unclear if the terms STA and Implementation are intended to be the same entity (the Mod Spec interpreted them to be the same entity). It may be confusing for an implementer if consistent terminology is not used in both specs or an explanation is not provided describing the differences. 2. ‘Vouch’ RTM 10 Applicability Statement for Secure Health Transport 1.4 Associated X509 Certificates “An organization that maintains Organizational Certificates MUST vouch for the identity of all Direct Addresses at the Health Domain Name tied to the certificate(s).” Comment: There was some confusion surrounding the definition of ‘vouch’ we included the implementation guidance: “Vouch” in this case means “guarantee” which can only be done when the organization has verified the user’s identity before they can use the services. 3. ‘Appropriate Error Notification’ RTM 18 Applicability Statement for Secure Health Transport 2.1 Health Content Containers “Such addressees MUST provide appropriate error notification in response to inbound messages that do not conform to its specification.” Comment: There was some confusion about what constituted ‘appropriate’ error notification. Mod Spec included the following implementation guidance: “The error notification depends on the result of the processing that happens at the receiver’s end as governed by their local policy. For example the error could be that the content could not be unencrypted or trust could not be verified or the message content is a MIME type that is not supported etc… The Error notification should use the MDN standards according to RFC 3798.” 4. ‘Root CA’ RTM 42 Applicability Statement for Secure Health Transport 2.5.2 Certificates in Signatures “Signatures MUST include the signing certificate and the full certificate chain up to the root CA, following the requirements of RFC 5652” Comment: The phrase ‘the root CA’ may be interoperated by implementers that there is a single root CA that must be included in the certificate chain. An explicit statement clarifying that the root CA does not necessarily need to be included in the cert path could be useful. We included the implementation guidance: “Validation of an intermediate signing CA was purposely left out of scope of the reference implementation. Any CA with the basic constrain set to true can be used as a trust anchor, and Root CAs do not necessarily need to be included in the cert path chain validation. However, this is not to say a CA taking on the role of a trust anchor should not have to be validated before being included in the trust anchor store. This step is left up to the policy and procedures of the HISP.” 5. ‘Appropriate Audit Logs’ RTM 54 Applicability Statement for Secure Health Transport 3.0 Message Disposition Notification “Because the STA's confirmation of receipt will be used to indicate legal and regulatory compliance, it is RECOMMENDED that such confirmation be accompanied by appropriate audit logs.” Comment: There was confusion surrounding what constituted an ‘appropriate’ audit log. Some additional information in the spec would be useful. Mod Spec included the implementation guidance: “While the use of audit logs is governed by the internal policies of implementers, audit logs are recommended to include information about how messages are dispositioned. The audit logs could serve as a record of all message transactions and be used as a source of information if the status of a message is under dispute (ex. a recipient clams to not have received a message).” 6. ‘Any Appropriate Way’ RTM 56 Applicability Statement for Secure Health Transport 3.0 Message Disposition Notification “An STA MAY reflect the status indicated by the MDN in any appropriate way back to the original sender Comment: There was confusion surrounding what was meant by ‘any appropriate way’ Mod Spec included the following SME guidance: “Requirement 56 is in reference to the notification to the sender (user/process) when an MDN is received from the receiver. Requirement 49 guarantees that the MDN is sent from the receiver to the sender and Requirement 56 states that once the sender receives the MDN, the processing of it is organization dependent.” 7. ‘Chain Back’ RTM 75 Applicability Statement for Secure Health Transport 4.2.2 Certificate Paths “A given leaf certificate MUST chain back to a trust anchor that is trusted by the STA.” Comment: The term ‘chain back’ is ambiguous and should be further defined for implementers. Mod Spec included the implementation guidance: “RFC 5280 defines the certificate chain, “chain back” is being used here to refer to the fact that the certificate is issued by a CA that is trusted by the STA and is part of its trust anchors.” 8. ‘Appropriate Mechanisms’ RTM 81 Applicability Statement for Secure Health Transport 4.3 Communication of Verification Failures “An STA MUST appropriately communicate and log trust verification failures through appropriate mechanisms.” Comment: There was some confusion as to what constituted ‘appropriate mechanisms’ further definition may be beneficial to implementers. Mod Spec included the following implementation guidance: “It is recommended that trust verification failures be logged in an audit log as part of message processing.” Applicability Statement for Secure Health Transport 6.1.2 Minimal Metadata Definition “Implementations are RECOMMENDED to implement metadata conformance in a way that is open to future modification.”