Orie, you wrote “We could have reused 5 for pub... should we do that?”.
Yes, I would suggest reusing existing field identifiers where they make sense.
The single-byte COSE identifiers are limited and it would be better to reuse
them than to needlessly create new ones with similar meanings to ones that you
could reuse.
And in JOSE, you probably want to use string identifiers that correspond to the
algorithm’s descriptions in the specs your referencing.
-- Mike
From: COSE <[email protected]> On Behalf Of Orie Steele
Sent: Sunday, October 22, 2023 2:08 PM
To: cose <[email protected]>
Subject: [COSE] Updates on Dilithium for JOSE and COSE
Hello,
We're not planning to publish new drafts for the post quantum signature for
JOSE and COSE items that are adopted.
We're still discussing / waiting for the names to solidify, and the final
versions from NIST to be published.
However we have made some progress towards complete representations for JOSE
and COSE of keys and envelopes.
Here are some rendered examples that are generated from an experimental
implementation, based on cloudflare's go library for dilithium.
https://github.com/transmute-industries/cose/tree/main/interop
Obviously all the code points for new things are placeholders, but I find them
easier to use than TBDs.
I wanted to draw attention to this pre-draft proposal for the COSE Key Type
Structure:
~~~~ cbor-diag
{ / COSE Key /
1: 7, / ✨ 7 is MLWE /
2: h'85eb5426...533214a2', / Identifier /
3: -55555, / ✨ -55555 is CRYDI2 /
-13: h'fbd0006c...f2f88c9c', / ✨ private key for 7 /
-14: h'fbd0006c...f2f88c9c', / ✨ public key for 7 /
}
~~~~
-13 and -14 are new private and public components for the new kty 7 (MLWE).
I noticed that
https://www.iana.org/assignments/cose/cose.xhtml#key-type-parameters
Has a lot of repeating "d",... has "x", "y", and "pub"... I think this
structure is a bit awkward, and confusing, but the time to fix it has passed....
In order to keep things simple, I am suggesting that the cose and jose key
types for dilithium, define new public and private components, and not re-use
"d" and "x", or "pub" (there is no priv to reuse)....
We could have reused 5 for pub... should we do that?
These proposed changes are not yet reflected in our drafts, but they seem worth
making so that folks implementing support for post quantum cryptography have
nice friendly labels for post quantum key types.
Current proposal would be:
/ kty / 1: 7, / MLWE /
/ priv / -13 : ... / ( short for private key or secret key) /
/ pub / -14 : ... / ( short for public key ) /
Feedback is welcome, we're still working on validating the implementation of
the drafts, generating better examples for the draft appendix... and of course
waiting for naming to settle down.
Regards,
OS
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries<http://www.transmute.industries/>
[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
