OTC VOTE: Disallow SM2 with a non-SM2 curve

[Kurt Roeckx]

On Tue, Mar 09, 2021 at 03:57:32PM +0200, Nicola Tuveri wrote:
> It is tangent to the vote in itself, but I'd like to highlight that in part
> this vote is motivated by getting rid of cases where there is a need to
> convert between compatible key types (e.g. SM2 & EC, DH & DHX).
> 
> The vote of this text does not cover it, but another use case that we will
> likely lose in 3.0 when this vote passes is using ECDH/ECDSA over the curve
> identified by the SM2 OID.
> 
> It's likely another niche use, not relevant for any production system, but
> it is creating a precedent where OpenSSL accepts that the SM2 standard
> overrides the SECG standard.
> 
> In 1.1.1 we do _default_ to decode a key serialized as "SECG EC over the
> SM2 OID curve" as a SM2 key, but we are not preventing developers from
> creating an EC key object over that curve, nor an SM2 key object over any
> other curve (serialization of such "weird" key objects would be identical,
> deserialization would require an explicit set_alias call to mutate from the
> default type).
> 
> With the changes proposed as a corollary to this vote that were discussed
> on the last OTC meeting, we would remove this ability: we could maybe still
> create an ephemeral "EC over SM2 OID" key object but there would be no way
> to deserialize one.
> 
> 
> I would instead prefer to vote on requiring for 3.0 a mechanism to
> "convert" key types: an EVP_PKEY_todata function to mirror
> EVP_PKEY_fromdata.
> It will be then up to the individual keymgmt of the source key object to
> decide if it can be exported to OSSL_PARAMs, and to the receiving keymgmt
> on which fromdata is called to determine if the input OSSL_PARAMs are valid
> to create a proper key object.
> Yes, we would still have a breaking change (set_alias needs to be replaced
> by the todata/fromdata dance) but we wouldn't lose functionality.
> 
> Such a mechanism could be useful also beyond the current problem of key
> conversions within the builtin providers, and allow future proofing and
> interoperability between different providers that might end up using
> different names for compatible key types (for whatever reason it might
> happen).

This text does not seem to help me to make a vote, it seems I just
get more questions.

The EVP_PKEY_set_alias_type() manpage says that SM2 use the same
encoding an ECDSA. I assume that during deserialization we don't
know if we should create an ECDSA key or an SM2 key, because we
don't look at the OID when deserializing and always create an
ECDSA key. My understanding is that there is code that needs to
know an SM2 key is stored in that object, and is not looking at
the OID, but instead looks at what the pkey type is. My suggested
fix for that would be to make the deserialization smarter so it
sets the correct pkey type base on the OID.

Assuming that we can get an SM2 key, I currently fail to see why
ECDSA or ECDH wouldn't work with them, but I know very little
about SM2.

I also don't understand what the vote is really about. Can 1.1.1
do SM2 on one of the nist curves?


Kurt