HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 23:34:43 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Sat, 02 Mar 1996 13:56:57 GMT ETag: "304c65-1c70-313853a9" Accept-Ranges: bytes Content-Length: 7280 Connection: close Content-Type: text/plain HTTP Working Group Laurent Demailly INTERNET-DRAFT Observatoire de Paris Expires SIX MONTHS FROM---> Nov 13th 1995 HTTP Content-Digest header Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Please send comments to the HTTP working group at . Discussions of the working group are archived at . General discussions about HTTP and the applications which use HTTP should take place on the mailing list. Abstract This extension suggest an additional header for HTTP/1.1: An extensible entity body digest (checksum) method for increased data integrity and security. Table of Contents 1. Introduction 1.1 Purpose 1.2 Overall Operation 1.3 Definitions 1.4 Practical Considerations 2. Examples 3. Security Considerations 4. Acknowledgments 5. References 6. Author's Address 1. Introduction 1.1 Purpose The HyperText Transfer Protocol, HTTP [1] defines a Content-Length: header that, when applicable, specify the length of the entity body following. We define here a header that generally specify a digest of the entity body. A digest algorithm is an algorithm that takes as input a message of arbitrary length and produces as output a much smaller, generally fixed size (like 128-bits) "fingerprint", "message digest", or "checksum" of the input. The generally wanted property is that any slight change of the input message makes a different digest output so it allows to detect integrity loss of the message. Some algorithms also have the property that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest thus providing increased security (if the digest transmission channel is secure/different than the message transmission channel). A Content-MD5 [2] MIME [3] header is already defined, but it is tied to a specific algorithm (MD5). Also it involves specific considerations about "canonical" format that does not apply to HTTP. Lastly the digest coding it suggests is not consistent with other md5 digest producing tools like stand-alone md5/md5sum programs and thus can not be used easily without dedicated user agent. The purpose of this extension is to overcome the limitations of the existing solution and to devise and extensible scheme for specific inclusion in HTTP, this while nothing is currently defined for message integrity verification with HTTP. 1.2 Overall Operation Each time an HTTP request is made where the Content-Length header is present, a Content-Digest header can be present. 1.3 Definitions Using HTTP notation: Content-Digest = "Content-Digest" ":" 1#(digest) digest = digest-algorithm "=" digest-value digest-algorithm = "MD4" | "MD5" | "SHA" | extension-algo extension-algo = any token identifying the algorithm digest-value = string The digest-algorithm states which algorithm was used, proposed common keywords are RSA's MD4 and MD5 [4],... The minimal implementation should probably use MD5. For MD5 digest the string coding should be the 32 characters long hexadecimal representation of the 128 bits checksum (like md5/md5sum stand-alone programs output) 1.4 Practical Considerations The header is not compulsory and can be ignored (specially for performance considerations) If a server uses the header to check incoming POST/PUT entity, and the digest does not match it shall issue an 4xx error (to be defined) If a client uses the header and detects non matching digest it shall warn the user explicitly. 2. Example For a body content of "this is a test\n" you get : --------- HTTP/1.0 200 Document follows Server: datasrv/dl2.6d99 Last-Modified: Mon, 16 Oct 1995 15:42:06 GMT Content-Type: text/plain Content-Length: 15 Content-Digest: MD5=e19c1283c925b3206685ff522acfe3e6 this is a test --------- 3. Security The purpose of this extension is to improve integrity. It does not imply the object has not been forged along with the headers. The protection is against accidental modifications and not malevolent ones. As there is no a strong cryptographic need, if performance is an issue, it is suggested to use MD4 as the digest algorithm to use, though MD5 is strongly recommended for compatibility with the broadest range of existing implementations. Anyway, It is strongly recommended that servers implement the digest for HEAD methods, thus allowing a second channel verification for documents (You first get the document and check at the GET time that the transport has not corrupted it, then you later ask an HEAD and thus have a chance to get the digest from a second (temporally) channel. This scheme does not prevent against redirection and modification of all your traffic but does prevent one-shot hijacking). 4. Acknowledgments Thanks to Rich Salz, Rohit Khare, Shel Kaphan and others from the http WG. Comments, suggestions, corrections, additions, etc... are very welcome, please send to and/or the WG at . 5 References [1] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen. "HyperText Transfer Protocol -- HTTP/1.0" Internet-Draft (work in progress), UC Irvine, , March 1995. [2] J. Myers and M. Rose, "The Content-MD5 Header Field" RFC 1864 Oct 1995. [3] 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. [4] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992. 6 Author's Address Laurent Demailly dl@hplyot.obspm.fr Observatoire de Paris DESPA - Bat Lyot 5, pl J. Janssen F-92190 Meudon France