<div dir="auto">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).<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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). </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto">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.</div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Nicola</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021, 12:24 Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">topic: In 3.0 it will not be possible to use SM2 with a non-SM2 curve. This<br>
        should be documented.<br>
Proposed by Matt Caswell<br>
Public: yes<br>
opened: 2021-03-09<br>
closed: 2021-mm-dd<br>
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)<br>
<br>
   Matt       [+1]<br>
   Mark       [  ]<br>
   Pauli      [+1]<br>
   Viktor     [  ]<br>
   Tim        [+1]<br>
   Richard    [+1]<br>
   Shane      [+1]<br>
   Tomas      [ 0]<br>
   Kurt       [  ]<br>
   Matthias   [  ]<br>
   Nicola     [-1]<br>
<br>
</blockquote></div>