- From: <hallam@vesuvius.ai.mit.edu>
- Date: Thu, 17 Oct 96 11:13:54 -0400
- To: "Donald E. Eastlake 3rd" <dee@cybercash.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: hallam@vesuvius.ai.mit.edu
>> - security >> draft-ietf-wts-shttp-03.txt 'bounced' as Proposed Standard. Most >> likely if it progresses at all it will go forward as Experimental, >> after editorial work happens (or a disclaimer gets added.) >> >> I think that the separation and lack of coordination between >> WTS and HTTP-WG was a serious problem, and that I should have done >> more to prevent this morass. > >Was this mis-coordination the real problem here? I don't think that mis-coordination was an issue at all. Once security was separated from the main HTTP spec the end result was inevitable. S-HTTP has severe problems and I don't know that its possible to fix them without a very radical change of approach. S-HTTP is simply too complex. >> I believe the Internet needs documented standards-track security >> mechanisms for HTTP & distributed content. Perhaps we should >> re-charter a new group to work on standards for SSL and applet >> signing. >Are you aware of the TLS working group which is aiming at a merged >SSL/PCT? Where? according to the IETF the official mailing list for WTS is www-security@rutgers. I can find no pointer anywhere to the list where the real discussion has been going on. I think that that is in itself a serious problem. Merging SSL and PCT is not a difficult matter and a good thing to do. I think that overall this approach has a lot to offer the Internet generally and may well end up rendering the IP-SEC work moot. It is not a panacea however. Working at the transport layer prevents any usefull interaction between the application and transport to create the appropriate security for a particular transaction. I think that keeping SSL and transaction layer security separate is essential. If people attempt to force SSL to support application oriented features in the transport layer the result will be an abomination. As part of our project I had to create a scheme to allow two web servers to be kept in lockstep via authenticated HTTP exchanges. It provides the functionality of S-HTTP with the exception of negotiation but uses only five headers instead of twenty, does not involve ASN.1 and has a much cleaner interface to a negotiation system. If anyone is interested I can finish the writeup and post it. I was planning to write an active-x control and experiment with the protocol incorporated into a browser. If anyone has experience of implementing such a control or knows of an example I would be very pleased to know! Unfortunately Microsoft's documentation is more forthcomming on what one can do with active-x than how to do any of it. If active-x makes any sense it is as a general purpose operating system level "component-ware" solution. If I don't like the features provided by the O/S provided jpeg filter or HTTP transport I swap in my own. According to the propaganda it should provide me with an open testbed to experiment with extending the protocols without having to write a browser and server. It should be possible for an end user to adopt my modified protocol without having to replace his whole browser. Unrfortunately there is a general agreement amongst those of us in this building that have tried to do such things that there is a distinct lack of concrete examples in this area. Phill
Received on Thursday, 17 October 1996 08:35:32 UTC