I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-hpke-hpke-04 Reviewer: Paul Kyzivat Review Date: 2026-08-01 IETF LC End Date: 2026-08-03 IESG Telechat date: ??? Summary: This draft is on the right track but has open issues, described in the review. Note: I have minimal knowledge of cryptographic algorithms. Hence this review doesn't address any cryptographic issues, and doesn't attempt to validate the appendices. Comments are structural, procedural and editorial. Issues: 7 Nits: 4 1) ISSUE: Are one-stage KDFs ready for prime time? Section 4.2 (Key Derivation Functions) introduces the notion one-stage and two-stage KDFs. This is a notable change from RFC 9180. It considerably increases complexity. Did you try to better encapsulate the distinction? (E.g., turn one-stage into a degenerate form of two-stage.) Also, the parameter "Nh" is defined only for a two-stage KDF. It isn't defined for one-stage KDFs. And Table 3 in section 7.2 lacks any entries for one-stage KDFs. It appears to me that the notion of one-stage KDFs might be speculative, and under-specified. 2) ISSUE: References to RFC 9180 This document obsoletes RFC 9180, but still references it. Some references are reasonable, to highlight the differences. But some references remain that probably should instead refer to this document. Notably: Section 7.1, Table 2 Section 7.2, Table 3 Section 7.3, Table 5 Section 9.7.3 Ideally, I think it would be better to confine references to RFC 9180 to Appendix A, while making the rest of the document stand on its own. 3) ISSUE: IANA Registration issues Section 11 (IANA Considerations) fails to clearly identify the location of the IANA registries. Instead it references the definitions in RFC 9180. Since this doc obsoletes RFC 9180, it should fully take over the specification of the IANA registries. What do you want to allow after this document is published? Do you want all current registrations, made under RFC 9180 rules, to remain? Even those that use features that have been removed? (More specifics below.) 4) ISSUE: Update of KEM Identifiers Section 11.2 (KEM Identifiers) says "Initial contents: Provided in Table 2". If the intent is to preserve everything that is currently registered, rather than starting over, then this is not true. Instead, I think you need to specify that table 2 provides additions and/or updates to the existing registry. I gather the "Auth" column is made obsolete by this document, and is perhaps being retained for backward compatibility with RFC 9180. If so, do you want to allow future registrations to specify a value for this? I'm not sure how best to handle this, but you should specify your intent. Perhaps a discussion with IANA would be helpful. 5) ISSUE: Update of KDF Identifiers Section 11.3 (KDF Identifiers) says "Initial contents: Provided in Table 3". If the intent is to preserve everything that is currently registered, rather than starting over, then this is not true. Instead, I think you need to specify that table 3 provides additions and/or updates to the existing registry. Also, this adds a column to the table. IANA needs some guidance about how to handle this for existing table entries. What value should be used for "Two-Stage". (I gather the default would be "Y".) 6) ISSUE: Update of AEAD Identifiers Section 11.4 (AEAD Identifiers) says "Initial contents: Provided in Table 5". The registry was already defined by RFC 9180, and it appears that Table 5 is consistent with the existing registry content, including referencing RFC 9180 rather than this document. (With exception of N/A in the Export-only row.) I think IANA needs better direction about what to do. I suggest you update Table 5 to reference this document rather than 9180, and direct IANA to replace the existing table with the contents of Table 5. 7) ISSUE: Undefined terms Section 4.1 (Key Encapsulation Mechanisms) omits the definitions of AuthEncap and AuthDecap which were included in RFC 9180. Yet they are still referenced in 7.1 and 11.2. Please either define them, or omit the references. (See other issues for more on this.) 8) NIT: Lack of normative language In section 8.1 (Auxiliary Authenticated Application Information) the last paragraph is wishy-washy, and lacking normative language. If you intend to permit the behavior you discourage, then please at least say more about the negative consequences of doing so, and/or explain when that behavior would be appropriate, using normative language. 9) NIT: Byte order unspecified Section 3 (Notation) The definition of lengthPrefixed fails to specify what encoding is to be used for the two-byte length. (Presumably network byte order.) 10) NIT: wording In section 4 (Cryptographic Dependencies) the statement: "An Authenticated Encryption with Associated Data (AEAD);" seems to be lacking a noun stating what the AEHD *is*. Based on the title of 4.3, how about revising to: "An Authenticated Encryption with Associated Data (AEAD) algorithm;" 11) NIT: IdNits The IdNits tool reports a couple of things that seem relevant: == Unused Reference: 'BHK09' is defined on line 1992, but no explicit reference was found in the text -- Duplicate reference: RFC9849, mentioned in 'RFC9849', was also mentioned in 'ECH'.