Explain why one key format is not realistic.

[msporny]

This PR attempts to address issue #115 by explaining that having one key format is not realistic, how the spec attempts to minimize key formats, but understands that ecosystems have to support the key formats that are native to their ecosystems.

/cc @peacekeeper

---

Preview | Diff

[rxgrant]

The proposed "suggests" plea is quaintly non-normative, but DCD will not object to it.

A normative change would be to set up another registry where W3C participants agree on the encodings, and demand two interoperable open source implementations in a range of required languages (Javascript and Rust might be a good start) for every allowed key encoding. That means work.

Some key encodings require maintaining a registry, to describe all the combinations with different curves and whatnot, which means that the registry maintainers could implement a gatekeeping attack. That is a reason not to have just one encoding unless it is really good and everyone likes the registry and the maintainers.

The kind of risk from having too many encodings in the ecosystem is an embrace-and-extend attack. This solveable by pulling in a library to implement an encoding seen in the wild, which is not the same kind of risk as being shut out of the ecosystem. Meanwhile, implementors are incentivized to not create a new standard that no one else parses. Therefore, I assess the overall risk as low.

[iherman]

The issue was discussed in a meeting on 2024-11-20

• no resolutions were taken

View the transcript

#### 1.2. Explain why one key format is not realistic. (pr controller-document#120) _See github pull request [controller-document#120](https://github.com/w3c/controller-document/pull/120)._ **Manu Sporny:** Issue was raised by Microsoft four years ago, asking us to settle on one key format. Discussed internally, said no, that's not the way it's implemented in the field. … While it would be nice for there to be one, there are multiple key formats in the world and often in one system. … I think it's got positive reviews, I think I addressed David Chadwick's concerns. … One question I have for the group is that we mention key formats that are more broadly distributed but not mentioned in the document. Should we add SHA public keys and others in the context as something that people can express but not write into the spec? **Ivan Herman:** Apologies if this is already in the document. The argument on why we have two key formats in the document... Is there any trace of that in the document itself? … I want to see something in the document that explains why we do that. **David Chadwick:** I was coming at this with a blank sheet and historical knowledge, but not about discussions. … Back in the 1990s playing with X.509, there were multiple key formats, which was a pain, hence my comment. … I accept the group's decision. **Manu Sporny:** To Ivan, the text you're asking for is in the PR. > *Ivan Herman:* +1. **Manu Sporny:** To DavidC's point, I don't think we should get into this discussion. We should just merge this and move on. We starting 10 years ago with public key PEM was enough but as people came in and out and as development happened, these were the two key formats we could get people to like. … These formats don't do much beyond what PEM does. … I think we should have stuck with PEM but this is the direction the group has gone. … I don't think it's worth reopening at this point, but we may do so in the future or add an extension. … It's very weird that we don't allow the two most widely distributed key formats.

[peacekeeper]

I remember the discussions in the past about one vs. multiple key formats, and I agree with the proposed text here. I have worked on some DID methods where e.g. Base58 or Multikey or JsonWebKey are all not easy to do. Also let's keep in mind that there are verification methods that don't just consist of a single key (e.g. see ConditionalProof or CesrKey).

[brentzundel]

Perhaps a line could be added like "Profiles of this document are encouraged to restrict the number of allowed key formats as much as possible"

[msporny]

Standards are about making choices.

Standards are also about documenting reality. The reality is that there is no one key format that developers have agreed upon in the past or even today.

Standards are also about documenting the available choices that developers are deploying.

This PR adds words without adding clarity. In fact it does the opposite by withdrawing our clear statement that "this specification limits the number of formats".

Please provide concrete text that would address your objection.

[selfissued]

Standards are also about documenting reality.

Yes, but the language in this PR further opens the Pandora's box by implying that other key formats may be used beyond the two already described in the specification. That not documenting reality - it's failing to make choices. You did agree in your comment that standards are about making choices.

Please provide concrete text that would address your objection.

I will plan to do that after the weekend. But the gist of what will address the objection is continuing to explicitly limit the key representations to the two already described in the specification.

[msporny]

The language in this PR further opens the Pandora's box by implying that other key formats may be used beyond the two already described in the specification. That not documenting reality - it's failing to make choices.

No, disagree, it's documenting reality. The specification is an "open world" specification, other developers can choose to extend it in various ways, including the support of other key formats.

To put it in perspective, none of us wanted the Ethereum community to use publicKeyHex, but that's what they used because it made sense for them (because in that community, keys are expressed as hex values). That's documenting reality -- no amount of us telling them to do something else would have helped. We can guide people to use one key format, but the global ecosystem has consistently not done that over multiple decades and not acknowledging that is putting our heads in the sand. Specifications also need to document reality in order to increase the chances of interoperability.

Furthermore, by your logic, everything was going fine with just ASN.1/DER/PEM-encoded keys... the choice had been made. Sure there were other choices, but the worst thing that could have happened at that point, per your logic, is to introduce an entirely new key format, which the JOSE WG did with JOSE Web Key... and then further harmed interoperability by allowing x509 certificate chains to be embedded in the key descriptions resulting in undefined behavior when it came to mixing the two key formats... and then JOSE further failed to make choices by allowing multiple key types, multiple curve types, seemingly random use of octet representations, etc... all colossal failures to make a choice (again, per your logic).

Now, I don't see JOSE as failing to make a choice -- sure, it provides far too many choices, but that was done in an attempt to reflect reality (even though, IMHO, it got it wrong when it came to the number of choices on the whole -- i.e., there was no rational reason for 512-bit EC key lengths in 2014 much less a decade later in 2024.

All that to say, we have lots of proof to the contrary that picking a single key format is NOT how the world operates. Even suggesting that two key formats are going to be workable is wishful thinking, IMHO, but that's where consensus seems to have landed in this group.

All we can do at this point is to urge ecosystems to use a single key type, but acknowledge that the two key types we provide might not work for their ecosystems and so we understand if they have to make a different choice, but hope that they do so in a way that optimizes for interoperability in their ecosystem and the broader ecosystem.

You did agree in your comment that standards are about making choices.

We're miscommunicating. I don't agree with that statement alone. In fact, I reject it as a myopic guiding principle taken by itself in a vacuum.

I do agree that standards are about making choices when it's possible to reduce the number of choices and have it reflect reality.

Please provide concrete text that would address your objection.

I will plan to do that after the weekend. But the gist of what will address the objection is continuing to explicitly limit the key representations to the two already described in the specification.

The text doesn't change that the spec limits the key representations to two. The new text acknowledges that others can be used too, but we warn against that.

Thank you for planning to suggest concrete text.