《信息安全技术 电子文档加密与签名消息语法》编制说明

ICS35.040

L80

中华人民共和国国家标准

GB/TXXXXX—200X

信息安全技术电子公文加密与签名消息

语法

Informationsecuritytechniques-EncryptionandSignatureMessage

SyntaxforElectronicDocument

（草案）

××××-××-××发布××××-××-××实施

中华人民共和国国家质量监督检验检疫总局

发布

中国国家标准化管理委员会

GB/TXXXXX—200X

引言

本部分等同采用国际标准RFC3852，它是由国际标准组织IETF起草的。

本部分给出了GB/TXXXXX的所有部分中使用的术语和符号，并给出了它们的定义。

本部分给出了密码应用数据的通用语法。

本部分还给出了六种应用密码的数据类型。

本部分凡涉及密码算法的相关内容，按国家有关法规实施。

II

GB/TXXXXX—200X

电子公文加密与签名消息语法标准

1范围

本标准同PEM（Privacy-EnhancedMail）相兼容，其中的签名数据内容以及签名和封装数据内容

以PEM-兼容的模式构建，不通过任何密码操作就可以转换为PEM消息。类似地，PEM消息也可以转换

为签名数据类型以及签名和封装数据类型。

本标准支持各种基于证书的密钥管理构架，比如RFC1422中为PEM提出的构架。但是构架决策问

题，比如哪个证书颁发者应该被选为最高层—即信任锚、哪些DN（distinguishednames）是允许的、

证书颁发者应该遵循哪些策略等等，不在本标准考虑范围内。

根据本标准生成所有值必须是BER编码，因此通常是字节串。虽然很多系统都可以可靠地传输字

节串，但是，也有很多的电子邮件系统不行。本标准不提供相关的技术来解决，将字节串编码为ASCII

字符串或重新编码字节串以保证可靠传输等问题，RFC1421中为此问题提供了一个可能的解决方案。

2规范性引用文件

下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注明日期的引用文件，其随后所

有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各

方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。

FIPSPUB46-1NationalBureauofStandards.FIPSPUB46-1:

DataEncryptionStandard.January1988.

PKCS#1RSALaboratories.PKCS#1:RSAEncryption.

Version1.5,November1993.

PKCS#6RSALaboratories.PKCS#6:Extended-Certificate

Syntax.Version1.5,November1993.

PKCS#9RSALaboratories.PKCS#9:SelectedAttribute

Types.Version1.1,November1993.

RFC1421Linn,J.,"PrivacyEnhancementfor

InternetElectronicMail:PartI:Message

EncryptionandAuthenticationProcedures,"RFC1421

February1993.

RFC1422Kent,S.,"PrivacyEnhancementfor

InternetElectronicMail:PartII:Certificate-

BasedKeyManagement,"RFC1422,February1993.

RFC1423Balenson,D.,"PrivacyEnhancementfor

InternetElectronicMail:PartIII:Algorithms,

Modes,andIdentifiers,"RFC1423,February1993.

RFC1424Kaliski,B.,"PrivacyEnhancementfor

InternetElectronicMail:PartIV:Key

CertificationandRelatedServices,"RFC1424,

February1993.

RFC1319Kaliski,B.,"TheMD2Message-Digest

Algorithm,"RFC1319,April1992.

1

GB/TXXXXX—200X

RFC1321Rivest,R.,"TheMD5Message-Digest

Algorithm,"RFC1321,April1992.

X.208CCITT.RecommendationX.208:Specificationof

AbstractSyntaxNotationOne(ASN.1).1988.

X.209CCITT.RecommendationX.209:Specificationof

BasicEncodingRulesforAbstractSyntaxNotation

One(ASN.1).1988.

X.500CCITT.RecommendationX.500:TheDirectory--

OverviewofConcepts,Modelsand

Services.1988.

X.501CCITT.RecommendationX.501:TheDirectory--

Models.1988.

X.509CCITT.RecommendationX.509:TheDirectory--

AuthenticationFramework.1988.

[NIST91]NIST.SpecialPublication500-202:Stable

ImplementationAgreementsforOpenSystems

InterconnectionProtocols.Version5,Edition1,

Part12.December1991.

[RSA78]R.L.Rivest,A.Shamir,andL.Adleman.Amethod

forobtainingdigitalsignaturesandpublic-key

cryptosystems.CommunicationsoftheACM,

21(2):120-126,February1978.

3术语和定义

3.1X.509中确立的下列术语和定义适用于本标准。

3.1.1

算法标识AlgorithmIdentifier

一种标识算法（使用对象标示符）和相关参数的类型。

3.1.2

证书Certificate

通过一个数字签名将某一实体同特定公钥绑定起来，证书中还包含证书颁发者的名字、颁发者特

定的序列号、颁发者的签名算法标识符以及有效期；

3.1.3

