Framing the Header Encryption Issue

Issue #1: Routing Headers

In all cases, mail servers need to see routing information (e.g., To/From headers) in order to deliver messages. It is unclear if the policy committee will classify these routing headers as PHI, currently it seems likely they will NOT do so.

This policy decision will impact NHIN-D operations, not architecture, in the following way:

1. If routing headers ARE PHI, then all external mail servers must be business associates to their clients, intermediate hops must be disallowed, and all transport channels must be TLS encrypted.
2. If routing headers are NOT PHI, these requirements are greatly relaxed, and more existing server infrastructure is available for use without new relationships.

We will not discuss this further here because it will not impact the work of the implementation teams.

Issue #2: Content Headers

Content headers such as Subject are stickier, because given typical email usage patterns they may well contain PHI. Mail clients also have traditionally encoded additional content metadata in headers; these could contain PHI as well.

The S/MIME standard provides defines two supported models for encryption:

1. MIME entity only. Note this leaves headers unencrypted.
2. FULL MESSAGE. This encrypts the full body and headers

The safest path would be to require FULL MESSAGE encryption for NHIN-D. This effectively takes all content headers “off the table” so we don’t have to worry about future policy decisions at all. However, this choice is in conflict with a desire to use existing off-the-shelf email clients, because across the board they only do MIME encoding, not FULL MESSAGE. So the options are:

Option	Policy Implication	Software Implication
MIME only	Risk that technology may need to be reworked to support future policy mandates.	NHIN-D can be implemented using only off-the-shelf clients available today. Do not expect high adoption of this model (vs. server-side agent) because of certificate management complexity, but it does provide a great option.
FULL MESSAGE	Safe	Kills the “no new software” implementation. Could still use existing clients, but would need a desktop “gateway” to manage encryption.
Punt. Specify that both types are acceptable from a technology point of view and wait for policy	Safe	Higher technology ask for new code, because we have to support two models and configuration to choose between them. May be wasted effort if MIME only option is unacceptable for all policy environments.
Hybrid. Use FULL MESSAGE for all new code on the outbound, but allow (with local policy override) inbound messages in either format to be accepted.	Safe	Basically same as above, but simplifies the technology a bit because we only generate one type.

We will discuss this issue at on our next call on 7/15.