I agree with what you wrote, and I suspect developers will especially enjoy not needing to use COSE_KDF_Context.
I don't fully understand the details of how the binding to the protected header will be accomplished. Is the protected header binding always present in Enc_structure? Does it matter if the protected header excludes any algorithm details such as aead, mode, kem, or kdf? On Sun, Jul 2, 2023, 7:51 PM AJITOMI Daisuke <[email protected]> wrote: > 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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