证书序列号CertificateSerialNumber

唯一标识特定证书颁发者签发的证书。

3.1.4

区分编码规则DistinguishedEncodingRules(DER)

对ASN.1的区分编码规则。

3.2X.208中确立的下列术语和定义适用于本标准。

3.2.1

抽象语法符号1AbstractSyntaxNotationOne

抽象语法符号，用于描述各种数据类型。

3.3X.209中确立的下列术语和定义适用于本标准。

3.3.1

基本编码规则BasicEncodingRules（BER）

2

GB/TXXXXX—200X

对ASN.1的基本编码规则。

3.4RFC1319中确立的下列术语和定义适用于本标准。

3.4.1

MD2MessageDigest2

RSA数据安全公司的MD2消息摘要算法。

3.4.2

md2md2

MD2的对象标识符。

3.5RFC1321中确立的下列术语和定义适用于本标准。

3.5.1

MD5MessageDigest5

RSA数据安全公司的MD5消息摘要算法。

3.5.2

md2md2

MD2的对象标识符。

3.6PKCS#1中确立的下列术语和定义适用于本标准。

3.6.1

rsaEncryptionrsaEncryption

RSA加密算法的对象标识符。

3.7PKCS#6中确立的下列术语和定义适用于本标准。

3.7.1

扩展证书ExtendedCertificate

包含一个X.509证书以及一系列属性，X.509公钥证书的颁发者对所有这些内容进行签名。

3.8RFC1422中确立的下列术语和定义适用于本标准。

3.8.1

证书撤销列表CertificateRevocationList（CRL）

包含了已被颁发者提前结束有效性的证书的相关信息，包括颁发者名字、颁发时间、证书序列号

清单及相应证书撤销时间，由证书颁发者签发。

3.9RFC1424中确立的下列术语和定义适用于本标准。

3.9.1

增强安全的私人函件Privacy-EnhancedMail（PEM）

Internet增强安全的私人函件。

3.10FIPSPUB46-1中确立的下列术语和定义适用于本标准。

数据加密标准DataEncryptionStandard（DES）

DES数据加密算法。

3.11NIST91中确立的下列术语和定义适用于本标准。

3.11.1

desCBCdesCBC

CBC模式的DES算法对象标识符。

4符号

标准中并未定义任何符号。

5概述

3

GB/TXXXXX—200X

本标准包括9个部分：有用的类型、通用语法、6个内容类型以及对象标识符。

标准中的语法比较通用，足以支持多种不同的内容类型。另外，标准中还定义了6个内容类型：数

据、签名数据、封装数据、签名和封装数据、摘要数据和加密数据，将来可能加入其它内容类型，也

可能使用此标准以外的内容类型，但是内容交换的双方必须达成双边约定。

内容类型分为两大类：基本的和增强的。基本类的内容类型只包含数据，不含密码增强。目前，

只有一个内容类型属于此类，即数据内容类型。增强类的内容类型包含某种类型的内容（可能是加密

的）以及其它密码增强。比如，封装数据内容可能包含（加密的）签名数据内容，而签名数据内容中

又包含数据内容。数据内容类型之外的有4个类型属于增强类。因此，增强类中的内容类型使用了封装，

引入“外部内容”（包含增强的部分）和“内部内容”（被增强的部分）两个术语。

语法的设计确保增强类内容类型可以在单通道中使用长度不确定的BER编码进行准备，并且在单

通道中使用任意的BER编码进行处理。如果内容是存储在磁带中或者是从另外一个进程流水线传送过

来的话，单通道操作特别有用。然而，单通道操作也存在一个缺陷，即很难通过单通道输出一个DER

编码，因为不同组件的长度可能无法事先预知。因为签名数据内容、签名和封装数据内容以及摘要数

据内容都要求DER编码，所以当数据内容类型以外的内容类型作为这些内容类型的内部内容时，就需

要一个额外的通道。

6有用的类型

这一部分对那些在标准中多处（至少两处）使用的类型进行定义。

6.1CertificateRevocationLists

CertificateRevocationLists类型给出了一个证书撤销列表集。希望此集合包含足够的信息，来确定

集合关联的证书是否是“有效的”，集合中包含的证书撤销列表可能多于或少于必要的证书撤销列表。

CertificateRevocationLists::=SETOFCertificateRevocationList

6.2ContentEncryptionAlgorithmIdentifier

ContentEncryptionAlgorithmIdentifier类型标识一个对内容进行加密的算法，比如DES。内容-加密

算法支持加密和解密操作。加密操作，在内容加密密钥的控制下，将一个字节串（消息）映射为另一

个字节串（密文）。解密是加密的逆操作，具体进行的是哪个操作，取决于所处理的内容。

ContentEncryptionAlgorithmIdentifier::=AlgorithmIdentifier

6.3DigestAlgorithmIdentifier

