Refactor eckey_{param2type,type2param}()

EC key parameters can be determined by an OID or they can be explicitly
encoded. The confusingly named eckey_{param2type,type2param}() decode a
new EC key from either form of parameters, or they encode a given key's
parameters in the proper way. Signature and semantics are all over the
place. It also features an inlined version of EC_KEY_new_by_curve_name().
This commit brings some order into this mess.

Parameters are given by a pair (ptype, pval), where the ptype is either
V_ASN1_OBJECT for OID encoding or V_ASN1_SEQUENCE for explicit encoding.
Accordingly, the void pointer pval is an ASN1_OBJECT or an ASN1_STRING.
These pairs are abstracted away in the X509_ALGOR object.

The library decides whether a given EC key uses OID or explicit parameter
encoding using the asn1_flag on the EC key's internal EC_GROUP, i.e., the
object representing its curve. If this flag is set, the OID is determined
by the nid returned by EC_GROUP_get_curve_name().

Add 'mutually inverse' pairs of functions eckey_{to,from}_params() which
wrap eckey_{to,from}_object() and eckey_{to,from}_explicit_params(). This
way the EC ameth pub and priv key de/encoding functions can transparently
translate from/to an X509_ALGOR object.

Of course, this is just an intermediate step and if you look closely you
notice const weirdness (due to the fact that the carefully planned and
executed const rampage missed the ECParameters API) and all sorts of other
things that need to be fixed. Who would bat an eye lid? It wouldn't be
visible amid all the twitching anyway.

ok jsing

0 files changed, 0 insertions, 0 deletions