[PROPOSED WORK ITEM] ECDSA Secpr1 Cryptosuite v2019

msporny commented 2 years ago

Abstract

https://digitalbazaar.github.io/di-ecdsa-secpr1-2019/

This specification describes the ECDSA Secpr1 cryptosuite created in 2019 for the Data Integrity specification. Just like the exiting CCG work items for the <a href="https://w3c-ccg.github.io/lds-ed25519-2020/">Ed25519 Cryptosuite, the Secp256k1 Cryptosuite, and the BBS+ Cryptosuite, this cryptosuite extends the Data Integrity specification to support cryptography supported by many large organizations throughout the world.

Owners

Owners: @msporny, @martyr280

Work Item Questions

Explain what you are trying to do using no jargon or acronyms.

This specification adds support for a type of digital signature that is used heavily by large organizations throughout the world. It was our hope that we would not have to support this digital signature suite due to it's controversial nature, but given the slow pace of the hardware security module industry, along with the slow pace at which national institutes that standardize cryptography are moving, and given the hostility of a vocal minority of W3C Member companies towards the scope of the Verifiable Credentials work, publishing this work item and folding it into the VCWG 2.0 work protects that work from any W3C Member that might insist that work on this technology is out of scope (and thus hobbling the VCWG group's ability to be responsive to cryptographic needs in the industry).

How is it done today, and what are the limits of the current practice?

The current focus of Elliptic Curve digital signatures in the VC ecosystem seems to be around something called the "Twisted Edwards Curve", or Ed25519. That cryptography uses provably secure techniques. Unfortunately, that technology has just been approved by the National Institute of Standards in draft form and it might take years for it to be supported in the commercial hardware security modules that many governments and large organizations depend on. It was our hope that the industry was going to make more progress by this point, but it's not moving fast enough. We plan to standardize a few cryptosuites in the upcoming VCWG 2.0 work. In order to mitigate the risk that Ed25519 won't be available in commercial hardware security modules by the time that some vendors need to deploy into production settings with large organizations and governments, we are suggesting that ECDSA Secpr1 should be an option for Issuers that desire its functionality.

What is new in your approach and why do you think it will be successful?

There is nothing new in the approach, in fact, the cryptography used here is fairly old (almost 20+ years at this point). If it is successful, it will be because of the broad market adoption that the technology already has.

How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: the Americas, APAC, Europe, Middle East.)

Due to the nature of the work item (cryptographic security), it is difficult to include non-technical participants. We will be involving the CCG and VCWG, which do include non-technical participants throughout the world, but again, their ability to influence the technical direction will be quite limited.

What actions are you taking to make this work item accessible to a non-technical audience?

Overall, none, as non-technical audiences need not be exposed to this level of detail.

We will happily try and explain what we're doing on the CCG mailing list if non-technical members have questions about the technology.

peacekeeper commented 2 years ago

+1 to this, looks like a useful addition to complement the set of existing cryptosuites.

OR13 commented 2 years ago

I am not opposed to creating duplicate JSON-LD types for existing key and signature representations, as long as the prior art is properly acknowledged, and the "reason for the new suite being needed" is documented completely.

I am opposed to new work items that fail to do this sufficiently.

https://w3id.org/security/suites/multikey-2021/v1 ->

"P384Key2021": {
      "@id": "https://w3id.org/security#P384Key2021",
      "@context": {
        "@protected": true,
        "id": "@id",
        "type": "@type",
        "controller": {
          "@id": "https://w3id.org/security#controller",
          "@type": "@id"
        },
        "revoked": {
          "@id": "https://w3id.org/security#revoked",
          "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
        },
        "publicKeyBase58": {
          "@id": "https://w3id.org/security#publicKeyBase58"
        },
        "publicKeyMultibase": {
          "@id": "https://w3id.org/security#publicKeyMultibase"
        }
      }
    },

