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

[Ilari Liusvaara <[e-mail]>]

On Thu, Jul 25, 2024 at 12:55:27PM +0900, Ken Takayama wrote:
> 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.
> 
> ## 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

Yes, library API design is really important for security.


> 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

Then there is middle ground of requiring alg for symmetric keys but not
for asymmetric ones. The two seem really different.

 
> [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

Better yet, don't implement unsafe algorithms at all. "Disabling"
algorithms is much harder than it looks. There is litany of CVEs where
supposedly "disabled" algorithm rose like zombie from grave.


[COSE] How to mitigate the LAMPS attack in implementation.

- Ideally, don't implement unauthenticated encryption.




-Ilari