W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: Encryption simplification

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 31 Oct 2016 21:03:24 +1100
Message-ID: <CABkgnnWdMgHHmJMKnt763M0NEL6qhwSOWcqo6GHiPn=dEtb+2g@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 31 October 2016 10:04:00 UTC