Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]

[Ilari Liusvaara <[e-mail]>]

On Fri, Mar 11, 2022 at 03:34:08PM -0500, Russ Housley wrote:
> 
> 
> > On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara <[e-mail]> 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