国密TLS1.1构造certificateverify时，握手数据为何做了2次sm3哈希？

[xbguo]

查询了国密相关标准，sm2签名时，Z值生产涉及1次哈希，但是不包含待签名数据，待签名数据理论上只参与1次哈希。

[yanshichao0226]

rfc5246规范里是digitally-signed(msg)；0024里面是digitally-signed(sm3(msg))

[yanshichao0226]

digitally-signed操作包含摘要和签名

[xbguo]

十分感谢！看了您的答复，又仔细看了一下0024文档和rfc文档，0024描述签名结构时和tls1.0（rfc2246）、tls1.1(rfc4346)类似，查看tls1.0（rfc2246）签名结构的描述如下：
select (SignatureAlgorithm)
{ case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
} Signature;
openssl 1.0.2 在构造构造certificateverify时，并没有额外做一次哈希。
0024对签名结构的描述类似，但是额外做了一次哈希

tls1.2（rfc5246）直接将这个描述变得更清晰了，0024开始提到过是在tls1.1的基础上定制的，有没有可能tls1.0和tls1.1的数字签名指的就是私钥加密，不包括摘要计算，而tls1.2的数字签名描述的签名是摘要计算+私钥加密。

[xbguo]

tls1.1(rfc 4346) 4.7章节找到了如下描述，0024是基于rfc4346，但是没有如下章节，所以也造成了歧义。
有关ras签名时，rfc说的是直接私钥加密，直接对md5+sha1的值直接做私钥加密

4.7. Cryptographic Attributes
The four cryptographic operations digital signing, stream cipher
encryption, block cipher encryption, and public key encryption are
designated digitally-signed, stream-ciphered, block-ciphered, and
public-key-encrypted, respectively. A field's cryptographic
processing is specified by prepending an appropriate key word
designation before the field's type specification. Cryptographic
keys are implied by the current session state (see Section 6.1).

In digital signing, one-way hash functions are used as input for a
signing algorithm. A digitally-signed element is encoded as an
opaque vector <0..2^16-1>, where the length is specified by the
signing algorithm and key.

In RSA signing, a 36-byte structure of two hashes (one SHA and one
MD5) is signed (encrypted with the private key). It is encoded with
PKCS #1 block type 1, as described in [PKCS1A].

Note: The standard reference for PKCS#1 is now RFC 3447 [PKCS1B].
However, to minimize differences with TLS 1.0 text, we are
using the terminology of RFC 2313 [PKCS1A].

In DSS, the 20 bytes of the SHA hash are run directly through the
Digital Signing Algorithm with no additional hashing. This produces

[zzl360]

@xbguo 在0024和tlcp里，服务端的签名数据和客户端的签名数据是不一样的。需要注意区分。

[xbguo]

@yanshichao0226 @zzl360 多谢二位回复

在tls1.0（rfc2246)和tls1.1(rfc4346)中都使用了“digitally-signed struct ”字样，但是在https://www.rfc-editor.org/rfc/rfc4346#section-4.7 章节，又对签名做了描述，直接进行私钥加密，查看openssl的实现，也确实没有做额外的哈希。
回到国密相关标准，0024开始提到是参考TLS1.1，但是缺少与https://www.rfc-editor.org/rfc/rfc4346#section-4.7 对应的章节，也是使用了“digitally-signed struct ”字样，这样就会被理解成对哈希后的数据签名，而签名时还需要做一次哈希。

这可能是造成对“digitally-signed struct ”理解不一样的原因，但额外最一次哈希看上去确实很奇怪。

PS:按我目前的认知，觉得签名需要做哈希，主要原因是公钥算法太耗时，从这个角度看再做一次哈希也不会再有改善了，出于好奇，才查了一下SM2签名相关的文档，在各位的回复后，我才意识到方向是错的，需要查看0024和TLCP，因为这2个标准规定对什么数据进行签名，与RFC对比后发现了上面的不同。

[yanshichao0226]

以上分别为0024规范中关于Server Key Exchange消息Certificate Verify消息的定义。从Server Key Exchange消息来看，digitally-signed操作包含摘要和私钥运算，因为digitally-signed输入长度明显大于32字节。我的观点是，同一份规范中digitally-signed应具有相同的语义，所以Certificate Verify中的digitally-signed操作也包含摘要和私钥运算。

[xbguo]

@yanshichao0226
从一致性的角度看，已经十分具有说服力了！
目前看Server Key Exchange的描述更接近TLS1.2(rfc5246)，Certificate Verify的描述更接近TLS1.0（rfc2246）、TLS1.1(rfc4346)，当二者放到同一个上下文，确实只能再做一次哈希了。