On Fri, Jul 08, 2022 at 11:01:46AM +0000, Hannes Tschofenig wrote:
> Hi Ilari,
>
> I have been thinking about this a bit more and the disconnect between
> your approach and mine is that you assume HPKE defines a wire format
> for the ephemeral public key. I think it does not, as I mentioned in
> an earlier email (see
> https://mailarchive.ietf.org/arch/msg/cose/HL5jG5s2e5c49y3d4w6y_3BDRrA/).
>
> Could this be the case?
>
> Ciao
> Hannes
>
> -----Original Message-----
> From: COSE <[email protected]> On Behalf Of Hannes Tschofenig
> Sent: Friday, July 8, 2022 11:12 AM
> To: Ilari Liusvaara <[email protected]>; [email protected]
> Subject: Re: [COSE] HPKE: Ephemeral public key encoding
>
> Where in this structure is information about the type of key that
> is being carried here? Where would the curve identifier go in your
> examples (since it is not included in your snippet)? How do you
> distinguish between compressed and uncompressed point representations?
>
>
> Ciao
> Hannes
>
> PS: I wonder whether the encoding of an ephemeral public key as a
> symmetric key will cause confusion among developers and readers. I am
> tempted to just define a new COSE Key Type instead.
For illustrating the format, here are some cbor2diag dumps of written
files, with some comments added:
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
