RE: Updating SafeCurves for 2022...

Regardless of the speed (or lack thereof) of both standardization and infrastructure support it feels as though cryptographic agility is still something that needs to be fully explored and baked into the VC/DID standards more than it has been, and on a parallel track socialized, accepted and utilized by the broader ecosystem.

However, based on out-of-band conversations I have had with some of you, I am not clear what exactly the term "cryptographic agility" encompasses here, so would appreciate some clarification.

Is it:

  1.  The ability for me deploy a solution that supports a particular cryptographic proof format and in the future upgrade it something else e.g. I choose some manner of a *pre-quantum* cryptographic scheme now and in the future have the ability to update my solution to something that uses a *post-quantum* cryptographic scheme?
  2.  The ability to deploy a solution that simultaneously supports multiple cryptographic schemes so that based on verifier policy regarding the features it can support, it can accept one, or the other, or both; OR a separate case being that one of the cryptographic schemes gets broken and there is a  way to signal that such that the verifier is sure to use the other non-broken scheme  e.g. I simultaneously deploy support for both FIPS compliant cryptography and for BBS+ signatures with the choice of what should be used at a verifier to be negotiated between the holder and the verifier.

If the (2) scenario is valid, does it automatically include (1)? And what are the trade-offs and considerations that are involved in deploying something like (2) into the ecosystem?

Best Regards,

Anil

Anil John
Technical Director, Silicon Valley Innovation Program
Science and Technology Directorate
US Department of Homeland Security
Washington, DC, USA

Email Response Time - 24 Hours

[A picture containing graphical user interface  Description automatically generated]<https://www.dhs.gov/science-and-technology>[/Users/holly.johnson/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1972159395]

Received on Thursday, 26 May 2022 20:53:33 UTC