0

关于证书和TLS支持

Sun Yimin edited this page 2025-03-03 13:50:20 +08:00

Table of Contents

• smx509实现中的问题：
• 解决方案
• 方案一
• 方案二

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

• 证书支持：smx509
• http tls支持(tlcp)：第三方实现gotlcp，该实现ECC_SM4_GCM_SM3、ECC_SM4_CBC_SM3经过互操作测试，其它ECDHE_SM4_GCM_SM3、ECDHE_SM4_CBC_SM3没有通过互操作测试，目前没有可信的互操作测试目标，规范也描述不清。
• ShangMi (SM) Cipher Suites for TLS 1.3，实现了和golang 1.19.x类似的ecdh，能融入golang sdk就比较好实现，单独维护成本太大，而且使用范围不广。

smx509实现中的问题：

现有smx509实现中，我们定义了以下结构（非别名），用于覆盖x509中的实现或者添加新方法：

// A Certificate represents an X.509 certificate.
type Certificate x509.Certificate

// CertificateRequest represents a PKCS #10, certificate signature request.
type CertificateRequest x509.CertificateRequest

type RevocationList x509.RevocationList

它的优点是：

• 新的类型，可以覆盖旧方法、添加新方法；
• 无需复制x509中相关结构的完整定义和方法；

它的缺点是：

• 需要显示转换才能在这些类型和x509相应类型之间进行转换。
• 如果x509中相应类型有私有字段（不管是直接的还是间接的），并且我们的扩展实现必须访问，则会引发可访问性问题。
• 如果有其它类型中定义了该类型的字段，那这个类型必须完整重定义（复制完整实现），代码改动量、维护工作量也比较大。

Golang 在x509.Certificate中引入了新字段(忽略简单字段)：

这种情况下，在sm509中实现相应功能就显得十分困难！

解决方案

方案一

重新定义Certificate，不再是简单的类型定义type Certificate x509.Certificate，而是拷贝x509.Certificate完整结构，或者扩展x509.Certificate结构，这样的话，在两者之间转换成本就偏高。

假设以后Golang在某个版本又新加了新字段，那为了兼容以前的旧版本，在两者转换的时候，还需要通过反射来判断该字段的存在性；或者不转新字段，直到支持的Golang最小版本都支持该字段。

方案二

彻底抛弃原来的实现，放弃支持非国密，这个改动可能成本更高，且有上游的兼容性问题。

这个等有实际case需要support的时候再考虑吧。至于为什么要引入x509.OID，可以参考golang的issue #60665 crypto/x509: introduce new robust OID type & use it for certificate policies.