"P384EcdsaSignature2021": {
      "@id": "https://w3id.org/security#P384EcdsaSignature2021",
      "@context": {
        "@protected": true,
        "id": "@id",
        "type": "@type",
        "challenge": "https://w3id.org/security#challenge",
        "created": {
          "@id": "http://purl.org/dc/terms/created",
          "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
        },
        "domain": "https://w3id.org/security#domain",
        "expires": {
          "@id": "https://w3id.org/security#expiration",
          "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
        },
        "nonce": "https://w3id.org/security#nonce",
        "proofPurpose": {
          "@id": "https://w3id.org/security#proofPurpose",
          "@type": "@vocab",
          "@context": {
            "@protected": true,
            "id": "@id",
            "type": "@type",
            "assertionMethod": {
              "@id": "https://w3id.org/security#assertionMethod",
              "@type": "@id",
              "@container": "@set"
            },
            "authentication": {
              "@id": "https://w3id.org/security#authenticationMethod",
              "@type": "@id",
              "@container": "@set"
            },
            "capabilityInvocation": {
              "@id": "https://w3id.org/security#capabilityInvocationMethod",
              "@type": "@id",
              "@container": "@set"
            },
            "capabilityDelegation": {
              "@id": "https://w3id.org/security#capabilityDelegationMethod",
              "@type": "@id",
              "@container": "@set"
            },
            "keyAgreement": {
              "@id": "https://w3id.org/security#keyAgreementMethod",
              "@type": "@id",
              "@container": "@set"
            }
          }
        },
        "proofValue": {
          "@id": "https://w3id.org/security#proofValue",
          "@type": "https://w3id.org/security#multibase"
        },
        "verificationMethod": {
          "@id": "https://w3id.org/security#verificationMethod",
          "@type": "@id"
        }
      }
    },

msporny commented 2 years ago

@OR13 wrote:

as long as the prior art is properly acknowledged, and the "reason for the new suite being needed" is documented completely.

What statements would you need to see in the specification that would properly acknowledge the things you want acknowledged and documented? The more specific you are with the text, the easier it will be for me to put some variation of it in the work item.

https://w3id.org/security/suites/multikey-2021/v1

