> Using hkc there is a bad idea (it says what KEM is supported, not what KEM it is).
I don't think it's a bad idea. In the new kty "HPKE-KEM", it may be possible to make "hkc" be MUST, so I think there is no need to hesitate to use the hkc::kem. AJITOMI Daisuke 2023年5月2日(火) 15:55 Ilari Liusvaara <[email protected]>: > On Mon, May 01, 2023 at 11:00:48PM -0700, Laurence Lundblade wrote: > > Here’s a clarification request. Here’s the proposal for the new kty: > > > > 4.2. Key Type for COSE_Key > > > > A new generic kty(1) value HPKE-KEM(T.B.D.) is defined to represent > > the private and public key used for the HPKE KEM. A key with this > > kty has the following parameters: > > > > * The parameter kty(1) MUST be HPKE-KEM(T.B.D). > > > > * The parameter hkc(T.B.D.) MUST be present and contains the HPKE > > Key Configuration defined in Section 3.2.1. > > > > * The parameter pub(-1) MUST be present and contains the public key > > encoded in a byte string (bstr type). > > > > * The parameter priv(-2) MUST be present if the key is private key > > and contains the private key encoded in a byte string (bstr type). > > Using hkc there is a bad idea (it says what KEM is supported, not what > KEM it is). I think it should be something like: > > * The parameter kty(1) MUST be HPKE-KEM(T.B.D). > > * The parameter kem(-1) MUST be present and contains the HPKE > KEM identifier (uint type). > > * The parameter pub(-2) MUST be present and contains the public key > encoded in a byte string (bstr type). > > * The parameter priv(-3) MUST be present if the key is private key > and contains the private key encoded in a byte string (bstr type). > > > > How will you know what the actual serializations for pub(-1) and > > priv(-2) will be? They have to vary by KEM, right? > > Opaque for COSE-HPKE; It is defined by the KEM. > > Of course, one needs to know the HPKE KEM identifier to make any sense > of the key. E.g., both X25519 and CP-256 have 32-byte public keys, and > one would expect >10% of bit patterns be valid for both. > > > > Also tried to figure out what Ilari’s 1212481536 is. Most KEM and > > curve IDs are small integers. > > It is offset between HPKE kem and COSE crv spaces. > > Such offset needs to exist, because this mapping needs a contiguous > block of 65536 crv, and values like 4 are already allocated on COSE > side, but available for allocation on HPKE side. > > And to not hog 1-, 2- or 3-byte space, the offset needs to be at > least 65536. And for keeping it in 5-byte space (which is plentiful), > the offset can be at most 4294901760. > > BTW, 1212481536 = 0x48450000. And in ASCII, 0x48 => H, 0x45 => E. > > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
