Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty String for Info Value #25

Open
hannestschofenig opened this issue Mar 17, 2023 · 7 comments
Open

Empty String for Info Value #25

hannestschofenig opened this issue Mar 17, 2023 · 7 comments

Comments

@hannestschofenig
Copy link
Collaborator

Daisuke wrote:

At the very least, until now, I believed that the info value for HPKE should be an empty string. The reason is that HPKE interface used in COSE is essentially the Single-shot API, and a single HPKE encryption context is not used across multiple encryption/decryption processes. In other words, aad alone is sufficient. As I mentioned before, RFC9180 Section 8.1 also says "Implementations which only expose single-shot APIs should not allow applications to use both Setup info and Context aad or exporter_context auxiliary information parameters". I will also give it some more consideration though.

@hannestschofenig
Copy link
Collaborator Author

I have just been wondering why we need to restrict the use of HPKE with COSE to the single-shot APIs. The single-shot APIs are likely to be a common use case but I could imagine that the other APIs are used as well.

@hannestschofenig
Copy link
Collaborator Author

Btw, the APIs are not mandatory to implement and an implementer may choose to implement a different API.

@dajiaji
Copy link
Contributor

dajiaji commented Apr 18, 2023

@hannestschofenig thank you for creating the issue. I am not very confident about this matter.
I wanted to hear the opinions of other experts, so I tried posting this matter on the COSE WG mailing list:

https://mailarchive.ietf.org/arch/msg/cose/dJsXu_gscj5eefWslU6QOJmUj8c/

@OR13
Copy link
Contributor

OR13 commented Apr 18, 2023

https://www.ietf.org/archive/id/draft-ietf-cose-hpke-05.html#info
https://www.rfc-editor.org/rfc/rfc9053#section-5.2

@ilaril
Copy link
Contributor

ilaril commented Oct 3, 2023

It is not possible to non-trivially use non-oneshot stuff, because that requires message sequencing, which COSE can not do.

(non-trivially because oneshot interfaces are equivalent to preparing a context and using it once.)

And the "APIs" defined in HPKE RFC describe the operations. All the supported ones must be implemented as specified, but how exactly the inputs and outputs are passed can vary from implementation to implementation.

@ilaril
Copy link
Contributor

ilaril commented Oct 8, 2023

I think that the only interoperable choice is to use empty info value:

  1. HPKE RFC section 8.1 says that HPKE implementations with only single-shot interfaces (and COSE-HPKE is inherently single-shot) should only allow setting one of aad or info. Therefore using both is not interoperable.
  2. HPKE RFC section 7.2.1 says that info should be limited to 64(!) bytes (no length limit is given for aad). Therefore using larger info is not interoperable.
  3. The protected headers must go to either aad or info.

The protected headers can easily be large enough to blow past 64 bytes. If that happens, the only way to avoid both interoperability problems is to use empty info.

@OR13
Copy link
Contributor

OR13 commented Oct 9, 2023

Sounds like the current winning argument here is empty info, and send the protected headers to aad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants