feat(identity): allow importing and exporting ECDSA keys

[drHuangMHT]

Description

Implement encoding to/decoding from DER-encoded secret key document for ecdsa::SecretKey.
Implement encoding to/decoding from protobuf format for ECDSA keys.
Bump dependency p256 from 0.12 to 0.13.
Bump dependency sec1 from 0.3.0 to 0.7

Related: #3681.

Notes & open questions

Attempt for decoding support failed because the returned error type pkcs8::error::Error does not implement std::error::Error(requires std feature on pkcs8, despite std is enabled on p256), which is required for DecodingError::failed_to_parse.

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[thomaseizinger]

``(requires std feature on `pkcs8`, despite `std` is enabled on `p256`)

You can work around this by adding an explicit dependency for pkcs8 and activate the std feature there. I'd also recommend opening an upstream issue/PR that fixes this so we can eventually remove that dependency again!

[thomaseizinger]

Awesome! Thank you for splitting this out.

I think we should integrate this into the Keypair::to_protobuf_encoding function.
Also, can you add a changelog entry?

[drHuangMHT]

``(requires std feature on `pkcs8`, despite `std` is enabled on `p256`)

You can work around this by adding an explicit dependency for pkcs8 and activate the std feature there. I'd also recommend opening an upstream issue/PR that fixes this so we can eventually remove that dependency again!

Can be fixed by using p256 version 0.13

[thomaseizinger]

I forgot to create a new branch previously

Another way would be to simply branch off a different commit:

git checkout -b remove-sec1-dependency <COMMIT_HASH>

Where <COMMIT_HASH> is a commit before all your changes. Find one with git log.

[thomaseizinger]

Implementation looks good to me, CI failures need to be addressed :)

[thomaseizinger]

Awesome, thank you!

Waiting with merge on the otherlibp2p implementations to check that we are doing the right thing:

See libp2p/specs#537.

[drHuangMHT]

Um what's wrong with the hex value?

[thomaseizinger]

We don't seem to be doing the correct encoding, can you look into that?

libp2p/specs#537 (comment)

[drHuangMHT]

We don't seem to be doing the correct encoding, can you look into that?

libp2p/specs#537 (comment)

The key used for testing is generated using openssl. It was in pem so I told openssl to convert it to pkcs#8. The first integer is 0 by looking at the key on my machine. However, the key generated by our implementation also comes with the first integer being 0. p256 is a pure rust implementation right? So could it be p256? Still digging.

[drHuangMHT]

Problem solved. However I don't see a convenient way to encode the key. Seems we need to implement it ourselves.

[thomaseizinger]

Problem solved. However I don't see a convenient way to encode the key. Seems we need to implement it ourselves.

I haven't dug into the details but you mentioned RFC5915 in the specs repository. A crates.io search revealed the following: https://docs.rs/sec1/0.7.2/sec1/

Perhaps that is all we need?

[drHuangMHT]

Problem solved. However I don't see a convenient way to encode the key. Seems we need to implement it ourselves.

I haven't dug into the details but you mentioned RFC5915 in the specs repository. A crates.io search revealed the following: https://docs.rs/sec1/0.7.2/sec1/

Perhaps that is all we need?

God we just wanted to drop that dependency, hilarious.

[thomaseizinger]

Awesome, thanks for updating!