DigestAlgorithmIdentifier类型标识一个消息摘要算法，比如MD5和MD2。消息摘要算法将字节串

（消息）映射为另一个字节串（消息摘要）。

DigestAlgorithmIdentifier::=AlgorithmIdentifier

6.4DigestEncryptionAlgorithmIdentifier

DigestEncryptionAlgorithmIdentifier类型标识一个对消息摘要进行加密的摘要加密算法，比如

PKCS#1的rsaEncryption。摘要加密算法支持加密和解密操作。加密操作在摘要加密密钥的控制下，将

一个字节串（消息摘要）映射为另一个字节串（加密消息摘要），解密是加密的逆操作，具体进行的

是哪个操作，取决于所处理的内容。

DigestEncryptionAlgorithmIdentifier::=AlgorithmIdentifier

6.5ExtendedCertificateOrCertificate

ExtendedCertificateOrCertificate类型，标识一个PKCS#6扩展证书或者一个X.509证书，此类型遵循

PKCS#6中推荐的语法：

4

GB/TXXXXX—200X

ExtendedCertificateOrCertificate::=CHOICE

{

certificateCertificate,--X.509

extendedCertificate[0]IMPLICITExtendedCertificate

}

6.6ExtendedCertificatesAndCertificates

ExtendedCertificatesAndCertificates类，标识一个扩展证书和X.509证书集合。希望此集合包含足够

的信息，包含从信任根或顶级认证机构到集合关联的所有签发者的证书链，但是集合中包含的证书可

能多于或少于必须的证书。

ExtendedCertificatesAndCertificates::=SETOFExtendedCertificateOrCertificate

注意：“证书链”的精确含义不属于此标准的范畴。此标准的某些应用可能对证书链有个长度的

上限限制；另一些应用可能对证书链中的证书主体和颁发者的强加某种关系，比如在RFC1422中对PEM

就强加了某种关系。

6.7IssuerAndSerialNumber

IssuerAndSerialNumber类型，通过证书颁发者的DN和颁发者特定的证书序列号来标识一张证书。

IssuerAndSerialNumber::=SEQUENCE

{

issuerName,

serialNumberCertificateSerialNumber

}

6.8KeyEncryptionAlgorithmIdentifier

KeyEncryptionAlgorithmIdentifier类型，标识一个可以对内容加密密钥进行加密的密钥-加密算法，

比如PKCS#1中的rsaEncryption。密钥加密算法也支持加密和解密操作。加密操作在密钥加密密钥的控

制下，将一个字节串（密钥）映射为另一个字节串（加密密钥）。解密是加密的逆操作，具体进行的

是哪个操作，取决于所处理的内容。

KeyEncryptionAlgorithmIdentifier::=AlgorithmIdentifier

6.9Version

Version类型标识语法的版本号，为了兼容将来对标准的修订。

Version::=INTEGER

7通用语法（generalsyntax）

根据本标准定义的实体间内容交换的通用语法，将内容类型与内容联系起来，语法中应该包含

ASN.1类型的ContentInfo：

ContentInfo::=SEQUENCE

{

contentTypeContentType,

content[0]EXPLICITANYDEFINEDBYcontentTypeOPTIONAL

}

ContentType::=OBJECTIDENTIFIER

ContentInfo类型的两个域的含义如下：

5

GB/TXXXXX—200X

contentType：标识内容的类型，是一个对象标识符，由权威机构颁发，用于定义内容类型的

唯一整数串。此标准定义了6种内容类型：数据内容、签名数据内容、封装数据内容、签名和

封装数据内容、摘要数据内容和加密数据内容。

content：表示内容，此域是可选的。如果没有提供此域，则其期望值必须通过其它方式提供。

它的类型同contentType的对象标识符一同确定。

注意：

1.下文假定内容的类型可以通过contentType唯一确定，所以同对象标识符一同确定的类型不应

该是CHOICE类型。

2.当ContentInfo值作为签名数据、签名和封装数据或摘要数据内容类型的内部内容出现时，使

用消息摘要算法对content域DER编码的内容字节进行处理；当ContentInfo值作为封装数据或

签名和封装数据内容的内部内容时，使用内容加密算法对content域的确定长度BER编码的内

容字节进行处理。

3.content域的可选缺省，使得“外部签名”的构建成为可能，而不需要进行，比如修改待签名

的内容或者复制待签名的内容等操作。在外部签名的情况下，被签名的内容必须从签名数据

内容类型包含的内部封装ContentInfo值中省略。

8数据内容类型

数据内容类型只是一个字节串，应该是ASN.1类型数据：

Data::=OCTETSTRING

数据内容类型用于表示任意的字节串，比如ASCII文本文件；具体的解释根据应用而定。这类串

不必有任何内部结构（虽然他们可能是DER编码）。

9签名数据内容类型

