As per Relevance of the word canonical, we have this rfc below:
Network Working Group J.
Request For Comments: 1864 Carnegie
Obsoletes: 1544 M.
Dover Beach Consulting, Inc
October 1995
The Content-MD5 Header
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This memo specifies an optional header field, Content-MD5, for
with MIME-conformant messages
Table of
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.
Despite all of the mechanisms provided by MIME [1] which attempt
protect data from being damaged in the course of email transport,
is still desirable to have a mechanism for verifying that the data
once decoded, are intact. For this reason, this memo defines the
of an optional header field, Content-MD5, which may be used as
message integrity check (MIC), to verify that the decoded data
the same data that were initially sent. The Content-MD5 header
also be placed in the encapsulated headers of an object of
message/external-body, to be used to verify that the retreived
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
the data will be reflected in alterations in the digest. The MD
Myers & Rose Standards Track [Page 1]
RFC 1864 Content-MD5 Header Field October 1995
algorithm itself is defined in [2]. This memo specifies how
algorithm may be used as an integrity check for MIME mail
2. Generation of the Content-MD5
The Content-MD5 field is generated by only an originating user agent
Message relays and gateways are expressly forbidden from generating
Content-MD5 field
Use of the Content-MD5 field is completely optional, but its use
recommended whenever data integrity is desired, but Privacy-
Mail services [3] are not available. (Consult Section 4 for
details.) The Content-MD5 field may only be added to MIME entities
a `leaf' nature, i.e., the Content-MD5 field may be used with
content type other than multipart or message/rfc822.
To generate the value of the Content-MD5 field, the MD5 algorithm
computed on the canonical form of the MIME entity's object.
particular, this means that the sender applies the MD5 algorithm
the data immediately after conversion to canonical form,
applying any content-transfer-encoding, and that the receiver
applies the MD5 algorithm on the canonical form, after undoing
content-transfer-encoding. For textual data, this means the MD
algorithm must be computed on data in which the canonical form
newlines applies, that is, in which each newline is represented by
CR-LF pair. The canonical encoding model of MIME is described
Appendix G of [1].
The output of the MD5 algorithm is a 128 bit digest. When viewed
network byte order (big-endian order), this yields a sequence of 16
octets of binary data. These 16 octets are then encoded according
the base64 algorithm in order to obtain the value that is placed
the Content-MD5 field. Thus, if the application of the MD5
over the raw data of a MIME entity results in a digest having
(unlikely) value of "Check Integrity!", then that MIME entity'
header could contain the
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Finally, as discussed in Appendix B of [1], textual data is
altered in the normal delivery of mail. Because the addition
deletion of trailing white space will result in a different digest
either the quoted-printable or base64 algorithm should be employed
a content-transfer-encoding when the Content-MD5 field is used
Myers & Rose Standards Track [Page 2]
RFC 1864 Content-MD5 Header Field October 1995
3. Processing the Content-MD5
If the Content-MD5 field is present, a recipient user agent
choose to use it to verify that the contents of a MIME entity
not been modified during transport. Message relays and gateways
expressly forbidden to alter their processing based on the
of the Content-MD5 field. However, a message gateway is allowed
remove the Content-MD5 field if the corresponding MIME entity
translated into a different content-type
4. Security
This document specifies a data integrity service that protects
from accidental modification while in transit from the sender to
recipient. A secure data integrity service, such as that provided
Privacy Enhanced Mail [3], is conjectured to protect data from
modifications
5.
This memo is based almost entirely on text originally written
Nathaniel Borenstein of Bellcore. In addition, several
were suggested by Keith Moore of the University of Tennessee
Knoxville
6.
[1] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet
Extensions) Part One: Mechanisms for Specifying and
the Format of Internet Message Bodies", RFC 1521, Bellcore
Innosoft, September 1993.
[2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Laboratory for Computer Science and RSA Data Security, Inc.,
April 1992.
[3] Linn, J., "Privacy Enhancement for Internet Electronic Mail,
I: Message Encryption and Authentication Procedures", RFC 1421,
IAB IRTF PSRG, IETF PEM WG, February 1993.
Myers & Rose Standards Track [Page 3]
RFC 1864 Content-MD5 Header Field October 1995
7. Authors'
John G.
Carnegie Mellon
EMail: jgm+@cmu.
Marshall T.
Dover Beach Consulting, Inc
EMail: mrose@dbc.mtview.ca.
Myers & Rose Standards Track [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
