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