签名数据内容类型包含任何类型的内容，以及零个或多个签名者对内容摘要的加密。一个签名者

的加密摘要是那个签名者对内容的“数字签名”。任意数量的签名者可以并行地对任意类型的内容进

行签名。而且，这个语法包含零个签名者的特殊情况，这种情况可以用于传播证书和证书撤销列表。

可以预计，签名数据内容类型的典型应用是用于表示签名者对数据内容类型内容的签名；另一个

典型的应用是，传播证书和证书撤销列表。构造签名数据的过程如下：

1.对于每个签名者，使用签名者指定的消息摘要算法计算内容的摘要（如果两个签名者使用相

同的消息摘要算法，那么只需要计算一次消息摘要）。如果签名者要鉴别除了内容之外的任

何信息（参阅9.2节），那么使用签名者指定的消息摘要算法，对内容摘要和其他信息计算

摘要，得到的结果为“消息摘要”；

2.对于每个签名者，使用签名者的私钥对消息摘要和相关信息进行加密；

3.对于每个签名者，将得到的加密消息摘要以及其它签名者特定的信息整合到一个SignerInfo

值中，此值在9.2节介绍。每个签名者对应的证书和证书撤销列表，以及其它不对应于签名

者的证书和证书撤销列表，都在这一步中搜集；

4.所有签名者的消息摘要算法以及SignerInfo值都搜集起来，放到SignedData值中，此值在9.1

节介绍。

接收者验证签名的方式为：用每个签名者的公钥来解密加密的消息摘要，然后比较得到的消息摘

要与独立计算得到的消息摘要是否相等。签名者的公钥或者通过包含在签名者信息中的证书得到，或

者通过颁发者DN和颁发者特定的序列号（通过这两个值可以唯一标识某公钥对应的证书）进行引用。

本节分成五部分：第一部分描述最上层的类型SignedData；第二部分描述每个签名者信息的类型

SignerInfo；第三和第四部分，描述消息摘要和摘要加密的过程；第五部分概述对PEM的兼容性。

9.1SignedData类型

6

GB/TXXXXX—200X

签名数据内容类型应该为ASN.1类型的SignedData：

SignedData::=SEQUENCE

{

versionVersion,

digestAlgorithmsDigestAlgorithmIdentifiers,

contentInfoContentInfo,

certificates[0]IMPLICITExtendedCertificatesAndCertificatesOPTIONAL,

crls[1]IMPLICITCertificateRevocationListsOPTIONAL,

signerInfosSignerInfos

}

DigestAlgorithmIdentifiers::=SETOFDigestAlgorithmIdentifier

SignerInfos::=SETOFSignerInfo

SignedData类型的各个域意义如下：

version：是语法的版本号，本标准中的版本为1；

digestAlgorithms：是消息摘要的算法标识符的集合，集合中可以有任意个元素，包括零个。

每个元素标识某签名者用于计算消息摘要的消息摘要算法（以及相关的参数）。希望通过此

集合列举出签名者使用的所有消息摘要算法，列举顺序任意，以方便单通道的签名验证。消

息摘要计算过程在9.3节中描述。

contentInfo：是待签名的内容，可以包含已定义的任何内容类型；

certificates：是一个PKCS#6扩展证书和X.509证书集合。希望此集合包含足够的信息，包含从

信任根或顶级认证机构到signerInfos域中的所有签发者的证书链，但是集合中包含的证书可能

多于必须的证书，而且可能包含从两个独立的顶级认证机构下来的证书链。如果已知有其它

的方法可以获得必要的证书来验证签名（比如，从之前的集合中获取证书），集合中包含的

证书也可能少于必须的证书。

crls：是一个证书撤销列表集合。希望此集合包含足够的信息，来确定certificates域中的证书

是否是“有效的”，但是数量不一定相当，集合中的证书撤销列表可能多于或少于必须的列

表。

signerInfo：是每个签名者信息的集合。集合中可以包含任意数量的元素，包括零个。

注意：

1.digestAlgorithms在contentInfo之前，而signerInfos域在contentInfo之后，确保了单通道处理

SignedData值成为可能（关于单通道处理过程，参阅第5节）。

2.对于内容中不包含签名者的情况，被签名的ContentInfo值没有实际意义。在这种情况下，建

议待签名的ContentInfo值的内容类型为数据内容类型，ContentInfo的content域省略。

9.2SignerInfo类型

每个签名者的信息使用SignerInfo类型表示：

SignerInfo::=SEQUENCE

{

versionVersion,

issuerAndSerialNumberIssuerAndSerialNumber,

digestAlgorithmDigestAlgorithmIdentifier,

authenticatedAttributes[0]IMPLICITAttributesOPTIONAL,

digestEncryptionAlgorithmDigestEncryptionAlgorithmIdentifier,

encryptedDigestEncryptedDigest,

7

GB/TXXXXX—200X

unauthenticatedAttributes[1]IMPLICITAttributesOPTIONAL

}

