S&T Header Recommendations for Implementors
Jump to navigation
Jump to search
Because header metadata is a likely target for policy decisions, we felt it was important to call out how headers are dealt with in the S/MIME standard and offer some guidance for implementation teams in their handling of them.
S/MIME Encryption
The S/MIME standard we are using defines two methods for encrypting messages:
1. MIME ONLY encrypts just the message content and MIME headers that describe the content format. All other headers are left in the clear.
2. FULL MESSAGE encrypts the entire message, content and headers, leaving only the routing headers (e.g., TO/FROM) in the clear.
Off-the-shelf clients today tend to support sending using the MIME ONLY approach, and can receive either type, although FULL MESSAGE encrypted files appear as an empty message with the “real” message as an attachment.
Implications
Header information may be considered PHI. We will not delve into the arguments for and against this --- we simply are recognizing that it is a likely case that in some environments headers will be classified this way.
There are a number of ways to deal with the issue of protecting the content of headers. For example:
1. Simply dictate that no PHI may be placed in headers. This can be automated in new code, and made a user mandate for those using existing email clients.
2. Require FULL MESSAGE encryption on all messages.
Both of these have pros and cons, and there are likely other approaches. Our recommendation is that we create software that can support the variety of environments various policy choices may create.
Recommendation
We recommend that new implementations:
· Be capable of encrypting using either technique, configurable by the system administrator.
· Be capable of decrypting using either technique, configurable by the system administrator.
· Discourage the use of PHI in header information, for example by automatically creating useful but PHI-limited subject headers, e.g., “Endocrine test results for patient ordered 7/10/2010” rather than “Test results for patient John Smith”.
S/MIME Encryption
The S/MIME standard we are using defines two methods for encrypting messages:
1. MIME ONLY encrypts just the message content and MIME headers that describe the content format. All other headers are left in the clear.
2. FULL MESSAGE encrypts the entire message, content and headers, leaving only the routing headers (e.g., TO/FROM) in the clear.
Off-the-shelf clients today tend to support sending using the MIME ONLY approach, and can receive either type, although FULL MESSAGE encrypted files appear as an empty message with the “real” message as an attachment.
Implications
Header information may be considered PHI. We will not delve into the arguments for and against this --- we simply are recognizing that it is a likely case that in some environments headers will be classified this way.
There are a number of ways to deal with the issue of protecting the content of headers. For example:
1. Simply dictate that no PHI may be placed in headers. This can be automated in new code, and made a user mandate for those using existing email clients.
2. Require FULL MESSAGE encryption on all messages.
Both of these have pros and cons, and there are likely other approaches. Our recommendation is that we create software that can support the variety of environments various policy choices may create.
Recommendation
We recommend that new implementations:
· Be capable of encrypting using either technique, configurable by the system administrator.
· Be capable of decrypting using either technique, configurable by the system administrator.
· Discourage the use of PHI in header information, for example by automatically creating useful but PHI-limited subject headers, e.g., “Endocrine test results for patient ordered 7/10/2010” rather than “Test results for patient John Smith”.