The main point I took away from Orie was the following, which the updates to PR #76 don't seem to me to address:
> 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? On Mon, Oct 27, 2025 at 5:08 AM tirumal reddy <[email protected]> wrote: > 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] > -- _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]
