I support adoption of this draft. Thanks, [MATTR website]<https://mattr.global/>
Tobias Looker MATTR +64 273 780 461 [email protected]<mailto:[email protected]> [MATTR website]<https://mattr.global/> [MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal> [MATTR on Twitter]<https://twitter.com/mattrglobal> [MATTR on Github]<https://github.com/mattrglobal> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it – please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. From: jose <[email protected]> on behalf of Simo Sorce <[email protected]> Date: Wednesday, 10 January 2024 at 9:26 AM To: Ilari Liusvaara <[email protected]>, [email protected] <[email protected]> Subject: Re: [jose] Call for Adoption: draft-jones-jose-fully-specified-algorithms EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. On Tue, 2024-01-09 at 17:24 +0200, Ilari Liusvaara wrote: > On Mon, Jan 08, 2024 at 10:28:01AM -0500, Simo Sorce wrote: > > On Tue, 2024-01-02 at 14:13 -0500, Karen ODonoghue wrote: > > > JOSE working group members, > > > > > > This email starts a two week call for adoption for: > > > https://datatracker.ietf.org/doc/draft-jones-jose-fully-specified-algorithms/ > > > > > > As discussed at the November IETF meeting, with the approved expansion of > > > the charter to include maintenance items, this document is now within > > > scope. > > > > > > Please reply to this email with your comments on the adoption of this > > > document as a starting point for the related JOSE work item. > > > > > > This call will end on Wednesday, 17 January 2024. > > > > > > While this draft is theoretically useful I am NOT in favor of its > > adoption for existing curves. > > > > The curve used is already implicit in the size of the signature, and > > besides servers generally only have a specific key they use so there is > > really no confusion, at worst you get an error during cryptographic > > operations, something you must always be prepared to deal with as it > > can always happen with untrusted input. > > > > Either way there is no practical ambiguity that really _needs_ to be > > resolved. > > Note that there is some confusion on what the actual issue is. > > The actual issue is not swapping of curves or algorithms, or that keys > can not be "fully specified", but that some widely used applications > assume that signature algorithm impiles key type. > > That of course breaks with Ed25519 and Ed448 in COSE/JOSE and ECDSA > in COSE. EdDSA can be used with either Ed25519 or Ed448 keys, and > ES* can be used with P-256/P-384/P-521 keys. > > With ECDSA, one could apply the hash algorithm convention, but this > does not work with EdDSA because there is only one alg for two key > types. > > What this draft defines is replacements for these that imply single > key type. So applications are buggy and need to be fixed, doesn't sound to me the same as applications are buggy and RFCs need to be changed. I understand that it would be nicer or easier to deal with pairing a key to an algorithm, but the cat is out of the bag, ECDSA and EdDSA already exist as is and those applications need to be fixed anyway (one way or another), why add additional interoperability issues in the mix by changing existing specifications ? You improve one self-inflicted problem by swapping it with a system- wide problem? Simo. -- Simo Sorce, DE @ RHEL Crypto Team, Red Hat, Inc _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
