Hi Michael,
~~~ snip ~~~
Hannes Tschofenig via Datatracker <noreply@xxxxxxxx> 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 <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
_______________________________________________
COSE mailing list
COSE@xxxxxxxx
https://www.ietf.org/mailman/listinfo/cose
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
