Corrections and Clarifications to Applicability Statement for Secure Health Transport v1
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 recommendations relating to the Applicability Statement for Secure Health Transport v1.0 were initially reviewed by Direct Project members who participated in the creation of the Applicability Statement, and were then discussed further within the Direct Project Reference Implementation Workgroup and Implementation Geographies Workgroup. Assessment of those recommendations have led to the workgroups agreeing that certain errors and typos should be corrected and certain language clarified within the Applicability Statement for Secure Health Transport v1.0. These items are listed below.
Corrections and Clarifications
1. Correction to RFC section reference in Section 2.6 Digest Algorithms
Current Text
Section 2.6 Digest Algorithms states:
STAs MAY support more secure Digest Algorithms, as listed as SHOULD+ in RFC 5751 section 2.2
Mod Spec Comments
RFC 5751 section 2.2 is “SignatureAlgorithmIdentifier,” section 2.1 “DigestAlgorithmIdentifier” is the correct reference for this statement.
Source: Mod Spec Recommendations to Direct Minor Clarifications v1.0, Minor Error Corrections and Clarifications #1
Recommendation
Current text is in error. Change reference to "RFC 5751 section 2.2" to "RFC 5751 section 2.1".
2. Correction to RFC section reference in Section 2.7 Encryption Algorithms
Current Text
Section 2.7 Encryption Algorithms states:
STAs MAY support more secure Encryption Algorithms, as listed as SHOULD+ in RFC 5751 section 2.1
Mod Spec Comments
RFC 5751 section 2.1 is “DigestAlgorithmIdentifier,” section 2.2 “SignatureAlgorithmIdentifier,” is the correct reference for this statement.
Source: Mod Spec Recommendations to Direct Minor Clarifications v1.0, Minor Error Corrections and Clarifications #2
Recommendation
Current text is in error. Change reference to "RFC 5751 section 2.1" to "RFC 5751 section 2.2".
3. Clarification to receipt confirmation in Section 3.0 Message Disposition Notification
Current Text
Section 3.0 Message Disposition Notification states:
That is, even if disposition notification was not specifically requested, the STA MUST confirm receipt.
Mod Spec Comments
Mod Spec added clarifying text, "…the STA MUST confirm receipt with a disposition notification message."
Source: Mod Spec Recommendations to Direct Minor Clarifications v1.0, Minor Error Corrections and Clarifications #3
Recommendation
Change "...the STA MUST confirm receipt" to "...the STA MUST confirm receipt with a disposition notification message".
4. Correction to pkcs references
Current Text
Section 2.4 Signed and Encrypted Health Content Containers states:
[STAs] 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) ...
Section 2.5.1 Detached Signatures states:
[STAs MUST use] 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.
Mod Spec Comments
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 (e.g., "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."
Source: Mod Spec Recommendations to Direct v1.0, General Recommendations #2
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"
5. Clarification on Supported Digest Algorithms
Current Text
Section 2.6 Digest Algorithms states:
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)
Mod Spec Comments
SHA1 is listed as required, but is mentioned as SHOULD- in RFC 5751 which indicates that it should not be supported. This contradiction should be clarified. Mod Spec included the following implementation guidance:
“Direct implementations should follow the guidance in requirement 43 and support SHA1.”
Source: Mod Spec Recommendations to Direct v1.0, General Recommendations #3
Recommendations
The point of the constraints on RFC 5751 is that MD5 is obsolete, and SHA1 is the minimum bar for Digest Algorithms considered safe by the crypto community. While the Applicability Statement enumerates the specific Digest Algorithms that must be supported, simplified language would be helpful in making the point that SHA1 is supported but 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."
6. Correction around inclusion of root CA in certificate chain of message signature
Current Text
Section 2.5.2 Certificates in Signatures states:
Signatures MUST include the signing certificate and the full certificate chain up to the root CA ...
Section 4.2.2 Certificate Paths states:
For received messages, the message signature MUST include the full certificate chain.
Mod Spec Comments
The phrase "the root CA" may be interpreted 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 constraint 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."
Source: Mod Spec Recommendations to Direct v1.0, Language Clarifications #5
Recommendations
Current text is in error. These two references should be corrected as follows:
Section 2.5.2:
Change "Signatures MUST include the signing certificate and the full certificate chain up to the root CA ..." to "Signatures MUST include the signing certificate ..."
Section 4.2.2:
Change "For received messages, the message signature MUST include the full certificate chain" to "For received messages, the message signature MUST contain the signing certificate and implementations MUST construct and verify the full certificate path of the signing certificate."
7. Clarification of "chain back" in Section 4.2.2 Certificate Paths
Current Text
Section 4.2.2 Certificate Paths states:
A given leaf certificate MUST chain back to a trust anchor that is trusted by the STA.
Mod Spec Comments
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.”
Source: Mod Spec Recommendations to Direct v1.0, Language Clarifications #8