On 2021-06-24 5:32, Carsten Bormann wrote:
On 23. Jun 2021, at 18:42, Mike Jones
<[email protected]> wrote:
I believe that we should create a policy requiring that all future algorithm
registrations should be non-polymorphic. Furthermore, I believe we should
consider defining and registering new non-polymorphic algorithm identifiers so
that use of the existing polymorphic algorithm identifiers can be avoided and
deprecated.
While I can’t see anything wrong with registering “ciphersuite” style algorithm
identifiers like ES256k, there also is nothing wrong with “pure” algorithm
identifiers.
"Wrong" may not be the right word here but having multiple strategies in
frameworks like JOSE and COSE adds confusion.
For CSF (CBOR Signature Format), I followed the path provided by EC and RSA and
thus redefined -8 to mean Ed25519 (like FIDO) and -9 (currently unreserved) to
mean Ed448. This enables a fully table-driven system.
Jim's reference code highlights the problem, you apparently need a custom
provider in order to use Ed25519:
https://github.com/cose-wg/COSE-JAVA/blob/master/src/main/java/COSE/SignCommon.java#L32
Anders
They just can’t be used with protocols that expect the full ciphersuite to be
specified in one number.
So I don’t see a reason to deprecate pure (parameter agnostic) algorithm
identifiers, but we may want to complement them with a couple of ciphersuite
identifiers each.
It would be useful if the registry had more data about what a specific
algorithm identifier actually is (e.g., if it can be used in WebAuthn).
I think we’ll need to do a cleanup of the registry with respect to such
descriptive columns, soon (compare the hash algorithms issue).
Grüße, Carsten
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
