Hi Michael, ~~~ snip ~~~
Hannes Tschofenig via Datatracker <[email protected]> wrote: > Even on a smaller scale (with the key id) this already creates problems > for developers of COSE / JOSE libraries because the layers get combined > and important security decisions are outsourced to the developer. We > know that developers, who use these libraries, are unable to make good > security decisions. Are they unable, unwilling, or ignorant? [Hannes] I really don't know. Should our specifications pessimistically coddle poor choices, or optimistically aspire towards well designed software architectures? [Hannes] There is some history about what has gone wrong. We need to collect those cases and try to avoid it next time. My favorite is the "none" JWT algorithm that caused signature parsing to be skipped altogether. (Search for "none" and "JWT" and you will find a lot of hits.) I have to wonder if there are patterns (and anti-patterns) in library APIs that support better decisions, or encourage worse decisions. Are there language features that are better/worse here? [Hannes] We should organize a "workshop" or "side-meeting" to talk about this topic. I am curious what other folks are seeing. I also wonder about the role of certifications (FIPS-140 specifically) that seem to force developers into (ab)using less well designed libraries, or prevent them from fixing libraries to suit their application needs. [Hannes] Good question. The automated testing as part of the OpenID Connect Foundation conformance testing, which is self-certification, is an example where implementations have been checked and subsequently fixed. FWIW Mike was instrumental in getting that effort in the OpenID Foundation going. Maybe we need more of those activities but also fewer options in our specifications. Ciao Hannes -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
