search

martinthomson / ohttp

Rust library for encapsulating HTTP messages in a cryptographic wrapper
Apache License 2.0
24 stars 18 forks source link

Parsing multiple key configurations #44

Closed chris-wood closed 1 year ago

chris-wood commented 1 year ago

OHTTP gateways provide configurations in a sequence, without any sort of additional framing. That means consumers of this resource must know how to parse key configs in order to select the one that best fits their needs. Currently, however, the KeyConfig parser in this crate doesn't lend itself easily to doing this. The parser assumes there is exactly one encoded config in a blob and fails if there is anything trailing it.

@martinthomson, what's your take on how applications ought to support multiple configs using this library?

martinthomson commented 1 year ago

Hmm, that made me realize that we don't really have a good story for how to manage a resource that contains an unknown KEM ID. Once you hit one of those, you have to stop. Do you think we should try to make a change there? Adding a length prefix to each isn't very disruptive.

Other than that, we probably just need a new function for parsing a collection of key configurations.

chris-wood commented 1 year ago

Hmm, that made me realize that we don't really have a good story for how to manage a resource that contains an unknown KEM ID. Once you hit one of those, you have to stop. Do you think we should try to make a change there? Adding a length prefix to each isn't very disruptive.

Yeah, this seems pretty reasonable to me. I doubt people would object.

Other than that, we probably just need a new function for parsing a collection of key configurations.

This seems like a more disruptive change than desired. I quite like that the KeyConfig parser assumes the input blob represents at most one configuration. If the parser supported multiple, the calling application wouldn't necessarily know which config was used for encapsulation.

martinthomson commented 1 year ago

Opened https://github.com/ietf-wg-ohai/oblivious-http/pull/284 with a proposal to add a length prefix. I'm going to see if I can't work out something with the API now.