EncryptedDigest::=OCTETSTRING

SignerInfo的各个域含义如下：

version：是语法的版本号，对于此标准，版本号为1；

issureAndSerialNumber：通过颁发者DN和颁发者特定的序列号，指定签名者的证书（也就指

定了签名者的DN和公钥）；

digestAlgorithm：标识对内容和待鉴别属性（如果存在的话）进行摘要计算的消息摘要算法

（及任意关联的参数）。它必须包含在SignedData值中指定的digestAlgorithms域中。消息摘

要的计算过程参阅9.3节。

authenticatedAttributes是签名者需要进行鉴别的属性集合。此域是可选的，但是如果待签名的

ContentInfo值的内容类型不是数据内容类型，此域必须存在。如果此域存在，它必须包含，

至少两个属性：

1.PKCS#9内容类型属性：待签名的ContentInfo值的内容类型；

2.PKCS#9消息摘要属性：内容的消息摘要；

其它可能有用的属性，比如签名时间等等，也在PKCS#9中定义。

digestEncryptionAlgorithm标识摘要加密算法（以及任何相关的参数），使用签名者的私钥对

消息摘要及相关信息进行加密，摘要加密过程参阅9.4节；

encryptedDigest是使用签名者的私钥加密摘要和相关信息的结果；

unauthenticatedAttributes：是签名者不进行签名（即鉴别）的属性集合，此域可选。可能有用

的属性类型在PKCS#9中定义，比如连署签名（countersignatures）。

注意：为了更好的PEM兼容性，推荐在待签名的ContentInfo的内容类型为数据且没有任何待鉴别

属性时，省略authenticatedAttributes；

9.3消息摘要过程

消息摘要过程，对待签名内容或者签名者的待鉴别属性进行摘要计算，无论计算的是哪个内容，

消息摘要过程的初始输入都是需要签名的内容。特别地，初始输入是ContentInfo的content域DER编码

的内容字节。只对ContentInfo域的DER编码的内容字节串计算摘要，而不对标识符字节串或长度字节

串计算摘要。

消息摘要过程的结果（正式名称为“消息摘要”）根据authenticatedAttributes域是否存在会有所

不同。当此域缺省的时候，结果只是内容的消息摘要；当此域存在的时候，结果是authenticatedAttributes

域中包含的属性值的完整DER编码的消息摘要（澄清：authenticatedAttributes域中的IMPLICIT[0]标

签不属于属性值。属性值的标签是SETOF，并且SETOF标签的DER编码将同属性值的长度和内容一

起计算摘要，而不是IMPLICIT[0]标签）。因为当authenticatedAttributes域存在的时候，属性值必须包

含内容类型和内容的消息摘要两个属性，所以这两个值也就间接地包含在结果中了。

当被签名内容包含内容类型数据且authenticatedAttributes域缺省时，只对数据的值（比如，一个文

件的内容）计算摘要。这样做的优势是，不需要在加密过程之前，事先知道被签名的内容的长度，这

是同PEM相兼容的。

虽然不计算标识符串和长度串的摘要，仍然可以通过其它方式对他们进行保护。长度串通过消息

摘要算法的特性得到保护，因为摘要算法中假定：想要找到两个长度任意，摘要值相同的不同消息在

计算上是不可能的。

而且，假定内容类型唯一确定标识符串，那么标识符串可以通过如下两个方法之一得到保护：在

待鉴别属性中包含内容类型或者使用9.4节的PEM-兼容方案（意味着内容类型也是数据）。

8

GB/TXXXXX—200X

注意：消息摘要过程只对部分的DER编码进行计算，并不意味着DER是表示需要传送的那一部分

数据的必须方法。实际上，期望此标准的某些实现可能在DER编码以外存储对象，但是这并不会影响

消息摘要的计算。

9.4摘要加密过程

摘要加密过程的输入—提供给摘要加密算法的值—包括消息摘要过程的结果（正式名称为“消息

摘要”）以及摘要算法标识符（或对象标识符）。摘要加密过程的结果是使用签名者的私钥，对DigestInfo

类型的实例值的BER编码进行加密的结果：

DigestInfo::=SEQUENCE

{

digestAlgorithmDigestAlgorithmIdentifier,

digestDigest

}

Digest::=OCTETSTRING

DigestInfo类型的各个域含义如下：

digestAlgorithm：标识对内容和待鉴别属性进行摘要计算的消息摘要算法（以及任何关联的

参数）。必须同SignerInfo值中的digestAlgorithm域相同。

digest：消息摘要过程的结果。

注意：

1.这里定义的签名过程同PKCS#1中定义的签名算法唯一的区别在于，PKCS#1为了同X.509

