Add secp256k1 private key

[OR13]

Reasoning:

There already exists and ed25519 priv key: https://github.com/multiformats/multicodec/blob/master/table.csv#L128

Without the ability to represent both public and private components of asymmetric key pairs users will be forced for do things like this:

'id': '',
'type': 'EcdsaSecp256k1VerificationKey2020',
'controller': 'did:example:123',
'publicKeyMultibase': 'zQ3shU9mxTYfMTLceuppoNM5siowHvw3xBk21r855kwgNHNAX',
'privateKeyBase58': '6GyEn649EsbEEJXGQ5m8Eq6NANDmHTPQPWGyF5uL7kx8'

This prevents efficient compression using multibase codecs.

We will likely need to add entries for NIST curves and BLS12381 as well.

[rvagg]

Discussion on the ed25519 private key is worth a read btw https://github.com/multiformats/multicodec/pull/194, note also @msporny's comments at the bottom which I think is worth highlighting and one reason for hesitancy with increasing ease of representation of private keys. That's not to say we shouldn't do this, just that this is stepping into risky territory.

I think we should keep private keys in their own section, as mentioned in that thread and that lead to the placement of ed25519-priv, so I think this should be 0x1301

[OR13]

@rvagg thanks for the review!

@msporny and I have been having this argument for years :)

Its not as much of an issue with JSON-LD when you can just pretend that not defining the term is somehow making it safer to to do this:

'id': '',
'type': 'EcdsaSecp256k1VerificationKey2020',
'controller': 'did:example:123',
'publicKeyBase58': 'zQ3shU9mxTYfMTLceuppoNM5siowHvw3xBk21r855kwgNHNAX',
'privateKeyBase58': '6GyEn649EsbEEJXGQ5m8Eq6NANDmHTPQPWGyF5uL7kx8'

The "problem" with multibase... is that you can't not define the entry... and still use it to represent a private key... like you can with JSON-LD.

Folks using JSON-LD with privateKeyBase58 or privateKeyMultibase can decide if omitting context definitions is a security feature or not... but certainly nobody can even create a privateKeyMultibase without a registry entry here...

the alternative to defining privateKeyMultibase is to use privateKeyJwk, which already preserves key type information and public key representations, and relies on IANA... in order for multibase to ever improve on JWK, it must be at least as expressive, imo... its a show stopper for our adoption of it.. if we can't represent privateKeyMultibase for the key types we use, we will just keep using privateKeyJwk... I expect most developers will do the same when they realize they cannot completely represent a private key.