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

Requiring “alg” in a JWK for one class of algorithms and/or key type values would be non-parallel to other algorithms and/or key type values.  This matters not just for aesthetic reasons but also because it would make the JWK Thumbprint calculations [RFC 7638] have to special-case these algorithms and/or key type.

Yes, you always need to know the “alg” when using a key – but in JOSE and COSE you already authoritatively get that from the JOSE or COSE header parameters.  I believe there’s insufficient reason to make things different for this new class of algorithms.

                                                       -- Mike

From: COSE <cose-bounces@ietf.org> On Behalf Of Orie Steele
Sent: Monday, March 14, 2022 8:20 AM
To: Russ Housley <housley@vigilsec.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>om>; cose@ietf.org
Subject: Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]

Refocusing on the "kty" : "OKP" vs "PQK" issue.

As I understand it, "alg" is optional even when "kty": "OKP"... so a main reason to choose "kty": "PQK" would be to say that "alg" is now required... If we think overloading "OKP" would cause harm, we should make the new "kty" bring more to the table, such as mandating the presence of "alg".

I expect we will be marking "alg" values as forbidden (when the become unadvisable), and not marking whole "kty" families as forbidden in the future... having the "alg" be required in "kty" "PQK"  seems like it provides a better security posture in that context, but eager to hear from others.

Regards,

OS

On Sun, Mar 13, 2022 at 11:39 AM Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>> wrote:

> On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <ilariliusvaara@welho.com<mailto:ilariliusvaara@welho.com>> wrote:
>
> On Fri, Mar 11, 2022 at 03:34:08PM -0500, Russ Housley wrote:
>>
>>
>>> On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara <ilariliusvaara@welho.com<mailto:ilariliusvaara@welho.com>> 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
COSE@ietf.org<mailto:COSE@ietf.org>
https://www.ietf.org/mailman/listinfo/cose

--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<http://www.transmute.industries>

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries/>