GB/T 35275-2026 与 GM/T 0010-2023 对比

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
digest

3. 新增 AuthEnvelopedData——引入“带鉴别的数字信封”

这个是 35275-2026 在安全能力上的大升级。

GM/T 0010-2023 没有 AuthEnvelopedData。

35275 新增：

AuthEnvelopedData ::= SEQUENCE {
    version,
    recipientInfos,
    authEncryptedContentInfo,
    authAttrs,
    mac,
    unauthAttrs
}

也就是不仅有：

机密性 Confidentiality

还有：

完整性 / 鉴别 Integrity + Authentication

35275 对它的描述就是同时提供机密性和完整性。

并且明确支持：

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 ContentInfo

ContentInfo 是：

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 ::= ANY

GM/T 0010 虽然使用了：

Attributes
authenticatedAttributes
unauthenticatedAttributes

但其基本消息结构定义没有像新版这样把 Attribute 本身完整纳入基本类型体系。

所以 35275 的数据模型更自洽了：

Attribute
├─ signedAttrs
├─ unsignedAttrs
├─ authAttrs
└─ unauthAttrs

9. EnvelopedData：version 1 → version 2，并新增 unprotectedAttrs

这个也是结构级变化。

GM/T 0010

EnvelopedData ::= SEQUENCE {
    version,
    recipientInfos,
    encryptedContentInfo
}

并且：

version = 1

GB/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 OPTIONAL

10. EncryptedData 同样 version 1 → 2，并增加 unprotectedAttrs

GM/T 0010：

EncryptedData ::= SEQUENCE {
    version,
    encryptedContentInfo
}

且：

version = 1

GB/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
ECPrivateKey

35275 附录 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 0015

GMT 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	引用升级

相关阅读:
365天深度学习训练营-学习线路
 JSP企业客户管理系统myeclipse定制开发mysql数据库网页模式java编程jdbc
星巴克推出Web3平台；天啦噜，AI绘画能007了；『决策算法』电子书；合成人脸数据集；面向数据的版本控制；前沿论文 | ShowMeAI资讯日报
 GSEA -- 学习记录
 【教程】MySQL数据库学习笔记（五）——约束（持续更新）
Kubernetes技术与架构-网络 3
web前端-javascript-switch条件分支语句(语法，执行流程，补充)
搜索引擎算法工程师，在query理解方面，都有哪些方面的工作
 Java学习笔记（十七）
css调整字体间距以及让倾斜字体
原文地址：https://www.cnblogs.com/chenzhijie/p/22698458