Subject: RIP: Crypto-Key header field

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Nov 2016 14:56:41 +1100

As we discussed in the meeting (and before that, on the list), I've
created a PR to remove the Crypto-Key header field.  As a result, the
document is much, much smaller and cleaner.

https://github.com/httpwg/http-extensions/pull/271

There was also a comment about how to pad.  I ripped off some text
from other protocols:

https://github.com/httpwg/http-extensions/pull/272

In the spirit of "you know when you are done when there is nothing
left to remove", I think we are ready.  I'll give people a chance to
read these, then post a new revision.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Nov 2016 15:06:22 +1100

Oops, I didn't open the first PR, here 'tis:
https://github.com/httpwg/http-extensions/pull/273

---

From: Julian Reschke <[email-masked]>
Date: Tue, 22 Nov 2016 09:28:40 +0100

> read these, then post a new revision.

I remain a bit concerned about the vagueness with respect to key 
dictionaries. I understand why we don't specify them here precisely, but 
then any other spec that makes use of them will have to do the extra work.

Specifically:

1) The way "keyid" is currently specified makes it an octet sequence, 
that may or may not be valid UTF-8 and could even include NUL. Is that 
really the intention? We've seen the consequences of this with ALPN 
identifiers, which required us to define a funky escaping mechanism in 
alt-svc, so we could put them into places that take strings. This not 
only affects related specs, but also APIs for code that handles 
encryption encoding (such as: what's the datatype for the key in 
dictionaries?)

2) Is there a notion of uniqueness? Can there be multiple dictionaries, 
which might contain different information for the same keyid? What's the 
suggest behavior when there's more than one? Pick first? Pick first that 
works?

3) Is there any spec that uses encryption encoding and uses 
dictionaries? If so, how does it interface with key dictionaries?

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Nov 2016 11:47:46 +1100

On 22 November 2016 at 19:28, Julian Reschke <[email-masked]> wrote:
> 1) The way "keyid" is currently specified makes it an octet sequence, that
> may or may not be valid UTF-8 and could even include NUL. Is that really the
> intention? We've seen the consequences of this with ALPN identifiers, which
> required us to define a funky escaping mechanism in alt-svc, so we could put
> them into places that take strings. This not only affects related specs, but
> also APIs for code that handles encryption encoding (such as: what's the
> datatype for the key in dictionaries?)

The virtue of this is that a particular profile can define this field
as it chooses, to meet its own requirements.  If you intend to use
this with strings, then you can constrain to ASCII or UTF-8 as you see
fit.

> suggest behavior when there's more than one? Pick first? Pick first that

That would be application-defined.  Applications would have to define
the scope over which a dictionary is applicable.

Worst case is that you pick a key that works.  That is, one that
decrypts the first record.  Thanks to integrity protection, that's
never(*) going to get you the wrong answer, though it might be
sub-optimal.

> 3) Is there any spec that uses encryption encoding and uses dictionaries? If
> so, how does it interface with key dictionaries?

There is no such spec, unless your intent with the out-of-band stuff
was to define such a dictionary.

The question, I guess, is to work out what sort of guidance we might
want to provide around the use of these identifiers.  Is it entirely
up to the usage to define format and scope?  I think yes on both is
the obvious answer - we aren't defining how keys move around either.
Explicitly saying that is probably a good idea though.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Nov 2016 07:15:02 +0100

On 2016-11-23 01:47, Martin Thomson wrote:
> ...

I see lot of additional works and potential bugs by allowing non-UTF-8 
octet sequences, and something like zero advantages.

Best regards, Julian

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 23 Nov 2016 16:51:14 +0900

> octet sequences, and something like zero advantages.

Yes indeed. Not knowing what character encoding is used for a string, or 
not knowing whether something is binary or text, it a lot of pain, and 
no "virtue" at all. We have a lot of experience with that; let's not 
repeat these same mistakes over and over again.

Regards,   Martin.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Nov 2016 10:27:14 +1100

On 23 November 2016 at 18:51, Martin J. Dürst <[email-masked]> wrote:
> Yes indeed. Not knowing what character encoding is used for a string, or not
> knowing whether something is binary or text, it a lot of pain, and no
> "virtue" at all. We have a lot of experience with that; let's not repeat
> these same mistakes over and over again.

This presumes that the field is a string.  We already have a use for
it that treats it as an octet sequence.  If someone cares to designate
a usage that needs strings, then UTF-8 is available to them.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Nov 2016 07:20:53 +0100

> it that treats it as an octet sequence.  If someone cares to designate

Which?

> a usage that needs strings, then UTF-8 is available to them.

Which implies that those who define the use of dictionaries and the way 
they are transmitted have full control over what keyids are used. Is 
this the case?

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Nov 2016 11:29:06 +1100

> Which?

Webpush was considering using the field.  It's not final yet, but only
because there are questions about how to signal keys elsewhere, but
you can see a preview:
http://webpush-wg.github.io/webpush-encryption/pack_key_hack/

> Which implies that those who define the use of dictionaries and the way they
> are transmitted have full control over what keyids are used. Is this the
> case?

I don't see why not.  For instance, out-of-band can easily restrict
this to UTF-8 (or if you get hit on the head some time in the near
future, the special JSON UTF-16 with unpaired surrogates mess).

---

From: Costin Manolache <[email-masked]>
Date: Fri, 25 Nov 2016 17:36:15 +0000

Maybe use a bit to indicate binary vs utf8 ?

Costin

On Thu, Nov 24, 2016, 4:34 PM Martin Thomson <[email-masked]>
wrote:

> they