Rework Certificate issuance API, make DER/PEM serialization stable

[cpu]

Previously a Certificate was a container for CertificateParams and a KeyPair, most commonly created from a CertificateParams instance. Serializing the Certificate (either as self signed with serialize_pem or serialize_der, or signed by an issuer with serialize_pem_with_signer or serialize_der_with_signer) would issue a certificate and produce the serialized form in one operation. The net result is that if a user wanted both DER and PEM serializations they would likely call serialize_der(_with_signer) and then serialize_pem(_with_signer) and mistakenly end up with the encoding of two distinct certificates, not the PEM and DER encoding of the same cert. Since the KeyPair contains a private key this API design also meant that the Certificate type had to be handled with care, and Zeroized.

This branch reworks the issuance API and Certificate type to better match user expectation: Certificate is only public material and represents an issued certificate that can be serialized in a stable manner in DER or PEM encoding.

I recommend reviewing this commit-by-commit, but here is a summary of the most notable API changes:

• Certificate::from_params and Certificate::serialize_der and Certificate::serialize_pem for issuing a self-signed certificate are replaced with Certificate::generate_self_signed() and calling der or pem on the result.
• Certificate::from_params and Certificate::serialize_der_with_signer and Certificate::serialize_pem_with_signer for issuing a certificate signed by another certificate are replaced with Certificate::generate() and calling der or pem on the result.
• CertificateSigningRequest::serialize_der_with_signer and CertificateSigningRequest::serialize_pem_with_signer for issuing a certificate from a CSR are replaced with Certificate::from_request and calling der or pem on the result. The CertificateSigningRequest type is renamed to CertificateSigningRequestParams to better emphasize its role and match the other *Params types that already exist.
• Since we now calculate the DER encoding of the certificate at Certificate construction time, the pem and der fns are now infallible.
• Since Certificate no longer holds KeyPair, the generate fns now expect a &KeyPair argument for the signer when issuing a certificate signed by another certificate.
• The generation fns now return a CertifiedKey that contains both a Certificate and a KeyPair. For params that specify a compatible KeyPair it is passed through in the CertifiedKey as-is. For params without a KeyPair a newly generated KeyPair is used.

In the future we should look at harmonizing the creation of CertificateSigningRequest and CertificateRevocationList to better match this updated API. Unfortunately I don't have time to handle that at the moment. Since this API surface is relatively niche compared to the Certificate issuance flow it felt valuable to resolve #62 without blocking on this future work.

Resolves #62

[djc]

I think this makes the API much better, nice!

[est31]

looks great!

[est31]

I also really like the CertifiedKey struct. Maybe the name is not ideal but we can always change it in a followup PR.

I'm also thinking about a struct CertifiedKeyRef<'a,'b> { pub cert: &'a Certificate, pub key: &'b KeyPair }, which can be used in the cases where references for both the key and the cert are wanted, and a conversion function like impl CertifiedKey { fn ref(&self) -> CertifiedKeyRef<'_, '_> {...}} . I think that's also best for a followup.