Re: [jose] [COSE] Consensus on cryptographic agility in modern COSE & JOSE

[AJITOMI Daisuke <[e-mail]>]

Hi Maru,

The following article is a good summary of a modern take on the
> concerns related to "cryptographic agility":
> https://www.blockchaincommons.com/musings/musings-agility/


Thank you for the information. However, this article has already been
shared previously on this COSE WG mailing list, and I have sent comments to
the author, Christopher, regarding this article.

https://mailarchive.ietf.org/arch/msg/cose/KqFj9VqJ0Fjk45fEPh-Ys8HZiP8/

As I also mention in the link above, I am an implementer of JOSE/COSE and
also an implementer of PASETO, which adopted the "Versioned protocol"
approach born from the criticism of JOSE's cryptoagility feature.

Based on my experience and observations, the Versioned Protocol approach is
not as bad as Ilari mentioned (in fact, I found it easy to implement and
quite like it), but it doesn't seem to be working well in the real world.
In fact, the version switching of PASETO has not been going well at all.

In my opinion, a better approach would be to make a generic cryptographic
utility layer (like COSE or JOSE) be cryptoagility-oriented as much as
possible, and then narrow down the choice of cryptographic algorithms as
needed in higher-level, application-specific specifications.

Best regards,
AJITOMI Daisuke

2023年3月26日(日) 23:27 Manu Sporny <[e-mail]>:

> On Sun, Mar 26, 2023 at 9:49 AM AJITOMI Daisuke <[e-mail]> wrote:
> > Taking Ilari's post into account, I would like to take some time to
> reconsider my proposal and your raised issue.
>
> The following article is a good summary of a modern take on the
> concerns related to "cryptographic agility":
>
> https://www.blockchaincommons.com/musings/musings-agility/
>
> The Data Integrity work that is happening at the W3C, in the
> Verifiable Credentials WG, is an example of an approach that attempts
> to greatly reduce the number of parameters that a non-expert developer
> has access to when configuring cryptographic systems:
>
> Approaches such as "cryptographic agility", "cryptographic layering",
> and versioning are covered here:
>
> https://www.w3.org/TR/vc-data-integrity/#agility-and-layering
> https://www.w3.org/TR/vc-data-integrity/#versioning-cryptography-suites
>
> The design philosophy behind that approach is the notion that a
> non-trivial number of developers that utilize cryptographic libraries
> in application-space are ill equipped to know how to properly choose
> cryptographic parameters, so exposing them to the ability to configure
> those parameters is less safe than choosing good defaults for them.
> Choosing between P256 or RS256 or HS256, or why one would use SHA2-256
> or SHAKE-256, and so on are difficult choices for non-experts.
>
> Therefore, the "cryptosuites approach" attempts to provide reasonable
> defaults (with new versions released when needed) to those developers
> such that the chances of them trying to work with parameters that they
> don't have the skillset to pick are greatly reduced (or, ideally,
> eliminated). This is the approach that systems like Wireguard have
> taken in the Linux kernel. Reduction in parameter choice in
> cryptographic algorithms also leads to, as has been noted in this
> thread, less fan-out and thus an easier audit surface and a reduced
> attack surface.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>