[jose] To be covered topic? draft-tschofenig-jose-cose-guidance

[Ken Takayama <[e-mail]>]

Dear JOSE and COSE folks, especially the authors,

When I read this document, I feel that only key identification is covered.
Here I listed several topics that might be better to be covered,
hoping some of them are helpful to you.


## Guidance for Protocol Designers

[JOSE, COSE] Cryptographic algorithm choice
- start from RECOMMENDED+ algorithms (for JOSE), then RECOMMENDED, Optional, ...
- asymmetric vs symmetric
  - sign vs mac
  - key distribution and content encryption algorithms
- reference: draft-ietf-suit-mti

[COSE] Rough code size of the library (and depending ones)
- they may help protocol designers to choose supported algorithms,
especially for COSE to be used in constrained devices

[JOSE?, COSE] Deterministic KDF input
- it is just a binary in the final state, but strongly affects
interoperability and security
- RFC 7518 JWA (JSON Web Algorithms) is more clear but AlgorithmID of
COSE_KDF_Context in RFC 9053 is ambiguous
- we may need to make it clear that each values of KDF input is from
the JOSE/COSE message, or decided by protocol designers, senders or
recipients

[JOSE, COSE] jwt/cwt vs uccs
- reference: draft-ietf-cose-uccs


## Recommendations for JOSE/COSE Implementers

These recommendations are mainly for library implementers because
- most implementers of senders and recipients want to use libraries
because they don't want to encode/decode JOSE nor COSE messages
- since library users have less knowledge of the payload wrapper, the
library interfaces should be designed carefully and provide some
security mechanisms

I assume that the library functions take three arguments to
encode/decode the messages: payload or COSE/JOSE message, key or its
material, and KDF input filled by the senders and recipients.

[JOSE, COSE] Implement alg parameter for jwk and COSE_Key
- encourage/force the users to use it to avoid misuse of the key
inside the library

[JOSE, COSE] Disable Prohibited/Deprecated algs by default
- enable them only with explicit request from the users
  - e.g. flag arguments, splitted functions, compiler options, etc.
- warn users the risk of using them, and navigate users to RFC 9459 for COSE

[JOSE, COSE] Construct KDF input inside the library as much as it can
- keydatalen, AlgorithmID and SuppPubInfo are derived from the JOSE
message, and Z (?) and SuppPrivInfo are filled by the library
- AlgorithmID, keyDataLength and protected are derived from the COSE message

Best,
Ken