Re: RIP: Crypto-Key header field

[Julian Reschke <[e-mail]>]

On 2016-11-21 04:56, Martin Thomson wrote:
> 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.

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