Hi Ilari, You are again raising good points, namely
1) Should we convey the KEM ID, and KDF ID explicitly? I think so. 2) If we do, where should this information go? You suggest to put them into the COSE key (ephemeral key) structure. I would have thought that the unprotected header would be more appropriate but I do not really have a strong preference. 3) Should we define a new kty id? If we place the KEM ID and the KDF ID into the COSE key structure then I think it would be a good idea to define a new kty id. I am curious what others in the group think about this idea. I lost you when you are were talking about the "size issues" and tried to solve the issues. Maybe you could elaborate a bit what problem you see. IMHO we cannot use COSE_Encrypt0 because we need the recipient structure, which is not present with the COSE_Encrypt0. You also seem to define new key formats. What prevents us from re-using the existing COSE key formats? Section 13 of RFC 8152 defines various ECC key formats and those could be re-used. Since there is no compressed point format, we could add it. I am also not sure why you talk about PQC algorithms. Neither COSE nor HPKE define PQC algorithms. Do you think we should define them in this document? Ciao Hannes -----Original Message----- From: [email protected] <[email protected]> Sent: Thursday, January 20, 2022 6:49 PM To: Hannes Tschofenig <[email protected]> Cc: [email protected] Subject: Re: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01 On Tue, Jan 18, 2022 at 11:20:34AM +0000, Hannes Tschofenig wrote: > Hi Ilari, > > [Hannes] I think you are suggesting to do this: > > 96( > [ > // protected field with alg=AES-GCM-128 > h'A10101', > { // unprotected field with iv > 5: h'26682306D4FB28CA01B43B80' > }, > // null because of detached ciphertext > null, > [ // COSE_recipient_outer > > / protected / h'a1013818' / { > \ hpke-alg \ 1:16 \ HPKE/P-256+HKDF-256 \ > hpke-aead-id: 1 // AES-128-GCM > } / , > / unprotected / { > // HPKE encapsulated key > / ephemeral / -1:{ > / kty / 1:2, > / crv / -1:1, > / x / -2:h'98f50a4ff6c05861c8...90bbf91d6280', > / y / -3:true > }, > // kid for recipient static ECDH public key > / kid / 4:'[email protected]' > }, > // Encrypted CEK > h'FA55A50CF110908DA6443149F2C2062011A7D8333A72721A', > ] > ] > ] > ) Yeah, thereabouts. I am not sure what is the best precise variation to use. - I would like there being generic support for all HPKE algorithms. The most compact way of doing this is: * Have new alg=hpke. Which has the AEAD id as parameter. * Have new kty=hpke. Which has the KEM and KDF ids as parameters, as well as raw public/encapsulated key. However, this runs into size issues with P-x curves. HPKE encapsulated key for KEM=33, KDF=2, would be roughly: -1:{ 1:<id-kty-hpke>, -1:33, -2:2, -3:h'...' } This would be 11 bytes of overhead, assuming typical PQC sizes. - Solving the P-x size issues, option a): * With EC2, do not include explicit KEM and KDF ids. * The public keys are unpacked into public/encapsulated keys. Roughly corresponds to the above, but with no hpke-alg. - Solving the P-x size issues, option b): * Use the HPKE kty, with negative KEM id. * Pack the P-x keys using the same compression as in C509. AFAICT, this is one byte more compact than a) with P-x keys. The ephemeral key would roughly be: -1:{ 1:<id-kty-hpke>, -1:-1 -3:h'0398f50a4ff6c05861c8...90bbf91d6280' } For X25519 and X448, the both options above save 3 bytes. And looks like I underestimated the space savings from cose_encrypt0 if one only has one recipient. The savings are more like 50 bytes or so (more for 192-bit and 256-bit levels). -Ilari 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