Hrm, so there might be an opportunity here. I have grave concerns w/ kitchen sink JSON-LD Contexts, preferring modularity (like #include or JS import statements) over #include "theworld.h" style programming.

That said, having all of these cryptosuites flying around is painful and unsustainable (and we all want to reduce the pain and make this "as easy as JWS/JWK, but without the footguns").

So, what should we be pushing towards?

Not needing to pull in a plethora of JSON-LD Context files unnecessarily. Seems that people didn't like splitting them up, even though no one objected during DID Core.
Ensuring tight binding between signature format and expected key format, where it becomes obvious when there is a mismatch without needing to consult multiple fields (avoid JWT/JWK footguns).

So, what if the Data Integrity signature formats shifted to something more like this:

{
  "type": "DataIntegritySignature",
  "suite": "EdDSA2020", <-- this is a string, not a JSON-LD value 
                            (must be paired w/ public key that has Ed25519 multicodec header)
  "created": "2022-01-25T18:51:01Z",
  "verificationMethod": "did:key:z6MkiTBz1...#...jdX3mDooWp",
  "proofPurpose": "assertionMethod",
  "proofValue": "z294kQyiodB...ThH4XwV"
}

... and the did:key expanded to:

{
  "assertionMethod": [{
    "id": "did:key:z6MkiTBz1...#...jdX3mDooWp",
    "type": "DataIntegrityVerificationKey",
    "controller": "did:key:z6MkiTBz1..jdX3mDooWp",
    "publicKeyMultibase": "z6MkiTBz1..jdX3mDooWp" <-- has to have an Ed25519 multicodec header
  }]
}

If we do that, @OR13, we end up not needing kitchen sink JSON-LD Contexts (what I want) and end up switching off of a single value, which is the suite, that feels like JWK/JWS (what you want) but is safer (what I want). Just a thought experiment... so...

Thoughts?

dlongley commented 2 years ago

+1 to moving suite specification out of vocabulary space (so a single context can be used for all of this), but ensuring that the expected various components of a suite (encoding, canonicalization, hash, key type, curve, lattice params, ring types, y, z, ... whatever may come to pass) are unified under a single string identifier. This would make it so we can identify an acceptable combination of these things with a simple, human readable name (and preferably a date) without having to update vocabularies or contexts.

With this approach, we also get to encapsulate the internal components of keys and proofs so they are not directly exposed to the JSON that application developers are working with at a higher layer. This means that all public key information is encoded into a single term publicKeyMultibase (as is it is done above). It also means that there's always a single term for this (no need to invent new JSON terms like d, x, y, dq, qi, etc. for every new type of crypto) and it can't be confused with various private key variable names. I also believe we should unify private key material the same way, under a single term, perhaps secretKeyMultibase. We've done already this sort of encapsulation with proofs under the single term proofValue, avoiding the need to define new terms to hold various proof components for every proof type at the application JSON layer.

How crypto components are expressed within the value of these terms should be layered so it's in the domain of the crypto suite spec (and multicodec specs), not exposed to the application JSON.

While encoding crypto components in JSON (as JOSE does) is useful because JSON parsers are so prolific, it has also, IMO, resulted in exposing developers to layers that they should not be exposed to -- and with security, this can lead to vulnerabilities and systems that fail open instead of closed. Of course, this new approach doesn't rule out crypto suite authors from using JSON to encode their crypto components if they really want to -- but this information would be serialized to a string and just be part of the internal value of, for example, publicKeyMultibase from an application developer's perspective.

IMO, the above proposed approach would remove the friction involved in creating and implementing new suites for developers who just want to use them -- but would encapsulate data they shouldn't have to deal with nor should they try to recombine without the creation of a new suite. This causes specific combinations to be called out (ideally with a spec and some crypto experts signing off on that combination) via suite name. Applications could support specific suites by name -- and specs would instruct suite implementers to check specific validation rules ensuring that all of the meta data around keys, proof types, and so on are all expected combinations so individual components can't be split up or recombined leading to vulnerabilities.

OR13 commented 2 years ago

@msporny I think all that is needed is a section in the proposed spec that explains how to get to the other key types... so if you come to the spec for P-384 you don't end thinking P-256 is not supported.

Probably also the IRIs for type would need to be agreed to, and if no agreement can be had, the ambiguity should be called out explicitly to prevent confusion.

I am happy to make changes to the multi-key context... by allowing folks to pull all of multi-key, or just 1 suite...

when there is context that resolves from w3id.org that creates a conflict.... until then I would suggest using our definitions (@id values), and not creating that conflict.

on the subject of binary representations for publicKeyMultibase... the multiform spec does not define this specifically enough to achieve safe interop.

I assume these specs will fix this not just for P-384 (assume you will be using compressed representations, etc..).

How will this impact other key types... ?

Do we think that defining only P-384 will increase or decrease the chance that P-256 represents publicKeyMultibase differently?

If this is done poorly, its not just P-384 that suffers its developer experience for all of multiformats.

The problem lies in thinking a single spec handles this well imo... it would be better to define a "Multiformats LD" spec, and then makes contexts that allow you to isolate to a specific key and signature... which is what your current proposal is.

sorta like how JWK is a separate spec from from ES256K.

tplooker commented 2 years ago

In general I'm supportive of enabling LDP to being used with a broader set of NIST related curves.

So, what if the Data Integrity signature formats shifted to something more like this:

Also +1 to any proposal that decouples the need for importing several contexts to use different crypto suites.

peacekeeper commented 2 years ago

Seems that people didn't like splitting them up, even though no one objected during DID Core.

+1 to any proposal that decouples the need for importing several contexts to use different crypto suites.

When did this shift happen? I thought there were good reasons for having more granular contexts, and everyone was happy with that?

peacekeeper commented 2 years ago

Regarding this example in https://github.com/w3c-ccg/community/issues/228#issuecomment-1021507789:

{
  "assertionMethod": [{
    "id": "did:key:z6MkiTBz1...#...jdX3mDooWp",
    "type": "DataIntegrityVerificationKey",
    "controller": "did:key:z6MkiTBz1..jdX3mDooWp",
    "publicKeyMultibase": "z6MkiTBz1..jdX3mDooWp" <-- has to have an Ed25519 multicodec header
  }]
}

I like this. One thing I find problematic about e.g. Ed25519VerificationKey2020 with publicKeyMultibase is that it's not clear what happens if the multicodec header is anything other than Ed25519, maybe that's even a potential attack surface.

Perhaps the above example should better be called MulticodecKey2022? This way it would better mirror what JsonWebKey2020 is doing:

JsonWebKey2020 -> No key information in the term itself, all key information in the publicKeyJwk
MulticodecKey2022 -> No key information in the term itself, all key information in the publicKeyMultibase

msporny commented 2 years ago

When did this shift happen?

It hasn't, at least not yet. The above is just a though experiment. It's a topic for discussion in VCWG 2.0.

I thought there were good reasons for having more granular contexts, and everyone was happy with that?

@OR13 does not seem to be happy with it, so we're trying to find something that would make him happy. There is pain associated with multiple contexts, so we're trying to find a solution that avoids the "kitchen sink JSON Web Key / JSON Web Signature" approach, and keeping the best part of tightly bound signatures and acceptable key types. We think we can improve the developer experience (if everyone is on board) while keeping the same safeties that specific date-stamped cryptosuites give us.

One of the biggest mistakes that JWK made was giving developers affordances that they should never have been exposed to. For example, allowing developers the ability to change vaguely named cryptographic variable parameters such as x, y, and d was a mistake (made with good intentions).

One thing I find problematic about e.g. Ed25519VerificationKey2020 with publicKeyMultibase is that it's not clear what happens if the multicodec header is anything other than Ed25519, maybe that's even a potential attack surface.

The cryptosuite has to state that using a publicKeyMultibase with a non-Ed25519 multicodec header with a suite type of "EdDSA2020" MUST throw an error. This has to be tested in the test suite.

Perhaps the above example should better be called MulticodecKey2022? This way it would better mirror what JsonWebKey2020 is doing

We could just make it "MulticodecVerificationKey" because with those sorts of keys, the key identifies itself via a header encoded in publicKeyMultibase. This is in contrast to JWK, which has a typ field, which then may not match the other cryptographic parameters in the field. This might be what @OR13 is getting at above -- just create a MulticodecKey spec and define all the key types in it (these will never change from year to year, once a multicodec header is set, it's set forever). We have enough specs going into the WG at this point (if the charter survives a rechartering) to make a case for that spec inside the WG.

OR13 commented 2 years ago

@msporny I am happy about smaller context files... I am unhappy about 1-off crypto suites for a single key type.

I think its a best practice to ship smaller context files for those who want them... BUT.

Only doing the work to define public keys and 1 of the 3 popular NIST curves is a mistake from a standards perspective... It harms the overall impression developers get from publicKeyMultibase.

In short this work item is necessary but insufficient. (and from a JSON-LD context perspective I would argue it is 100% redundant to existing w3id.org terms)

One of the biggest mistakes that JWK made was giving developers affordances that they should never have been exposed to. For example, allowing developers the ability to change vaguely named cryptographic variable parameters such as x, y, and d was a mistake (made with good intentions).

At least JWK defines what a private key looks like. Every time I see this come up I agree (regarding JWK), and then I start laughing at how absolutely worse it is to leave private keys undefined.... the only thing worse than defining private keys poorly is not defining them at all and letting developers do it a unique way (possibly even more dangerously or possibly using JWK since thats the only representation that they know).

We could just make it "MulticodecVerificationKey" because with those sorts of keys, the key identifies itself via a header encoded in publicKeyMultibase.

Yes, I am saying define the entire format once, clearly, and then you are welcome to drop all keys except one variant when you make a recommendation... don't conflate the two.

msporny commented 2 years ago

I am saying define the entire format once, clearly, and then you are welcome to drop all keys except one variant when you make a recommendation.

Agreed.

@OR13, as an aside, you seem to be arguing against positions that no one that I know of is holding. Please take a step back and understand that you're tilting at windmills. :) ... it may be because you're presuming that the things that have been done historically (as an exercise to explore the space) are predictive of where we want to take the work (which is understandable, but incorrect in many of the cases above). You may also be taking a conversation out of context and applying it to something it was never intended to be applied to.

Let me try and be crystal clear about some of my positions (since this thread is turning into a comedy of miscommunication):

I would strongly support a specification that defines all the Multicodec public key values so that they can be referred to from cryptosuite specifications.
There are aspects of MultiKey2021 that I'd like to see standardized (definition of all possible multikey types... with the caveat that we must support an extension mechanism).
There are aspects of MultiKey2021 that are bad (definition of all possible signature types -- specific cryptosuite specifications should cover those things, and refer to the multikey (or JWS) spec for key types).
I would strongly support cryptosuite specifications being exceedingly strict about the public key material that is compatible for use with the cryptosuite. For example, ideally, for the "EdDSA2020" signature cryptosuite, only Multicodec Ed25519 keys encoded in publicKeyMultibase in base58-btc format are allowed. I would, however, not object to a cryptosuite (like "JWS2020") that wanted to be very lax about it as long as there were warnings on the cryptosuite about the dangers of mixing/matching public key material and mitigations in place to ensure that bad things can't accidentally happen... and of course, those rules enforced in a conformance test suite.
I have no problem defining secretKeyMultibase as a vocabulary term (for the expression of private keys... if people throw a fit about the word "secret", we can just call them "private").
I would find it acceptable to put that term in a JSON-LD context that is intended for the expression of secret key material (for example: https://w3id.org/security/secrets/v1). I would prefer that, in general, we /not/ do that because private keys should NOT survive JSON-LD processing.
I would be opposed to putting secretKeyMultibase in JSON-LD Contexts like the Verifiable Credentials context or the DID Context because no one should be using those contexts to express private keys.

@OR13 does this help highlight that things aren't nearly as bad as you seem to think they are? Are there any remaining items that you feel really need to be addressed (in general)? If not, I'd prefer specific language that you'd like to see added to this specification so we can move it forward.

@tplooker I heard you mention that NZ is fine with P-256. The only reason I picked p384r1 here is because I thought someone from MATTR said that p384r1 is the minimum accepted by NZ government. If that is not true, I'd like to shift this back to p256.

As a reminder to everyone else in this thread, we still need a co-sponsor to move this item forward.

peacekeeper commented 2 years ago

shift this back to p256

On the current did:ebsi pre-production environment (the EU's EBSI/ESSIF infrastructure), P-256 is moderately popular (~10% of verification methods), and P-384 is non-existent.

if people throw a fit about the word "secret"

-0.5 to "secret", +0.5 to "private" :)

tplooker commented 2 years ago

I heard you mention that NZ is fine with P-256. The only reason I picked p384r1 here is because I thought someone from MATTR said that p384r1 is the minimum accepted by NZ government. If that is not true, I'd like to shift this back to p256.

When permitted in the solution P-384 is preferred however P-256 is also supported in the event thats not possible. I would suggest we allow for both here

OR13 commented 2 years ago

@msporny I feel like you read my non caps text as caps text :)

I have strong opinions, but I am not the voice of a celestial.

Most of your summary is accurate, and I do have concerns that are embedded in most or the items... not sure if they are big enough to be windmills yet, but that won't stop me from tilting at them :)

That being said, we have spoken on this topic so many times I pretty much know your position and you know mine.

I am providing feedback on the work item.

I am not seeking to "block the work".

I am not volunteering to help the work in its current form.

If the proposal were modified to support other key types, and address the bullets from your list, I would consider co-sponsoring the work.

msporny commented 2 years ago

That being said, we have spoken on this topic so many times I pretty much know your position and you know mine.

Based on what you've said above, I don't believe that to be true. :)

You seem to think we disagree on things that we do not. We should probably switch to a call and discuss more, I think there is far more in common than what the discussion above has shown. For example, I will note that there is a new proposal above that we've never discussed before (on a call). I'd rather focus on a concrete path forward than "have strong opinions" without a plan (or with a vague notion of a plan) on how to converge on those strong opinions.

If the proposal were modified to support other key types, and address the bullets from your list, I would consider co-sponsoring the work.

I've asked for specific text that would address your concerns multiple times now[1][2]. You continue to not provide it. I know you know how frustrating it is when people rant about things, but then are unclear about exactly what they want. I have some vague notion at this point, that is all, and I'm concerned that if I put in the work, you're going to find some other reason to object to it.

I don't want to play "go fetch a rock" with you, but I guess you're leaving me no choice. I don't appreciate the asymmetry of the discussion either: "Go do a bunch of work and come back and show me and maybe I'll be ok with it, but probably not."

So, I'm throwing up my hands, will go off and do a ton of work, and come back and show that work here. I expect you to object to it, even though I'm trying to address your concerns. Again, exceedingly frustrating.

I'll have new content by the end of the weekend.

OR13 commented 2 years ago

@msporny if you wish to continue to assert that we don't understand each others view ok... i guess :)

For example, I will note that there is a new proposal above that we've never discussed before (on a call).

We discussed multikey before and it defines keys and signatures the same way (with minor differences I think we both understand, if you continue to assert otherwise I will concede to your view.).

I know you know how frustrating it is when people rant about things, but then are unclear about exactly what they want.

Make it clear in your proposal that you will define public and private key types for publicKeyMultibase and privateKeyMultibase for P-256 / ES256, P-384 / ES384, P-521 / ES512 in JSON-LD (in more than 1 context if you prefer).

Makes it clear that you will then recommend folks only use "one of these", in some place different than were you define these serializations (separate the definitions from your security recommendations).

But again... you don't need me to help you do this work :)

And if you don't want to implement my suggestions, you don't have too :)

