I support the adoption of this work. However, as I have previously mentioned the use of "OKP" is not entirely clear. If we begin with the (original) definition of "kty":
https://datatracker.ietf.org/doc/html/rfc7517#section-4.1 The "kty" (key type) parameter identifies the cryptographic algorithm family used with the key, such as "RSA" or "EC". This seems very reasonable. The problem is that RFC8037 already uses "OKP" (albeit in a rather quirky way by putting X* and Ed* under the same moniker although they are entirely different application wise). draft-looker-cose-bls-key-representations-00 "overloads" OKP but does not mention RFC8037 although it for an implementer is pretty significant since it requires an update of existing OKP code. Suggestion: either write that this is an extension/reuse of RFC8037 or replace OKP with BLS. Personally I strongly prefer the latter. This issue is similar to enumerations which are quite bothersome to use in platforms that evolve over time. It doesn't come as a surprise that for example Java does not use enumerations to specify cryptographic algorithms but rather rely on a dynamic registry. This is slightly cumbersome to use but updating the platform core due to an added algorithm doesn't scale. Thanx, Anders _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
