Daniel McCarney

Some (hopefully helpful) pointers for the failed CI tasks: * [Check for documentation errors](https://github.com/rustls/rustls/actions/runs/9121777381/job/25081683478?pr=1954): I think you need to use `crate::` instead of `rustls::` in the rustdoc for `UnimplementedSubjectPublicKeyInfo` (assuming...

> It looks like we've agreed to return Ok(None) by default for SigningKey::public_key. This looks sensible, though it means that certificate_and_key_are_consistent will (as this PR is written) always return Error::InvalidCertificate(CertificateError::BadEncoding),...

> @cpu, I took a stab at rewriting the keys_match() function with this in mind Thanks! That looks close to what I was thinking, but I was imagining it wouldn't...

> Is this actually what we're doing? Is that your preference? Without strong signal it seems better to follow the plan [outlined by Ctz](https://github.com/rustls/rustls/issues/1918#issuecomment-2093332074) unless there's consensus it isn't the...

@lvkv From my perspective I think Option 1 is probably the most agreeable. Option 2 and 3 will be breaking API changes to the exported `SigningKey` trait and we're trying...

@lvkv Apologies, I think we lost some of the earlier momentum we had going here. Have you become busy (very reasonable!) or are there remaining points of uncertainty we should...

> One idea to unstick the conversation: how do we feel about merging what we have right now (after cleanup)? That sounds OK to me :+1: > if there actually...

> I mostly agree, the one thing I'm in doubt about is whether the KeyConsistency type pulls its weight in this setup compared to just using Result or maybe even...

> I suggest we add something like That proposal sounds good to me. With reflection I think @djc's instincts are correct here & the consistent variant in the `KeyConsistency` enum...

> Apart from that, it seems providing some of the data tools like the Google Chrome DevTools show could be useful not just in research, but also things like e2e...