Hi Hannes, Mike, all, Over the past year, I haven’t been able to contribute to the revisions of the specification despite being a co-author. However, I’ve reviewed the latest content again and believe there are no major issues.
I’d feel a lot better about the “yes, let’s publish” if there was some > comment and confirmation that next_layer_alg in Recipient_structure > [3.1.2.1] secures the bulk encryption algorithm ID well enough that a > non-AEAD can be used. I think it does, but we should have a little > consensus on this. At one point, I misunderstood your proposal, but I’m now confident that the current approach is appropriate. One note: the COSE implementation I maintain hasn’t yet caught up with the recent updates leading up to WGLC, so I’d like to update it as soon as possible to perform a final validation of the spec. Regards, Daisuke 2025年6月21日(土) 3:21 Ilari Liusvaara <[email protected]>: > On Fri, Jun 20, 2025 at 06:07:59PM +0200, Renzo Navas wrote: > > Dear Hannes, all, > > > > I focused on reading RFC9180 and its application in this document. > > > > Just one high level comment/question. Since HPKE depends on message > > reordering and message loss of other mechanisms ( RFC9180 Section > > 9.7.1. Message Order and Message Loss ). Here I put the text of > > interest: > > > > “Applications that allow for multiple invocations of Open() / Seal() > > on the same context MUST enforce the ordering property described > > above. (...). > > HPKE is not tolerant of lost messages. Applications MUST be able to > > detect when a message has been lost. When an unrecoverable loss is > > detected, the application MUST discard any associated HPKE context. ” > > > > What does this imply for the “HPKE Key Encryption Mode” which targets > > multiple recipients? > > Can/If we detect one Recipient did not get the message, we discard > > both contexts? How do we handle this, is it out of scope? It is not > > clear to me. I would like some clarification (and maybe this > > clarification can enhance the “Security Considerations” sections of > > the document). > > This is not relevant for COSE-HPKE, because it does not allow multiple > Open/Seal invocations on the same context (it always does exactly one). > That is, each message is independent of all others. > > In case of multiple recipients, each recipient has its own context. > > > > > -Ilari > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
