Expose replay metadata after decapsulation - #99
Conversation
|
I suggest that you look first at #88 here. That gives the ability to get a key ID before decapsulation. The challenge there is that the |
|
Thanks, agree that fixed-header parsing should be separated from key selection, with My original use case is application-managed replay handling after successful decapsulation, but a header-first API would be more general and preserve useful information on failure. Would you prefer that I rework this PR to implement a staged API and layer the post-auth replay convenience on top, or close this PR and submit the header-decoding work separately first? Should the public header object expose all four fixed fields (key_id, KEM, KDF, AEAD), with enc becoming available only after key selection? |
|
I think that a separate PR on staged header decoding, along the lines of the change I linked, would be good. The advantage of that is that you don't need to create a sidecar for the anti-replay details. That can take |
|
#100 supersedes this work. |
Adds an optional buffered decapsulation API that returns the validated OHTTP key ID and authenticated HPKE
encvalue for application-managed replay detection under RFC 9458 §6.5.The existing
Server::decapsulateAPI remains unchanged and delegates to the new path. Replay caching and rejection policy remain application responsibilities.Streaming decapsulation intentionally does not expose this metadata because response state can exist before the complete request body is authenticated.
Tests cover ownership, cache-key consumption without cloning, replay-key stability, independent encapsulations, authentication failures, multiple KEM lengths, response round trips, and legacy compatibility.