On Thu, 23 Oct 2025 at 15:06, 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. > Yes, I faced a similar issue with PQ/T Hybrid KEM in HPKE. The same PQ/T key pair can be used across multiple cipher suites that differ in AEAD (e.g., QSF-X25519-MLKEM768-SHAKE256-SHA3256-AES-256-GCM and QSF-X25519-MLKEM768-SHAKE256-SHA3256-ChaCha20Poly1305). This problem should be solved with the new key type defined in the PR https://github.com/tireddy2/PQC_JOSE_COSE/pull/20 in which "alg" is optional. > > > > > - 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.) > Thanks, I raised PR https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/76 to address it. Cheers, -Tiru > > > > > -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]