msporny commented 2 years ago

Make it clear in your proposal that you will define public and private key types for publicKeyMultibase and privateKeyMultibase for P-256 / ES256, P-384 / ES384, P-521 / ES512 in JSON-LD (in more than 1 context if you prefer).

Finally! Thank you. Will do.

Makes it clear that you will then recommend folks only use "one of these", in some place different than were you define these serializations (separate the definitions from your security recommendations).

Again, great! That's all I needed to know. Will do.

But again... you don't need me to help you do this work :)

We do, we need all the help we can get. VCWG 2.0 is not going to be easy.

And if you don't want to implement my suggestions, you don't have too :)

As you can hopefully see above, I'm fine w/ implementing your suggestions.

... and this is why I kept insisting that we were speaking past each other.

msporny commented 2 years ago

@OR13 wrote:

Make it clear in your proposal that you will define public and private key types for publicKeyMultibase and privateKeyMultibase for P-256 / ES256, P-384 / ES384, P-521 / ES512 in JSON-LD (in more than 1 context if you prefer).

Done: https://digitalbazaar.github.io/di-ecdsa-secpr1-2019/#split-key-formats-from-cryptosuites

With detail around avoiding JSON-LD context proliferation here: https://digitalbazaar.github.io/di-ecdsa-secpr1-2019/#key-format-examples

