INTEGOK: updated wording

Several comments have come in that are incorporated into the revised
wording attached. A synopsis of the reasons for the changes:

1. Content-MD5 is not proof against malicious attacks
2. In both MIME and HTTP, the digest is computed on what would be sent
(modulo Transfer-Encoding or Content-Transfer-Encoding) AND (in
practice) the canonical form (modulo Content-Encoding); for text, the
canonical form differs slightly between the two. See the HTTP 1.0 spec,
appendix C, for the relationship of MIME media types and HTTP media
types.
3. Typos and awkward wording have been fixed.
4. Binary media types can specify their own transmission byte orders, so
network byte order can't be mandated in the digest.
5. The explanation on application of RFC 1864 in the HTTP context has
been changed to a note. The note at the end has been made definitive.

Thanks to Dave Kristol, Jim Gettys, Roy Fielding and Phill Hallam-Baker.

---------------------------------------------

10.13	Content-MD5

The Content-MD5 entity-header field is an MD5 digest of the entity-body,
as defined in RFC 1864 [xx], for the purpose of providing an end-to-end
message integrity check (MIC) of the entity-body. (Note: an MIC is good
for detecting accidental modification of the entity-body in transit, but
is not proof against malicious attacks.)

	ContentMD5	= "Content-MD5" ":" md5-digest
	md5-digest	= <base64 of 128 bit MD5 digest as per RFC 1864>

The Content-MD5 header may be generated by an origin server to function
as an integrity check of the entity-body. Only origin-servers may
generate the Content-MD5 header field; proxies and gateways MUST NOT
generate it, as this would defeat its value as an end-to-end integrity
check. Any recipient of the entity-body, including gateways and proxies,
MAY check that the digest value in this header field matches that of the
entity-body as received. 

The MD5 digest is computed based on the content of the entity body,
including any Content-Encoding that has been applied, but not including
any Transfer-Encoding.  If the entity is received with a
Transfer-Encoding, that encoding must be removed prior to checking the
Content-MD5 value against the received entity.

This has the result that the digest is computed on the octets of the
entity body exactly as, and in the order that, they would be sent if no
transfer coding were being applied.

   Note: there are several ways in which the application of
   Content-MD5 to HTTP entity-bodies differs from its
   application to MIME entity-bodies. One is that HTTP,
   unlike MIME, does not use Content-Transfer-Encoding,
   and does use Transfer-Encoding and Content-Encoding.
   Another is that, unlike MIME, the digest is computed
   over the entire entity-body, even if it happens to be
   a MIME "multipart" content-type. (Note that the multipart
   bodies may themselves have Content-MD5 headers.) Another
   is that HTTP more frequently uses binary content types
   than MIME, so it is worth noting that in such cases,
   the byte order used to compute the digest is the
   transmission byte order defined for the type. Lastly,
   the canonical form of text types in HTTP includes several
   line break conventions, so conversion of all line breaks
   to CR-LF is not required before computing or checking
   the digest: any acceptable convention should be left
   unaltered for inclusion in the digest.


----------------------------------------------------
Paul J. Leach            Email: paulle@microsoft.com
Microsoft                Phone: 1-206-882-8080
1 Microsoft Way          Fax:   1-206-936-7329
Redmond, WA 98052

Received on Tuesday, 2 April 1996 12:32:39 UTC