Re: Use of cryptography with W3C VCs and DIDs released

On Thu, Apr 21, 2022 at 10:54 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> SRI International has publicly released their independent review on the
> use of
> cryptography in W3C VCs and DIDs and made some recommendations:
>
> Cryptography Review of W3C Verifiable Credentials Data Model (VCDM) and
> Decentralized Identifiers (DIDs) Standards and Cryptography Implementation
> Recommendations by David Balenson & Nick Genise
>
> http://www.csl.sri.com/papers/vcdm-did-crypto-recs/
>
> It's largely a view from the US NIST cybersecurity standards, which are
> used
> through most of the world, but not everywhere. In any case, it's a valuable
> perspective that I hope the VC2WG and DIDWG takes into the next stage of
> the work.
>

Though I appreciate the hard work that went into this document (including
some support from our community) I ended up having a strong visceral
reaction to it as I feel its recommendations are largely bad long-term
decisions. If you want to do business with the US Government and its allies
(aka LESS "Legally Enabled Self-Sovereign" Identity), you will have to use
them. However, about the only thing I agree with is that we should start to
transition away from SHA-256, initially maybe to SHAKE256 (though I have
other nuances not considered by this report given VRFs, Schnorr and
ZK-proofs opportunities).

I feel there is some urgency here because I have colleagues in both Ukraine
& Russia that are effectively out of business, and I fear for others in
Taiwan. I fear for progressive countries changing their rules, especially
given the re-election of Orban in Hungary, continued leadership
by Morawiecki in Poland & Bolsonaro in Brazil (among many others), possible
election of LePen in France or Trump (or a Trump ally) in the United
States. Many other authoritarian threats are rising around the world.

Recently even in more progressive countries there is evidence and movement
toward using digital technologies to control people that I feel risk human
rights or violate human dignity. Canada closed protestors bank accounts
(and thus their ability to make a living) without using court hearings,
state-controlled central-bank cryptocurrencies are being proposed around
the world with high coercion risks, and public acceptance of Covid inspired
initiatives for legitimate public-health purposes are inspiring similar
approaches for more questionable purposes.

