Signatures and Authentication information must go at end of meesage.

Hello all.

I am trying to produce a spec for signatures and authentication info in HTTP 
messages. There are two options:

1) Produce something broken which some people will like on artistic grounds
2) Find a way of attacking the signatures to the _end_ of the message.

This problem is in many ways similar to the previous discussions of ways to 
avoid the need for specifying a content length in the message header while not 
using lossage such as the mime "ohh the probability of collision is small" 
kludge.

The problem I have is that for the applications I have it is _essential_ that a 
server be able to produce a stream of HTTP message dynamically and without a 
pointless buffer diversion which serves no purpose other than allowing 
signatures to go at the beginning. For example CNN might broadcast the 
President's state of the Union speech in HTML, line by line as it proceeds. If 
the content length is embedded in the head of the message we have to wait for 
the end of the message before we can send out the first byte. So people see 
blank screens until the speech is over. The same problem occurs with 
authentication and signatures.

Ideally the WRAPPED method would permit footers to be specified :-

WRAPPED * HTTP/1.1
Content-Type: application/http

GET foo.html HTTP/1.1
Accept: text/html

Signature: KD1 KEY:INBAND:1242363987124986 qwrsetf14riu12t31t3ert12r1==
	
[Note that I have deliberately punted on the issue of how content segments are 
done, content length is important...]

Now I have a handy buffer routine written which would make it very easy to put 
the signature in the header but I do not want to use it... Consider the problem 
where the reply is a 4Mb JPEG. Buffering would involve unnecessary server load. 
Presigning is not always possible since much of the content used today is 
active.

Perhaps this could be incorporated into the segmentation method.


Without a facility which permits authentication information to be placed at the 
end of a message I fear that we will have to use PKCS#7 ASN.1 packets. I 
strongly dislike a number of other hacks which attempt to avoid the problem - 
such as giving a URL from which the authentication information can be retrieved.

Better authentication is very important if we are going to use the Web in 
Intranet applications, such as system management, remote document retrieval etc. 
I believe that it is very important that a Web client be capable of integrating 
iself into whatever authentication infrastructure is already in place. Rather 
than first produce a broken implementation and then try to fix it lets try to 
produce a system that works first time.

I am sorry about the tone of this message, it is just that a large number of 
people have reacted to this suggestion as if I had suggested eating babies raw.


		Phill

Received on Wednesday, 7 February 1996 10:27:32 UTC