W3C home > Mailing lists > Public > public-credentials@w3.org > May 2022

Re: Updating SafeCurves for 2022...

From: Brent Shambaugh <brent.shambaugh@gmail.com>
Date: Thu, 26 May 2022 17:25:50 -0500
Message-ID: <CACvcBVpUMRaTf-2taY0whjr8L86aAPrOKvBpzDjPzMeXdJTsnw@mail.gmail.com>
To: "John, Anil" <anil.john@hq.dhs.gov>
Cc: W3C Credentials CG <public-credentials@w3.org>
I have worked with Ceramic and did-JWT and
https://github.com/sparkfun/SparkFun_ATECCX08a_Arduino_Library (p256 (NIST
FIPS) cryptographic co-processor that works with ESP32 mcu) due to ease of

Along the way I wondered if BBS+ signatures could be supported, but it was
something that seemed a long way off. The se050 seemed like an obvious next
step for more curves (maybe not Blake..but I found Tobias comment useful).

I am excited to hear about where this goes with my background knowledge
from  working on a prototype. I’ve had to play catch up reading your
documents. I’m sure you’ve seen me around.


On Thursday, May 26, 2022, John, Anil <anil.john@hq.dhs.gov> wrote:

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

-Brent Shambaugh

GitHub: https://github.com/bshambaugh
Website: http://bshambaugh.org/
LinkedIN: https://www.linkedin.com/in/brent-shambaugh-9b91259
Skype: brent.shambaugh
Twitter: https://twitter.com/Brent_Shambaugh
WebID: http://bshambaugh.org/foaf.rdf#me

(image/jpeg attachment: image002.jpg)

(image/jpeg attachment: image004.jpg)

Received on Thursday, 26 May 2022 22:26:03 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 26 May 2022 22:26:04 UTC