Mod Spec Phase 2 Recommendations for Secure Transport
Overview
As part of its Phase 2 activities, the Modular Specifications Project provided Direct Project with a set of recommendations. The Modular Specifications Project developed these recommendations based on input received from public calls attended by Direct Project participants and on review of the Direct Project specifications. The recommendations were bundled in two documents:
- Mod Spec Recommendations to Direct Minor Clarifications v1.0
- Mod Spec Recommendations to Direct v1.0
The items below are extractions from those documents specific to the Applicability Statement for Secure Health Transport v1.0. Comments and recommendations from the Direct Project group that evaluated these items are listed in red.
Recommendations
Minor Error Corrections and Clarifications
MECC 1
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.
Assessment Group Recommendations:
Current reference is incorrect. Change reference to "RFC 5751 section 2.2" to "RFC 5751 section 2.1".
MECC 2
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.
Assessment Group Recommendations:
Current reference is incorrect. Change reference to "RFC 5751 section 2.1" to "RFC 5751 section 2.2".
MECC 3
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”
Assessment Group Recommendations:
Support change. Change "...the STA MUST confirm receipt" to "...the STA MUST confirm receipt with a disposition notification message".
General Recommendations
GR 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.
Assessment Group Recommendations:
Suggest that Applicability Statement...
1. Clarify that discovery and publishing of certificates using DNS and LDAP must be supported. Two subsections:
- Publishing Certificates: Certificates MUST be published in either DNS or LDAP
- Resolving Certificates: STAs MUST support both DNS and LDAP certificate resolvers
2. Possibly make a reference to the S&I Provider Directories Initiative's Certificate Discovery for Direct Project Implementation Guide.
GR 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.
Assessment Group Recommendations:
References to "pkcs" are typos in the specification. All instances of "pkcs" in the Applicability Statement should be corrected to "pkcs7". Specifically, change:
- Section 2.4: reference to "application/pkcs-mime" to "application/pkcs7-mime"
- Section 2.4: reference to "application/x-pkcs-mime" to "application/x-pkcs7-mime"
- Section 2.5.1: reference to "application/pkcs-signature" to "application/pkcs7-signature"
- Section 2.5.1: reference to "application/x-pkcs-signature" to "application/x-pkcs7-signature"
GR 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.”
Assessment Group Recommendations:
Direct deliberately constrains RFC 5751. The point of the constraint is that MD5 is obsolete, and SHA1 is the minimum bar for Digest Algorithms considered safe by the crypto community. On a side note, it should be noted that even SHA1 is being phased out because of possible (theoretical) concerns; most state of the art systems are moving to SHA256.
The Applicability Statement enumerates the specific Digest Algorithms that must be supported, but simplified language might be helpful in making the point that MD5 is obsolete. Change "STAs MUST NOT support less secure Digest Algorithms, including additional algorithms listed as SHOULD- in RFC 5751 section 2.1 (e.g., MD5)" to "STAs MUST NOT support less secure Digest Algorithms such as MD5."
GR 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.”
Assessment Group Recommendations:
- Add explicit requirements for SMTP and S/MIME support to Applicability Statement.
- Clarify that compliance to Applicability Statement is required for an STA to be considered Direct Project compliant. (Perhaps also add some non-ambiguous wording to XDR and XDM for Direct Messaging specification.)
GR 12: List of valid MIME Bodies
RTM 16 & IG
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.
Assessment Group Recommendations:
Providing a listing of "valid" MIME types is outside the scope of the Applicability Statement.
No change to Applicability Statement is needed.
GR 13: multipart/signed format type
RTM 40
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
Assessment Group Recommendations:
Current Applicability Statement language accurately states multipart/signed is required. Direct deliberately constrains RFC 5751 and requires multipart/signed because:
- All Direct messages are encrypted
- After decryption, the original Direct messages must be viewable by the receiver - independant of the attached signature and even if the signature is not valid. Detached signatures let ordinary mail parsers, or even Notepad suffice as a reading system.
- The SignedData format encloses both the signature and the original data in an enclosing envelope that is not readable - except by using an SMIME/CMS crypto stack. And therefore, not appropriate for Direct.
No change to Applicability Statement is needed.
GR 14: Need for Additional MDN Guidance
- 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.
Assessment Group Recommendations:
Section 3.0 of the Applicability Statement is clear that:
- A Message Disposition Notification (MDN) is required in only one case - if the message was received and trusted by the receiver. (This is a "processed" notification and essentially serves as an ACK.)
- An STA must not ACK an ACK.
- Other MDNs may be sent in other situations, but are not required.
- Every MDN must be a Direct message.
No change to Applicability Statement is needed.
More on MDNs:
Direct requires that communication only occurs between trusted parties. The sender of an UNSIGNED message cannot possibly be trusted. Neither can the sender of an UNENCRYPTED message. Communicating with an untrusted sender -- MDN or otherwise -- may be a security issue. If an STA issued MDNs such as NACKs to any random email messages arriving from the Internet, it could find its mail servers overwhelmed, could find itself used to DOS attack a real Direct node with unasked-for MDNs, etc.
Direct nodes in production often see regular streams of junk mail - mostly from junk mailers -- so these issues are not theoretical.
Large mail providers silently discard junk mail messages - without sending MDNs and ACKs. So should Direct nodes. The Direct Project reference implementations err on the side of caution and do just that.
Language clarification
LC 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.
Assessment Group Recommendations:
Existing language seems clear.
No change to Applicability Statement is needed.
LC 4: ‘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.”
Assessment Group Recommendations:
Context behind this requirement is as follows:
- Alice sends Bob a Direct Message.
- Bob's STA successfully receives the Message and validates trust.
- The Message is then rejected based on local policy governing Bob. For instance...
- Attachment types are not acceptable by Bob.
- Attachments were schema invalid.
- Bob is expecting communications to adhere to a private OVERLAY protocol that allows only XYZ attachments - essentially an API.
- Etc
While a party rejecting a message in this situation must notify the sender that the message is rejected, a particular method for doing so (e.g., an MDN or a Direct message conveying an error code) is not specified in the Applicability Statement, as the particular method may depend on policy or the design of an overlay protocol built upon Direct.
No change to Applicability Statement is needed.
LC 5: 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.”
Assessment Group Recommendations:
LC 6: ‘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).”
Assessment Group Recommendations:
Logging requirements are entirely dependant on the STA's legal, HIPAA, privacy and other requirements. Compliance and the format of audit logs is out of scope of the Applicability Statement; all the Statement can do is recommend that such logs are maintained with enough detail to satisfy such requirements, which only the STA will know.
No change to Applicability Statement is needed.
LC 7: ‘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
Assessment Group Recommendations:
The required MDN type ("processed" MDN) originates with an STA receiving a Direct message and is sent back to the STA that issued the message in question. This particular sentence in the Applicability Statement further details that an STA that receives an MDN may, but is not required, to provide the status indicated by the MDN back to the sender of the original message. "In any appropriate way" is reflective of the fact that whether and how status is provided may be dependent on workflow or other requirements of the sender.
No change to Applicability Statement is needed.
LC 8: ‘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.”
Assessment Group Recommendations:
Clarify the requirement by changing the sentence "A given leaf certificate MUST chain back to a trust anchor that is trusted by the STA" to "The certificate chain of a given leaf certificate MUST include a trust anchor that is trusted by the STA".
LC 9: ‘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.”
Assessment Group Recommendations:
The requirements dictating "appropriate mechanisms" are entirely dependant on the STA's legal, HIPAA, privacy, and policy environment. Only the STA knows what its environment requires.
No change to Applicability Statement is needed.