On Sun, Jul 10, 2022 at 11:09:45AM +0000, Hannes Tschofenig wrote:
> 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.
In my code, the ephremeral key compression is entierely separate
function. The keys are not cross-checked against long-term keys or
against anything else in the message. That is, the code will happily
proceed to decompress key on the wrong curve and then feed it to HPKE
(which then will barf on bad key).
And COSE_CRV_HPKE_* constants do appear in the example public keys.
This also reflects the fact that it is much more complicated to add
(de)compression support for a curve than it is to support a new KEM
supported by the underlying HPKE library. The latter is literially one-
liner containing the information that is absolutely required for
function (COSE codepoint number, HPKE KEM, HPKE KDF and name for
keygen).
> 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