SIGNEDmacro一致，使用bit串表示签名；而这里使用字节串表示已加密的消息摘要；

2.通常加密过程的输入包含30或更少的字节。如果digestEncryptionAlgorithm是PKCS#1的

rsaEncryption，那么，使用单个分组就可以对输入进行加密，只要RSA模数至少为328bits（这

是合理的，并且同建议的安全性一致）；

3.为了限制由于一个消息摘要算法被破解造成的损失，DigestInfo值中包含消息摘要算法标识

符。比如，假定攻击者可以找到一个消息，其摘要值同给定的MD2消息摘要相同，那么攻击

者就可以伪造签名：攻击者首先找到一个同已签名消息具有相同摘要值的消息，然后将先前

的签名作为新消息的签名。当DigestInfo值中包含消息摘要算法时，这种攻击只有在签名者使

用MD2算法的情况下可以成功进行。如果签名者不再信任MD2算法，并且总是使用MD5算法，

MD2算法的攻破并不会影响签名者。但是，如果DigestInfo值中只包含消息摘要的话，只要

MD2算法被攻破，不管签名者使用哪个消息摘要算法，都会被攻击。

4.有个潜在的歧义，主要是由于DigestInfo值中并未指明，digest域是包含内容的消息摘要还是

authenticatedAttributes域的完整DER编码的消息摘要。换句话说，攻击者可以将对待鉴别属性

的签名变换为对内容的签名，通过将内容改变为authenticatedAttributes域的DER编码，然后去

除authenticatedAttributes域。（反之，将对内容域的签名变换为对待鉴别属性的签名也是可能

的，不过要求内容是某个鉴别属性值的DER编码，这种概率比较小）这个潜在的歧义并不是

新问题，也不是很严重，通常可以通过上下文来防止错用。实际上，攻击者也可能将证书或

证书撤销列表的签名变换为待签名数据内容的签名。

9.5同PEM的兼容性

如果待签名的ContentInfo值的内容类型是数据内容类型、没有待鉴别属性、消息摘要算法是md2

或md5、摘要加密算法是PKCS#1中的rsaEncryption等条件都满足，那么本标准同PEM中的MIC-ONLY

和MIC-CLEAR过程的是相兼容的，这里的加密消息摘要同PEM中生成的摘要可以互相匹配：

9

GB/TXXXXX—200X

1.当没有待鉴别属性时，PEM中消息摘要算法的输入同本标准中的相同。PEM中的MD2和MD5

算法，同md2和md5相同。

2.PEM中使用签名者的私钥加密的值（RFC1423中指定）同本标准相同，如果没有待鉴别属性。

PEM中的RSA私钥加密算法等同于PKCS#1中的rsaEncryption。

签名数据内容类型的其他部分（certificates,CRLs,algorithmidentifiers等）也可以与对应的PEM组

件进行方便的变换。

10封装数据内容类型

封装数据内容类型包含任意类型的加密内容以及加密的内容加密密钥，可以针对一个或多个接收

者。对于一个接收者，加密的内容和加密的内容加密密钥组合成一个“数字信封”。可以并行地对任

意数量的接收者进行任意类型的内容封装。

可以预计，封装数据内容类型的典型应用是，用于表示一个或多个接收者对数据、摘要数据或签

名数据等内容类型的内容进行封装的数据信封。

构造封装数据的过程如下：

1.为一个特定的内容加密算法随机生成一个内容加密密钥；

2.对每个接收者，使用接收者的公钥加密内容加密密钥；

3.对每个接收者，在RecipientInfo值中包含加密的内容加密密钥和其它接收者特定的信息，

RecipientInfo在10.2节介绍；

4.使用内容加密密钥加密内容。（在内容加密过程中，可能要求对内容进行填充，达到某分组

大小的整数倍，参阅10.3节）

5.将所有接收者的RecipientInfo值和加密的内容整合到EnvolopedData中，此类型在10.1中定

义。

接收者打开数字信封的方式为：使用接收者的私钥解密加密的内容加密密钥，然后使用得到的内

容加密密钥解密加密的内容。接收者的私钥通过一个颁发者DN和颁发者特定的序列号（唯一标识某公

钥对应的证书）进行引用。

本节分为四个部分：第一部分描述顶层的类型EnvolopedData；第二部分描述每个接收者的信息类

型RecipientInfo；第三和第四部分描述内容加密和密钥加密的过程。

此内容类型同PEM不兼容（即使它所定义的某些过程同PEM副本相兼容），因为PEM中总是包含

了数字签名，没有单独的数字信封。

10.1EnvelopedData类型

封装数据内容类型应该是ASN.1类型的EnvelopedData：

EnvelopedData::=SEQUENCE

{

versionVersion,

recipientInfosRecipientInfos,

encryptedContentInfoEncryptedContentInfo

}

RecipientInfos::=SETOFRecipientInfo

