RFC 9180, "Hybrid Public Key Encryption", February 2022

Errata ID: 7937
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Raul Siles
Date Reported: 2024-05-13
Verifier Name: Nick Sullivan
Date Verified: 2025-01-18

Section 7.1.3 says:

For X25519 and X448, the DeriveKeyPair() function applies 
a KDF to the input:

<function()>

It should say:

For X25519 and X448, the DeriveKeyPair() function applies 
a KDF to the input:

<function()>

The suite_id used implicitly in LabeledExtract() and LabeledExpand()
for DeriveKeyPair(ikm) is derived from the KEM identifier of the 
DHKEM in use (see Section 7.1), that is, based on the type of key 
pair been generated for that DHKEM type.

Notes:

RFC 9180 dos not specify all the internal values for LabeledExtract(…) and LabeledExpand(…) for DeriveKeyPair(ikm), specifically the suite_id value. These values are required to standardise the DeriveKeyPair(ikm) function, as it is reference in other IETF drafts, such as https://www.ietf.org/archive/id/draft-westerbaan-cfrg-hpke-xyber768d00-02.html#name-derivekeypair-2, and because it is also used in the RFC 9180 KATs: see Appendix A.


Verified on CFRG list by co-author with notes: I looked at MLSpp and mls-rs, and both of those implementations compute `suite_id`, and they both do it in the way this erratum suggests. And since they interoperate with a bunch of other MLS stacks (including on HPKE), I assume this is how people are reading what's there now. But it would be good to be explicit.

Report New Errata