This means that we must fight harder for more decentralized, more
correlation & coercion resistant digital identity technologies. I don't
believe we can do this with an incremental upgrade of our current digital
infrastructure — there are too many "invisible architectures" (see
http://www.astrodigital.org/space/stshorse.html for an example) from early
choices made during the 80s (X.509, expense computationally to make and
secure key on 1990s CPUs, etc.) that make the cryptographic choices today
in DID 1.0, VC 1.1, technologies like JOSE/JWT/JSON-LD, and systems like
OIDC problematic. I helped architect and have actively supported the basic
design concepts behind DIDs & VCs for the last 6 years, but I don't support
their current cryptographic implementation practices.

None of my diatribe here is to say that working toward government-focused
LESS Identity solutions are a waste of effort. They just are not sufficient
for the long-term — being pragmatic today is not good enough.

I personally am forking from DID 1.0, with a hope that maybe someday we can
merge these concepts back into DID 2.0 someday. Here are some of my early
ideal design thoughts & principles:

* Architect proactively for user independence (aka self-sovereign), privacy
focused on correlation-resistance & coercion resistance, use cases to
support human rights and dignity, AND support user resilience and
reliability.
* Multikey first. This means Distributed Key Generation (DKG), aggregatable
threshold signing & proofs, collaborative identifier and key rotation, and
collaborative identity recovery (not just social network key recovery, but
also recovery facilitated by personal IoT devices, cloud services, and a
personal choice of other responsible entities) using technologies like VSS,
Music2, FROST, ZK-STARKS, etc.
* All identifiers must have rotable key material, and such key material
should be minimally used (say an KERI-style inception key that is
immediately used to rotate, or a blockchain UTXO that is immediately spent).
* Minimize key reuse, avoid using keys for multiple purposes, separate
derived keys from the sources, support punctuated perfect forward secrecy,
* ECDSA , AES and SHA-2 should largely be transitioned out and retired.
* By default all public keys should be considered to to represent multisig
collaborative controllers, whether that is a key created in a VSS or Musig2
or FROST collaborate ceremony between multiple devices held by a single
individual (say a mobile phone, smart ring or watch, and a cloud service),
or by a dyad for P2P (Adam and Bart have a single public key that can only
be used in signing when they cooperative), or triads and up (some form of
aggregatable threshold quorum, such as 2 of 3, 4 of 9, 50+1 of many,
supermajority, consensus but not unanimity, etc.)
* Signatures and proofs should largely use aggregatable multisign Schnorr,
which currently only can be done safely on secp256k1 or ristretto255 style
curves (not NIST r1 or 25519).
* Leverage the possibilities of Schnorr for atomic operations, adapter
signatures, blind signatures, scriptless scripts, smart signatures, etc. as
well as leverage the DKG & VSS pre-cursors to group Schnorr.
* Don't allow public keys, signatures, and other proofs to be correlatable
— leverage VRFs and related commitment schemes, or Schnorr adapter
signatures and scriptless scripts to make even the ability to verify a
signature require some process of consent.
* All key-value assertions signed by default are redactable by the
presenter, using a hash tree or certificate transparency-style VRF
hash-tree mechanism. Integrate the default redactable support with other
forms of selective disclosure (BBS+, etc.).
* All secrets should be multisig centric, with no Single Points of Failure
(SPOF), Single Points of Compromise (SPOC), or Single Points of Denial
(SPOD). This means we don't have to rely on a single chip (FIDO), personal
device (mobile phone), or service (personal cloud), or ecoystem (Apple,
Google), to be able to leverage our secrets, either as individuals or as
groups.
* No single source of authority or vendor lock-in — start with P2P
web-of-trust, but anything greater than that is explicitly user choice with
multiple options.
* Trust must be granular - not black or white.  Create Progressive Trust
architectures http://www.lifewithalacrity.com/2004/08/progressive_tru.html
that may require  require many steps and round-trips, and less risky early
trust testing before establishment of long-term trust.
* Personal choices of roots of trust must not be just acceptable, but
preferable. Design to avoid dark patterns of one-time or default trust
acceptance (design for modest and safe choices first, educate, request
confirmation over time, review periodically, etc.). Avoid risks of process
fatigue and desire convenience with cognitive design.
* Rethink architectures of dedicated cryptographic hardware. Work with
silicon vendors so that we don't have to solely rely on single-keys on
hardened chips, using legacy cryptography, and address the larger need to
avoid supply chain threats.
* All data is by default encrypted at rest, and encryption may be nested
with multiple "permits" to reliably support decryption under
different scenarios.
* Focus on personal trust (aka P2P) first, group aggregated trust (more
like key transparency) second, before leveraging blockchain tech.
Time-related proofs and commitments are more useful than immutability.
* Minimize biometrics to their sole use by devices under users control (for
instance iPhone-style biometrics).
* Where human secrets are required (aka "passwords") focus them solely as
one factor of many, and leverage more modern techniques OPAQUE rather than
the more long-term vulnerable approaches of bcrypt/scrypt-style PAKE. When
personal secret is required, leverage psychology of memory and spaced
repetition to support greater personal secret entropy.
* Largely leverage CBOR (but not COSE) for self-describing data, torgaps
transports (Tor or I2P - not https), and design for separation of keys and
trust services using airgapped and other segregated approaches.
* Support multiple testing of sources of truth. Ask 3 servers, not one.
Support reliability & resilience.
* Firmly separate authentication from authorization.
* Leverage cryptographic o-cap for delegatable and attenuable authorization.

All of my wish list is quite ambitious, but some of them are distinctly
possible to start developing now. Blockchain Commons already is beginning
to address some of them for use cases in the emerging Bitcoin multisig
community, and we now have support from patrons who can implement what we
need in silicon or dedicated hardware (such as secp256k1, ristretto255, and
Schnorr support in a secure enclave). We have begun to ship reviewed source
code (SSKR for social key recovery) for some of the above, have numerous
specs, code libraries and POC reference code available, and we have begun
creation of methodologies to evaluate the SPOCs and SPOFs for
multisig scenarios (see drafs at
https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Scenario-Multisig.md
and
https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Multisig.md
)

Given the current rising community spread of Covid I unfortunately will not
be attending IIW next week, however, I am open to discussion with others
interested in supporting this more evolved (and radical) approach to
decentralized identity. So if you are in the area, I welcome invites to
lunch at some convenient outdoor location, and anytime via Zoom. I plan
that by September we can try to meet in person at the next Rebooting Web of
Trust in the Hague on September 26-30th
https://www.weboftrust.info/next-event-page.html.

I welcome your participation in development of these technologies and
tools,  and of course your monthly financial patronage (even if a small $20
a month, your social proof of support is valuable!) at
https://github.com/support/BlockchainCommons.

Offered with hope & optimism that we can do this…

-- Christopher Allen