x509-cert: don't bind builder with signer early

[baloo]

This is mostly a draft after discussion in #1160

cc @bkstein @tarcieri @jstayton

[tarcieri]

Looks good at first glance

[bkstein]

I think, this will improve the situation. However, monomorphization will still take place.

[tarcieri]

The signing API isn't dynamic (yet) so we can't yet avoid monomorphization around the signing operation. It would need fully dynamic counterparts to everything in signature including signature::Keypair.

[baloo]

This is a breaking change. I don't think we mean to introduce a 0.3 of x509-cert yet. I'm happy with the current state, but I'm not in a hurry to get it merged.

[tarcieri]

Yeah, that's fine. We can keep it open until the next breaking release cycle.

[bkstein]

Shouldn't this be independent of x509_cert?

[tarcieri]

?

[baloo]

That was just a rebase from this PR on a fresh master.
But I needed to change the signature of finalize because I attach the public key of the signer "late".
Getting the public from the keypair made it so that I could not get away with just a der::Result.

This is still a breaking change though.

[a1ien]

Could finalize possibly accept public_key or perhaps EncodePublicKey instead of signer? This adjustment would enable the implementation of signing using external crates or hardware tokens.
For instance, with a hardware token, the workflow could proceed as follows:

Obtain the public key.
Call `let tbs = builder.finalize(public_key);`
Utilize an API to sign tbs, resulting in signature.
Call `builder.assemble(signature, algo);`

One of the shortcomings of the current API is its assumption that the private key is always available.

By adopting this approach, only the build method would necessitate access to the private key (or signer). Users could directly invoke finalize and assemble.

[baloo]

Here is an example of the use of this API (before this PR merged):
https://github.com/parallaxsecond/rust-cryptoki/pull/192/files#diff-252eb4db79d32a6b9d23737972d71f2fdf640f29003df3b6f84456df92748bb9

Here is an example of the use of this API (after this PR merged):
https://github.com/iqlusioninc/yubikey.rs/pull/554/files#diff-cdf9b5cf6cfb8f48487829e8ca241f6bbdf86b075fea46aa4f660931053dde9f

Both are use-cases where the signer doesn't have direct access to the private material (PKCS11 for use on HSMs, YubiKey in the PIV applet).

For YubiHSMs there are also various implementations of signers:

• https://docs.rs/yubihsm/latest/yubihsm/?search=signer
• rsa: Adds a signer for PSS and PKCS1#1.5 iqlusioninc/yubihsm.rs#493

I'd like to come around and make a compatibility crate for TPMs at some point (in https://github.com/parallaxsecond/rust-tss-esapi) too.

I'd love help on any of those :) But I think that should address your concerns about hardware tokens.

[a1ien]

Yeah thanks. This looks really awesome.