Add support for server certificate validation

[lulf]

Add support for supplying a CA trust in the TlsConfig and use this to validate the Certificate presented by the server.

[lulf]

Status update on this feature:

At present, the webpki crate is a compile time option for enabling certificate validation. However, the webpki crate does not work on embedded devices and has a few issues:

1. C library dependencies and custom assembly code that makes supporting new targets very slow
2. Random number generation is "owned" by webpki. This doesn't work well with the embedded ecosystem, because there are many different random number generators, and implementing them all in webpki is not feasible.

Therefore, I think it is useful to take a look at alternatives.

IMO the minimal feature set drogue-tls should support are:

• Validating server certificate. One exception is the expiry range: most embedded devices does not have a clock, so this must be ignorable (This is done already for the webpki implementation, but requires a webpki patch)
• Validating signature if the key exchange using the server certificate.

In the first instance I think supporting the elliptic curve signature algorithms should be sufficient:

• EcdsaSecp256r1Sha256 (0x0403)
• EcdsaSecp384r1Sha384 (0x0503)
• EcdsaSecp521r1Sha512 (0x0603)
• Ed25519 (0x0807)

RSA would be nice, but I don't know of any crates being able to do RSA without allocator.

There are several crates not requiring any allocators that could be used for this task (most developed under RustCrypto:

• Signature Algorithms
  • ECDSA
  • ED25519
• Formats
  • Pkcs8
  • SPKI
  • Probably more crates, but some might require alloc and should be avoided

[yaoxin-jing]

Hey @lulf , I wonder what is the status of this feature? Is embedded-tls client support server certificate validation if the server provides a self-signed certificate?

[lulf]

It's the same as the last status I'm afraid. Whether the server certificate is self-signed or not doesn't matter, the only difference would be that you'd have to use your own CA as the trust root.

[bugadani]

I feel like we should extract the webpki verifier to its own crate. rust-analyzer doesn't like that it's gated behind a feature (won't really work with the webpki.rs file), and we might want to encourage developing additional verifier backends if there is a standalone example of how to do it.

rustls has forked webpki. Since they also build on ring, I don't expect this fork would be any more useful for us, but it's something worth knowing about, and might be a good idea to support, too.

[lulf]

I think we should just kill the webpki verifier, I don't think it's useful the way it is, and would rather see one that uses rust-only crates.

[bugadani]

A rust-only solution is a good idea, but killing webpki is harsh IMO. I'm considering using it myself in one form or another, though I haven't started yet.