<#secure method=pgpmime mode=sign>
I have no opinion about this document, but enjoyed reading Hannes' review.
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?
Should our specifications pessimistically coddle poor choices, or
optimistically aspire towards well designed software architectures?
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?
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.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
