DRY principle for multikeys?

[iherman]

This issue is also valid for the EdDSA and BBS specifications.

The §2.1.1 Multikey section gives a (normative!) definition for Multikeys for the various versions of ECDSA. However, section §2.2.2 Mulltikey of the controller document also defines (normatively!) not only the concept of Multikeys, but also its specific definitions for ECDSA/EdDSA/BBS.

I think this is wrong, it violates the DRY principles and, worse, it may lead to discrepancies. (To be clear, I did not see any discrepancies today.) In the current setting of the various specifications, I believe the right place is the CD specification.

(Note that the DID spec possibly adopting Multikeys as one of the standard key representation. The Multikey definition is relevant for DID, the cryptosuites are not...)

In my view, the definition should be removed from the ECDSA (and EdDSA and BBS) specification.

[msporny]

Yes, I agree that it is a problem. Initially, the concept of Multikey was in the controller document, and the specific key formats were in each cryptosuite. That is the right thing to do, IMHO, as the controller document cannot and should not try and define every single type of key that might ever exist. That said, there was one person that complained about this in the controller document and insisted that we put the definition there as well (because they didn't want to reference the data integrity cryptosuites. So, that's why we have the repetition that we do today.

The right thing to do is to define the key types with the cryptosuite that they go with and to remove the key definitions from the controller document. I expect that to get objections. Similarly, putting all the key types in the controller document is the wrong thing to do because we would centralized key formats to the controller document (which is unnecessary centralization). The compromise is what we have right now.

I don't know if that helps, but that's where we are today. I'd rather leave sleeping dragons alone than poke at them with pointy sticks this close to the CR2 transition.

[iherman]

The right thing to do is to define the key types with the cryptosuite that they go with and to remove the key definitions from the controller document.

The problem with this is that the Multikey definition for, say, ECDSA, may be used for purposes that are not covered by, and not necessary relevant for the cryptosuite definition. The obvious example is DID: we recently agreed to use Multikeys in a DID document as well. By this logic, this would force the DID spec to define the exact Multikey format as well. Or refer to the cryptosuite, which would feel odd and out of place.

[iherman]

Just to make it clear: I won't lie down the road if things stay as they are today, I have no intention to face dragons either. But I believe that, eventually (maybe as part of the maintenance work?) we may have to come back to this issue.

[msporny]

Or refer to the cryptosuite, which would feel odd and out of place.

Why would that feel odd and out of place? It's the cryptosuite spec that defines the key formats that work with the cryptosuite. It's fine for a specification to normatively reference another specification, if only for a small part of the specification (key format), no?

[iherman]

It's fine for a specification to normatively reference another specification, if only for a small part of the specification (key format), no?

Formally, yes, I never disputed that. But, to use a probably extreme example, it is a bit as if the ECDSA Cryptosuite specification contained the formal (i.e., normative) definition of the P-256 curve. That would be possible, but inappropriate, because that curve is used for numerous cryptographic operations that have nothing to do with verifiable credentials.

Multikeys, on a much more modest level of course, are similar. It is a short, compact way to express a, say, ECDSA P-256 key (to keep to the example), which could be used for other purposes that have nothing to do with verifiable credentials. It could be used to convey the public key for an email signature in ECDSA, for example, in place of PGP. And, of course, there is, closer to home, used by a DID document which is again very different.

The DID developers are, mostly, either part of, or close to the "tribe" of Verifiable Credential developers. Finding and using multikeys in the (otherwise complicated) cryptosuite specifications is not a problem for them. But I doubt that would be the case for someone wishing to use ECDSA for email signatures. If we want to ensure that multikeys have any kind of presence outside this "tribe", then the definitions of those keys for some of the most widespread crypto schemes is important in the same definition. IMHO...

[iherman]

The issue was discussed in a meeting on 2024-09-26

• no resolutions were taken

View the transcript

#### 3.1. DRY principle for multikeys? (issue vc-di-ecdsa#76) _See github issue [vc-di-ecdsa#76](https://github.com/w3c/vc-di-ecdsa/issues/76)._ **Ivan Herman:** For whatever reason, we have now the cryptosuite and the DI spec and the controller document. Not interested in how it came into being. The controller document has been put forward as abstracting a number of features, terms, and data types that are shared by different specifications, including some not in this group. I think that's a good thing. At least in my mind, a controller document should ge usable in applications that have nothing to do with VCs or DIDs. … The multikey format (abstract) has been put into the controller document. The multikey specification format is useful if its defined for each algorithm (ECDSA etc.). … Currently, this definition is duplicated. That's bad. We don't repeat ourselves, otherwise we get into trouble. It is my fairly strong position that it must be in the controller document and only there. Let's say that I want to make an application that signs an email. That has nothing to do with credentials or cryptosuites. Multikey gives me a compact representation form. … Using ECDSA, I may have to go to the data integrity specification to get full details. … The right place is to have it in the controller document only. **Manu Sporny:** The slide has three options. There are a couple of challenges with putting all of the key definitions in the controller document. Multikey and multibase have jumped specifications multiple times; they should be their own specifications so that people can refer to them in their own way. We're not doing that. … We tried to publish at IETF and were blocked, so we put them back here. … The thing I'm most concerned about is that cryptosuites need to specify which key types work with them. … Let's say we create a new cryptosuite that uses a new key type. If so, we would have to reopen the controller document to define the key type. I think that the right approach is for cryptosuites to define their own key types and for their key types to be in a registry somewhere. … We have comments that people didn't want to refer to other documents for the key specification. … Putting it in the controller document means that you would have to reopen the controller document for each new key format. … Putting it in the cryptosuite document makes it easier to add new key types. The way that we have it now is unfortunate but is a compromise that allows us to get through without objections. **Ivan Herman:** I won't lie in the road to get in the way. I see a fourth possible approach, possibly sub-optimal, that we move everything into the controller document, publish everything because we're under time pressure, and then in maintenance we work out a way for people to add new keys on a website or similar. … We don't have the time to do it fully and cleanly, but we can open the way to do it later. **Manu Sporny:** We have the VC extensions. We could add another table there where we could add new registries there that would allow you to add stuff. My concern is still the same. Cryptosuite specifications need to be able to define the key types. > *Dave Longley:* +1 to using extensions and language that says cryptosuite spec authors can define new/reference new key types. **Manu Sporny:** As long as we have language that allows cryptosuite authors to add key types, we're probably fine. **Ivan Herman:** I have the impression that this is something that should be there anyway. The statement that you made is regardless of whether the cryptosuite has them or not. That guidance should be there, regardless of the outcome of this issue. Putting it into VC extension for now works for me. We can clean up in maintenance. **Manu Sporny:** I'm worried about the changes that this might make to the specification. Can we take those definitions out of the specs and put them in the registry? **Ivan Herman:** No. **Manu Sporny:** I'm worried that there's some language in the cryptosuite specification that may trigger some kind of issue if we do this. **Ivan Herman:** After cursory look, for me, there is one paragraph that could be replaced with "look at table in controller document". … Definition for multikey for ECDSA is a single paragraph. **Manu Sporny:** What if we say that the controller document establishes a registry for multikey and multibase and then we point to the registry. **Ivan Herman:** The registry can define multikey with no additional references required. **Michael Jones:** I disagree. Registries are never the authoritative definition; they refer to authoritative definitions in specifications. **Brent Zundel:** What registry are y'all taking about? We ain't got none of those. … This group decided very firmly to not have anything to do with registries, which, on the record, I disagree with. **Manu Sporny:** The changes would be that the controller document would point to the VC extensions list, if you're interested in any of the values, go to that table. … It would be the same content but shifted over to VC extensions. **Ivan Herman:** That document can't have the authoritative definition of a key because it's a note. > *Dave Longley:* +1 to using VC extensions and have each entry there list the spec where the key definition is. **Ivan Herman:** We open up a table which can point back to the controller document. If at some time later someone comes up to an authoritative definition for multikey, we can point to that definition. … For the WG purpose today, we have a table for all multikeys that we define in the controller document and we create an index for developers to find them easily. **Manu Sporny:** What that means is that we cannot add anything new if we do not have a working group. … Other working groups can, but we would not be in a position to say that what they did is authoritative. **Gabe Cohen:** We need an approach that allows us to register new security mechanisms after this group has left. **Manu Sporny:** The other thing to consider is that the thing that is normative is the specification, not the registry. … That means that that list doesn't need to be normative. We can have a statement in a normative document pointing to a note. … In the controller document, we can have a section that says that if you're interested in key types, go to this list of extensions, and it will list all the key types. **Ivan Herman:** You are doing a sneaky way of doing what is there. My idea is almost what you say but not exactly. In your scheme, you keep the ECDSA version in the ECDSA cryptosuite. My variant is to have what we define in the working group in the controller document. > *Dave Longley:* +1 to Ivan's proposal. **Ivan Herman:** We can then point to an index to look up additional definitions and move what we have defined into the controller spec. **Manu Sporny:** I would be fine with that as a compromise. **Michael Jones:** A lot was said in the last ten minutes about what changes have been proposed. **Manu Sporny:** We are going to put the key definitions for multikey in the controller document; they are already there and will remain. We are going to modify the controller document to point to a list of other key extensions and remove the definitions from the cryptosuites. > *Denken Chen:* +1 to the current resolution here. It helps from the developer’s side to avoid confusion.

[msporny]

The fix for this issue has been implemented in commit 5a21251dd04824e3162c4f56986787eea63962e3. Closing.