Length prefix key encoding when there are multiple

[martinthomson]

This changes the definition of "application/ohttp-keys" in a way that is not backwards compatible, but it ensures that the format is usable once new KEMs are introduced.

[ericorth]

I just left a should-we-really-do-this comment in the issue. But if we decide "yes, we should", this text all looks reasonable to me.

[LPardue]

Is there any benefit in defining a minimum size for encoded configuration? Or perhaps there is some benefit from sending 00 00 here and there...

[tfpauly]

The text does say:

A Client that receives an "application/ohttp-keys" object with encoding errors
 might be able to recover one or more key configurations.  Differences in how key
 configurations are recovered might be exploited to segregate Clients, so Clients
 MUST discard incorrectly encoded key configuration collections.

So, any error in parsing a configuration would lead to failing the entire thing. I imagine a 00 00-length config would be considered an invalid configuration, yes?

[LPardue]

I reminded myself of the Key Config structure in https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html#format-key-config. I think that makes it clear enough what the minimum size would be. Some other specs dedicate text to call out a "too small to contain mandatory data" condition, others don't. I could live as is.

[martinthomson]

I think that empty != invalid, but empty == unusable, so maybe the effect is the same. It might be worth noting though.

[chris-wood]

I think we can leave this as-is. Merging now. Thanks, all!