> On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <[email protected]> wrote:
>
> 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.
If you are talking about ECC Point Compression, I agree that COSE should ignore
it. For a very long time, the patent kept many implementations from supporting
it. Now that patent has expired, but the engineering effort to add support for
ECC Point Compression is significant, and everyone will have to be prepared to
encounter implementations that are not yet prepared to handle compression. The
savings of 32 bytes does not seem worth the transition pain.
Russ
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