EncryptedContentInfo::=SEQUENCE

{

contentTypeContentType,

contentEncryptionAlgorithm

ContentEncryptionAlgorithmIdentifier,

encryptedContent

10

GB/TXXXXX—200X

[0]IMPLICITEncryptedContentOPTIONAL

}

EncryptedContent::=OCTETSTRING

EnvelopedData的各个域含义如下：

version：是语法的版本号，本标准中的版本号为0；

recipientInfos：每个接收者信息的集合，集合中至少有1个元素；

encryptedContentInfo：加密的内容信息；

EncryptedContentInfo类型各个域的含义如下：

contentType：标识内容的类型；

contentEncryptionAlgorithm：标识对内容进行加密的内容加密算法（以及任何关联参数）。

内容加密过程参阅10.3节，对于所有接收者此算法是一样的。

encryptedContent：对内容进行加密的结果。此域是可选的，而且如果此域不存在的话，它的

期望值必须通过其它方式提供。

注意：recipientInfos域出现在encryptedContentInfo域之前，确保可以通过单通道来处理

EnvelopedData的值（EnvelopedData处理参阅第5节）。

10.2RecipientInfo类型

每个接收者的信息使用RecipientInfo类型进行表示：

RecipientInfo::=SEQUENCE

{

versionVersion,

issuerAndSerialNumberIssuerAndSerialNumber,

keyEncryptionAlgorithm

KeyEncryptionAlgorithmIdentifier,

encryptedKeyEncryptedKey

}

EncryptedKey::=OCTETSTRING

RecipientInfo类型各个域的含义如下：

version：语法版本号，本标准中的版本号为0；

issuerAndSerialNumber：通过颁发者DN和颁发者特定的序列号标识接收者的证书（也就标识

了接收者的DN和公钥）；

keyEncryptionAlgorithm：标识使用接收者的公钥对内容加密密钥进行加密的密钥加密算法

（以及任何关联参数），密钥加密过程参阅10.4节；

encryptedKey：使用接收者的公钥加密内容加密密钥的结果。

10.3内容加密过程

内容加密过程的输入是待封装的内容的“值”，更确切的说，是需要进行封装处理的ContentInfo

值content域的长度确定BER编码的内容字节。只有BER编码的内容字节被加密，而不包括标识符字节

或长度字节。

当待封装的内容包含内容类型数据时，只对数据的值（比如，一个文件的内容）进行加密。这样

做的优势是，不需要在加密过程之前，事先知道被加密的内容的长度，这是同PEM相兼容的。

内容加密过程不对密标识符串和长度串进行加密。长度字节串可以通过加密过程进行隐式的保护，

依赖于加密算法；而标识符字节并无任何保护，虽然他们可以通过内容类型得到恢复（假定内容类型

11

GB/TXXXXX—200X

唯一确定标识符字节）。对标识符和长度字节串的显式保护需要用到签名和封装数据内容类型或者相

继使用摘要数据内容类型和封装数据内容类型。

注意：

1.之所以要求BER编码的长度确定，是因为封装数据内容类型中并没有哪一个bit位是用来指明

长度是确定的还是不确定的。对于字节串这类简单的类型，更适合使用确定长度的编码，所

以这里选择确定长度的编码。

2.某些内容加密算法假定输入的长度是k字节的整数倍，K>1；并且在应用中定义一个方法来处

理那些长度非k的整数倍的输入。对于这类算法，处理的方法是：在输入的尾端填充k-(lmodk)

个字节，每个字节的值均为k-(lmodk)，l是输入的长度。换句话说，对输入的填充串如下：

01–如果lmodk=k-1

0202–如果lmodk=k-2

.

.

.

kk...kk–如果lmodk=0

由于所有的输入都将进行填充，而且没有一个填充串是另一个串的后缀，所以即使把填充部分去

掉也不会产生歧义。当且仅当k<256的时候，此填充方法很好；对于更大的k，需要在将来进行更多的

讨论。

10.4密钥加密过程

密钥加密过程的输入—提供给接收者的密钥加密算法的值—是内容加密密钥的“值”。

11签名和封装数据内容类型

本节定义签名和封装数据内容类型。为简洁起见，本节的许多内容直接引自第9和第10节。

签名和封装数据内容类型包含任意类型的加密内容、针对一个或多个接收者的加密的内容加密密

钥、针对一个或多个签名者的双重加密的消息摘要。所谓“双重加密”指：先用签名者的私钥对消息

进行加密，然后使用内容加密密钥对得到的内容进行加密。

一个加密的内容和一个加密的内容加密密钥构成一个“数字信封”，恢复的单重加密消息摘要是

对恢复的内容的“数字签名”。任意数量的接收者和任意数量的签名者可以并行地对任意类型的内容

进行封装和签名。

