Support non RSA keys

[Stebalien]

E.g., ed25519.

[marten-seemann]

#9 adds support for ECDSA keys.

The problem with ed25519 is that Go doesn't support EdDSA certificates (yet): golang/go#25355. According to the milestone tag, support is supposed to be added in Go 1.12, although it's already pretty late in the process (the beta was released in mid December already), so it might not make it.

[Stebalien]

Is there any way to explicitly include the libp2p key type in the certificate? I'm worried about future extensions where we have multiple key types that map to the same wire format in TLS1.3.

[Stebalien]

There's also the intersection between this and libp2p/specs#111. We may need to be able to encode additional metadata.

[marten-seemann]

x509.Certificate allows us to specify extensions, which are included as ASN1. We could use that to send arbitrary data.

I'm not sure I fully understand the whole discussion of libp2p/specs#111, but wouldn't using arbitrary keys and hash functions (as opposed to those supported by TLS) mean that we can't use certificate-based authentication at all?

[Stebalien]

We just need to be able to derive:

1. The peer's original libp2p key.
2. The peer's ID.

We should still be able to use certificates, we just need to transmit enough information to get 1 which will allow us to derive 2.

[marten-seemann]

How exactly would we derive the libp2p key? Since you're highlighting libp2p key, I'm assuming that it might be different from the key used in the certificate.

[Stebalien]

I mean the key as defined in https://github.com/libp2p/go-libp2p-crypto/. For now, we're fine. However, with libp2p/specs#111, we'll add a new field (to indicate the hash algorithm we're using to generate the peer ID) to https://github.com/libp2p/go-libp2p-crypto/blob/master/pb/crypto.proto. We'll need to somehow include this in the key we send with TLS.

[marten-seemann]

That sounds doable. We'll define a new pkix.Extension and include that in the certificate. In that extension, we somehow encode the hash algorithm. We probably can just send the multihash code point.
My only concern is interop with the JS implementation here. Adding an extension is easy in Go, but I have no idea how things look in JS land. Who do we need to ping to discuss this?

[Stebalien]

@vasco-santos or @jacobheun?

My thinking is:

1. Take the serialized libp2p key.
2. Decode it as a protobuf.
3. Remove the actual public key material. This will end up in the certificate/tls key.
4. Re-serialize the key protobuf.
5. Stick this in the extension.

That way, we always preserve all additional keys.

---

Note: Relates to https://github.com/libp2p/go-libp2p-crypto/issues/51.

[jacobheun]

So, js-libp2p-crypto is currently using node-forge. It looks like adding an extension should be fairly straightforward.

[marten-seemann]

Fixed by #20.