关于gmssl生成的sm2withsm3证书在gmsm中验证失败的问题

[mingjunyang]

现在很多涉及到sm2证书的，都用了默认用户身份标识

9. 用户身份标识 ID 的默认值
无特殊约定的情况下，用户身份标识ID的长度为16字节，其默认值从左至右依次为：
0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38

https://github.com/guanzhi/GmSSL/blob/838f4effbefd150a8c64e251bbac1be224ab24dc/go/gmssltest/gmssltest.go#L199

https://github.com/guanzhi/GmSSL/blob/1c00e47681678afc16cb1bc04fe814adf732b4b3/include/openssl/sm2.h#L72

https://github.com/cryptape/libsm/blob/3f62eb92758df72eb8f5deec71c9702b82d22eaf/src/sm2/signature.rs#L152
https://github.com/cryptape/libsm/blob/3f62eb92758df72eb8f5deec71c9702b82d22eaf/src/sm2/signature.rs#L201

提示一下，如果用gmsm的代码去验证gmssl生成的sm2withsm3的证书，记得自己在 CheckSignature(algo SignatureAlgorithm, signed, signature []byte) 的时候在signed前面补上16字节的用户身份标识ID。

其实比较好奇为啥gmsm项目不直接按照那个规范去做。虽然我也觉得在前面加一串1234567812345678有点莫名其妙的。

[GoldSaintEagle]

现在很多涉及到sm2证书的，都用了默认用户身份标识

9. 用户身份标识 ID 的默认值
无特殊约定的情况下，用户身份标识ID的长度为16字节，其默认值从左至右依次为：
0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38

https://github.com/guanzhi/GmSSL/blob/838f4effbefd150a8c64e251bbac1be224ab24dc/go/gmssltest/gmssltest.go#L199

https://github.com/guanzhi/GmSSL/blob/1c00e47681678afc16cb1bc04fe814adf732b4b3/include/openssl/sm2.h#L72

https://github.com/cryptape/libsm/blob/3f62eb92758df72eb8f5deec71c9702b82d22eaf/src/sm2/signature.rs#L152
https://github.com/cryptape/libsm/blob/3f62eb92758df72eb8f5deec71c9702b82d22eaf/src/sm2/signature.rs#L201

提示一下，如果用gmsm的代码去验证gmssl生成的sm2withsm3的证书，记得自己在 CheckSignature(algo SignatureAlgorithm, signed, signature []byte) 的时候在signed前面补上16字节的用户身份标识ID。

其实比较好奇为啥gmsm项目不直接按照那个规范去做。虽然我也觉得在前面加一串1234567812345678有点莫名其妙的。

其实sm2标准规定了要采用用户id生成za，然后再用za和消息连接做摘要生成e（e=Hash(za||m)）。但是实现的时候发现，我X，多了一个用户id参数！直接导致上层X509啊什么的接口都要变了（这里致敬一下sm2的发明者，为sm2的推广搞了非常大的坑）……于是大家用标准中给出的例子，1234567812345678，当作默认值，来保障上层接口同一。

However，虽然接口同一了，但是go 上层（x509）的实现，是先e=Hash（m），然后判断其签名类型。因此，如果将sm2完全当作一个无缝的提供上层使用，那么就无法做za的添加，也就该项目的实现方法（za的接口保留）。
如果按照sm2标准的话，就需要在上层修改调用的实现方法，先判断签名类型，再获得e的值。