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 <[email protected]> wrote: > > > > 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 > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