@OR13 wrote:

Makes it clear that you will then recommend folks only use "one of these", in some place different than were you define these serializations (separate the definitions from your security recommendations).

Done: https://digitalbazaar.github.io/di-ecdsa-secpr1-2019/#split-key-formats-from-cryptosuites

With detail around avoiding cryptosuite proliferation here: https://digitalbazaar.github.io/di-ecdsa-secpr1-2019/#signature-format-examples

@tplooker and @peacekeeper I rewrote the spec to support both Curve P-256 and Curve P-384 in ECDSA based on both of your input.

@peacekeeper I used your suggestion to use the MulticodecVerificationKey term in the Multibase-encoded Multicodec Curve P-384 public key example (and it worked out well, so I think we should use it): https://digitalbazaar.github.io/di-ecdsa-secpr1-2019/#example-a-multibase-encoded-multicodec-curve-p-384-public-key

@OR13 I believe this addresses your initial concerns with this specification, can you please confirm that it does so that we can focus on the search for a co-owner of the specification? To ease that search, Digital Bazaar expects to put the majority of work into this specification if it ends up becoming a customer requirement, which is highly likely.

peacekeeper commented 2 years ago

Example 1 and Example 2 now show exactly the same thing, except that one uses EcdsaSecp384r1VerificationKey2019 and the other MulticodecVerificationKey. Is that intentional?

