idnits 2.17.1 draft-myers-mime-md5-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1995) is 10418 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1521 (ref. '1') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '2') ** Downref: Normative reference to an Historic RFC: RFC 1421 (ref. '3') Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Myers 3 Internet Draft: draft-myers-mime-md5-00.txt Carnegie Mellon 4 Expires in six months M. Rose 5 Dover Beach Consulting, Inc. 6 October 1995 8 The Content-MD5 Header Field 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It 19 is inappropriate to use Internet Drafts as reference material or to 20 cite them other than as a work in progress. 22 Abstract 24 This memo specifies an optional header field, Content-MD5, for use 25 with MIME-conformant messages. 27 Internet DRAFT POP3 October 1, 1995 29 1. Introduction 31 Despite all of the mechanisms provided by MIME [1] which attempt to 32 protect data from being damaged in the course of email transport, it 33 is still desirable to have a mechanism for verifying that the data, 34 once decoded, are intact. For this reason, this memo defines the use 35 of an optional header field, Content-MD5, which may be used as a 36 message integrity check (MIC), to verify that the decoded data are 37 the same data that were initially sent. 39 MD5 is an algorithm for computing a 128 bit "digest" of arbitrary- 40 length data, with a high degree of confidence that any alterations in 41 the data will be reflected in alterations in the digest. The MD5 42 algorithm itself is defined in [2]. This memo specifies how the 43 algorithm may be used as an integrity check for MIME mail. 45 2. Generation of the Content-MD5 Field 47 The Content-MD5 field is generated by only an originating user agent. 48 Message relays and gateways are expressly forbidden from generating a 49 Content-MD5 field. 51 Use of the Content-MD5 field is completely optional, but its use is 52 recommended whenever data integrity is desired, but Privacy-Enhanced 53 Mail services [3] are not available. (Consult Section 4 for further 54 details.) The Content-MD5 field may only be added to MIME entities of 55 a `leaf' nature, i.e., the Content-MD5 field may be used with any 56 content type other than multipart or message/rfc822. 58 To generate the value of the Content-MD5 field, the MD5 algorithm is 59 computed on the canonical form of the MIME entity's object. In 60 particular, this means that the sender applies the MD5 algorithm on 61 the data immediately after conversion to canonical form, before 62 applying any content-transfer-encoding, and that the receiver also 63 applies the MD5 algorithm on the canonical form, after undoing any 64 content-transfer-encoding. For textual data, this means the MD5 65 algorithm must be computed on data in which the canonical form for 66 newlines applies, that is, in which each newline is represented by a 67 CR-LF pair. The canonical encoding model of MIME is described in 68 Appendix G of [1]. 70 The output of the MD5 algorithm is a 128 bit digest. When viewed in 71 network byte order (big-endian order), this yields a sequence of 16 72 octets of binary data. These 16 octets are then encoded according to 73 the base64 algorithm in order to obtain the value that is placed in 74 the Content-MD5 field. Thus, if the application of the MD5 algorithm 75 over the raw data of a MIME entity results in a digest having the 76 (unlikely) value of "Check Integrity!", then that MIME entity's 78 Internet DRAFT POP3 October 1, 1995 80 header could contain the field 82 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== 84 Finally, as discussed in Appendix B of [1], textual data is regularly 85 altered in the normal delivery of mail. Because the addition or 86 deletion of trailing white space will result in a different digest, 87 either the quoted-printable or base64 algorithm should be employed as 88 a content-transfer-encoding when the Content-MD5 field is used. 90 3. Processing the Content-MD5 field 92 If the Content-MD5 field is present, a recipient user agent may 93 choose to use it to verify that the contents of a MIME entity have 94 not been modified during transport. Message relays and gateways are 95 expressly forbidden to alter its processing based on the presence of 96 the Content-MD5 field. However, a message gateway is allowed to 97 remove the Content-MD5 field if the corresponding MIME entity is 98 translated into a different content-type. 100 4. Security Considerations 102 This document specifies a data integrity service that protects data 103 from accidental modification while in transit from the sender to the 104 recipient. A secure data integrity service, such as that provided by 105 Privacy Enhanced Mail [3], is conjectured to protect data from all 106 modifications. 108 5. Acknowledgements 110 This memo is based almost entirely on text originally written by 111 Nathaniel Borenstein of Bellcore. In addition, several improvements 112 were suggested by Keith Moore of the University of Tennessee, 113 Knoxville. 115 6. References 117 [1] N. Borenstein, N. Freed. MIME: Mechanisms for Specifying and 118 Describing the Format of Internet Message Bodies. Request for 119 Comments 1521, (September, 1993). 121 [2] R. Rivest, The MD5 Message-Digest Algorithm. Request for 122 Comments 1321, (April, 1992). 124 [3] J. Linn, Privacy Enhancement for Internet Electronic Mail, Part 125 I: Message Encryption and Authentication Procedures. Request for 126 Comments 1421, (February, 1993). 128 Internet DRAFT POP3 October 1, 1995 130 7. Authors' Addresses 132 John G. Myers 133 Carnegie Mellon University 134 jgm+@cmu.edu 136 Marshall T. Rose 137 Dover Beach Consulting, Inc. 138 mrose@dbc.mtview.ca.us 140 Internet DRAFT POP3 October 1, 1995 142 Table of Contents 144 Status of this Memo ............................................... i 145 Abstract .......................................................... i 146 1. Introduction ................................................... 2 147 2. Generation of the Content-MD5 Field ............................ 2 148 3. Processing the Content-MD5 field ............................... 3 149 4. Security Considerations ........................................ 3 150 5. Acknowledgements ............................................... 3 151 6. References ..................................................... 3 152 7. Authors' Addresses ............................................. 4