<div dir="ltr">Yes, in 1.1.1j the following is possible:<br><br>- SM2 cryptosystem operations over the "SM2 curve"<br>- SM2 cryptosystem operations over arbitrary curve (including NIST ones)<br>- ECDSA/ECDH cryptosystem operations over the "SM2 curve"<br><br>(See attached patches to verify this is the case in the tests)<br><br>They require an explicit call to `EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2);` or `EVP_PKEY_set_alias_type(pkey, EVP_PKEY_EC);`, to pick respectively SM2 cryptosystem operations or ECDSA/ECDH cryptosystem operations.<br><br>In 3.0, we want to get rid of `EVP_PKEY_set_alias_type()` and make the "type" of a key object immutable: this will be a breaking change for applications that were using SM2 in 1.1.1.<br><br>This vote is, in addition, about removing existing functionality: doing SM2 stuff over non-SM2 curves (and, somewhat implicitly, also about doing ECDSA/DH-stuff over the "SM2 curve").<br><br>I'd prefer to retain the functionality, accessible programmatically, to create an EC keymgmt object over the "SM2 curve" as well as an SM2 keymgmt object over any arbitrary curve. (Hence my -1 in this vote).<br><br>I'd also like to have a separate vote, when we will formalize that key types are immutable, to require a `EVP_PKEY_todata()` mechanism to mirror the `EVP_PKEY_fromdata()` mechanism, so that while key types remain immutable, there will be a convenient way for us and our users to export a key object from a keymgmt and import it into another keymgmt, letting provider implementations define what is exported and if the exported data is compatible with what is expected on import.<br><br><br>## Serialized SM2-related keys<br><br>Regarding serialization/deserialization of SM2-related keys: at the standard level SM2 reuses the format for standard EC keys, including the "outer" OID for the key type which is "id-ecPublicKey"; it also defines an OID to be used for the (currently) only curve that is recommended for use by the SM2 standard.<br>This OID (<a href="http://oid-info.com/get/1.2.156.10197.1.301">`1.2.156.10197.1.301`</a>) is also a bit weird: it's labeled as `"SM2" elliptic curve cryptography` and it's not a leaf node in the OID tree, among the children there are `.1` for `SM2-1 Digital Signature Algorithm`, `.3` for `"SM2-3" public key encryption` and `.101` for `"wapip192v1"` (which seems to be another SM2 curve, but I never found where it is actually used); but because most implementations (including OpenSSL) use `1.2.156.10197.1.301` to indicate the SM2-recommended 256-bit prime curve some projects (notably gmSSL) refer to at as `sm2p256v1`.<br><br>At the same time, from the <a href="https://gist.github.com/romen/d752b8d1897bc1a0009017511770de06">available SM2 standards</a>, while `sm2p256v1` is currently the only recommended curve, nothing prevents using other elliptic curves: in theory both prime and binary curves are allowed, and IIRC also explicit parameter ones.<br><br>Overall the current scenario of how SM2 OIDs are assigned/used, combined with the fact that the SM2 standard reuses the same serialization format defined by SECG for regular ECDSA/ECDH keys, makes it impossible to distinguish between a key for the SM2 cryptosystems or for the ECDSA/DH cryptosystems.<br><br>In 1.1.1j, when deserializing with `PEM_read_PrivateKey()` this key:<br><br>~~~<br>-----BEGIN PRIVATE KEY-----<br>MIGHAgEAMBMGByqGSM49AgEGCCqBHM9VAYItBG0wawIBAQQgOYffNMmrl1T1HVVC<br>wijmHL5xn9vm/IeLWfLnA/NJwgehRANCAAQsIGyWbZl+m04MHFOf47z/Z06Yyr69<br>ZjZZoyJviFyj/9mx4B8Mjs2ranuRjykBF6SdIcLD+c6AqZ9cvs2V4m2R<br>-----END PRIVATE KEY-----<br><br> 0:d=0 hl=3 l= 135 cons: SEQUENCE <br> 3:d=1 hl=2 l= 1 prim: INTEGER :00<br> 6:d=1 hl=2 l= 19 cons: SEQUENCE <br> 8:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey<br> 17:d=2 hl=2 l= 8 prim: OBJECT :sm2<br> 27:d=1 hl=2 l= 109 prim: OCTET STRING <br> 0000 - 30 6b 02 01 01 04 20 39-87 df 34 c9 ab 97 54 f5 0k.... 9..4...T.<br> 0010 - 1d 55 42 c2 28 e6 1c be-71 9f db e6 fc 87 8b 59 .UB.(...q......Y<br> 0020 - f2 e7 03 f3 49 c2 07 a1-44 03 42 00 04 2c 20 6c ....I...D.B.., l<br> 0030 - 96 6d 99 7e 9b 4e 0c 1c-53 9f e3 bc ff 67 4e 98 .m.~.N..S....gN.<br> 0040 - ca be bd 66 36 59 a3 22-6f 88 5c a3 ff d9 b1 e0 ...f6Y."o.\.....<br> 0050 - 1f 0c 8e cd ab 6a 7b 91-8f 29 01 17 a4 9d 21 c2 .....j{..)....!.<br> 0060 - c3 f9 ce 80 a9 9f 5c be-cd 95 e2 6d 91 ......\....m.<br><br>~~~<br><div><br>we create an EVP_PKEY object with `{ .type = 408 (= EVP_PKEY_EC, "id-ecPublicKey"), .save_type = 408 }`. If used via EVP functions in this form, this will be used as a regular EC key, computing ECDSA/ECDH.<br><br>After an explicit call to `EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2))`, the EVP_PKEY object reads `{ .type = 1172 (= EVP_PKEY_SM2, "SM2"), .save_type = 408 }`, and using EVP functions will result in using this as a key for the SM2 cryptosystems (e.g. SM2DSA).</div><div><br></div><div><br></div><div>In 3.0, as of 3e6a0d5738, our DECODER implementation is able to distinguish on the inner curve OID, so parsing the PEM above results in a key object belonging to the SM2 keymgmt.<br>Because `EVP_PKEY_set_alias_type()` is not supported, in current 3.0 it is hard (if not impossible) to flexibly use EC/SM2 keys as in 1.1.1, but it is still possible to do something with ephemeral keys (e.g. one can initialize an SM2 keygen EVP_PKEY_CTX and set P-521 as the curve, which ultimately delivers an SM2 key object over an arbitrary curve that can be used, for example, for SM2DSA operations as demonstrated by 0001-drop-3.0.0-test-SM2DSA-and-SM2ENC-DEC-over-NIST-P-52.patch).<br><br><br>Nicola</div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021 at 8:50 PM Kurt Roeckx <<a href="mailto:kurt@roeckx.be">kurt@roeckx.be</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Mar 09, 2021 at 03:57:32PM +0200, Nicola Tuveri wrote:<br>
> It is tangent to the vote in itself, but I'd like to highlight that in part<br>
> this vote is motivated by getting rid of cases where there is a need to<br>
> convert between compatible key types (e.g. SM2 & EC, DH & DHX).<br>
> <br>
> The vote of this text does not cover it, but another use case that we will<br>
> likely lose in 3.0 when this vote passes is using ECDH/ECDSA over the curve<br>
> identified by the SM2 OID.<br>
> <br>
> It's likely another niche use, not relevant for any production system, but<br>
> it is creating a precedent where OpenSSL accepts that the SM2 standard<br>
> overrides the SECG standard.<br>
> <br>
> In 1.1.1 we do _default_ to decode a key serialized as "SECG EC over the<br>
> SM2 OID curve" as a SM2 key, but we are not preventing developers from<br>
> creating an EC key object over that curve, nor an SM2 key object over any<br>
> other curve (serialization of such "weird" key objects would be identical,<br>
> deserialization would require an explicit set_alias call to mutate from the<br>
> default type).<br>
> <br>
> With the changes proposed as a corollary to this vote that were discussed<br>
> on the last OTC meeting, we would remove this ability: we could maybe still<br>
> create an ephemeral "EC over SM2 OID" key object but there would be no way<br>
> to deserialize one.<br>
> <br>
> <br>
> I would instead prefer to vote on requiring for 3.0 a mechanism to<br>
> "convert" key types: an EVP_PKEY_todata function to mirror<br>
> EVP_PKEY_fromdata.<br>
> It will be then up to the individual keymgmt of the source key object to<br>
> decide if it can be exported to OSSL_PARAMs, and to the receiving keymgmt<br>
> on which fromdata is called to determine if the input OSSL_PARAMs are valid<br>
> to create a proper key object.<br>
> Yes, we would still have a breaking change (set_alias needs to be replaced<br>
> by the todata/fromdata dance) but we wouldn't lose functionality.<br>
> <br>
> Such a mechanism could be useful also beyond the current problem of key<br>
> conversions within the builtin providers, and allow future proofing and<br>
> interoperability between different providers that might end up using<br>
> different names for compatible key types (for whatever reason it might<br>
> happen).<br>
<br>
This text does not seem to help me to make a vote, it seems I just<br>
get more questions.<br>
<br>
The EVP_PKEY_set_alias_type() manpage says that SM2 use the same<br>
encoding an ECDSA. I assume that during deserialization we don't<br>
know if we should create an ECDSA key or an SM2 key, because we<br>
don't look at the OID when deserializing and always create an<br>
ECDSA key. My understanding is that there is code that needs to<br>
know an SM2 key is stored in that object, and is not looking at<br>
the OID, but instead looks at what the pkey type is. My suggested<br>
fix for that would be to make the deserialization smarter so it<br>
sets the correct pkey type base on the OID.<br>
<br>
Assuming that we can get an SM2 key, I currently fail to see why<br>
ECDSA or ECDH wouldn't work with them, but I know very little<br>
about SM2.<br>
<br>
I also don't understand what the vote is really about. Can 1.1.1<br>
do SM2 on one of the nist curves?<br>
<br>
<br>
Kurt<br>
<br>
</blockquote></div>