A.
General Recommendations .............................................................................................................................. 3
1.
Certificate Discovery .................................................................................................................................. 3
2.
Type pkcs ................................................................................................................................................... 3
3.
Support of SHA 1 ....................................................................................................................................... 3
4.
SMTP TO and RCPT FROM SMTP commands ........................................................................................ 4
5.
confidentialityCodes ................................................................................................................................... 4
6.
Optionality of XDR/XDM Conversions ..................................................................................................... 4
7.
SMTP and S/MIME as Direct compliant baseline ...................................................................................... 4
B.
Language clarification ..................................................................................................................................... 5
1.
‘STA v. Implementation’ ............................................................................................................................ 5
2.
‘Vouch’ ....................................................................................................................................................... 5
3.
‘Appropriate Error Notification’ ................................................................................................................. 5
4.
‘Root CA’ ................................................................................................................................................... 6
5.
‘Appropriate Audit Logs’ ........................................................................................................................... 6
6.
‘Any Appropriate Way’ .............................................................................................................................. 6
7.
‘Chain Back’ ............................................................................................................................................... 6
8.
‘Appropriate Mechanisms’ ......................................................................................................................... 7
C.
Minor Clarifications and Typos....................................................................................................................... 7
1.
1 .................................................................................................................................................................. 7
2.
2 .................................................................................................................................................................. 7
3.
3 .................................................................................................................................................................. 7
4.
4 .................................................................................................................................................................. 7
Version
0.1
0.2
Date
10/7/2011
10/14/2011
Changed By
Deloitte
Deloitte
Description
Initial documentation
Added ‘SMTP and S/MIME as Direct compliant baseline’

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.
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.
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.”
RTM 95
XDR and XDM for Direct Messaging 4.3 Transport conversion from SMTP to SOAP
“Addressing lists MUST be taken from SMTP TO and RCPT FROM SMTP commands.”
RTM 106
XDR and XDM for Direct Messaging 4.4 Transport conversion from SOAP to SMTP
“….The SMTP TO and RCPT FROM commands MUST carry the recipients and sender of the transaction…”
Comment : "SMTP TO" and "RCPT FROM SMTP" are not mentioned in the underlying RFC specifications (RFC
5321). The examples in the Direct specs include:
“MAIL FROM: <drjones@direct.sunnyfamily.example.org>
RCPT TO: <drsmith@direct.happyvalley.example.com>”
The Spec Team received the guidance “RFC's have the RCPT TO and MAIL FROM commands which is what should be used.” The Mod Spec includes the corrected commands in requirements 95 and 106.
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.
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.
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.”
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.
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.
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.
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.”
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. we included the implementation guidance”
“There is no single CA, there can be many CA's. The Root CA in this case is the CA that issued the certificate to the end points. If an intermediate CA is used for this purpose, then the root CA of the intermediate CA also needs to be included so that receiver can verify.”
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).”
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.”
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.”

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.”
RTM 45
Applicability Statement for Secure Health Transport 2.6 Digest Algorithms
“STAs MAY support more secure Digest Algorithms, as listed as SHOULD+ in RFC 5751 section 2.2”
Comment : RFC 5751 section 2.2 is “SignatureAlgorithmIdentifier,” section 2.1 “DigestAlgorithmIdentifier” is the correct reference for this statement.
RTM 48
Applicability Statement for Secure Health Transport 2.7 Encryption Algorithms
“STAs MAY support more secure Encryption Algorithms, as listed as SHOULD+ in RFC 5751 section 2.1”
Comment : RFC 5751 section 2.1 is “DigestAlgorithmIdentifier,” section 2.2 “SignatureAlgorithmIdentifier,” is the correct reference for this statement.
RTM 51
Applicability Statement for Secure Health Transport section 3.0 Message Disposition Notification
“That is, even if disposition notification was not specifically requested, the STA MUST confirm receipt.”
Comment : Mod Spec added clarifying text “….the STA MUST confirm receipt with a disposition notification message”
RTM 99
XDR and XDM for Direct Messaging 4.3 Transport conversion from SMTP to SOAP
“The Web Services address is used to identifier the SOAP endput for the XDR message.”
Comment : “The Web Services address is used to identify the SOAP endpoint for the XDR message.