-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
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. |
Btw, the APIs are not mandatory to implement and an implementer may choose to implement a different API. |
@hannestschofenig thank you for creating the issue. I am not very confident about this matter. https://mailarchive.ietf.org/arch/msg/cose/dJsXu_gscj5eefWslU6QOJmUj8c/ |
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. |
I think that the only interoperable choice is to use empty info value:
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. |
Sounds like the current winning argument here is empty info, and send the protected headers to aad. |
Daisuke wrote:
The text was updated successfully, but these errors were encountered: