loading pkcs8 EC private keys

[mcr]

We have rsa::KeyPair::from_pkcs8, but no ec::KeyPair::from_pkcs8 (that I can see).
(Ideally, I'd like a fn that could load either EC or RSA private keys without the application have to know which it has got)

Reading unwrap_key*(), I see that the purpose of the template, which is loaded as a literal OID value,
it seems that it's just the alg_id_value in OID format. unwrap__() compares it as a ("less safe") slice.
Why have an external file for a single OID, which is then turned into an untrusted::Input, when it could just be a literal static slice?

[briansmith]

We have rsa::KeyPair::from_pkcs8, but no ec::KeyPair::from_pkcs8 (that I can see).

The from_pkcs8 functions for each KeyPair type all have slightly different signatures. This comes partly from the fact that every randomized function in ring takes a reference to rand::SecureRandom, and only EcdsaKeyPair needs it for constructing a key.

(Ideally, I'd like a fn that could load either EC or RSA private keys without the application have to know which it has got)

One part of the design of ring is that you cannot use an algorithm without mentioning it explicitly. (Ed25519 is an exception, because it uses SHA-512 implicitly, but really SHA-512 is part of Ed25519 as implemented here.)

I understand the value in having a function that takes a list of acceptable algorithms and returns a key if it is for one of those algorithms. I just never got around to implementing it.

Why have an external file for a single OID, which is then turned into an untrusted::Input, when it could just be a literal static slice?

Today, I probably wouldn't do it that way. IIRC, having it in an external file allowed me to use some external tools to verify that the encoding of the OID was correct, but that became superfluous.