secp256k1 key support

[lemoustachiste]

Hi,

following the issue I opened on the TS repo (decentralized-identity/trustdidweb-ts#15), and the response I got there, I am opening an issue here to ask if secp256k1 key support could/would be added to the did:tdw spec?

I have a working (minimal) example locally and trying to build up on top of the did document, if you would be interested in seeing the changes involved in the code.

[swcurran]

I’m not a cryptographer, but briefly looking at the differences between secp256k1 and ed25519 keys I gather there is not a lot of difference in the two approaches cryptographically. We don’t want to add support for every key type into the spec. for the Data Integrity signing of the log entries (although the DIDDoc can have any key type). The more we support, the more complex the resolver has to be. It might be fine to support mutliple types, but each has to “earn” its way into the spec.

What is the argument for including both in the spec. and one vs. the other?

Do folks think other key types should be included, and if so, why?

[lemoustachiste]

I'm not sure I'm the one in the best position to make a compelling argument for the support of secp256k1 or any other specific algorithms, but my 2 cents would be that it seems that in the space Ed25519 and EC curves are generally well supported and the go to algorithms for what we are trying to do.

I'm not sure if this applies to BC gov, being Canadian and all, but NIST recommends algorithms for cryptographic use in this document (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186.pdf), and Ed25519 and secp256k1 (in appendix H.2) are approved for cryptographic usage, as well as other curves that may have garnered less support in this space.

As a European citizen working for a US based company, I may have developed a bias towards the NIST importance, but I do seem to observe that at least these two types of algorithm are used by the companies in the "SSI" space and while I am not the maintainer of the spec, or of any DID method spec for that matter, it would still make sense from my perspective to broaden the range of supported cryptographic algorithms to improve adoption.

And for what it's worth, and I'm not certain it is a strong argument, did:webs also theoretically supports secp256k1, although I wasn't able yet to manage a DID creation with a specific seed.

[swcurran]

A priority is use algorithms that are secure, so a NIST is used as guidance. We wouldn’t select something otherwise — and that is covered with both. After that, since both are quite similar, the question of using ed25519 vs. secp256k1 vs. both vs. another algorithm is one of code maintainability and managing dependencies. If we decide to support 10 algorithms, every resolver has to include a dependency for all 10 — a pain for everyone. As such, we want to limit the options so that we simplify the solution.

The DID Method is intended for widespread use, so its definitely not limited to BC Gov preferences.

I do want to underline that there is a big difference in the algorithms for securing the DID Log Entries (currently just ed25519) and what algorithms can be placed into the DIDDoc for use in signing/encryption using the DID — where any algorithm can be used. There is no limit on what types of keys that can be put into the DIDDoc.

[stevenvegt]

I would say, in adition to NIST, also to look at popular key-vaults and language support when choosing the set of curves. It seems Hashicorp Vault and Golang does not have native support for secp256k1.