Re: RIP: Crypto-Key header field

On 22 November 2016 at 19:28, Julian Reschke <julian.reschke@gmx.de> 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.

> 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?

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.

Received on Wednesday, 23 November 2016 00:48:18 UTC