OTC VOTE: Disallow SM2 with a non-SM2 curve

[Nicola Tuveri]

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).




Nicola

On Tue, Mar 9, 2021, 12:24 Matt Caswell <matt at openssl.org> wrote:

> topic: In 3.0 it will not be possible to use SM2 with a non-SM2 curve. This
>         should be documented.
> Proposed by Matt Caswell
> Public: yes
> opened: 2021-03-09
> closed: 2021-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
>
>    Matt       [+1]
>    Mark       [  ]
>    Pauli      [+1]
>    Viktor     [  ]
>    Tim        [+1]
>    Richard    [+1]
>    Shane      [+1]
>    Tomas      [ 0]
>    Kurt       [  ]
>    Matthias   [  ]
>    Nicola     [-1]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20210309/c6cab777/attachment-0001.html>