On 2022-07-11 18:20, Ilari Liusvaara wrote:
On Mon, Jul 11, 2022 at 10:26:18AM -0500, Orie Steele wrote:
Would you mind replying with hypothetical JWK representations and a label
to refer to them, so we can work towards consensus on draft revisions?
I am hearing a preference for more specific, which aligns with my option 2,
but you go even further to include parameters in the `kty`...
Option 4:
<snip>
To me, this is starting to contradict the original RFC text... because
the `kty` no longer refers to a "family" it refers to an "individual".
I think the JOSE RFC text is based on obsolete assumptions.
If this is the case an errata should be issued.
What I think it assumes is that wild internal differences cause wild
external differences. That is, each "family" has different "keyshape".
However, that assumption is no longer true with modern cryptographic
design.
Object-oriented crypto APIs of the kind I'm working with do not burden
application developers with key shapes except when transforming back or forth
from external representations (*).
In such systems, an X25519 key is class wise distinct to an Ed25519 key.
As a consequence, the "family" concept remains relevant for application
developers which is the primary target for such systems, while giving crypto system
implementers freedom creating the perfect internal representation.
I doubt this will change because it is helping application developers who only
occasionally qualify as cryptographers, which BTW include yours truly :)
This also explains why we end-up with different conclusions.
Anders
*) My hope is that this step eventually can be delegated to the platform but we
are not there yet (except for X.509 public keys).
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
