2004/id/draft-ietf-http-cd-header-00.txt

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
1	HTTP Working Group Laurent Demailly
2	INTERNET-DRAFT Observatoire de Paris
3	<draft-ietf-http-cd-header-00.txt>
4	Expires SIX MONTHS FROM---> Nov 6th 1995
5
6
7
8	HTTP Content-Digest header
9
10	Status of this Memo
11
12	This document is an Internet-Draft. Internet-Drafts are working
13	documents of the Internet Engineering Task Force (IETF), its areas,
14	and its working groups. Note that other groups may also distribute
15	working documents as Internet-Drafts.
16
17	Internet-Drafts are draft documents valid for a maximum of six
18	months and may be updated, replaced, or obsoleted by other
19	documents at any time. It is inappropriate to use Internet-
20
21	Drafts as reference material or to cite them other than as
22	"work in progress."
23
24	To learn the current status of any Internet-Draft, please check
25	the "1id-abstracts.txt" listing contained in the Internet-
26	Drafts Shadow Directories on ds.internic.net (US East Coast),
27	nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
28	munnari.oz.au (Pacific Rim).
29
30	Distribution of this document is unlimited. Please send comments
31	to the HTTP working group at <http-wg@cuckoo.hpl.hp.com>.
32	Discussions of the working group are archived at
33	<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions
34	about HTTP and the applications which use HTTP should take place
35	on the <www-talk@info.cern.ch> mailing list.
36
37	Abstract
38
39	This extension suggest an additional header for HTTP/1.1:
40	An extensible entity body digest method.
41
42	Table of Contents
43
44	1. Introduction
45	1.1 Purpose
46	1.2 Overall Operation
47	1.3 Definitions
48	1.4 Practical Considerations
49	2. Examples
50	3. Security Considerations
51	4. Acknowledgments
52	5. References
53	6. Author's Address
54
55
56	1. Introduction
57
58	1.1 Purpose
59
60	The HyperText Transfer Protocol, HTTP [1] defines a Content-Length:
61	header that, when applicable, specify the length of the entity body
62	following. We define here a header that generally specify a digest
63	of the entity body.
64	A digest algorithm is an algorithm that takes as input a message
65	of arbitrary length and produces as output a much smaller,
66	generally fixed size (like 128-bits) "fingerprint", "message
67	digest", or "checksum" of the input. The generally wanted property
68	is that any slight change of the input message makes a different
69	digest output so it allows to detect integrity loss of the message.
70	Some algorithms also have the property that it is computationally
71	infeasible to produce two messages having the same message digest,
72	or to produce any message having a given prespecified target
73	message digest thus providing increased security (if the digest
74	transmission channel is secure/different than the message
75	transmission channel).
76
77	A Content-MD5 [2] MIME [3] header is already defined, but it
78	is tied to a specific algorithm (MD5). Also it involves specific
79	considerations about "canonical" format that does not apply to HTTP.
80	Lastly the digest coding it suggests is not consistent with other
81	md5 digest producing tools like stand-alone md5/md5sum programs
82	and thus can not be used easily without dedicated user agent.
83
84	The purpose of this extension is to overcome the limitations of the
85	existing solution and to devise and extensible scheme for specific
86	inclusion in HTTP, this while nothing is currently defined for
87	message integrity verification with HTTP.
88
89	1.2 Overall Operation
90
91	Each time an HTTP request is made where the Content-Length header
92	is present, a Content-Digest header can be present.
93
94	1.3 Definitions
95
96	Using HTTP notation:
97
98	Content-Digest = "Content-Digest" ":" 1#(digest)
99
100	digest = digest-algorithm "=" digest-value
101	digest-algorithm = "MD4" \| "MD5" \| "SHA" \| extension-algo
102	extension-algo = any token identifying the algorithm
103	digest-value = string
104
105	The digest-algorithm states which algorithm was used,
106	proposed common keywords are RSA's MD4 and MD5 [4],...
107
108	The minimal implementation should probably use MD5.
109	For MD5 digest the string coding should be the 32 characters long
110	hexadecimal representation of the 128 bits checksum (like
111	md5/md5sum stand-alone programs output)
112
113	1.4 Practical Considerations
114
115	The header is not compulsory and can be ignored (specially for
116	performance considerations)
117
118	If a server uses the header to check incoming POST/PUT
119	entity, and the digest does not match it shall issue an 4xx error
120	(to be defined)
121
122	If a client uses the header and detects non matching digest
123	it shall warn the user explicitly.
124
125	2. Example
126
127	For a body content of "this is a test\n"
128	you get :
129	---------
130	HTTP/1.0 200 Document follows
131	Server: datasrv/dl2.6d99
132	Last-Modified: Mon, 16 Oct 1995 15:42:06 GMT
133	Content-Type: text/plain
134	Content-Length: 15
135	Content-Digest: MD5=e19c1283c925b3206685ff522acfe3e6
136
137	this is a test
138	---------
139
140
141	3. Security
142
143	The purpose of this extension is to improve integrity.
144	It does not imply the object has not been forged along with the
145	headers. The protection is against accidental modifications and
146	not malevolent ones. As there is no a strong cryptographic
147	need, if performance is an issue, it is suggested
148	to use MD4 as the digest algorithm to use, though MD5 is probably
149	currently the more common.
150	Anyway, It is strongly recommended that servers implement the
151	digest for HEAD methods, thus allowing a second channel
152	verification for documents (You first get the document and check at
153	the GET time that the transport has not corrupted it, then you later
154	ask an HEAD and thus have a chance to get the digest from a second
155	(temporally) channel. This scheme does not prevent against
156	redirection and modification of all your traffic but does
157	prevent one-shot hijacking).
158
159	4. Acknowledgments
160
161	Thanks to Rich Salz, Rohit Khare, Shel Kaphan and others
162	from the http WG.
163
164	5 References
165
166	[1] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen.
167	"HyperText Transfer Protocol -- HTTP/1.0"
168	Internet-Draft (work in progress), UC Irvine,
169	<URL:http://ds.internic.net/internet-drafts/
170	draft-ietf-http-v10-spec-00.txt>, March 1995.
171
172	[2] J. Myers and M. Rose, "The Content-MD5 Header Field"
173	RFC 1864 Oct 1995.
174
175	[3] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
176	Extensions) Part One: Mechanisms for Specifying and Describing
177	the Format of Internet Message Bodies", RFC 1521, Bellcore,
178	Innosoft, September 1993.
179
180	[4] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
181	Laboratory for Computer Science and RSA Data Security, Inc.,
182	April 1992.
183
184
185
186	6 Author's Address
187
188	Laurent Demailly
189	dl@hplyot.obspm.fr
190	Observatoire de Paris
191	DESPA - Bat Lyot
192	5, pl J. Janssen
193	F-92190 Meudon
194	France