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]
