Re: Future-proofing VCs via multiple signatures

Leonard Rosenthal wrote:

> Since each of the signatures/proofs is associated with a different key
> pair – how does the validator know which one(s) to trust?

Wouldn't a collection of two or more signatures for a single object be the
equivalent of an object that was signed by an equal number of completely
independent signers? In the multiple signer case, the validator would
search among a potentially very large number of signatures to find one(s)
that it trusted more than others. (I might trust that Alice's signature
provides some useful semantic content, but not Bob's.) Trust comes from
knowledge of the signer, not from anything inherent to the signature
itself. Without having trust in the signer, the signature only serves as a
checksum for state of the signed object at the moment it was signed.

bob wyman


On Thu, Jan 6, 2022 at 12:02 PM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> I might be missing something here, but doesn’t this approach open up an
> attack/abuse vector?
>
>
>
> For this to work, the proof is over everything except the stuff in the
> `proofs` key..otherwise, you couldn’t have multiple values…. Correct?
>
>
>
> Since each of the signatures/proofs is associated with a different key
> pair – how does the validator know which one(s) to trust?  What prevents a
> bad actor from adding their own proof on a VC after the original issuer one
> has expired?
>
>
>
>
>
> The other question this raises for me is about use cases for this
> approach.  If I were an education institution that offers joint
> accreditation with a secondary institution – would you see this as a way
> for the VCs that we issue to have signatures from **both** institutions??
>
>
>
> Leonard
>
>
>
> *From: *Manu Sporny <msporny@digitalbazaar.com>
> *Date: *Thursday, January 6, 2022 at 10:34 AM
> *To: *W3C Credentials CG <public-credentials@w3.org>
> *Subject: *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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fmsporny%2Fab415042ffd9c06ea3ad1ebd1df1da0a&amp;data=04%7C01%7Clrosenth%40adobe.com%7C9fbb6d55fc3c4b3cd22908d9d129db83%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637770800887059226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=dVDE5OU3h%2BuOSwsPnD360JnU8TLosFQ3zvA6Cz0ylec%3D&amp;reserved=0
>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&amp;data=04%7C01%7Clrosenth%40adobe.com%7C9fbb6d55fc3c4b3cd22908d9d129db83%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637770800887069177%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3yElzs5jz29lqnEpWrgtg%2FSjioalohnVzYH1OYRxqaM%3D&amp;reserved=0
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.digitalbazaar.com%2F&amp;data=04%7C01%7Clrosenth%40adobe.com%7C9fbb6d55fc3c4b3cd22908d9d129db83%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637770800887069177%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xn6CCPBznKLpcyy%2FiRby0TKDav%2BnSC%2FYE85nB1MtK6k%3D&amp;reserved=0
>
>