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]
