- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 31 Oct 2016 21:03:24 +1100
- To: Costin Manolache <costin@gmail.com>
- Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Julian Reschke <julian.reschke@gmx.de>, HTTP working group mailing list <ietf-http-wg@w3.org>
On 31 October 2016 at 17:13, Costin Manolache <costin@gmail.com> wrote: > 1. Why not add the Crypto-Key to the binary header ? If we have to deal with > binary encoding, we can at > least avoid parsing more text headers - and it doesn't have to be b64. I considered doing this, but - other than webpush, more on that below - the key usually has to travel independently of the encrypted payload. Otherwise we're reduced to providing an elaborate checksum. > 2. For webpush - if the actual encryption is the same ( and I haven't > compared with the previous version ) - I > don't expect it to be a big problem to accept both formats for a while in > existing servers. I have an update for the webpush document that follows this. Unfortunately, the format and crypto is incompatible. That's unavoidable. I took the opportunity to simplify things further. We've managed this in the past by switching on the content-encoding header field value, and I plan to do the same. I consider that sort of extra complexity the cost of trying to implement a standard that isn't completely done. For the DH public key, I did consider packing it into the keyid field rather than relying on Crypto-Key. That seemed wrong, but I could be convinced that it's worth doing. I'll follow up on the webpush list and we can hash out that side of things there.
Received on Monday, 31 October 2016 10:03:57 UTC