Expose algorithm field on PublicKey

[rickvanprim]

Fixes #280.

[cpu]

This seems reasonable to me. AIUI this is a capability callers had before #205

[rickvanprim]

This seems reasonable to me. AIUI this is a capability callers had before #205

My code on the older version of rcgen did do the algorithm check as it was exposed as part of CertificateParams 🙂

[est31]

I think it would be better to add it as a function on PublicKey instead, then mut access doesn't allow you to generate invalid configurations.

Also, I wonder whether it makes sense to additionally expose the PublicKeyData trait to the public (I don't like APIs that require you to import a trait, ideally the functions are available both through traits and inherent functions, unless it is a lot of API surface that's covered). Maybe that's a separate discussion though.

[cpu]

I think it would be better to add it as a function on PublicKey instead, then mut access doesn't allow you to generate invalid configurations.

Sounds reasonable to me.

Also, I wonder whether it makes sense to additionally expose the PublicKeyData trait to the public

I like this direction less personally. I think this trait is a bit awkward (but have a hard time articulating why). I think exposing it in the existing API will make it harder to smooth out any rough edges.

[rickvanprim]

@est31 / @cpu, I changed to a method on PublicKey, which is a copy paste of the method for PublicKeyData. I could make the PublicKeyData method call the method on PublicKey as well if that's preferred, but given how they're both trivial accessors, I'm not sure that serves much point. Please let me know if any further changes are desired 🙂

One small discrepancy I just noticed while adding this to test_csr_roundtrip() is KeyPair::algorithm() vs PublicKeyData::alg().

[est31]

Thanks!

[cpu]

Thanks!