On Apr 24, 2023, at 12: 46 AM, Ilari Liusvaara <ilariliusvaara@ welho. com> wrote: On Sun, Apr 23, 2023 at 12: 59: 08PM -0700, Laurence Lundblade wrote: On Apr 22, 2023, at 12: 54 AM, Ilari Liusvaara <ilariliusvaara@ welho. com> wrote: On
On Sun, Apr 23, 2023 at 12:59:08PM -0700, Laurence Lundblade wrote:On Apr 22, 2023, at 12:54 AM, Ilari Liusvaara <[email protected]> wrote:
On Fri, Apr 21, 2023 at 06:15:31PM -0700, Laurence Lundblade wrote:
A couple of observations:
HPKE isn’t an algorithm like RSA or the PQ algorithms or EC. It’s a
user of those algs (except RSA). We’re not defining new a key type the
way RFC 8230, RFC 8812 and RFC 9053 do. We already have the key types
to work with HPKE KEMs. Seems like the sole thing is to define how
alg restriction with the alg parameter works for HPKE.
I do not think this is correct.
- We do not have key tpyes to work with HPKE KEMs. All the current ones
yes, but that is one expert review away from changing. In contrast,
the HPKE kty truly offers key type for all HPKE KEMs.
These are just key serialization formats. I don’t see why an expert
would disallow them or what the basis of that prohibition would be.
The threat that an expert will revoke use of key type with HPKE is
probably not a good strategy to win people over to HPKE. It makes me
look at the lack of policy and criteria for the HPKE IANA algorithm
registry with worry. It would also be hard to enforce any sort of
global prohibition.
I did not mean any prohibition or any sort of revocation.
I know writing the details out for us non-cryptographers is a pain, but it can be helpful and avoid misunderstandings (this is not a sarcastic comment).
I meant, e.g., draft-cfrg-schwabe-kyber-01 getting approved in expert
review. Afterwards, the present kty's are no longer sufficient.
But all use of kyber will not be in HPKE, right? Others will use it for other protocols. So there must be a kyber key serializations that are not based on HPKE.
I don’t want a new kty for HPKE.
- A new key type would bring the need for conversion to/from
The new key type would directly encode values to/from HPKE, makingthe conversion trivial.All the other kty's require nontrivial conversion.- OKP needs remapping the crv value.- EC2 needs highly nontrivial conversion, including point decompression.
Crypto libraries have an internal representation that is different and separate from the serialization format. In MbedTLS it is a psa_key_handle_t. OpenSSL has several, one of which is EVP_PKEY. These are the representations that the actual ECDH implementation uses. There must be conversion from the serialized key to the internal representation.
Conversion from DER serialized EC keys is already widely implemented.
The OKP and EC2 for EC keys are some years old now. There are implementations now and more coming.
I think the work here is relatively easy or is already done. It is not nontrivial.
Implementing desrialization of OKP and EC2 benefits all users of EC keys in the COSE world, not just the HPKE world. I expect that COSE_Key is in spirit CBOR_Key — it’s the CBOR key serialization format alternative to DER that will be used beyond COSE.
If OKP and EC2 are so bad that we can’t implement them for HPKE, wouldn’t they also be bad for all the other CBOR uses of EC keys?
I don’t see how defining key serialization specific to HPKE adds much. It’s just another serialization format that has to be implemented in libraries, HW and such. There’s not going to be a psa_hpke_handle_t in MbedTLS or an EVP_HPKE_PKEY in OpenSSL is there? It’s not a candidate to replace OKP and EC2 for all use cases, right? And it’s kind of the same with keys for kyber. We want a serialization format that is not HPKE specific.
LL
smime.p7s