Thanks for your feedback, do you have an opinion on the registry point
Ilari made?
Should we put Kyber1024 in the Elliptic Curve Registry maintained by IANA?
Are you proposing we do something like this:
{ kty: Dilithium2, alg: DI2, x, d }
{ kty: Dilithium3, alg: DI3, x, d }
{ kty: Dilithium5, alg: DI5, x, d }
OS
On Tue, Nov 15, 2022 at 8:29 AM Mike Ounsworth <[email protected]>
wrote:
> Hi all,
>
>
>
> I admit that I’m an outsider and don’t grok why you need a KTY and an ALG,
> but the naming proposed below seems odd to me.
>
>
>
> I suppose you can group things into “LWE”, “NTRU”, “HASH”, but the various
> LWE schemes do not have interchangeable key types; a Dilithium3 key is a
> Dilithium3 key, you can’t use it with any other algorithm, even within the
> LWE family. So for anyone outside the PQC experts I think this is going to
> cause more confusion than help, ex.: people trying to use a Dilithium key
> with Kyber.encaps(), or whatever.
>
>
>
> I also don’t love “CRYDI3”. Why not just “DI3”? I would vote for a naming
> convention of “2-letter + param set” (which Orie suggested in a private
> email)
>
>
>
> FA512 / FA768 / FA1024 / DI3 / DI5 / KY768 / KY1024 / SP256
>
>
>
> “SPHINCS+-SHAKE-256s-robust” seems obscene, especially if you’re only
> supporting one variant. Do “SP256” or “SP256sr”. Also, I’m not a deep
> SPHINCS+ expert, but the “-robust” is probably overkill for JOSE / COSE. I
> think Scott Fluhrer suggested that it’s even overkill for 30-year windows
> code-signing certs, do “-simple” and save yourself 1/2 the bandwidth.
>
>
>
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>
>
>
> *From:* Orie Steele <[email protected]>
> *Sent:* November 13, 2022 3:00 PM
> *To:* cose <[email protected]>; JOSE WG <[email protected]>; Mike Ounsworth <
> [email protected]>
> *Subject:* [EXTERNAL] COSE and JOSE Keys for Kyber
>
>
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> ------------------------------
>
> Friends,
>
> Mike O. and I have been discussing the need to represent Kyber keys in
> JOSE and COSE, especially as we prepare to consider their use with HPKE.
>
> Mike P. and I have previously shared a draft for presenting Dilithium,
> Falcon and Sphincs -
> https://datatracker.ietf.org/doc/draft-ietf-cose-post-quantum-signatures/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-cose-post-quantum-signatures/__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIFXLOHms$>
>
> I reviewed the original registries established in:
> https://www.rfc-editor.org/rfc/rfc7518.html#section-7
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7518.html*section-7__;Iw!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIkFE2gTI$>
>
>
>
> I also reviewed the latest "kty" and "alg" registered in
> https://datatracker.ietf.org/doc/html/rfc8778
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8778__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIVxp-mn8$>
>
> I'm going to stick to JOSE(ish) notation here, my goal is to get a clear
> answer on
> *"which values for `kty` and `alg` are relevant to kyber". *
> See the latest editor's draft for additional details:
> https://github.com/OR13/draft-steele-cose-kyber
> <https://urldefense.com/v3/__https:/github.com/OR13/draft-steele-cose-kyber__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIlrb1NBk$>
> .
>
> First, let's start with what we have today:
>
> - https://www.iana.org/assignments/cose/cose.xhtml
> <https://urldefense.com/v3/__https:/www.iana.org/assignments/cose/cose.xhtml__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuI7xRKz4s$>
> - https://www.iana.org/assignments/jose/jose.xhtml
> <https://urldefense.com/v3/__https:/www.iana.org/assignments/jose/jose.xhtml__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIHk5wYN0$>
>
> { kty: RSA, alg: PS384 / RSAES-OAEP w/ SHA-256}
>
> { kty: RSA, alg: RS384 / RSAES-OAEP w/ SHA-256}
>
> { kty: EC2, crv: P-256, alg: ES256 / ECDH-ES+A256KW }
> { kty: OKP, crv: Ed25519, alg: EdDSA } -
> https://www.rfc-editor.org/rfc/rfc8037#section-2
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8037*section-2__;Iw!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuI1uryn64$>
>
> { kty: OKP, crv: Bls12381G1, alg: ??? } ...
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-bls-key-representations-01#section-2.1.3
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-cose-bls-key-representations-01*section-2.1.3__;Iw!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIQW72VRU$>
> { kty: HSS-LMS, alg: HSS-LMS }
> { kty: WalnutDSA, alg: WalnutDSA }
>
> Observations:
>
> 1. Although `alg` is optional... It looks especially needed in some cases
> (RSA), and especially not needed in others (HSS-LMS, WalnutDSA)
> 2. We appear to have slowly started to encode "Purpose" in the key type
> (HSS-LMS
> / WalnutDSA) , which suggests that we are commiting to keeping `alg`
> optional forever, and also acknowledging that it is best to use a key for a
> single purpose.
>
> 3. It is possible to define a key and NOT define any algorithms for it...
> (see bls-key draft above).
> 4. OKP is reserved for Elliptic Curves only.
>
> 5. IANA Registries exist for Elliptic Curves but no other "families" such
> as lattices, stateful hash based schemes, or stateless hash based
> schemes... based on HSS-LMS not attempting to fix this, it seems we are
> ok not establishing new IANA registries for lattice or hash types.
> 6. Walnut encodes parameters as separate values in the key type, but not
> the algorithm name... similar to RSA... which seems like a step backwards
> to me.
>
> Here is a proposal for Kyber keys that aligns with the previous proposals
> and drafts for post quantum signatures:
>
> { kty: LWE, alg: CRYDI5 }
> { kty: LWE, alg: CRYDI3 }
> { kty: LWE, alg: CRYDI2 }
>
> { kty: NTRU, alg: FALCON1024 }
> { kty: NTRU, alg: FALCON512 }
>
> { kty: HASH, alg: SPHINCS+-SHAKE-256s-robust }
>
> { kty: LWE, alg: Kyber-1024 }
> { kty: LWE, alg: Kyber-768 }
> { kty: LWE, alg: Kyber-512 }
>
> Please focus your comments on establishing consensus for relevant values
> for `kty` and `alg`.
>
> Regards,
>
> OS
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
> <https://urldefense.com/v3/__http:/www.transmute.industries__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIUR8efA4$>
>
>
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__https:/www.transmute.industries__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIup8-YOU$>
> *Any email and files/attachments transmitted with it are confidential and
> are intended solely for the use of the individual or entity to whom they
> are addressed. If this message has been sent to you in error, you must not
> copy, distribute or disclose of the information it contains. Please notify
> Entrust immediately and delete the message from your system.*
>
--
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries
<https://www.transmute.industries>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
