The Content-MD5 Header Field
An optional MIME field that carries a digest for checking whether content changed in transit.
Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, DOI 10.17487/RFC1864, October 1995, <https://www.rfc-editor.org/info/rfc1864>.
@misc{rfc1864,
series = {Request for Comments},
number = 1864,
howpublished = {RFC 1864},
publisher = {RFC Editor},
doi = {10.17487/RFC1864},
url = {https://www.rfc-editor.org/info/rfc1864},
author = {J. Myers and M. Rose},
title = {{The Content-MD5 Header Field}},
pagetotal = 4,
year = 1995,
month = oct,
} RFC text
Contents
Network Working Group J. Myers
Request For Comments: 1864 Carnegie Mellon
Obsoletes: 1544 M. Rose
Dover Beach Consulting, Inc.
October 1995
The Content-MD5 Header Field
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This memo specifies an optional header field, Content-MD5, for use
with MIME-conformant messages.
Table of Contents
1. Introduction .............................................. 1
2. Generation of the Content-MD5 Field ....................... 2
3. Processing the Content-MD5 field .......................... 3
4. Security Considerations ................................... 3
5. Acknowledgements .......................................... 3
6. References ................................................ 3
7. Authors' Addresses ........................................ 4
1. Introduction
Despite all of the mechanisms provided by MIME [1] which attempt to
protect data from being damaged in the course of email transport, it
is still desirable to have a mechanism for verifying that the data,
once decoded, are intact. For this reason, this memo defines the use
of an optional header field, Content-MD5, which may be used as a
message integrity check (MIC), to verify that the decoded data are
the same data that were initially sent. The Content-MD5 header may
also be placed in the encapsulated headers of an object of type
message/external-body, to be used to verify that the retreived and
decoded data are the same data that were initially referenced.
MD5 is an algorithm for computing a 128 bit "digest" of arbitrary-
length data, with a high degree of confidence that any alterations in
the data will be reflected in alterations in the digest. The MD5
algorithm itself is defined in [2]. This memo specifies how the
algorithm may be used as an integrity check for MIME mail.
2. Generation of the Content-MD5 Field
The Content-MD5 field is generated by only an originating user agent.
Message relays and gateways are expressly forbidden from generating a
Content-MD5 field.
Use of the Content-MD5 field is completely optional, but its use is
recommended whenever data integrity is desired, but Privacy-Enhanced
Mail services [3] are not available. (Consult Section 4 for further
details.) The Content-MD5 field may only be added to MIME entities of
a `leaf' nature, i.e., the Content-MD5 field may be used with any
content type other than multipart or message/rfc822.
To generate the value of the Content-MD5 field, the MD5 algorithm is
computed on the canonical form of the MIME entity's object. In
particular, this means that the sender applies the MD5 algorithm on
the data immediately after conversion to canonical form, before
applying any content-transfer-encoding, and that the receiver also
applies the MD5 algorithm on the canonical form, after undoing any
content-transfer-encoding. For textual data, this means the MD5
algorithm must be computed on data in which the canonical form for
newlines applies, that is, in which each newline is represented by a
CR-LF pair. The canonical encoding model of MIME is described in
Appendix G of [1].
The output of the MD5 algorithm is a 128 bit digest. When viewed in
network byte order (big-endian order), this yields a sequence of 16
octets of binary data. These 16 octets are then encoded according to
the base64 algorithm in order to obtain the value that is placed in
the Content-MD5 field. Thus, if the application of the MD5 algorithm
over the raw data of a MIME entity results in a digest having the
(unlikely) value of "Check Integrity!", then that MIME entity's
header could contain the field
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Finally, as discussed in Appendix B of [1], textual data is regularly
altered in the normal delivery of mail. Because the addition or
deletion of trailing white space will result in a different digest,
either the quoted-printable or base64 algorithm should be employed as
a content-transfer-encoding when the Content-MD5 field is used.
3. Processing the Content-MD5 field
If the Content-MD5 field is present, a recipient user agent may
choose to use it to verify that the contents of a MIME entity have
not been modified during transport. Message relays and gateways are
expressly forbidden to alter their processing based on the presence
of the Content-MD5 field. However, a message gateway is allowed to
remove the Content-MD5 field if the corresponding MIME entity is
translated into a different content-type.
4. Security Considerations
This document specifies a data integrity service that protects data
from accidental modification while in transit from the sender to the
recipient. A secure data integrity service, such as that provided by
Privacy Enhanced Mail [3], is conjectured to protect data from all
modifications.
5. Acknowledgements
This memo is based almost entirely on text originally written by
Nathaniel Borenstein of Bellcore. In addition, several improvements
were suggested by Keith Moore of the University of Tennessee,
Knoxville.
6. References
[1] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, Bellcore,
Innosoft, September 1993.
[2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
Laboratory for Computer Science and RSA Data Security, Inc.,
April 1992.
[3] Linn, J., "Privacy Enhancement for Internet Electronic Mail, Part
I: Message Encryption and Authentication Procedures", RFC 1421,
IAB IRTF PSRG, IETF PEM WG, February 1993.
7. Authors' Addresses
John G. Myers
Carnegie Mellon University
EMail: jgm+@cmu.edu
Marshall T. Rose
Dover Beach Consulting, Inc.
EMail: mrose@dbc.mtview.ca.us
ISO Plain Language
On this page
§1A Check for Changed Message Content
MIME has mechanisms intended to protect data during email transport, but a receiver may still want to check that decoded data match what was sent. RFC 1864 defines the optional Content-MD5 header field for this purpose. The field may also be placed in the encapsulated headers of a message/external-body object to check retrieved and decoded data.
MD5 computes a 128-bit digest from data of any length. This memo specifies its use for MIME mail; it does not define the MD5 algorithm itself.
Content-MD5 gives a recipient a way to check whether MIME content changed in transit. It carries a short digest made from the content, not from the encoded form sent through email.
§2How the Sender Makes the Field
Only the originating user agent generates Content-MD5. Message relays and gateways must not generate it. The field is optional and may be added only to a MIME entity that is not a multipart entity or a message/rfc822 entity.
The sender computes MD5 on the entity's canonical form, before applying content-transfer-encoding. For text, canonical newlines use a carriage return followed by a line feed. The digest is 128 bits, or 16 octets, viewed in network byte order; the sender encodes those octets with base64 for the field value. The RFC says quoted-printable or base64 transfer encoding should be used because adding or removing trailing white space changes the digest.
The sender's mail program makes the digest from the content in its standard form, before encoding it for delivery. It then puts the base64 version of that digest in the header.
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==§3How the Recipient Checks the Field
When Content-MD5 is present, a recipient user agent may use it to check whether the MIME entity changed during transport. The recipient first undoes any content-transfer-encoding, computes MD5 on the canonical form, and can compare the result with the field value.
Relays and gateways must not change how they process a message because Content-MD5 is present. A gateway may remove the field if it translates the entity to a different content type.
The recipient can decode the content, make the same digest, and compare the result with the header. Mail relays must not change their handling because the field is present.
§4What the Integrity Check Does Not Protect
The RFC describes Content-MD5 as protection against accidental modification while data travel from sender to recipient. It distinguishes this from a secure data-integrity service, such as the one provided by Privacy-Enhanced Mail, which it says is intended to protect against all modifications.
Content-MD5 can help reveal accidental changes. The RFC does not present it as protection against someone deliberately changing the content.