可以预计，签名和封装数据内容类型的典型应用是，表示一个签名者以及一个或多个接收者对数

据内容类型内容的签名和封装。

签名和封装数据的构造过程如下：

1.对特定的内容加密算法随机生成一个内容加密密钥；

2.对每个接收者，使用接收者的公钥加密内容加密密钥；

3.对每个接收者，在RecipientInfo值中包含加密的内容加密密钥和其它接收者特定的信息，

RecipientInfo的定义参阅10.2节；

4.对于每个签名者，使用签名者指定的消息摘要算法计算内容的摘要（如果两个签名者使用相

同的消息摘要算法，那么只需要计算一次消息摘要）。

5.对于每个签名者，使用签名者的私钥对消息摘要和相关信息进行加密，然后使用内容加密密

钥对得到的结果进行加密。（第二次加密前可能要求对第一次加密的结果进行填充，参阅10.3

节）；

6.对于每个签名者，将得到的双重加密消息摘要以及其它签名者特定的信息整合到一个

SignerInfo值中，SignerInfo的定义参阅9.2节。

7.使用内容加密密钥加密内容。（参阅10.3节）

12

GB/TXXXXX—200X

8.所有签名者的消息摘要算法、所有签名者的SignerInfo值以及所有接收者的RecipientInfo值，

连同加密的内容都搜集在SignedAndEnvelopedData值中，参阅11.1节。

接收者分两步打开信封并验证签名：第一步，使用接收者的私钥解密加密的内容加密密钥，然后

使用恢复出来的内容加密密钥解密加密的内容；第二步，使用恢复出来的内容加密密钥解密每个签名

者的双重加密消息摘要，然后使用签名者的公钥解密得到的结果，最后比较得到的消息摘要是否等同

于独立计算得到的消息摘要。

接收者的私钥和签名者的公钥获取方法，参阅第9和10节。

本节分为三个部分：第一部分描述顶层类型SignedAndEnvelopedData；第二部分描述摘要-加密过

程，其它类型和过程参阅9和10节；第三部分概述同PEM的兼容性。

注意：签名和封装数据内容类型提供的密码增强类似于相继使用签名数据和封装数据内容类型。

然而，由于签名和封装内容类型不包含鉴别或非鉴别属性，也不对除了签名之外的签名者消息进行封

装；因此，通常情况下相继使用签名数据和封装数据内容类型比直接使用签名和封装数据内容类型更

好，如果不考虑同PEM中的ENCRYPTED过程类型的兼容性。

11.1SignedAndEnvelopedData类型

签名和封装数据内容类型应该是ASN.1类型的SignedAndEnvelopedData：

SignedAndEnvelopedData::=SEQUENCE

{

versionVersion,

recipientInfosRecipientInfos,

digestAlgorithmsDigestAlgorithmIdentifiers,

encryptedContentInfoEncryptedContentInfo,

certificates[0]IMPLICITExtendedCertificatesAndCertificatesOPTIONAL,

Crls[1]IMPLICITCertificateRevocationListsOPTIONAL,signerInfosSignerInfos

}

SignedAndEnvelopedData的各个域含义如下：

version：语法的版本号，本标准中的版本号为1；

recipientInfos：每个接收者信息的集合，参阅第10节，集合中至少有1个元素；

digestAlgorithms：消息摘要算法标识符的集合，参阅第9节。如果没有待鉴别属性，那么消

息摘要过程同第9节相同；

encryptedContentInfo：加密的内容，参阅第10节，可以使用任何已定义的内容类型；

certificates：一个PKCS#6扩展证书和X.509证书的集合，参阅第9节；

crls：证书撤销列表集合，参阅第9节；

signerInfos：每个签名者的信息集合，集合中至少包含一个元素，如果不包含encryptedDigest

域的话，SignerInfo值的含义等同于第9节中的描述。

注意：recipientInfos域和digestAlgorithms域出现在contentInfo域之前，而signerInfos域出现在

contentInfo域之后，确保可以在单通道中处理SignedAndEnvelopedData值（关于单通道处理过程，参阅

第5节）。

11.2摘要加密过程

摘要加密过程的输入同第9节描述的一样，但是过程本身是不同的。特别地，这个过程包含两步：

首先，同第9节一样，将过程的输入提交给签名者的摘要加密算法；然后，使用内容加密密钥对前一

步的结果进行加密。在两步之间并没有DER编码，将第一步的输出直接输入到第二步（参阅10.3节

的讨论）。

13

GB/TXXXXX—200X

这个过程同PEM中的ENCRYPTED过程相兼容。

注意：第二部的目的是防止攻击者恢复内容的摘要，如果没有这一步，攻击者就能够通过比较每

个内容的消息摘要和实际摘要是否相等，来确定一个候选内容列表中哪个内容是实际内容。

11.3同PEM的兼容性

如果待签名和封装的ContentInfo值的内容