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.”