1. Applicability Statement v1.1 Feedback: DirectTrust May 5, 2015

2. Applicability Statement v1.1 Feedback 2 »The following feedback related to the Applicability Statement v1.1 was received from DirectTrust. »Viewpoints and any recommendations suggested are DirectTrust’s own and do not necessarily reflect Direct Project consensus.

3. 3 DirectTrust Feedback

4. Terms 4 »AS: Applicability Statement »DNIG: Implementation Guide for Delivery Notification in Direct »DSN: Delivery Status Notification »HISP: Health Information Service Provider »MDN: Message Delivery Notification »STA: Security/Trust Agent »TTT: ONC Transport Test Tool

5. Issue: Sending of Processed MDNs 5 Recommendation: AS Section 3 should clarify when a Processed MDN should be sent. It should clarify that transmission of a Processed MDN indicates that the receiving STA is taking responsibility to attempt delivery to the specified recipient, rather than responsibility to deliver, and that receipt of a Processed MDN does not guarantee that final delivery was made (if such guarantee is required, the mechanisms defined in the DNIG should be used). Background: Some HISPs have cited the AS assertion in Section 3.0 that sending a Processed MDN constitutes accepting responsibility to deliver a message as a reason to delay transmission of the Processed MDN, sometimes until after the recipient reads the message. The AS should be clarified to indicate that the transmission constitutes acceptance of responsibility to attempt delivery, and if guarantees for final delivery are needed, the mechanisms defined in the DNIG should be used.

6. Issue: Other Notifications After Processed MDN 6 Recommendation: AS Section 3 should clarify the notification requirements and mechanisms when message delivery does not succeed, including notifications that may arise after an initial Processed MDN is sent, or when message payload cannot be processed. Cases where a message contains more than one payload or payload type, and not all content could be understood, should also be considered. Background: »Many HISP and/or edge systems will handle a delayed failure such as subsequent rejection of a message by the edge client by sending a Failed MDN or DSN at the time that the subsequent failure occurs. However, the AS does not provide a mechanism for the confirmation of receipt of such delayed failure notifications, and unlike the initial Processed MDN, the original sender is not expecting it as a guaranteed part of the protocol, so there is no way to be certain that the original sender ever receives it. For example, if a delayed, Failed MDN or DSN is lost in transit, there would be no way for the original sender to know it was sent by the recipient or the recipient’s HISP, nor for the recipient to know it was not received by the original sender. Extending the AS to address this limitation would improve the robustness of these delayed notification mechanisms. »A Processed MDN may be returned even when the message payload is delivered but cannot be consumed, which may be misleading to the sending system, and may even lead to failures in care coordination among providers. Some HISPs and edge systems are actively communicating payload- related failure notifications, but this is not yet standardized. Additional clarification on when to return a Processed MDN or the communication of failures after a Processed MDN has been sent is necessary, to eliminate this ambiguity.

7. Issue: MDNs and null envelope sender 7 Recommendation: AS Section 3 should clarify if a null SMTP MAIL FROM envelope is acceptable for MDNs. Background: MDNs in the field commonly have the original recipient's Direct address in the SMTP MAIL FROM envelope (per recommendation for Direct messages in AS Section 2.2), whereas RFC 3798 Section 3 requires a null SMTP MAIL FROM envelope for all MDNs. TTT used to (probably still does) break if MDN with spec- compliant null envelope sender is received. AS IGW group may wish to formalize whether this is ok or not ok.

8. Issue: Use of AIA certificate extension 8 Recommendation: The use of the Authority Information Access (AIA) extension in Direct certificates should be upgraded in Section 4.2.2 from a recommendation to a requirement (i.e., from RECOMMENDED to MUST), at least for certification hierarchies that include intermediate Certification Authorities (CAs) that may not initially be known to counter parties. Background: Interoperability problems can occur when CAs omit or do not properly populate the Authority Information Access (AIA) extension of a certificate such that a relying party does not have sufficient information to build a certificate chain from an end entity certificate to an issuing CA when intermediate CA certificates are not known to the relying party. AS Section 4.2.2 currently recommends inclusion of AIA information but could be revised to require it in cases where intermediate CAs are used.

9. Additional Items for Discussion 9 1.While well-defined by the specs, we see miscomputed message digests in the field sometimes when messages contain text/* parts. Don't know if this warrants an AS change but is worth mentioning in the AS IGW call for comment or reference. 2.Confusion in field about what it means to perform revocation checking as per AS Section 4. Might require clarification. 3.Mixed use domains (e.g., domain-bound cert for jack.direct.com and address- bound cert for jack@direct.com) can cause ambiguities - worth mentioning in the AS practice note that talks about email addresses with periods in them? 4.Specific call out of self-signed certs in trust section -- necessary/useful? 5.Unwrapped messages are subject to header re-writing attacks and exposure of unencrypted headers including Subject header text or potentially sensitive routing info. DirectTrust requires wrapping for all sent messages. Should the AS try to close this security issue by requiring wrapping?

10. 10 Parking Lot

11. Open Items 11 Items 1-2 are from DCDT feedback discussion. 1.Continued use of SHA-1? 2.Change “organizationally-bound” to “domain-bound” throughout AS?