Thanks, Orie, for the detailed explanation. I’ve updated PR #76 <https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/76> to address these points. The recipient_protected_header has been removed, and the next_layer_alg field has been made mandatory, along with added rationale for its inclusion.
Cheers, -Tiru On Sat, 25 Oct 2025 at 19:57, Orie <[email protected]> wrote: > The purpose of these structures is to create application specific context > that can separate symmetric keys via kdf or cyphers via ahead aad. > > In JOSE there is no risk of being tricked to use non aead, but in COSE > that risk does exist. > > This only matters for key encryption. > > The desired feature is to have the 2 layers connected, such that a change > to one layer forces the other layer to fail closed, without revealing > anything. > > This can be accomplished by pulling the next layer into the info > parameter, as is done in concatKDF in JOSE via a context structure. > > The kdf is the earliest place to separate application context in HPKE, so > I assume it's the safest. > > But the problem is that this safety is eroaded when all you are encrypting > is a content encryption key, and the algorithm that is used with that key > can be controlled by the attacker. > > This is what motivates the need for a structure that binds between the > hpke encrypted content encryption key (per recipient) and the encrypted > content (shared by all recipients). > > The essential property is that when encrypting and decrypting the content > encryption key, you must know the next algorithm (and accept that it is > secure enough for your use case). > > My original JOSE/COSE hpke implementations tried to solve this by just > pulling the symmetric layer protected header (including algorithm > identifiers) into the hpke aead aad. > > In COSE this doesn't work, because algorithms in protected headers are > optional. Ilari also pointed out other layering issues with this approach. > > To try to solve this for both JOSE and COSE, you need to pull the > essential parameters into a structure and then use that structure in the > hpke operation on the content encryption key. > > Here is an example: > > hpke_info_or_aad = [ > "hpke_key_encryption_context", > HPKE-0, > A128GCM, > private_info = "" > ] > > This reads out as: > > I'm using hpke-0 to encrypt a content encryption key for use with A128GCM > with optional private information mixed into the kdf or committed via ahead > aad. > > I don't see why we need canonicalization to solve this problem. > > Use string concatenation in JOSE, and CBOR encoding in COSE. > > Am I missing something essential that motivates the need for determinism > in arbitrary data structures to accomplish the security goal? > > Regards, > > OS > > > > > On Sat, Oct 25, 2025, 8:39 AM Brian Campbell <bcampbell= > [email protected]> wrote: > >> The rationale for adding Recipient_structure also eludes me. >> >> Especially on the heels of an unsuccessful WGCL and the Madrid meeting >> where I was under the impression that efforts were going to be put into >> fixing the representation and differentiation of integrated and >> key encryption. Yes, of course, different people can sometimes have >> different takeaways from the same meeting but I am certain I am not the >> only one that had that impression. Yet nothing whatsoever has happened >> toward that end. >> >> Instead this problematic Recipient_structure thing appears in the draft >> as a surprise to much of the WG. >> >> The entire ethos of JOSE and a major contributor to its success has been >> the avoidance of any attempts at general JSON normalization or >> canonicalization. Yes, I am aware of RFC7638 JWK Thumbprints, which >> produces a canonical JWK representation. But it operates on an extremely >> narrow and tightly defined subset of content that makes it workable for >> that purpose and is definitely not a general JSON canonicalization >> thing. RFC7638 isn't really appropriate to try to use as some kind of >> general deterministic message encoding. >> >> Nothing like this Recipient_structure with deterministic JSONing is >> present in any of the existing JWE key key management algorithms. Why is >> jose-hpke special? There needs to be actual justification for >> introducing something that departs from established norms. >> >> >> >> >> On Thu, Oct 23, 2025 at 3:56 AM Filip Skokan <[email protected]> wrote: >> >>> The reasoning behind adding Recipient_structure in the first place >>> eludes me, it is not explained in the doc, its change history, or the >>> actual PR it was added in, nor do I recall a message on the list where its >>> inclusion was meant to resolve feedback. >>> >>> I would like to ask that the authors explain why it was added in -12, >>> what it's meant to achieve and clarify its language ( >>> https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/issues/74). >>> As an implementer, I ask that it be refactored to avoid any generic >>> canonicalization of unbound JSON structures, though without knowing what >>> its goal is I am unable to come up with suitable suggestions. >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Thu, 23 Oct 2025 at 11:36, Ilari Liusvaara <[email protected]> >>> wrote: >>> >>>> On Thu, Oct 23, 2025 at 11:52:17AM +0530, tirumal reddy wrote: >>>> > On Sun, 19 Oct 2025 at 22:51, Ilari Liusvaara < >>>> [email protected]> >>>> > wrote: >>>> > >>>> > > Some quick comments: >>>> > > >>>> > > - The text about AKP is not orphan. It defines what it means to use >>>> > > JOSE-HPKE algorithms with AKP keys. Without it, any new >>>> ciphersuite >>>> > > using AKP would have to redefine it, and getting it wrong would be >>>> > > a major problem. >>>> > > >>>> > >>>> > This document currently defines behavior only for traditional >>>> algorithms >>>> > which do not rely on the AKP format. While AKP has been defined for >>>> use >>>> > with PQC signature algorithms such as ML-DSA, its applicability to >>>> PQC KEMs >>>> > is still under discussion within the JOSE/COSE WGs. I would say AKP >>>> use is >>>> > considered out of scope for this document. >>>> >>>> The COSE-HPKE prototype implementation I have written actually runs into >>>> a bit of trouble with AKP: The decryption code really does not like any >>>> restrictions on the key, so it translates alg in AKP into cryptograhpic >>>> algorithm (not good). >>>> >>>> JOSE-HPKE would run into the same trouble. >>>> >>>> >>>> > > - The RFC7638 serialization does not look to be even close to being >>>> > > able to deal with header blocks. >>>> > > >>>> > > RFC7638 only seems to do sorting and whitespace elimination. It >>>> > > does not seem to even attempt string canonicalization, let alone >>>> > > number canonicalization (infamously nasty problem[1]). Plus it is >>>> > > unclear if it does nested object sorting or not. >>>> > > >>>> > > It seems like public key fields in JWKs are usually strings of >>>> > > characters (base64url) there is no reason to escape, so RFC7638 >>>> > > did not need to define any sort of value canonicalization. >>>> > > >>>> > > And if you think that any canonicalization preserves numeric value, >>>> > > there is at leat one "canonicalization" that does not. >>>> > > >>>> > >>>> > One possible option would be to leverage the canonicalization in >>>> > https://www.rfc-editor.org/rfc/rfc8785 but that >>>> > would be a downward reference. >>>> >>>> That canonicalization fails to preserve numeric value and looks to >>>> be much more complicated than needed. >>>> >>>> I think the following rules would give valid canonicalization: >>>> >>>> 1) There is no insignificant whitespace. >>>> 2) Objects have keys sorted in stable lexicographical order of >>>> strings of unicode codepoints. >>>> 3) Strings are encoded in minimal number of bytes, with all >>>> HEXDIGs uppercasd. >>>> 4) Numbers are encoded as follows: >>>> * 0 is encoded as '0'. >>>> * Nonzero numbers are encoded as follows (preserving real value): >>>> + int part is not multiple of 10. >>>> + frac part is absent. >>>> + exp part absent if 0, otherwise with uppercase E, no positive >>>> sign and no leading zeros. >>>> >>>> >>>> (The number canonicalization breaks the "integers canonicalize as >>>> integers" property. Which is not useful, since value is never parsed.) >>>> >>>> >>>> >>>> >>>> -Ilari >>>> >>>> _______________________________________________ >>>> jose mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>> _______________________________________________ >>> jose mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.*_______________________________________________ >> jose mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
