Hi Hannes, Ilari and Laurence
I think Ilari's proposal below is a good one.
One point I would like to clarify is whether the mode information (Base,
Auth, PSK or AuthPSK) and HPKE version information should be defined in
HPKE Sender Information (HSI) as optional.
I had previously suggested putting a sender public key as an optional
parameter to HSI, but as Ilari pointed out, it was wrong. What should have
been included was the mode information.
The need for the mode information is also pointed out by Laurence on the
Github issue (https://github.com/cose-wg/HPKE/issues/13).
If the HSI needs to have more than one optional parameter, then the array
structure is not suitable for it and my proposal might be better. If it
doesn't, then Ilari's proposal is better.
// 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',
> ])
Best,
Daisuke
2022年11月19日(土) 0:16 Orie Steele <[email protected]>:
> Inline:
>
> On Fri, Nov 18, 2022 at 7:56 AM Ilari Liusvaara <[email protected]>
> wrote:
>
>> On Fri, Nov 18, 2022 at 07:41:14AM -0600, Orie Steele wrote:
>> > 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?
>>
>> Yes, it is guaranteed to be known if private key kty is HPKE, since the
>> kem field in key is required (it subtypes the key).
>>
>> And it should always be known even for kty != HPKE keys, since it is
>> unlikely that there ever will be two KEMs that can use the same key and
>> have the same enc length.
>>
>
> This is one of my concerns with adding kty:HPKE, since kem can be
> inferred even when kty:EC...
>
> You might have a case where the header has left off the kem...
>
> and the kid pointed to a key that was not kty: HPKE, that also did not
> have a kem...
>
> Building on your examples:
>
> // 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
> ],
> },
> / encrypted plaintext /
> h'ee22206308e478c279b94bb071f3a5fbbac412a6effe34195f7
> c4169d7d8e81666d8be13',
> ])
>
> // Example of COSE Key for HPKE (in JOSE syntax for readability)
> {
> kid: h'3031'
> kty: HPKE or EC
> crv: P-256 // required for kty:EC, optional for kty:HPKE ?
> kem: DHKEM(P-256, HKDF-SHA256) // required for kty:HPKE, optional for
> kty:EC ?
> alg: HPKE, // always optional?
> x,
> y,
> d
> }
>
> A complete example of a header and key for both JOSE and COSE would really
> help,
> but I can keep guessing, if guessing seems to be what we are recommending
> implementers do :) (sorry if this humor lands poorly).
>
> I don't think we are going to make progress on these issues without
> showing both the key representation and the header expressions.
>
> I don't have a strong opinion for either PR based on the current examples
> in them.
>
>
>> Currently all KEMs in HPKE use different keys, but e.g., the CP-* stuff
>> would have the same keys as existing P-* KEMs, but the enc length is
>> smaller (that is the whole point of CP-*).
>>
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> COSE mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/cose
>>
>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
