home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1544 < prev    next >
Text File  |  1993-11-10  |  6KB  |  172 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            M. Rose
  8. Request for Comments: 1544                  Dover Beach Consulting, Inc.
  9. Category: Standards Track                                  November 1993
  10.  
  11.  
  12.                       The Content-MD5 Header Field
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This memo specifies an optional header field, Content-MD5, for use
  25.    with MIME-conformant messages.
  26.  
  27. Table of Contents
  28.  
  29.    1. Introduction ..........................................    1
  30.    2. Generation of the Content-MD5 Field ...................    2
  31.    3. Processing the Content-MD5 field ......................    2
  32.    4. Security Considerations ...............................    3
  33.    5. Acknowledgements ......................................    3
  34.    6. References ............................................    3
  35.    7. Author's Address ......................................    3
  36.  
  37. 1.  Introduction
  38.  
  39.    Despite all of the mechanisms provided by MIME [1] which attempt to
  40.    protect data from being damaged in the course of email transport, it
  41.    is still desirable to have a mechanism for verifying that the data,
  42.    once decoded, are intact.  For this reason, this memo defines the use
  43.    of an optional header field, Content-MD5, which may be used as a
  44.    message integrity check (MIC), to verify that the decoded data are
  45.    the same data that were initially sent.
  46.  
  47.    MD5 is an algorithm for computing a 128 bit "digest" of arbitrary-
  48.    length data, with a high degree of confidence that any alterations in
  49.    the data will be reflected in alterations in the digest.  The MD5
  50.    algorithm itself is defined in [2].  This memo specifies how the
  51.    algorithm may be used as an integrity check for MIME mail.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Rose                                                            [Page 1]
  59.  
  60. RFC 1544                Content-MD5 Header Field           November 1993
  61.  
  62.  
  63. 2.  Generation of the Content-MD5 Field
  64.  
  65.    The Content-MD5 field is generated by only an originating user agent.
  66.    Message relays and gateways are expressly forbidden from generating a
  67.    Content-MD5 field.
  68.  
  69.    Use of the Content-MD5 field is completely optional, but its use is
  70.    recommended whenever data integrity is desired, but Privacy-Enhanced
  71.    Mail services [3] are not available.  (Consult Section 4 for further
  72.    details.) The Content-MD5 field may only be added to MIME entities of
  73.    a `leaf' nature, i.e., the Content-MD5 field may be used with any
  74.    content type other than multipart or message/rfc822.
  75.  
  76.    To generate the value of the Content-MD5 field, the MD5 algorithm is
  77.    computed on the canonical form of the data.  In particular, this
  78.    means that the sender applies the MD5 algorithm on the raw data,
  79.    before applying any content-transfer-encoding, and that the receiver
  80.    also applies the MD5 algorithm on the raw data, after undoing any
  81.    content-transfer-encoding.  For textual data, the MD5 algorithm must
  82.    be computed on data in which the canonical form for newlines applies,
  83.    that is, in which each newline is represented by a CR-LF pair.
  84.  
  85.    The output of the MD5 algorithm is a 128 bit digest.  When viewed in
  86.    network byte order (big-endian order), this yields a sequence of 16
  87.    octets of binary data.  These 16 octets are then encoded according to
  88.    the base64 algorithm in order to obtain the value that is placed in
  89.    the Content-MD5 field.  Thus, if the application of the MD5 algorithm
  90.    over the raw data of a MIME entity results in a digest having the
  91.    (unlikely) value of "Check Integrity!", then that MIME entity's
  92.    header could contain the field
  93.  
  94.                Content-MD5:  Q2hlY2sgSW50ZWdyaXR5IQ==
  95.  
  96.    Finally, as discussed in Appendix B of [1], textual data is regularly
  97.    altered in the normal delivery of mail.  Because the addition or
  98.    deletion of trailing white space will result in a different digest,
  99.    either the quoted-printable or base64 algorithm should be employed as
  100.    a content-transfer-encoding when the Content-MD5 field is used.
  101.  
  102. 3.  Processing the Content-MD5 field
  103.  
  104.    If the Content-MD5 field is present, a recipient user agent may
  105.    choose to use it to verify that the contents of a MIME entity have
  106.    not been modified during transport.  Message relays and gateways are
  107.    expressly forbidden to alter its processing based on the presence of
  108.    the Content-MD5 field.  However, a message gateway is allowed to
  109.    remove the Content-MD5 field if the corresponding MIME entity is
  110.    translated into a different content-type.
  111.  
  112.  
  113.  
  114. Rose                                                            [Page 2]
  115.  
  116. RFC 1544                Content-MD5 Header Field           November 1993
  117.  
  118.  
  119. 4.  Security Considerations
  120.  
  121.    This document specifies a data integrity service that protects data
  122.    from accidental modification while in transit from the sender to the
  123.    recipient.  A secure data integrity service, such as that provided by
  124.    Privacy Enhanced Mail [3], is conjectured to protect data from all
  125.    modifications.
  126.  
  127. 5.  Acknowledgements
  128.  
  129.    This memo is based almost entirely on text originally written by
  130.    Nathaniel Borenstein of Bellcore.  In addition, several improvements
  131.    were suggested by Keith Moore of the University of Tennessee,
  132.    Knoxville.
  133.  
  134. 6.  References
  135.  
  136.    [1] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
  137.        Extensions) Part One: Mechanisms for Specifying and Describing
  138.        the Format of Internet Message Bodies", RFC 1521, Bellcore,
  139.        Innosoft, September 1993.
  140.  
  141.    [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
  142.        Laboratory for Computer Science and RSA Data Security, Inc.,
  143.        April 1992.
  144.  
  145.    [3] Linn, J., "Privacy Enhancement for Internet Electronic Mail, Part
  146.        I: Message Encryption and Authentication Procedures", RFC 1421,
  147.        IAB IRTF PSRG, IETF PEM WG, February 1993.
  148.  
  149. 7.  Author's Address
  150.  
  151.    Marshall T. Rose
  152.    Dover Beach Consulting, Inc.
  153.    420 Whisman Court
  154.    Mountain View, CA 94043-2112
  155.  
  156.    Phone: (415) 968-1052
  157.    EMail: mrose@dbc.mtview.ca.us
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Rose                                                            [Page 3]
  171.  
  172.