Yes, those are the assumptions. Whether those are good assumptions is another question because ultimately all we do is to make an optimization here to make the kem id an optional parameter. In the HPKE integration into TLS those assumptions do not appear to be made.
From: COSE <[email protected]> On Behalf Of Orie Steele Sent: Friday, November 18, 2022 2:41 PM To: Ilari Liusvaara <[email protected]> Cc: cose <[email protected]> Subject: Re: [COSE] Example for alternative proposals Just to be clear, kem is guessable in the examples based on `kid` and the assumption that the hint is enough to get the right private key, and that key will only ever have 1 supported kem, right? It's guaranteed to be known if private key is kty HPKE and kem is required... Right? OS On Fri, Nov 18, 2022, 5:09 AM Ilari Liusvaara <[email protected]<mailto:[email protected]>> wrote: On Fri, Nov 18, 2022 at 09:46:39AM +0000, Hannes Tschofenig wrote: > Hi all, > > We have two alternative proposals for encoding the HPKE-related information, > namely > * Ilari's proposal: https://github.com/cose-wg/HPKE/pull/10 > * Daisuke's proposal: https://github.com/cose-wg/HPKE/pull/9 > > While Daisuke's proposal contains an example (although we are still > debating about how it should look like), Ilari's proposal does not > have one yet. > > It would be good to have an example (or even multiple examples) to > discover inconsistencies with the proposals. I think translating the one layer example is straightforward, since the only real difference is encoding of COSE_HPKE_Sender (I don't think that even affects any cryptographic calculations): // Example of COSE-HPKE (Encrypt0) // payload: "This is the content", aad: "" // 16([ h'a10120', // alg = HPKE (-1) { 4: h'3031', // kid -4: [ // HPKE sender information 1, // kdf = HKDF-SHA256 1, // aead = AES-128-GCM h'048c6f75e463a773082f3cb0d3a701348a578c67 80aba658646682a9af7291dfc277ec93c3d58707 818286c1097825457338dc3dcaff367e2951342e 9db30dc0e7', // enc 16, // kem = DHKEM(P-256, HKDF-SHA256) ], }, / encrypted plaintext / h'ee22206308e478c279b94bb071f3a5fbbac412a6effe34195f7 c4169d7d8e81666d8be13', ]) The optional kem field is included because the original examples also had those (even if the kem should be easily guessable). The two layer example looks to be errorneous: It uses HPKE as outer algorithm, which is not possible, as outer algorithm must be symmmetric bulk cipher (e.g., AES-GCM or Chacha20-Poly1305), but HPKE is always either asymmetric or hybrid. The recipient structure, which seems to be sane, translates in a straightforward way: [ h'a10120', // alg = HPKE { 4: h'3031', // kid -4: [ // HPKE sender information 1, // kdf = HKDF-SHA256 1, // aead = AES-128-GCM / enc output / h'0421ccd1b00dd958d77e10399c 97530fcbb91a1dc71cb3bf41d9 9fd39f22918505c973816ecbca 6de507c4073d05cceff73e0d35 f60e2373e09a9433be9e95e53c', 16, // kem = DHKEM(P-256, HKDF-SHA256) ], }, // ciphertext containing encrypted CEK h'bb2f1433546c55fb38d6f23f5cd95e1d72eb4 c129b99a165cd5a28bd75859c10939b7e4d', ], Again, the kem should be guessable, but was included as it was in the original. -Ilari _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
