Internet DRAFT - draft-ietf-http-cd-header
draft-ietf-http-cd-header
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 02:36:47 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 06 Nov 1995 23:00:00 GMT
ETag: "2eda63-1b48-309e9370"
Accept-Ranges: bytes
Content-Length: 6984
Connection: close
Content-Type: text/plain
HTTP Working Group Laurent Demailly
INTERNET-DRAFT Observatoire de Paris
<draft-ietf-http-cd-header-00.txt>
Expires SIX MONTHS FROM---> Nov 6th 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 method.
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 probably
currently the more common.
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.
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