SM2 CSR public key OID error

[qwe857359351a]

openssl version:3.1.2

Used in our projects CSR:

MIHYMIGAAgEAMB4xHDAaBgNVBAMME0NlcnRpZmljYXRlIFJlcXVlc3QwWTATBgcqhkjOPQIBBggqgRzPVQGCLQNCAASyiSsUGJKsk53i8Qw7yvBPcBRsMNZg/WuboFnnhCo07sXgQB7gWpILUflgCtb+17r13cdbsBC74xTxDeMDrvzKoAAwCgYIKoEcz1UBg3UDRwAwRAIgMXPS8ZxsPi1HQcpH5ZhiC3mPnYu/IIE9X0Gt0wvJDqECIEon2P3dHrbUjMaGcaDbvgNvt4x7A23Wg4/BtHYQMhXJ

The openssl create CSR, not available:

MIHaMIGBAgEAMB4xHDAaBgNVBAMME0NlcnRpZmljYXRlIFJlcXVlc3QwWjAUBggqgRzPVQGCLQYIKoEcz1UBgi0DQgAEjXUWOS8b9nVeWy4G+9uRSJc5zOp4jhuPBCxzpmBuf5ywI77vkjX6lAqL6CzI46WrqwoV5Hi2SlVBh49L/3Rjf6AAMAoGCCqBHM9VAYN1A0gAMEUCIEKEWVq6DFMlp/8Bd8CrdWUohuqb78os+6xrzdVV4EuTAiEAsVP8FKJ8kPnO5mPkehGRUnGGDcM9WHMX5bpUU/q7yNQ=

this is code:

EVP_PKEY* pkey = NULL;
EVP_PKEY* pubKey = NULL;

EVP_MD_CTX *mdCtx = NULL;
EVP_PKEY_CTX* pkctx = NULL;
EC_KEY* ecKey = NULL;
X509_REQ* x509Req = NULL; 
X509_NAME* x509Name = NULL;
unsigned char* keyBuf = NULL;
unsigned char* csrBuf = NULL;
BIO* bio = BIO_new(BIO_s_mem());

unsigned int keyBufLen = 0;
unsigned int csrBufLen = 0;

unsigned int signLen = 0;

pkctx = EVP_PKEY_CTX_new_id(EVP_PKEY_SM2, NULL);
EVP_PKEY_keygen_init(pkctx);

EVP_PKEY_generate(pkctx, &pkey);

keyBufLen = i2d_PrivateKey(pkey, NULL);


keyBuf = (unsigned char*)malloc(keyBufLen);
i2d_PrivateKey_bio(bio, pkey);
BIO_read_ex(bio, keyBuf, -1, &keyBufLen);

//Gen CSR
x509Req = X509_REQ_new();
X509_REQ_set_version(x509Req, 0);

x509Name = X509_REQ_get_subject_name(x509Req);

X509_NAME_add_entry_by_txt(x509Name, "CN", MBSTRING_UTF8, (const unsigned char*)"Certificate Request", -1, -1, 0);

X509_REQ_set_pubkey(x509Req, pkey);

mdCtx = EVP_MD_CTX_new();
//set userid
EVP_PKEY_CTX_set1_id(pkctx, SM2_DEFAULT_USER_ID, SM2_DEFAULT_USER_ID_LEN);
EVP_MD_CTX_set_pkey_ctx(mdCtx, pkctx);
X509_REQ_sign_ctx(x509Req, mdCtx);

signLen = X509_REQ_sign(x509Req, pkey, EVP_sm3());

csrBufLen = i2d_X509_REQ(x509Req, NULL);
csrBuf = (unsigned char*)malloc(csrBufLen);
BIO_reset(bio);
i2d_X509_REQ_bio(bio, x509Req);
BIO_read_ex(bio, csrBuf, -1, &csrBufLen);

What should I do to use the same OID?

[qwe857359351a]

I checked some websites，include openssl/test/certs/sm2-csr.pem, and java BouncyCastle，OID all 1.2.840.10045.2.1

[qwe857359351a]

This is the generated key and CSR，oid incorrect
KEY：
MHcCAQEEICW42jLdpT7Z6i7yD9UZWmUQ9hCQnQk5RsgNeOIfHB37oAoGCCqBHM9VAYItoUQDQgAEw0ChusIPURxssnWDyriD5JGWOXld4y3O4/QzOQKB7vzgVeRDxDYJkwOLYJgnU7gMyAZuGiNjtOYt023M+XVPhg==

CSR：
MIHbMIGBAgEAMB4xHDAaBgNVBAMME0NlcnRpZmljYXRlIFJlcXVlc3QwWjAUBggqgRzPVQGCLQYIKoEcz1UBgi0DQgAEw0ChusIPURxssnWDyriD5JGWOXld4y3O4/QzOQKB7vzgVeRDxDYJkwOLYJgnU7gMyAZuGiNjtOYt023M+XVPhqAAMAoGCCqBHM9VAYN1A0kAMEYCIQCKZcmjT6pLjSvmYQwtYfmNltfqKU/Lhmy2FUpzq/H7KQIhALDGHTVGpBzBeru7oRoqbAh0OXgL0zanSi4PqS8sd6Bf

[t8m]

@InfoHunter Do you have any ideas here?

[InfoHunter]

as per: #22184 (reply in thread)

[qwe857359351a]

@InfoHunter Can you help me deal with it?

[xiezhaokun]

The signature is also wrong

[qwe857359351a]

There will be a discussion later, if you are interested, you can follow it

[slontis]

I get a similiar thing just by doing the following