I think MulticodecKey2022 would be a better name than MulticodecVerificationKey, just to make the naming more aligned with JsonWebKey2020.

Anyway, no need to figure out all those details immediately. I support this work item in pretty much any form!

msporny commented 2 years ago

Example 1 and Example 2 now show exactly the same thing, except that one uses EcdsaSecp384r1VerificationKey2019 and the other MulticodecVerificationKey. Is that intentional?

Yes, that's intentional. The difference here is that the key isn't bound to any particular year. We had been doing this before, but that's one of the things that led to the key format proliferation that @OR13 is concerned about. If we remove the year, we remove the need to publish a new JSON-LD context for every year and we reduce all multikey formats to a single spec (instead of possibly 10-20 specs over a decade).

I think MulticodecKey2022 would be a better name than MulticodecVerificationKey

The whole point here is to remove the year for verification keys. The year will still be necessary in the cryptosuites (because that's what enforces the types and sizes of the multikeys that can be used).

just to make the naming more aligned with JsonWebKey2020

I don't think JsonWebKey2020 is a pattern we want to follow because it conflates a bunch of different cryptographic algorithms into the same suite. It's an improvement on JWK, but still represents a lazy security pattern that we really shouldn't be proliferating.

Remember that JWKs can express public keys, and private keys, and octet sequences, and HMAC keys, and encryption keys... and... you get the idea. It's the kitchen sink of key specifications, and that has led to security vulnerabilities in production software, so we want to be more deliberate in the Data Integrity work. At the very least, we want to make a distinction between a MulticodecVerificationKey and a MulticodecSecretKey and a MulticodecSymmetricKey.

Anyway, no need to figure out all those details immediately.

Agree, we'll sort all of this out in the VCWG. :)

OR13 commented 2 years ago

another thing to consider is that P-384 is also used for key agreement... so its not just a "signing key"...

We use JsonWebKey2020 for signatures and encryption, and we use MultiKey the same way... but unlike JWK, publicKeyMultibase has no way of expressing a preference for use... and assuming that type will solve that seems dangerous to me...

msporny commented 2 years ago

publicKeyMultibase has no way of expressing a preference for use

The purpose for which a Verification Method can be used is expressed via a Verification Relationship. Again, JOSE conflates the expression of key material with what that material can be used for. It's arguably a layer violation because JOSE just jams a bunch of layers together instead of keeping a good separation between the layers.

another thing to consider is that P-384 is also used for key agreement... so its not just a "signing key"...

Yes, agreed. If we move to the multikey proposal (above), P-384 can be used for authentication, assertion, key agreement, capability invocation, and capability delegation via Verification Relationships.

vsnt commented 2 years ago

@msporny @OR13 can you please join the main call tomorrow/Tuesday so we can discuss? Thank you.

msporny commented 2 years ago

@msporny @OR13 can you please join the main call tomorrow/Tuesday so we can discuss? Thank you.

Yes, I will be there. TL;DR: I think I addressed all of @OR13's concerns with the CCG taking up this work item. @OR13, please let me know if I didn't.

martyr280 commented 2 years ago

@msporny I'll support this as a co-owner.

msporny commented 2 years ago

@msporny I'll support this as a co-owner.

Huzzah! Thank you for stepping up, @martyr280!

@vsnt @mprorock - I believe we've met all the criteria for a work item in CCG. Please confirm so I can transfer the repo over to CCG.

vsnt commented 2 years ago

Fantastic news! Send the repo over and we'll get it confirmed!

msporny commented 2 years ago

@vsnt wrote:

Fantastic news! Send the repo over and we'll get it confirmed!

Done.

https://github.com/w3c-ccg/di-ecdsa-secpr1-2019 https://w3c-ccg.github.io/di-ecdsa-secpr1-2019/

kwlinson commented 2 years ago

This work item has been officially created and has its own CCG repo. Closing issue.

w3c-ccg / community