Re: remove WRAPPED?

Roy noted:

>  WRAPPED -> Part of Dave Kristol's original extension
>  proposal, with additions
>     from myself and Rohit (for PEP).  I am not sure whether
>     this qualifies or not.
>  I can live without WRAPPED, but removing TRACE and DELETE
>  will create more controversy than you seek to avoid by
>  removing them.

Well, there was some debate about WRAPPED, and I took up some of my concerns  
with Roy for a bit, and this was my thanks:

>> I anoint you "defender of WRAPPED".  Now go to it.  ;-)

OK, here goes. There is one overriding application scenario for WRAPPED  
messages: it's the only tenable mechanism for protecting the request URI and  
return status of HTTP transactions. "Protecting" includes not only PEP-like  
mechanisms, but the use of encodings and (IMHO) MIME types.

Furthermore, it seems to be reasonably easy to implement. Just as clients can  
expect to re-present application/http bodies to themselves, servers can  
simply take the output of whatever a MIME (or PEP) process produces from the  
WRAPPED body and present it to itself as applciation/http.

Of course, I think that we face a juncture in deciding to admit other MIME  
types than application/http in WRAPPED bodies. On one hand, MIME-PGP would be  
able to offer a handy and direct security hook:

Content-Type: application/x-pgp


since the sender's intent is that the entity-body is (eventually) app/http?

On the other hand, a client will only learn if wrapping non-http works by  
trial and failure. If we leave the requirement in, it will be easy for servers  
to implement WRAPPED for application/http, but extenders will come along and  
be forced to lie about Content-Type, using PEP or a private Content-Encoding  
to protect the information on the wire.

Bottom line: WRAPPED should stay in, either with the application/http  
restriction and PEP, or without any restriction, so long as the client intends  
application/http. (Damned non-composable content-types!)

If it's left out, well, you can't build application security solutions within  
HTTP/1.1. Even document signatures become problematic, since "signing the  
entity-body" won't have any mechanism for signing a message complete with all  
its request or reply headers (many of which are sensitive, too).

Rohit Khare

Received on Friday, 23 February 1996 19:22:01 UTC