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]
