Re: Artart last call review of draft-ietf-httpbis-message-signatures-16

Justin,

> On Mar 10, 2023, at 8:08 PM, Justin Richer <jricher@mit.edu> wrote:
> 
> Point taken. We've tried to anchor all of the items to specific definitions from the HTTP semantics spec here, what can we do to make that more precise so that other url types are fully covered or excepted in an unambiguous way? I don't see why this couldn't be used on other url types as it stands but I could be wrong.

Aside from the concerns that others have already voiced, the only thing I can add is that doing message signatures like this across intermediaries (proxies, etc.) is hard and will expose a lot of problems in existing implementations.

Some semi-recent work in the IPP workgroup [1] has explored both integrity and privacy protection of print jobs.  We opted to use S/MIME containers (PGP is another option we considered) with a new MIME media type to encapsulate the request/response messages instead of doing anything at the HTTP level because we explicitly wanted to support "less trusted" intermediaries and didn't think existing implementations would preserve new HTTP headers or IPP data types.  Another advantage for our particular use cases is that the S/MIME container can require an additional password/PIN to access the data, which is the sort of thing enterprise print users need when releasing a print job at a printer.

[1]: https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrustnoone10-20210519.pdf

> 
> From: Michael Sweet <msweet@msweet.org>
> Sent: Friday, March 10, 2023 9:47 AM
> To: Julian Reschke <julian.reschke@gmx.de>
> Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org>
> Subject: Re: Artart last call review of draft-ietf-httpbis-message-signatures-16   Julian,
> 
> > On Mar 10, 2023, at 3:01 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> > 
> > On 07.03.2023 18:39, Justin Richer wrote:
> >> ...
> >>> All of section 2.2 seems to assume that we’re dealing only with HTTP
> >>> URLs. This
> >>> assumption should be made explicit.
> >> 
> >> This specification is signing for HTTP messages. What other URLs would
> >> there be at play here? It seems redundant to call it out, especially
> >> because we’re using the terms from the HTTP semantics specification to
> >> define the components.
> >> ...
> > 
> > HTTP can in theory also be used to access resources with non-HTTP(s)
> > URIs. In HTTP/1.1, you can use the absolute form of the request target
> > for that.
> > 
> > Is it common? No (I believe).
> 
> IPP uses this mechanism (ipp: and ipps: URIs specify IPP over HTTP/HTTPS), and with billions of IPP printers out there I think we can call it common. :)
> 
> (but I doubt IPP will use this mechanism for ensuring message integrity...)
> 
> ________________________
> Michael Sweet
> 
> 
> 

________________________
Michael Sweet

Received on Saturday, 11 March 2023 15:01:45 UTC