- From: Donald E. Eastlake 3rd <dee@cybercash.com>
- Date: Thu, 8 Feb 1996 13:42:04 -0500 (EST)
- To: hallam@w3.org
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Wed, 7 Feb 1996 hallam@w3.org wrote: > Date: Wed, 07 Feb 96 13:24:54 -0500 > From: hallam@w3.org > To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com > > 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. Whatever you end up doing I think you should steal as much as you can from RFC 1847 and 1848 to get the maximum commonality of mechanism and labeling at all levels... > 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. ? There is nothing stopping MIME implementations from pre-scanning the material they are to send to guarantee a unique boundary or from modifying anything which might cause a false match. Such modification is trivial if you are using quoated printable or base64 transfer encoding although I can understand why you might not want the overhead. Seems to me you either need a count in advance or a marker you can detect. If you go for a marker, you need to either pre-scan, filter and diddle the encoding to avoid false matches, or live with a probability of failure. > Phill Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html
Received on Thursday, 8 February 1996 10:49:10 UTC