Hi Ilari, Thanks for the examples. Those reflect my view as well.
Only one minor question: In the " P256/Chacha encrypted message" examples you set the "EC identifier (crv)" to "1" (P-256) for key type 2 "EC2". This is inline with what I did in https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-01. However, in light of your mail regarding new algorithms registry in your email https://mailarchive.ietf.org/arch/msg/cose/Hllzp2Pznnqcr1XcL2zYWOHjyT0/ I was wondering whether the value shouldn't be COSE_CRV_HPKE_P256_SHA256 instead. Your examples use the newly proposed COSE_HPKE_* algorithms but none of the COSE_CRV_HPKE_* elliptic_curve values. Ciao Hannes X25519 public key: { 1: 1, / kty => OKP / 2: h'623FCA05CED1C293', / Some random kid / -1: -65540, / crv => -65540 (HPKE X25519 with SHA256) / / Raw public key data, 32 bytes / -2: h'56D7B1DEBC69B56EE457E518DB604EF60CF528A91E08B6326C112D9E886BC135' } P256 public key: { 1: 1, / kty => OKP / 2: h'1F677209D1C5174C', / Some random kid / -1: -65537, / crv => -65537 (HPKE P256 with SHA256) / / Raw public key data, 65 bytes / -2: h'040E271193AE34E989C5BDD36A8AF81391B62A2501A49203EA7511B5CC4E44A5753FAB35EA9E5FDEAF037E2B24CB1FF21C4C4AF1ED8AF3A91C4FECF69187DA4369' } X25519/Chacha encrypted message (test\n): [ / { alg => -65539 (HPKE Chacha20Poly1305) } / h'A1013A00010002', { 4: h'623FCA05CED1C293', / kid copied from the key / / Uncompressed ephremeral key / -1: { 1: 4, / kty => symmetric / / Uncompressed raw key, 32 bytes / -1: h'580C05EF2AADBB07DE02BD44A2654CABF575689CAF067BA61BF3ACF74DF76138' } }, / 5+16 = 21 bytes ciphertext. / h'B9A8708F3E956001A273511B013371A518503E9D6A' ] P256/Chacha encrypted message (test\n): [ / { alg => -65539 (HPKE Chacha20Poly1305) } / h'A1013A00010002', { 4: h'1F677209D1C5174C', / kid copied from the key / / Compressed ephremeral key. Note that this could be / / Replaced by the 65 byte decompressed key marked as / / symmetric-type and the message would still decrypt. / -1: { 1: 2, / kty => EC2 / -1: 1, / crv => P-256 / / x-coordinate of point, 32 bytes / -2: h'96E997A98294937ED395D4B29673BB163C87313F9ECBF887B9CA15D7A5C5E675', -3: true / y coordinate is odd / } }, / 5+16 = 21 bytes ciphertext. / h'6F7E60C1DCCCDD5F4C8CD02942B92A9AAA6492ED1D' ] Regarding defining a new key type, the key type could then be defined to carry explicit HPKE KEM/KDF algorithm identifiers in long-term keys, removing any need to track those in COSE. Any new KEMs/KDFs defined by HPKE would instantly become usable in COSE. -Ilari _______________________________________________ COSE mailing list [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
