On Sun, 19 Oct 2025 at 22:51, Ilari Liusvaara <[email protected]> wrote:
> On Sun, Oct 19, 2025 at 03:47:12AM -0700, [email protected] wrote: > > Internet-Draft draft-ietf-jose-hpke-encrypt-13.txt is now available. It > is a > > work item of the Javascript Object Signing and Encryption (JOSE) WG of > the > > IETF. > > > > Title: Use of Hybrid Public Key Encryption (HPKE) with JSON Object > Signing and Encryption (JOSE) > > Authors: Tirumaleswar Reddy > > Hannes Tschofenig > > Aritra Banerjee > > Orie Steele > > Michael B. Jones > > Name: draft-ietf-jose-hpke-encrypt-13.txt > > Pages: 22 > > Dates: 2025-10-19 > > 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 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. > > > > [1] It is provably impossible to canonicalize JSON numbers such that: > > - Any number can be canonicalized. > - The canonicalization preserves the numeric value. > - Integers canonicalize as integers. > - The algorithm is O(something_sub_exponential). > > Proof: Canonicalize "1E"||"9"^n (n > 0; which is length n+2) using > any canonicalization meeting the first three. The output length will > be 10^n, which is fully exponential, and thus runtime will also be > fully exponential, which is not O(something_sub_exponential). Q.E.D. > > 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. 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]
