I've finally read the NIST SP800 56A(revision.3)(*1) and 56C(*2). In conclusion, we should not use COSE_KDF_Context for COSE-HPKE.
First of all, COSE_KDF_Context is designed to be compliant with NIST SP800 56A#Section 5.8.2.1, but it's for *One-step Key Derivation*. On the other hand, HPKE adopts Two-step Key Derivation internally (See RFC9180#KeySchedule<Role>(), LabeledExtract(), LabeledExpand() definitions), so we should refer not Section 5.8.2.1 but Section 5.8.2.2, *Two-step Key Derivation (Extraction-then-Expansion)*. In Section 5.8.2.2, a strict context structure that consists of AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo is NOT required. Instead, only a Label, Context and L (the length of the keying material) are required. The explanation of the context information for Two-step key derivation is as follows, and I believe it allows for flexible definitions: ... > Context is a binary string containing information relating to the derived > keying material. Section 5.8.2 provides a list of context-specific > information that *may be appropriate* for the inclusion in this string. > ... Different orderings of the component data fields of FixedInfo may be used, > and one or more of the data fields may be combined (or omitted under > certain circumstances). These three fields are clearly considered in the HPKE design. Specifically, in HPKE, the KEM and KDF steps supply sufficient context information (e.g., recipient and sender public keys, "HPKE-v1", mode, specified ciphersuite (implicitly includes L info for the AEAD step), and usage label) to the key derivation process. Even by limiting it to the context information supplied by the HPKE layer, it covers the "Context-specific information that may be appropriate for inclusion in FixedInfo" described in 56A#Section 5.8.2 to adequately. Additionally, by using Enc_structure, it is possible to bind protected header information to the context. If we consider not only the KEM/KDF steps but also the AEAD step, the application-specific information can be bound to the context using external_aad. I believe that the combination of HPKE itself and the COSE Enc_Structure mechanism adequately binds transaction information to the derived keying material. Next, regarding the compliance with RFC9052/9053. My proposal is to fully replace the Enc_structure with COSE_KDF_Context in > COSE-HPKE. I am not proposing double protection. As Ilari pointed out, it's impossible. Enc_structure is a mandatory specification for the main structures, COSE_Encrypt0 and COSE_Encrypt, and not using it would completely break compatibility with RFC9052/9053. On the other hand, COSE_KDF_Context is defined specifically for use with the KDF defined within the RFC 9053 document and the "alg" values that should be used with COSE_KDF_Context are also clearly defined. Therefore, It is not necessary to use COSE_KDF_Context for COSE-HPKE, and it is possible to exclude it without affecting the functionality. Based on the fact that we have to use Enc_structure, adopting COSE_KDF_Context in COSE-HPKE seems to result only in unnecessary duplication of the context binding. Best, Daisuke *1: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf *2: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr1.pdf 2023年6月10日(土) 2:15 lgl island-resort.com <[email protected]>: > > On Jun 7, 2023, at 9:40 AM, Ilari Liusvaara <[email protected]> > wrote: > > To that end I’ve tried to see how all the items in COSE_KDF_Context > apply to COSE-HPKE. I think those are the arguments that matter. > > > I just did go through all the subfields. I think every one of those is > either redundant, explicitly non-generic or trivially broken in generic > context. > > > Not sure non-generics can be dismissed just because they are non-generic. > Part of the point is to have inputs so that non-generic cases can be > property secured. > > LL > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
