Parsing a PKCS#8 ECDSA signing keypair is confusing and inefficient about ring HOT 3 OPEN

So if I understood that correctly, to summarize

• There are multiple combinations of parameters (curve + algorithm), some of which are safe and some of which aren't
• Right now the safe combinations are enumerated as ECDSA_* etc, along with usage method (fixed, asn1)
• Private keys only contain part of the parameters (curve) so the additional information is required to be supplied when deserializing (in this case the full set of parameters)
• The full parameters and private key data are stored together in the keypair so there's no chance of mix ups

So far that sounds reasonable to me.

The issues caused by pairing up the curve + algorithm are:

• The same key may be used with multiple algorithms which currently isn't straightforwardly possible due to the pairing
• Responsibilities are often split where the user loads the key and passes it to a library that uses the key, but in order to load the key the user needs to know what algorithm the library expects to use.

The idea proposed here is (roughly)

1. Keep the enumerated combinations
2. When parsing, the user presents a set of combinations. This could, for instance, be a default set like default_signing() or something?
3. Based on the curve in the key, the subset of presented combinations are stored with the key
4. When the key is used, an algorithm is presented, and that's checked against the stored list of combinations

You also mentioned splitting them, I assume like:

1. When parsing, no extra input. Curve is read and stored in key
2. When signing, the algorithm is presented and checked to see if it could be safely used with the curve

The disadvantage to this approach is that it's implicit in accepting combinations, there's no difference between using a FIPS compliant combination vs a non-compliant legacy combination, but the latter must still be supported due to existing uses.

The proposed solution seems smart to me (from my very outside view). My only concern is I wonder how much information a user needs in order to deserialize key pairs. If a default algorithm set could be used that's fine, but if they need to know more about how the key will be eventually used by a library in order to deserialize it it leaks library implementation details.

I think the pattern of "user gets pem, needs to deserialize it, then pass it to a library" is common. Right now rustls gets around it by just taking a pem (string?) and doing the deserialization itself, but if the cert needs to be reused it presents a less type safe interface since it pushes you to pass around untyped bytes (are those bytes from a pem? der? pcks8? sec1? etc).

Another option might be to have sign reject less secure combinations and a sign_allow_legacy or sign_dangerous for if you need those? It would shift responsibility to the library, but I'm not sure if that's reasonable in the typical contexts for needing legacy combinations.

from ring.

• There are multiple combinations of parameters (curve + algorithm), some of which are safe and some of which aren't

It isn't necessarily about safe vs. unsafe, but "allowed" vs. "not allowed," depending on which rules one is required to follow. In particular, when one is required to follow NIST/FIPS rules then certain combinations are not allowed for whatever reason.

When parsing, the user presents a set of combinations. This could, for instance, be a default set like default_signing() or something?

We do not provide things that would be like the default_signing() in ring currently. Basically, we expect the library to decide (probably by offering some configurability) which algorithms to support. Partly, this is to let the user choose the policies they are trying to conform too. Partly, this is a code size optimization, as any algorithms that the user doesn't provide to ring as an "allowed algorithm" will automatically be discarded at link time.

When parsing, no extra input. Curve is read and stored in key
When signing, the algorithm is presented and checked to see if it could be safely used with the curve

Close. When parsing, one would supply what {curve,digest algorithm} combinations are allowed. When signing, ring would verify that the digest algorithm used was one of the ones that were mentioned being allowed at parsing time.

My only concern is I wonder how much information a user needs in order to deserialize key pairs. If a default algorithm set could be used that's fine, but if they need to know more about how the key will be eventually used by a library in order to deserialize it it leaks library implementation details.

In your library, you can maintain this "default algorithm set" yourself within your library, if you don't want the user to have to configure which algorithms are allowed. But usually if you are dealing with things like PKCS#8 you will need to have some user configuration about which algorithms are allowed, because different users have different policies they need to conform to.

from ring.

Ah okay, makes sense. Thanks!

from ring.