Closed selfissued closed 8 years ago
Omitting this is a simplification as key_ops provides the same set of information. There is no reason to have two methods to do the same thing.
For public keys, having the simple two-valued "use" parameter is substantially simpler than requiring the use of an array-valued "key_ops" parameter. This is the approach used by XMLDSIG/XMLENC and by many JOSE profiles. Given that public keys are the common case, it's one we should be optimizing for.
Given that this action has not been done, it is incorrect to categorize this issue as "complete". As with some other open issues, it would be useful to have more working group members than just Jim and myself weighing in on this. Thanks.
Given that a request for input on this topic was issued at the beginning of January and none was forthcoming, it seems reasonable to have closed this as a won't fix item.
No justification of this request has been made on the mailing list that states why it is better to have two versions of the same thing and why the proposed (and not commented on) solution was not better.
Hit the wrong button
Agree that this has not (yet) seen support from the WG. If such support arises then we can file a new issue or reopen this one. Thank you.
When characterizing key usage for public keys, the two-valued “use” parameter does the job. (The two values are “sign” and “encrypt”.) Restoring it would give COSE functional parity with XML DSIG, JOSE, and the WebCrypto API in this regard. The more complicated and array-valued key_ops is only needed when describing private key usage, which many applications never do.
This issue was previously described on slide 14 of the “COSE Key Issues And Choices” presentation at https://www.ietf.org/proceedings/93/slides/slides-93-cose-7.pdf.