Certificate::generate_self_signed can't work reliably with yubikey::piv::generate

[str4d]

In yubikey 0.7, Certificate::generate_self_signed took a yubikey::certificate::PublicKeyInfo argument as the key to generate the certificate for. This was an enum that was obtained from yubikey::piv::generate after passing in an AlgorithmId enum, so algorithm information was inherently passed from one to the other.

In yubikey 0.8, yubikey::piv::generate and Certificate::generate_self_signed now communicate via a SubjectPublicKeyInfoOwned, which is an opaque type. As a side-effect, Certificate::generate_self_signed now requires a type argument to work. Failing to set the type argument causes obscure and confusing errors related to the extensions closure.

However, yubikey::piv::generate still takes an AlgorithmId enum. So the algorithm of the SubjectPublicKeyInfoOwned that yubikey::piv::generate returns may be determined at runtime, and yet Certificate::generate_self_signed requires it to be fixed at compile time. This is a confusing API, as to correctly handle runtime determination you need to embed four copies of Certificate::generate_self_signed.

• We should either have the API use a runtime-specified or compile-time-specified algorithm, not both.
• If we go with compile-time, yubikey::piv::generate should not return an opaque SubjectPublicKeyInfoOwned, but instead a type that carries the compile-time algorithm with it for Certificate::generate_self_signed to use.

[tony-iqlusion]

cc @baloo

[baloo]

Yeah we can go the compile time road I guess.

Have generate look like:

pub fn generate<KT: KeyType>(
    yubikey: &mut YubiKey,
    slot: SlotId,
    pin_policy: PinPolicy,
    touch_policy: TouchPolicy,
) -> Result<KT::VerifyingKey> {

I think I can revisit this with the pre-release of x509-cert