[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

HTTP Working Group                             Laurent Demailly
INTERNET-DRAFT                                 Observatoire de Paris
<draft-demailly-cd-header-00.txt>
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 <http-wg@cuckoo.hpl.hp.com>.
   Discussions of the working group are archived at
   <URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions
   about HTTP and the applications which use HTTP should take place
   on the <www-talk@info.cern.ch> 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 <dl@hplyot.obspm.fr> and/or the WG at
   <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>.

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,
        <URL:http://ds.internic.net/internet-drafts/
        draft-ietf-http-v10-spec-00.txt>, 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


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/