On Fri, Mar 11, 2022 at 03:34:08PM -0500, Russ Housley wrote:
>
>
> > On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara <[email protected]>
> > wrote:
> >
> > NISTPQC signatures would fit into signature keys "subtype", but NISTPQC
> > KEMs will not fit into the key agreement keys "subtype", so that would
> > be a third "subtype" (all NISTPQC algorithms have OKP-style key format,
> > as this was required by NIST).
>
> Right. It makes sense to add support for KEM. We can figure that out
> without waiting for NIST to announce Round 3 winners. We can do the
> work based on RFC 5990.
One idea how (modelled on ECDH-ES, as operation of KEMs is very similar
to ECDH-ES):
- Add new alg values KEM+{A{128,192,256}KW,HKDF-{256,512}}, mirroring
the ECDH-ES ones.
- Add new new header algorithm parameter "encapsulated ciphertext"
(bstr) that carries the KEM ciphertext.
- Sender procedure:
- Select the public key to encrypt to.
- Apply the KEM encapsulate operation to the public key.
- Use the encapsulate secret output as input for key derivation, just
like in ECDH-ES.
- Write the encapsulate ciphertext output into the "encapsulated
ciphertext" header algorithm parameter.
- Receiver procedure:
- Retretive the private key to use.
- Read the ciphertext input from the "encapsulated ciphertext" header
algorithm parameter.
- Apply the KEM decapsulate operation to the private key and the
ciphertext. If decapsulate fails, fail.
- Use the decapsulate secret output as input for key derivation, just
like in ECDH-ES.
A word of cauntion: Altough it might seem that the "encapsulated
ciphertext" header can be reused for HPKE, there is a subtle issue:
This mechanism can not trivially support compressing the ciphertext. So
reusing it would require HPKE to define compact NIST curves, so COSE
could just forget about key compression.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
