GB/T 35275-2026 并不是形式上"代替 GM/T 0010-2023"。GB/T 35275-2026 的前言明确写的是"代替 GB/T 35275-2017"；而 GM/T 0010-2023 是另一条密码行业标准编号体系。
但从内容上看，两者高度重合，都是在规定 SM2 加密、签名、数字信封等消息的 ASN.1 封装 。所以从工程实现角度，完全可以把GB/T 35275-2026 看成一套更新、更偏通用 PKI/CMS 风格的消息格式方案来和 0010-2023 对比。
我逐项比下来，变化还挺大。最核心的可以概括成：
GB/T 35275-2026 弱化/取消了 GM/T 0010-2023 中的"隐式证书专用体系"，同时新增摘要消息、鉴别数字信封，修改 SignedData/SignerInfo 结构，补充明确的签名计算规则，并把 EnvelopedData、EncryptedData、SignerInfo 等关键结构升级到 version 2。
1. 最大变化：取消了"隐式证书专用消息格式"
这个是两份标准最明显的架构差异。
GM/T 0010-2023 一共定义了普通消息类型和隐式证书专用类型。
它的 OID 体系包括：
data
signedData
envelopedData
signedAndEnvelopedData
encryptedData
keyAgreementInfo
imcSignedData
imcEnvelopedData
imcSignedAndEnvelopedData其中 .7、.8、.9 专门留给：
1.2.156.10197.6.1.4.2.7 imcSignedData
1.2.156.10197.6.1.4.2.8 imcEnvelopedData
1.2.156.10197.6.1.4.2.9 imcSignedAndEnvelopedData而且 GM/T 0010-2023 整整有一个规范性附录 B《SM2 隐式证书的加密签名消息语法》，里面单独定义：
ImcSignedData
ImcSignerInfo
ImcEnvelopedData
ImcRecipientInfo
ImcSignedAndEnvelopedData例如 ImcSignedData 使用：
certificates ImcCertificates
crls ImcCertificateRevocationLists
signerInfos ImcSignerInfos其中隐式证书的 signer 不是普通：
issuerAndSerialNumber而是：
sid CertificateId也就是通过隐式证书 Hash 来识别签名者。
到了 GB/T 35275-2026，这套体系没了。
35275 只定义 8 类：
Data
SignedData
EnvelopedData
SignedAndEnvelopedData
EncryptedData
KeyAgreementInfo
DigestedData
AuthEnvelopedData新的 OID 分配变成：
.1 Data
.2 SignedData
.3 EnvelopedData
.4 SignedAndEnvelopedData
.5 EncryptedData
.6 KeyAgreementInfo
.10 DigestedData
.11 AuthEnvelopedData也就是说：
.7 imcSignedData
.8 imcEnvelopedData
.9 imcSignedAndEnvelopedData在 35275-2026 中不再作为消息类型出现。
这个变化很值得注意
可以画成：
GM/T 0010-2023
普通证书体系
├─ signedData
├─ envelopedData
└─ signedAndEnvelopedData
隐式证书体系
├─ imcSignedData .7
├─ imcEnvelopedData .8
└─ imcSignedAndEnvelopedData .9变成：
GB/T 35275-2026
统一消息体系
├─ SignedData
├─ EnvelopedData
├─ SignedAndEnvelopedData
├─ DigestedData .10 ← 新
└─ AuthEnvelopedData .11 ← 新所以如果你在做格式识别：
看到 OID 尾号
.7/.8/.9，应该考虑 GM/T 0010-2023 隐式证书消息，而不能按 GB/T 35275-2026 解析。
2. 新增 DigestedData------终于正式把"摘要消息"定义进来了
这是 35275 一个非常明显的补全。
GM/T 0010-2023 中虽然出现了 digestedData 这个名字，例如说：
EnvelopedData 可以封装：
data
digestedData
signedData但是 0010 本身没有独立章节定义 DigestedData 数据结构，也没有给它分配自己的消息类型 OID。
而 35275-2026 正式增加：
DigestedData ::= SEQUENCE {
version Version,
digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo,
digest Digest
}
Digest ::= OCTET STRING并分配：
1.2.156.10197.6.1.4.2.10所以这是一个很实质性的完善：
GM/T 0010
提到了 digestedData
↓
但没有完整定义
GB/T 35275
↓
正式定义 DigestedData
↓
version
digestAlgorithm
encapContentInfo
digest3. 新增 AuthEnvelopedData------引入"带鉴别的数字信封"
这个是 35275-2026 在安全能力上的大升级。
GM/T 0010-2023 没有 AuthEnvelopedData。
35275 新增：
AuthEnvelopedData ::= SEQUENCE {
version,
recipientInfos,
authEncryptedContentInfo,
authAttrs,
mac,
unauthAttrs
}也就是不仅有：
机密性 Confidentiality还有：
完整性 / 鉴别 Integrity + Authentication35275 对它的描述就是同时提供机密性和完整性。
并且明确支持：
SM4-CCM
SM4-GCM同时规定：
CCMParameters {
sm4-nonce
sm4-ICVlen
}
GCMParameters {
sm4-nonce
sm4-ICVlen
}其中 ICVlen 就是 Tag 长度。
这一点从工程上很重要：
0010 的数字信封
主要是：
SM2
↓
保护会话密钥
SM4等
↓
加密业务数据35275 新增的 AuthEnvelopedData
则可以：
SM2
↓
保护会话密钥
SM4-GCM / SM4-CCM
↓
密文 + Tag
↓
同时保证机密性 + 完整性所以 35275 明显把现代 AEAD 机制纳入消息格式体系了。
4. SignedData 的内容封装方式发生了明显变化
这是实现时非常容易不兼容的地方。
GM/T 0010-2023
SignedData：
SignedData ::= SEQUENCE {
version,
digestAlgorithms,
contentInfo,
certificates,
crls,
signerInfos
}其中：
contentInfo ContentInfoContentInfo 是：
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
}GB/T 35275-2026
改成：
SignedData ::= SEQUENCE {
version,
digestAlgorithms,
encapContentInfo,
certificates,
crls,
signerInfos
}其中：
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL
}所以这是：
GM/T 0010
contentInfo
└─ content ANY变成：
GB/T 35275
encapContentInfo
├─ eContentType
└─ eContent OCTET STRING这是一个挺重要的规范化。
0010 的：
ANY DEFINED BY contentType类型比较开放；
35275 收敛为：
OCTET STRING格式更明确，也更方便统一做 DER/CMS 类消息解析。
5. SignerInfo 字段名称和语义全面规范化
两边的结构其实"长得很像"，但名称发生了明显变化。
GM/T 0010
SignerInfo ::= SEQUENCE {
version,
issuerAndSerialNumber,
digestAlgorithm,
authenticatedAttributes [0] OPTIONAL,
digestEncryptionAlgorithm,
encryptedDigest,
unauthenticatedAttributes [1] OPTIONAL
}GB/T 35275
改成：
SignerInfo ::= SEQUENCE {
version,
issuerAndSerialNumber,
digestAlgorithm,
signedAttrs [0] OPTIONAL,
signatureAlgorithm,
signature,
unsignedAttrs [1] OPTIONAL
}对应关系特别清楚：
| GM/T 0010-2023 | GB/T 35275-2026 |
|---|---|
| authenticatedAttributes | signedAttrs |
| digestEncryptionAlgorithm | signatureAlgorithm |
| encryptedDigest | signature |
| unauthenticatedAttributes | unsignedAttrs |
我认为这里属于 "术语纠正 + 数据模型现代化"。
比如：
encryptedDigest这个名字容易让人误以为：
对摘要值做了一次"加密"。
而 SM2 实际进行的是：
数字签名所以 35275 直接改成：
signature
signatureAlgorithm语义明显更准确。
6. SignerInfo 的 version 从 1 升到了 2
这个是字节级格式兼容时必须关注的变化。
GM/T 0010-2023 的 SignerInfo：
version = 1从其表 3 可以看到。
GB/T 35275-2026：
SignerInfo.version = 2所以解析器不能写死：
if (version != 1)
error;如果要同时支持两套标准，建议：
SignerInfo
version == 1
→ 倾向 GM/T 0010 格式
version == 2
→ 倾向 GB/T 35275-2026 格式当然实际识别还应该结合整体 ASN.1 和 OID，不能单凭 version。
7. 35275 新增了非常关键的"签名计算规则"
这个我认为是 2026 版里对实际开发最有价值的更新之一。
GM/T 0010 对 authenticatedAttributes 的描述比较概括：
如果存在，该域中摘要的计算方法是对原文进行摘要计算结果。
但是很多实现中会碰到一个经典问题：
到底签
eContent，还是签signedAttrs？签 signedAttrs 的什么编码？
35275 把这件事写得非常明确。
signedAttrs 存在
签名数据为：
signedAttrs 的 DER 编码结果并要求里面包含：
messageDigestAttribute其值：
MessageDigest = SM3(eContent)signedAttrs 不存在
签名数据：
eContent 的内容本身并明确：
不包括 DER 编码中的标签和长度。
这个区别非常关键。
也就是说：
signedAttrs 存在：
eContent
↓ SM3
messageDigest
↓
放入 signedAttrs
↓ DER
DER(signedAttrs)
↓ SM2
signature而：
signedAttrs 不存在：
eContent
↓
SM2签名这直接消除了很多厂商互操作时的歧义。
8. 新增 Attribute 基本类型
这也是为了配合 signedAttrs、unsignedAttrs、authAttrs。
35275 明确定义：
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANYGM/T 0010 虽然使用了：
Attributes
authenticatedAttributes
unauthenticatedAttributes但其基本消息结构定义没有像新版这样把 Attribute 本身完整纳入基本类型体系。
所以 35275 的数据模型更自洽了：
Attribute
├─ signedAttrs
├─ unsignedAttrs
├─ authAttrs
└─ unauthAttrs9. EnvelopedData：version 1 → version 2，并新增 unprotectedAttrs
这个也是结构级变化。
GM/T 0010
EnvelopedData ::= SEQUENCE {
version,
recipientInfos,
encryptedContentInfo
}并且：
version = 1GB/T 35275
变为：
EnvelopedData ::= SEQUENCE {
version,
recipientInfos,
encryptedContentInfo,
unprotectedAttrs [1] OPTIONAL
}而：
version = 2也就是增加：
unprotectedAttrs允许附带：
不受加密保护的属性。
所以结构上已经不能把新版直接当旧版解析：
0010：
SEQUENCE
├─ version 1
├─ recipientInfos
└─ encryptedContentInfo变成：
35275：
SEQUENCE
├─ version 2
├─ recipientInfos
├─ encryptedContentInfo
└─ unprotectedAttrs OPTIONAL10. EncryptedData 同样 version 1 → 2，并增加 unprotectedAttrs
GM/T 0010：
EncryptedData ::= SEQUENCE {
version,
encryptedContentInfo
}且：
version = 1GB/T 35275：
EncryptedData ::= SEQUENCE {
version,
encryptedContentInfo,
unprotectedAttrs [1] OPTIONAL
}且：
version = 2这个变化与 EnvelopedData 是一致的。
11. RecipientInfo 去掉了"SM2隐式证书公钥加密机制"
GM/T 0010 的普通 RecipientInfo 其实允许两类算法：
SM2椭圆曲线加密算法
或
SM2隐式证书公钥加密机制而 35275 明确写：
keyEncryptionAlgorithm
用接收者公钥加密数据加密密钥的算法，
为 SM2 椭圆曲线加密算法没有再写隐式证书机制。
这和前面"取消独立隐式证书消息体系"是一致的。
12. KeyAgreementInfo：userCertificate 从 OPTIONAL 变成必选
这个变化不大，但非常实质。
GM/T 0010
KeyAgreementInfo ::= SEQUENCE {
version,
tempPublicKeyR,
userCertificate Certificate OPTIONAL,
userID
}标准明确：
用户证书，可选GB/T 35275
变成：
KeyAgreementInfo ::= SEQUENCE {
version,
tempPublicKeyR,
userCertificate Certificate,
userID
}这里：
userCertificate不再 OPTIONAL。
所以：
0010：
userCertificate 可没有
35275：
userCertificate 必须存在做 ASN.1 校验器时这条要单独改。
13. 密钥格式总体没变，但去掉了隐式证书相关内容
这一块反而变化不大。
GM/T 0010 附录 C：
Parameters
SubjectPublicKeyInfo
ECPrivateKey35275 附录 B：
Parameters
SubjectPublicKeyInfo
ECPrivateKey核心结构几乎一致。
公钥
两者都是：
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey SM2PublicKey
}私钥
都是：
ECPrivateKey ::= SEQUENCE {
version,
privateKey,
parameters OPTIONAL,
publicKey
}真正变化主要在算法标识引用。
GM/T 0010：
OID → GM/T 0006并且明确：
SM2密码算法
SM2隐式证书公钥机制都可以使用。
35275：
OID → GB/T 33560只说：
SM2密码算法14. 引用的基础标准整体升级到国家标准体系
GM/T 0010 主要引用：
GM/T 0006
GM/T 0009
GM/T 0015GMT 0010-2023 SM2密码算法加密签名消息语法规范.pdfPDF
而 35275 换成大量 GB/T：
GB/T 20518 数字证书格式
GB/T 32905 SM3
GB/T 32918 SM2
GB/T 33560 密码应用标识
GB/T 35276 SM2密码算法使用规范
GB/T 36624 可鉴别加密机制GBT 35275-2026 网络安全技术 SM2密码算法加密签名消息格式.pdfPDF
对应关系可以理解成：
| GM/T 0010-2023 依赖 | GB/T 35275-2026 依赖 |
|---|---|
| GM/T 0006 密码应用标识 | GB/T 33560 |
| GM/T 0009 SM2使用规范 | GB/T 35276 |
| GM/T 0015 数字证书格式 | GB/T 20518-2018 |
| --- | GB/T 36624 可鉴别加密机制 |
所以 35275 不只是改几个 ASN.1 字段，整个规范引用体系也在向现行国家标准体系靠拢。
15. 两个标准最重要的变化汇总
我把实际开发最需要关心的整理成这张表：
| 项目 | GM/T 0010-2023 | GB/T 35275-2026 | 影响 |
|---|---|---|---|
| 普通 SignedData | 有 | 有 | 修改 |
| 隐式证书 imcSignedData | 有 | 无 | 删除体系 |
| imcEnvelopedData | 有 | 无 | 删除体系 |
| imcSignedAndEnvelopedData | 有 | 无 | 删除体系 |
| DigestedData | 未完整定义 | 新增 | 新增 |
| AuthEnvelopedData | 无 | 新增 | 重大新增 |
| SM4-GCM/CCM | 无专门格式 | 新增 | AEAD |
| SignedData.contentInfo | ContentInfo |
EncapsulatedContentInfo | 结构变化 |
| authenticatedAttributes | 有 | 改为 signedAttrs |
重命名/规范化 |
| digestEncryptionAlgorithm | 有 | 改为 signatureAlgorithm |
语义规范 |
| encryptedDigest | 有 | 改为 signature |
语义规范 |
| unauthenticatedAttributes | 有 | 改为 unsignedAttrs |
规范化 |
| SignerInfo.version | 1 | 2 | 编码变化 |
| 签名计算规则 | 较简略 | 明确 DER signedAttrs/eContent | 重要 |
| EnvelopedData.version | 1 | 2 | 编码变化 |
| EnvelopedData.unprotectedAttrs | 无 | 新增 | 结构变化 |
| EncryptedData.version | 1 | 2 | 编码变化 |
| EncryptedData.unprotectedAttrs | 无 | 新增 | 结构变化 |
| KeyAgreement.userCertificate | OPTIONAL | 必选 | 兼容性变化 |
| 公钥格式 | SubjectPublicKeyInfo | 基本相同 | 小变化 |
| 私钥格式 | ECPrivateKey | 基本相同 | 小变化 |
| 密码应用OID | GM/T 0006 | GB/T 33560 | 引用升级 |
| SM2使用规范 | GM/T 0009 | GB/T 35276 | 引用升级 |
| 证书格式 | GM/T 0015 | GB/T 20518 | 引用升级 |