- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 12 May 2015 12:56:16 +0000
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- cc: Mark Nottingham <mnot@mnot.net>, Willy Tarreau <w@1wt.eu>, Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
-------- In message <5551F31A.2000404@cs.tcd.ie>, Stephen Farrell writes: >In other contexts, we've seen that people talk about use-cases >for signing and even deploy signing, but verification can lag >significantly behind, which can make the whole effort somewhat >pointless. Agree, there are plenty of wrecks in the road-side, but the other side of that problem is that people end up rolling their own because there is no standard. I personally think this is the privacy area we should have focused on, rather than the blunt weapon of "SSL-everywhere", because this does not conflict with laws and disable caching to the same degree. However, it is not obvious to me that it is a good idea to involve the Content-Encoding at all, whereas I see several downsides. For instance we cannot Vary: on just the aesgcm-128 part of the C-E header, and since the Encryption: header is just noise without the qualifying C-E element, varying on just Encryption: is not a good idea. Leaving C-E entirely out of the picture will make no difference in any scenario I can come up with (Please enlighten me if such scenarios exist). I think it would make much more sense to concentrate all the relevant information in a single new header (Content-Encryption ?) which would make Vary "just work". This would also make the obvious "Accept-Encryption" negotiation header possible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 12 May 2015 12:56:47 UTC