cnpkcs#7.docx
《cnpkcs#7.docx》由会员分享,可在线阅读,更多相关《cnpkcs#7.docx(20页珍藏版)》请在冰豆网上搜索。
![cnpkcs#7.docx](https://file1.bdocx.com/fileroot1/2023-1/5/8e643c48-9f9c-47e7-97f3-88b47b5b433b/8e643c48-9f9c-47e7-97f3-88b47b5b433b1.gif)
cnpkcs#7
PKCS#7:
加密消息语法标准(CryptographicMessageSyntaxStandard)
AnRSALaboratoriesTechnicalNote
Version1.5
RevisedNovember1,1993*
1.范围
这一标准描述了待加密数据的一般语法,比如数字签名和数字信封。
该语法允许递归,如一个信封能够包含在另一个当中,或者一方能够对一已存在的封装数据进行签名。
它也允许专有的属性和消息的内容一起被鉴别,比如签名时间,并且提供其他属性如伴随着签名的连属(countersignature)。
该语法的一个简化版提供了发布证书和CRL的方法。
这一标准和PEM(Privacy-EnhanceMail)兼容,体现在签名数据和签名并封装的数据内容上,以一种PEM兼容格式构成,并能够在无需任何加密操作的情况下转换成PEM消息。
类似地,PEM消息也能转换成签名数据和签名封装数据的内容格式。
这一标准能够支持多种基于认证的密钥管理体系结构,比如它的一个提议已收录在PEM[RFC1422]中。
一些体系结构上的决定比如何种证书颁发者才是“顶级”的,何种实体证书颁发者应被授权,何种可辨别名能够被接受以及颁发者应该遵循怎样的证书策略等等这些问题不在本标准讨论范围之内。
由这一标准产生的值可能是BER编码的,这意味着该值会以8位字节串(octetstring)的形式表示。
众所周知,虽然许多系统能够可靠地传输专有的8位字节串,但很多电子邮件系统并没有这么做。
这一标准并不寻找编码8位字节串的机制,像ASCII字符串或者其他保证可靠传输的re-encoding8位字节串技术。
RFC1421对该问题提出了可能的解决方法。
2.参考
FIPSPUB46–1NationalBureauofStandards.FIPSPUB46–1:
DataEncryptionStandard.January1988.
PKCS#1RSALaboratories.PKCS#1:
RSAEncryptionStandard.Version1.5,November1993.
PKCS#6RSALaboratories.PKCS#6:
Extended-CertificateSyntaxStandard.Version1.5,November1993.
PKCS#9RSALaboratories.PKCS#9:
SelectedAttributeTypes.Version1.1,November1993.
RFC1421J.Linn.RFC1421:
PrivacyEnhancementforInternetElectronicMail:
PartI:
MessageEncryptionandAuthenticationProcedures.February1993.
RFC1422S.Kent.RFC1422:
PrivacyEnhancementforInternetElectronicMail:
PartII:
Certificate-BasedKeyManagement.February1993.
RFC1423D.Balenson.RFC1423:
PrivacyEnhancementforInternetElectronicMail:
PartIII:
Algorithms,Modes,andIdentifiers.February1993.
RFC1424B.Kaliski.RFC1424:
PrivacyEnhancementforInternetElectronicMail:
PartIV:
KeyCertificationandRelatedServices.February1993.
RFC1319B.Kaliski.RFC1319:
TheMD2Message-DigestAlgorithm.April1992.
RFC1321R.Rivest.RFC1321:
TheMD5Message-DigestAlgorithm.April1992.
X.208CCITT.RecommendationX.208:
SpecificationofAbstractSyntaxNotationOne(ASN.1).1988.
X.209CCITT.RecommendationX.209:
SpecificationofBasicEncodingRulesforAbstractSyntaxNotationOne(ASN.1).1988.
X.500CCITT.RecommendationX.500:
TheDirectory—OverviewofConcepts,ModelsandServices.1988.
X.501CCITT.RecommendationX.501:
TheDirectory—Models.1988.
X.509CCITT.RecommendationX.509:
TheDirectory—AuthenticationFramework.1988.
[NIST91]NIST.SpecialPublication500-202:
StableImplementationAgreementsforOpenSystemsInterconnectionProtocols.Version5,Edition1,Part12.December1991.
[RSA78]R.L.Rivest,A.Shamir,andL.Adleman.Amethodforobtainingdigitalsignaturesandpublic-keycryptosystems.CommunicationsoftheACM,21
(2):
120–126,February1978.
3.定义
Forthepurposesofthisstandard,thefollowingdefinitionsapply.
AlgorithmIdentifier:
Atypethatidentifiesanalgorithm(byobjectidentifier)andassociatedparameters.ThistypeisdefinedinX.509.
ASN.1:
AbstractSyntaxNotationOne,asdefinedinX.208.
Attribute:
Atypethatcontainsanattributetype(specifiedbyobjectidentifier)andoneormoreattributevalues.ThistypeisdefinedinX.501.
BER:
BasicEncodingRules,asdefinedinX.209.
Certificate:
Atypethatbindsanentity'sdistinguishednametoapublickeywithadigitalsignature.ThistypeisdefinedinX.509.Thistypealsocontainsthedistinguishednameofthecertificateissuer(thesigner),anissuer-specificserialnumber,theissuer'ssignaturealgorithmidentifier,andavalidityperiod.
CertificateSerialNumber:
Atypethatuniquelyidentifiesacertificate(andtherebyanentityandapublickey)amongthosesignedbyaparticularcertificateissuer.ThistypeisdefinedinX.509.
CertificateRevocationList:
Atypethatcontainsinformationaboutcertificateswhosevalidityanissuerhasprematurelyrevoked.Theinformationconsistsofanissuername,thetimeofissue,thenextscheduledtimeofissue,andalistofcertificateserialnumbersandtheirassociatedrevocationtimes.TheCRLissignedbytheissuer.ThetypeintendedbythisstandardistheonedefinedRFC1422.
DER:
DistinguishedEncodingRulesforASN.1,asdefinedinX.509,Section8.7.
DES:
DataEncryptionStandard,asdefinedinFIPSPUB46-1.
desCBC:
TheobjectidentifierforDESincipher-blockchaining(CBC)mode,asdefinedin[NIST91].
ExtendedCertificate:
AtypethatconsistsofanX.509public-keycertificateandasetofattributes,collectivelysignedbytheissueroftheX.509public-keycertificate.ThistypeisdefinedinPKCS#6.
MD2:
RSADataSecurity,Inc.'sMD2message-digestalgorithm,asdefinedinRFC1319.
md2:
TheobjectidentifierforMD2,asdefinedinRFC1319.
MD5:
RSADataSecurity,Inc.'sMD5message-digestalgorithm,asdefinedinRFC1321.
md5:
TheobjectidentifierforMD5,asdefinedinRFC1321.
Name:
Atypethatuniquelyidentifiesor"distinguishes"objectsinanX.500directory.ThistypeisdefinedinX.501.InanX.509certificate,thetypeidentifiesthecertificateissuerandtheentitywhosepublickeyiscertified.
PEM:
InternetPrivacy-EnhancedMail,asdefinedinRFCs1421–1424.
RSA:
TheRSApublic-keycryptosystem,asdefinedin[RSA78].
rsaEncryption:
TheobjectidentifierforRSAencryption,asdefinedinPKCS#1.
4.符号和缩略语
Nosymbolsorabbreviationsaredefinedinthisstandard.
5.概述
下面的9节指定了有用的类型,通用的语法,六种内容类型和对象标识符。
语法通常足够支持多种不同的内容类型。
这一标准定义了六个:
数据,签名数据,封装数据,签名封装数据,摘要数据和加密数据。
其他内容类型可在未来再加入。
可以使用此标准之外定义的内容类型,但是只限于双方对交换内容达成一致的情况。
这一标准输出一种类型、ContentInfo以及各种对象标志符。
有两种内容类型:
基本的和增强的。
基本的内容类型仅包含数据,没有进行加密。
目前有一种内容类型是属于这一类的,即数据内容类型。
增强的内容类型包含一些类型(如加密),并有其他一些密码方面的提高。
比如,封装数据内容能包含(将其加密)签名数据内容,签名数据内容又能够包含数据内容。
四种非数据内容类型属于增强的类别。
增强的内容类型使用封装,引发了术语“外部”内容(包含增强特性的)和“内部”内容(得到增强的)。
这一标准的设计使用不定长BER编码来使增强内容类型能够在一个single-pass中准备好,并用任意BER编码在一个single-pass中处理。
如果内容是存储在磁带上或是从其他进程“管道”传递而来,则single-pass操作特别有用。
single-pass的一个缺点就是在single-pass的过程中难以输出一个DER编码,因为它的不同组件的长度不能预先知道。
由于签名数据、签名封装数据和摘要数据的内容类型都需要DER编码,当一个非数据内容类型是那些内容类型中的一个内部内容时,就需要一个额外的传递。
6.有用的类型
这一节定义了在标准中至少两个地方有用的类型
6.1CertificateRevocationLists
CertificateRevocationLists类型给定一个证书撤销列表的集合。
它表示集合中包含足够的信息来决定集合中的证书是否是”hotlisted”的,但是可能有多于必要的证书撤销列表,也可能少于必要的。
CertificateRevocationLists:
:
=
SETOFCertificateRevocationList
6.2ContentEncryptionAlgorithmIdentifier
ContentEncryptionAlgorithmIdentifier类型确定一个内容加密算法比如DES。
一个内容加密算法支持加密和解密操作。
加密操作用一个内容加密密钥把一个8位字节串(消息)映射为另一个8位字节串(密文)。
解密操作和加密操作相反。
由上下文确定使用哪个操作。
ContentEncryptionAlgorithmIdentifier:
:
=
AlgorithmIdentifier
6.3DigestAlgorithmIdentifier
DigestAlgorithmIdentifier类型确定一个消息摘要算法。
例如MD2和MD5。
一个消息摘要算法把一个8位字节串(消息)映射位另一个8位字节串(消息摘要)。
DigestAlgorithmIdentifier:
:
=AlgorithmIdentifier
6.4DigestEncryptionAlgorithmIdentifier
DigestEncryptionAlgorithmIdentifier类型确定一个摘要加密算法(可用来加密消息摘要)。
一个例子就是PKCS#1的rsaEncryption。
一个摘要加密算法支持加密和解密操作。
加密操作用一个摘要加密密钥把一个8位字节串(消息摘要)映射为另一个8位字节串(加了密的摘要)。
解密操作和加密操作相反。
由上下文确定使用哪个操作。
DigestEncryptionAlgorithmIdentifier:
:
=
AlgorithmIdentifier
6.5ExtendedCertificateOrCertificate
ExtendedCertificateOrCertificate类型指定一个PKCS#6扩展证书或者一个X.509证书。
这一类型遵循PKCS#6第6节推荐的语法:
ExtendedCertificateOrCertificate:
:
=CHOICE{
certificateCertificate,--X.509
extendedCertificate[0]IMPLICITExtendedCertificate
}
6.6ExtendedCertificatesAndCertificates
ExtendedCertificatesAndCertificates类型指定一个扩展证书和X.509证书的集合。
它表示集合足以包含从可识别的“根”或“顶级CA”到所有签名者的证书链,但是可能有多于必要的证书,也可能少于必要的。
ExtendedCertificatesAndCertificates:
:
=
SETOFExtendedCertificateOrCertificate
注:
关于“链”的准确含义不在本标准的讨论范围之内。
这一标准的一些应用可能会对链的长度加一个上限;其他的可能会在主体到颁发者的证书链之间强制加上一些关联。
这一关联的一个例子就在RFC1422的Privacy-EnhancedMail中被提议。
6.7IssuerAndSerialNumber
IssuerAndSerialNumber类型用一个证书颁发者可识别名和颁发者特定的证书序列号来确定一份证书(和由此而来的实体及公钥)。
IssuerAndSerialNumber:
:
=SEQUENCE{
issuerName,
serialNumberCertificateSerialNumber}
6.8KeyEncryptionAlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier类型确定可用来加密对称密钥的密钥加密算法。
一个例子就是PKCS#1的rsaEncryption。
一个密钥加密算法支持加密和解密操作。
加密操作用一个key-encryption密钥把一个8位字节串(密钥)映射为另一个8位字节串(加了密的密钥)。
解密操作和加密操作相反。
由上下文确定使用哪个操作。
KeyEncryptionAlgorithmIdentifier:
:
=
AlgorithmIdentifier
6.9Version
为了这一标准的未来版本的兼容性,Version类型给定一个语法版本号。
Version:
:
=INTEGER
7.通用语法
参照此标准,实体间内容交换的通用语法在内容上结合了一个contenttype。
该语法应有ASN.1类型的ContentInfo:
ContentInfo:
:
=SEQUENCE{
contentTypeContentType,
content
[0]EXPLICITANYDEFINEDBYcontentTypeOPTIONAL}
ContentType:
:
=OBJECTIDENTIFIER
类型ContentInfo的域有以下意义:
∙contentType简要说明该内容的类型。
它是一个对象标识符,即它是一个由定义内容类型的权威机构分配的唯一整数串。
这一标准定义了六种内容类型:
(见Section14):
data,signedData,envelopedData,signedAndEnvelopedData,digestedData,和encryptedData。
∙content就是内容.域是可选的,如果该域不存在,它的intendedvalue一定由其他方式给出。
它的类型和contentType的对象标识符一起定义。
注:
1.下面的方法假设内容的类型能够被contentType唯一标识,故随对象标识符一起定义的类型不应是一个CHOICEtype。
2.当一个ContentInfo值是诸如signed-data、signed-and-enveloped-data、或者digested-data的内部内容,一个消息摘要算法就应用于该内容的DER编码的字节上。
当一个ContentInfo值是enveloped-data或signed-and-enveloped-data的内部内容,一个内容加密算法就应用于该内容的定长BER编码的字节上。
3.内容域的可选冗长项的存在使得构建“外签名”成为可能,如没有改变或代替所要签名的内容。
外签名的情况下,被签名的内容将会被从“inner”封装的ContentInfo值(包含在签名数据内容类型中)中删除。
8.Data内容类型
Data内容类型只是一字节串。
它应有ASN.1类型数据:
Data:
:
=OCTETSTRING
Data内容类型旨在表示任意的字节串,像ASCII文本文件;其翻译留给应用。
这样的串无需任何内部的结构(虽然能够,甚至能够用DER编码)
9.Signed-data内容类型
signed-data内容类型由任意类型的内容和加密的(0或多个签名者)消息摘要组成。
对于一个签名者来说加了密的摘要就是他对该内容的“数字签名”。
任何类型的内容能够同时被任意数量的签名者签名。
此外,该语法有一个简化版本,其中的内容没有签名者。
简化版本提供了一个发布证书和crl的方法。
signed-data内容类型的标准应就是用来表示一个签名者对该内容类型数据的数字签名。
另一个标准的应用是发布证书和crl。
签名数据的产生过程有如下几步:
1.对于每一个签名者,他用自己的消息摘要算法计算出摘要值(如果两个签名者使用同样的算法,那么摘要值只需计算一次)。
若签名者需要鉴别除内容以外的任何信息(见Section9.2),消息摘要和其他信息都由签名者的消息摘要算法进行计算,结果即是“消息摘要”。
2.对于每一个签名者,消息摘要和相关的信息用自己的私钥加密。
3.对于每一个签名者,把加密的消息摘要和其他的签名者特定信息放入SignerInfo值中,在Section9.2中定义了。
每个签名者的证书、crl以及那些并不对应任何签名者的信息也在这一步被收集进来。
4.把所有签名者的信息摘要算法、他们的SignerInfo值和内容一起放进SignedData值中,在Section9.1定义了。
接收者通过用签名者的公钥解开加密的信息摘要来验证他的签名,然后把恢复的消息摘要和独立计算的消息摘要进行比较。
签名者的公钥或者包含在签名者信息的证书中,或者由一个颁发者可辨别名和颁发序列号来指引,它能唯一标识该公钥证书。
这一节分为5部分。
第一部分描述了顶级的SignedData,第二部分讲述了每个签名者的信息类型SignerInfo,第三和第四部分描述了信息摘要和摘要加密的过程,第五部分概述了和Privacy-EnhancedMail的兼容性。
9.1SignedData类型
signed-data内容类型应该是ASN.1类