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

Reply via email to