Future-proofing VCs via multiple signatures

Hey folks,

Just throwing this out there as food for thought for now. There has been a bit
of debate in the VCWG about when certain signature formats will be standardized.

These have raised some questions, including: "When will BBS+ be through the
IETF process?", "What are we going to do about post-quantum crypto?", "What
about long-lived VCs?", "How do we enable stability and innovation at the same
time in a VC wrt. the signature format?".

Historically, when developers have to sign data, we've been forced to pick a
signature format and stick with it. So, historically, when you sign some data,
you have to pick ONE signature format.

This is changing, both with VCs and the Data Integrity specs (was: Linked Data
Proofs/Signatures), as well as with things like HTTP Signatures. You can now
support multiple signatures on a piece of data.

For example, this is supported (but not officially standardized) today with VCs:

{
  ... standard VC goes here ...,
  proofs: [
    {Ed25519Signature2020 goes here},
    {BbsBlsSignature2020 goes here},
    {PostQuantumSignature2022 goes here}
  ]
}

Here's a full example for a Verifiable Driver's License that has both an
Ed25519 signature, BBS+ signature, and a (yet to be specified) post-quantum
signature:

https://gist.github.com/msporny/ab415042ffd9c06ea3ad1ebd1df1da0a

What this means is that it is now possible to not have to depend on one
signature format, and instead use multiple to meet different needs. The VC
above supports NIST-approved cryptography today, while enabling the advanced
use of BBS+ (if an organization would like to use it /before/ it is
standardized at IETF), and also enabling protection if a quantum computer were
to break both Ed25519 and BBS+... all on the same VC in a fairly compact
format. The likelihood of all three signature formats being broken at the same
time are exceedingly low. Couple this with the new VC refresh feature, and you
can narrow the window in which a VC might be vulnerable even lower. So the
answers to the questions above become the following:

> "When will BBS+ be through the IETF process?"

It matters less if you can put two signatures on the VC... one using crypto
accepted by both IETF and NIST, and one with BBS+. This allows verifiers that
want a IETF/NIST-approved signature to request it, while allowing other
verifiers that want to live a bit more on the bleeding edge to do so by
requesting BBS+ proof.

> "What are we going to do about post-quantum crypto?",

We can add schemes while they're being standardized at IETF/NIST and those
that want to use them can, while those that don't can ask for an alternative
signature on the VC.

> "What about long-lived VCs?"

Adding multiple signature types (elliptic curve, pairing friendly, and
post-quantum) on the same VC increases the chances of that long-lived VC
surviving the technical failure of one of the signature formats.

> "How do we enable stability and innovation at the same time in a VC wrt. 
> the signature format?".

If organizations want to support stability and innovation at the same time,
they can do so by including multiple signatures on a VC.

Again, food for thought...

-- 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/

Received on Thursday, 6 January 2022 15:31:13 UTC