Re: Streamlining Data Integrity Cryptosuites

On Sun, Jul 31, 2022 at 11:33 AM Markus Sabadello <markus@danubetech.com> wrote:
> I think this is an interesting direction (related to discussion in
> https://github.com/w3c/vc-data-model/pull/759), but I have the following
> observations:

Hey Markus, thanks for reading through the proposal and providing
feedback. Responses to your concerns below...

> 1. The example on slide 6 about Ed25519Signature2020 and
> JsonWebSignature2020 feels a bit unfortunate, since the two suites
> actually differ in more than just the "type". The former uses
> "proofValue" whereas the latter uses "jws". A better example might be
> Ed25519Signature2020 and EcdsaSecp256k1Signature2020.

Yes, good point, that does create an unfortunate confusion in the
examples. The ideal would be that the new "jws-2022", "eddsa-2022",
"nist-ecdsa-2022", would all switch over to using the `proofValue`
property OR we'd include a special `jws` field in the v2 context. The
end result would be the same; you wouldn't need anything more than the
VC v2 context to support "most" use cases.

> 2. If the main idea of this proposal is to move the crypto suite type
> into a string and align everything else as much as possible, then isn't
> this to some extent re-inventing what we already have with
> JsonWebSignature2020?

No, because `JsonWebSignature2020` requires that a conforming
cryptosuite implements ALL listed cryptosuites. For example, if
`JsonWebSignature2020` is used, then it's expected that any supporting
library MUST implement RSA, EdDSA, ECDSA (NIST), ECDSA (Koblitz),
CRYSTALS-Dilithium/FALCON, and SPHINCS+. That's a lot of attack
surface to pull into a system. It's the cryptosink approach, which is
(debatably, and let's please not launch into that debate in this
thread) different from only requiring ONE to TWO digital signature
algorithms per cryptosuite type (e.g., primary and backup for
asymmetric signatures, primary and backup for post-quantum
signatures).

We have yet to have an extended debate around cryptographic agility
vs. cryptographic hardening and the benefits and drawbacks of each
approach.

> 3. I'm not sure if the DataIntegritySignature will really be applicable
> to 80% of the cryptosuites. For example, on slide 9 you mention
> "bbs-2022" as a potential "cryptosuite" string value, but my
> understanding of the whole BBS+ work is that it can sometimes require
> additional properties such as "requiredRevealStatements", which would
> then create a need for an addition JSON-LD context anyway to define that
> extension. I feel like other ZKP approaches and other future proof types
> may also involve additional extension properties that won't be
> completely covered by DataIntegritySignature.

At present, it seems like the "requiredRevealStatements" might be a
part of the cryptographic signature layer... that is, they might be
placed in the `proofValue`. If they are not, there will be an open
question wrt. whether we should provide a `zkpHeaders` field. If it
doesn't fall into either of those two categories, then yes, it'll need
a separate cryptosuite context and thus places it into the 20% of
cryptosuites that don't fit the general model.

We have time to figure out what those fields might be over the next
two years, driven largely by work happening in CFRG w/ BBS+ and other
selective disclosure / unlinkability signature schemes.

> 4. What about public key types and specs that depend on them (DID Core)?
> Do you envision something similar there, i.e. move the key type into a
> string value?

We have Multikey for that (not a string, but a byte header):

https://w3c-ccg.github.io/data-integrity-spec/#multikey

... and yes, that is work that we want to do here as well since we
have a number of DID Methods that utilize Multikey today (did:key
being the most prominent example).

I specifically did not try to tackle the Multikey discussion w/ this
slide deck (as they're separable concepts and we didn't want to pull
every change we want to make into this particular conversation about
DataIntegritySignature). All that to say, the decision about
DataIntegritySignature is separable from the Multikey decision.

-- 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 Monday, 1 August 2022 13:53:20 UTC