Sorry I meant reuse -1 for pub. In JOSE can we use pub and priv instead of x and d?
I don't understand what the convention is for choosing integer value for COSE Key. it seems like each kty value, can decide how to map each key parameter... But this means that key type parameters are not globally unique, and -4 could be mapped to "pub" for some future key type 7 or 8... It seems like it would have been logical for each new key type, to just start counting from -1 down, for each new parameter required But instead EC2 and OKP share -2 as x, -4 as d... -1 is crv for EC2, but -1 is pub for LMS. So which convention should we use to select the integer for kty: 7? We need to assign a number to public and private components. -1 and -2? Or -2 and -4? Seems like -1 for pub and -2 for priv is the way to go for 1:7. On Sun, Oct 22, 2023, 5:28 PM Michael Jones <[email protected]> wrote: > 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 > > <https://transmute.industries/> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