> LD_LIBRARY_PATH=. ./apps/openssl pkey -in test/certs/sm2-pub.key -pubin -outform DER -out sm2.der
> dumpasn1 sm2.der

  0  90: SEQUENCE {
  2  20:   SEQUENCE {
  4   8:     OBJECT IDENTIFIER sm2ECC (1 2 156 10197 1 301)
 14   8:     OBJECT IDENTIFIER sm2ECC (1 2 156 10197 1 301)
       :     }
 24  66:   BIT STRING
       :     04 30 A9 E3 64 5A 9E DF 8A ED 4A 66 7B 83 90 0B
       :     9C A4 CF 29 88 4C C4 4C BD 72 9A B7 2B 38 1B EF
       :     F2 68 4D 36 47 9B DB 46 AC 6D 68 05 40 8D B3 3A
       :     B4 8C F7 DF EC 5C 69 FD AC CD BF BA C3 3F 32 57
       :     1A
       :   }

[levitte]

This is an encoding bug, and this discussion should be converted to an issue

UPDATE: this might turn out not to be a bug, see further discussions below.

[levitte]

I've a draft for a fix here: #22529

[mattcaswell]

I am not convinced that this is a bug at all but rather a deliberate decision to use this OID.

[levitte]

Is that our decision to make? It is, after all, quite confusing, as the SM2 key is really an ECC key, but with a slightly different treatment.

[mattcaswell]

"with a slightly different treatment."...meaning it isn't ECDSA. So, yes, elliptic curve, as is EdDSA but that has a different OID.

[mattcaswell]

Hmmm. This encoding seems to have first been introduced by commit f2db052 - which makes no mention of the change of behaviour. So maybe this wasn't quite so deliberate after all. The question is whether we should change it now. It's been like this since 3.0.

[levitte]

I recall a lot of discussions surrounding this, and trying to dig into the standards we could find. So maybe this discussion will end up serving as a reminder of conclusions we made then.

[levitte]

As a reference re standards, I'm finding this: https://github.com/metanorma/gmt-0010-2012/blob/master/gmt-0010-2012-en.adoc#appendix-a-sm2-private-key-format

AlgorithmIdentifier is the binding of the object identifier and parameters ...
The SM2 cryptographic algorithm OID (algorithm) is defined in GM/T 0006-2012

The only GM/T 0006-2012 that I can find is this: https://github.com/guanzhi/GM-Standards/blob/master/GMT%E5%AF%86%E7%A0%81%E8%A1%8C%E6%A0%87/GMT%200006-2012%20%E5%AF%86%E7%A0%81%E5%BA%94%E7%94%A8%E6%A0%87%E8%AF%86%E8%A7%84%E8%8C%83.pdf
While I can't read chinese, the list of OIDs at the end is pretty readable...

So it's quite possible that my claim that this is a bug is incorrect.

[slontis]

I think we would need someone that is able to read Section 5.2.3.7 of GMT 0015-2012 基于SM2

https://github.com/guanzhi/GM-Standards/blob/master/GMT%E5%AF%86%E7%A0%81%E8%A1%8C%E6%A0%87/GMT%200015-2012%20%E5%9F%BA%E4%BA%8ESM2%E5%AF%86%E7%A0%81%E7%AE%97%E6%B3%95%E7%9A%84%E6%95%B0%E5%AD%97%E8%AF%81%E4%B9%A6%E6%A0%BC%E5%BC%8F.pdf

[slontis]

@qwe857359351a are you able to translate these docs?

[qwe857359351a]

Finally someone is paying attention to this issue！
My english is not very good。
But you can refer directly to the example，0015 appendix D.2 and 0010 appendix A.2。
openssl1.1 SM2 OID is correct。But it was changed in 3.0。I don't quite understand。
In China，all CA companies，all are used OID 1.2.840.10045.2.1。
I have now switched to TongSuo project，transformed based on openssl，surpport SM2 SSL，this project produces the right。
In TongSuo，someone also asked a similar question。SM2 AlgorithmIdentifier error。
This issue clearly pointed out，openssl3.0 does not meet the standards，create CSR not available。

[qwe857359351a]

@t8m @mattcaswell
Could you please continue to pay attention to this issue?

[levitte]

Ah, 0015 appendix D.2 is a very clear example, thank you!

[t8m]

@InfoHunter could perhaps also help

[zzl360]

the ROOTCA（rootca）which is operated by China Office of Security Commercial Code Administration (OSCCA) ‘s certficate also use 1.2.840.10045.2.1。we can download it from here

[InfoHunter]

Okay, this is something that makes people confused a lot due to the 'practice implementation' and 'the right thing' issue.

IIRC, the SM2 OID change from 1.1.1 to 3.0 was because the team had an agreement that SM2 should have an independent OID (1 2 156 10197 1 301) rather than using the ECC one. （need more time to find the history). I consider this is the right thing in the high level logic.

In the specific implementation, before OpenSSL 3.0, every implementations including OpenSSL 1.1.1 all treat SM2 as an ECC (1.2.840.10045.2.1) so the conflicts is here.

[InfoHunter]

Maybe one solution to this problem is: describe SM2 as one standalone key type in OpenSSL 3.0, but use the old OID (1.2.840.10045.2.1) to keep the backward compatibility ;-)

[InfoHunter]

How do you guys think? @levitte @t8m @mattcaswell

[levitte]

... and that makes it an encoding problem, which I addressed in #22529.

'cause whatever we think, if there's a standard that says that it should be encoded a specific way, it's really not our place to encode it differently.

But otherwise, you're quite right that internally, we treat SM2 keys as if they had the SM2 OID as a key type indicator. That's quite a source of confusion.