分类： 系统运维
2008-03-25 09:52:19
此备忘录的状况
此文档为因特网社区详细描述了一个因特网标准途径，并且请求改善的讨论和建
议。为了确保此的标准化状态，请参考当前版本的因特网官方标准（STD1）。本备
忘录的发布是不受限制的。
版权通知
版权所属因特网社会（1999），保留全部权力。
目录
1摘要 2
2略读 2
3证书请求信息(CertReqMessage)的语法 2
4拥有私钥的证明(POP) 3
4．1签名密钥 3
4．2加密密钥 3
4．3密钥 4
4．4POP语法 4
5CertRequest语法 6
6Controls语法 7
6．1注册号（RegistrationToken）控制 7
6．2鉴定者（Authenticator）控制 7
6．4文档选项（ArchiveOptions）控制 8
6．5旧证书ID（OldCertID）控制 9
6．6加密密钥（ProtocolEncryptionKey）控制 9
7对象标识符（ObjectIdentifiers） 10
8对于安全的考虑 10
9参考 10
10谢辞 11
附录A．构造dhMAC 11
AppendixB.UseofRegInfoforName-ValuePairs 12
AppendixC.ASN.1StructuresandOIDs 15
FullCopyrightStatement 21
1摘要
本文描述了证书请求消息格式(CRMF)。它被用来向CA传递一个产生X.509证书请求
(可能通过RA)。请求消息一般包括公钥和有关的登记信息。
2略读
证书请求构成的步骤如下：
1) 产生CertRequest值，其值包括：公钥，所有或部分的终端实体（EE）的名字，其他所
要求的证书值域，以及与登记过程相连系的控制信息。
2) 可以通过计算CertRequest的值来证明拥有与所请求的证书的公钥相连系的私钥，即可
计算出POP（proofofpossession，拥有私钥的证明）的值。
3) 以上两项所需要的其他登记信息，这些信息和POP值，CertRequest结构组成证书请求
信息。
4) 证书请求信息被秘密传递给CA，传递的方法不是本文叙述的范围。
3证书请求信息(CertReqMessage)的语法
证书请求信息由证书请求，一个可选的检验项，以及一个可选的登记信息项。
CertReqMessages::=SEQUENCESIZE(1..MAX)OFCertReqMsg
CertReqMsg::=SEQUENCE{
certReqCertRequest,
popProofOfPossessionOPTIONAL,
--其内容依赖于密钥类型
regInfoSEQUENCESIZE(1..MAX)ofAttributeTypeAndValueOPTIONAL}
POP用来证明证书请求者确实拥有所对应的私钥。此项可由certReq计算出来，其内容和结
构随公钥算法的类型和运作模式的改变而改变。regInfo项仅包括与证书请求有关的补充信
息。它还可包括请求者的联系信息，布告信息，或对证书请求有用的辅助信息。直接与证书
内容有关的信息应该包括在certReq中。然而若RA包含另外的certReq内容，这可以使pop
项无效。因此其余证书想要的数据可以由regInfo提供。
4拥有私钥的证明(POP)
为了防止某些攻击以及允许CA/RA检验终端实体和密钥对之间对应的有效性，PKI管
理操作使终端实体有能力证明拥有(也就是说能用)与证书公钥所对应的私钥。CA/RA在证书
交换中可自由选择如何实施POP（例如带外的方法或CRMF的带内的方法），也就是说这可
以是一个策略问题。然而，因为现在有许多非PKIX的操作在使用（例如许多电子邮件
），它们并不检验终端实体和私钥之间的对应性，这要求CA/RA必须通过一些方法来实
施POP。这种对应性仅能被CA/RA假设为已证实，直到普遍存在可操作的（如签名，
加密，密钥对），这样才能证明对应性的存在。因此若CA/RA没有证实对应性，在英特
网PKI中的证书将没有意义。
依照证书所要求的密钥类型，POP可用不同方法实现。若密钥可用于多种目的（如RSA
密钥），那么POP可用任何一种方式实现。
本文考虑到POP被CA或RA或两者都验证的情况。一些策略可能要求CA在认证过程
中检验POP。在此过程中，RA必须提交CertRequest和POP给CA，并且作为一种选择也
可以检验POP。若策略不要求CA检验POP，那么RA应该提交终端实体的请求和证明给
CA。如果这不可能的话（例如，RA用带外的方法检验POP），那么RA可以向CA证明所
要求的证明已经被验证。若CA使用带外的方法证明POP（例如人工传递CA所生成私钥），
那么POP项不会被用。
4．1签名密钥
对签名密钥来说，终端实体用签名来证明拥有私钥。
4．2加密密钥
对加密密钥来说，终端实体提供私钥给CA/RA，或为了证明拥有私钥被要求解密。解
密通过直接或间接来完成。直接的方法是RA/CA发布一个随机测试，终端实体被要求立即
做出回答。间接的方法是发布一个被加密的证书，让终端实体来证明它有能力对证书解密。
CA发布的证书使用一种仅能被指定终端实体使用的格式。
4．3密钥
对密钥来说，终端实体使用4.2节中的3种方法来加密密钥。对于直接和间接的方
法，为了证明终端实体拥有私钥（也就是对加密的证书解密或对发布的测试做出回答），终
端实体和PKI机构（即CA/RA）必须建立一个共享的密钥。注意：这并不需要任何限
制强加在被CA鉴定的密钥上，特别是对于Diffie-Hellman密钥，终端实体可自由选择它的
算法参数，例如必要时CA能产生一个带有正确参数的短期密钥对（如一次性密钥对）。
终端实体也可以MAC（与密钥有关的单向散列函数称为MAC，即消息鉴别码）证书请
求（使用共享的由Diffie-Hellman算法计算出的密钥）作为第四个可选择的事物来证明POP。
只要CA已经有了DH证书，这个证书已经被终端实体知道，并且终端实体愿意使用CA的
DH参数，这个选项就可以使用。
4．4POP语法
ProofOfPossession::=CHOICE{
raVerified[0]NULL,
--用于是否RA已经证明请求者拥有私钥
signature[1]POPOSigningKey,
keyEncipherment[2]POPOPrivKey,
keyAgreement[3]POPOPrivKey}
这个选项可以使用
POPOSigningKey::=SEQUENCE{
poposkInput[0]POPOSigningKeyInputOPTIONAL,
algorithmIdentifierAlgorithmIdentifier,
signatureBITSTRING}
--签名signature（使用algorithmIdentifier所指的算法）是基于poposkInput的DER
编码值。
--注意：如果certReq中的CertTemplate结构包含主体和公钥值，那么
--poposkInput必须省略掉，并且signature必须通过certReq的DER编码值计算出来。
--如果certReq中的CertTemplate结构没有包含主体和公钥值，poposkInput必须存在
--并被签名。
--这种策略保证了公钥不会同时存在于poposkInput和certReq中的CertTemplate结
构。
POPOSigningKeyInput::=SEQUENCE{
authInfoCHOICE{
sender[0]GeneralName,
--用于当存在一个被证实的sender的标识符时（例如一个来自于以前颁发并且
现在
--仍有效的证书的DN（可辨认名））
publicKeyMACPKMACValue},
--用于当现在不存在一个被证实的sender的GeneralName时；
--publicKeyMAC包括一个基于密码的消息鉴别码（MAC），
--它是基于publicKey的DER编码值。
publicKeySubjectPublicKeyInfo}
PKMACValue::=SEQUENCE{
algIdAlgorithmIdentifier,
--算法是基于密码的MAC{1284011353376613}，参数为PBMParameter。
valueBITSTRING}
POPOPrivKey::=CHOICE{
thisMessage[0]BITSTRING,
--此项含有拥有私钥的证明，并且此项包括私钥本身（被加密）。
subsequentMessage[1]SubsequentMessage,
dhMAC[2]BITSTRING}
--仅用于密钥，在此项中证明拥有私钥，此项包括一个基于来自终端实体的私
有的
--DH钥和CA的公共的DH钥的密钥的MAC（基于certReq的参数的DER编码值，
它
--必须都包括subject和公钥）；dhMAC必须根据附录A中的说明计算出来。
SubsequentMessage::=INTEGER{
encrCert(0),
--要求结果证书为了终端实体被加密，接着POP将被一个确认消息所证实
challengeResp(1)}
--要求为了证明拥有私钥，CA/RA参与进和终端实体之间的回答挑战的交流。
含有此规格的若要成为一个完整的将包括确认和回答挑战的消息。
4．4．1基于密码的MAC的使用
当publicKeyMAC被用于POPOSigningKeyInput中来证明请求的真实性，下述的算法将
被使用。
PBMParameter::=SEQUENCE{
saltOCTETSTRING,
owfAlgorithmIdentifier,
--使用单向函数的算法标识符（建议使用SHA-1算法)
iterationCountINTEGER,
--OWF被应用的次数
macAlgorithmIdentifier
--MAC的算法标识符(例如DES-MAC,Triple-DES-MAC[PKCS11],
}--或HMAC[2104,2202])
使用PBMParameter来计算publicKeyMAC，由此来证明公钥证书请求来源的过程可以
由两部分组成。第一部分使用共享的秘密信息来生成一个MAC密钥。第二部分散列公钥，
并用MAC密钥来产生一个确认值。
第一部分算法的初始化假设存在一个共享的分布在一个可信任的位于CA/RA和终端实
体之间的方式的秘密。salt值被加之与此共享的秘密，并使用iterationCount次单向散列函
数。这样，此共享的秘密作为第一次输入，接下来每一次重复计算中，上一次的输出作为这
一次的输入，最后产生密钥K。
在第二部分中，K和公钥作为输入来产生publicKeyMAC，如下所示：
publicKeyMAC=Hash(KXORopad,Hash(KXORipad,publickey))，opad、ipad定义于
2104。
单向散列函数的算法标识符是SHA-1{13143226}，MAC的算法标识符是
HMAC-SHA1{136155812}。
5CertRequest语法
CertRequest由请求标识符、证书内容模板和一组可选的控制信息组成。
CertRequest::=SEQUENCE{
certReqIdINTEGER,--使请求和回答相匹配的标识符
certTemplateCertTemplate,--所发布证书的选择域
controlsControlsOPTIONAL}--有关证书发布的属性信息
CertTemplate::=SEQUENCE{
version[0]VersionOPTIONAL,
serialNumber[1]INTEGEROPTIONAL,
signingAlg[2]AlgorithmIdentifierOPTIONAL,
issuer[3]NameOPTIONAL,
validity[4]OptionalValidityOPTIONAL,
subject[5]NameOPTIONAL,
publicKey[6]SubjectPublicKeyInfoOPTIONAL,
issuerUID[7]UniqueIdentifierOPTIONAL,
subjectUID[8]UniqueIdentifierOPTIONAL,
extensions[9]ExtensionsOPTIONAL}
OptionalValidity::=SEQUENCE{
notBefore[0]TimeOPTIONAL,
notAfter[1]TimeOPTIONAL}--至少存在一个
Time::=CHOICE{
utcTimeUTCTime,
generalTimeGeneralizedTime}
6Controls语法
证书请求的产生可以包括一个或多个有关请求过程的控制值。
Controls::=SEQUENCESIZE(1..MAX)OFAttributeTypeAndValue
以下的控制被定义为：regToken，authenticator，pkiPublicationInfo，pkiArchiveOptions，
oldCertID，protocolEncrKey（这些项被认为可以超时扩展）。
6．1注册号（RegistrationToken）控制
regToken控制包含以前的信息（或是基于秘密的评估或是基于了解的信息），这些信息
往往被CA用于在颁发证书前验证请求者身份。一收到包含regToken的证书请求，CA就验
证这些信息，以便确认在证书请求中的声称的身份。
RegToken可以被CA生成，并在带外提供给订户，或者对CA和订户都可用。任何带
外的交换的安全性应该足够应付如CA接受了某人的干扰信息而没有接受原本订户的信息
这样的冒险。
RegToken控制将典型的仅被用于终端实体进入PKI的初始化上，而authenticator控制
（见6．2节）将不仅用于初始化，而且将用于接下来的证书请求上。
在一些使用例子中，regToken可能是一个文本字符串或是一个数，如随机数。这个值接
下来能被作为二进制数或是一个二进制数的字符串表示来编码。不管数的属性，为了确保值
的统一的编码，regToken的编码将用UTF8。
6．2鉴定者（Authenticator）控制
Authenticator控制包含一些用于行为基础的信息，这些信息用来在和CA交流中产生非
密码的身份检查。例子有：母亲未婚时的名字，社会安全号的最后4个数字，或其他和订户
的CA共享的知识信息；这些信息的散列；或其他用于该目的的信息。Authenticator控制值
可由CA或订户生成。
在一些使用例子中，Authenticator可能是一个文本字符串或是一个数，如随机数。这个
值接下来能被作为二进制数或是一个二进制数的字符串表示来编码。不管数的属性，为了确
保值的统一的编码，Authenticator的编码将用UTF8。
6．3颁发信息（PublicationInformation）控制
pkiPublicationInfo控制使订户可以控制CA证书的发布。它被定义为如下语法：
PKIPublicationInfo::=SEQUENCE{
actionINTEGER{
dontPublish(0),
pleasePublish(1)},
pubInfosSEQUENCESIZE(1..MAX)OFSinglePubInfoOPTIONAL}
--如果action是"dontPublish"，pubInfos必须不存在。
--(如果action是"pleasePublish"，并且pubInfos被删除，
--action被设为"dontCare"。）
SinglePubInfo::=SEQUENCE{
pubMethodINTEGER{
dontCare(0),
x500(1),
web(2),
ldap(3)},
pubLocationGeneralNameOPTIONAL}
如果选择dontPublish项，请求者指示PKI不要发布证书（这表示请求者要自己发布证
书）。
如果选择dontCare项，或者如果PKIPublicationInfo控制被从请求中删除，请求者指示
PKI可以用任何它选择的方法发布证书。
如果请求者除了希望CA能够在其他存放处使证书有效，还希望证书至少出现在一些地
方，那就要为pubInfos设置两个SinglePubInfo值，一个是x500、web或ldap，另一个是
dontCare。
如果pubLocation被用的话，此项表示请求者愿意证书在这些地方被发现（注意，
GeneralName可包括例如URL和IP地址等）。
6．4文档选项（ArchiveOptions）控制
pkiArchiveOptions控制使订户能够应用这样的信息，这些信息用于建立一个对应于证书
请求公钥的私钥的文档。它的语法定义如下：
PKIArchiveOptions::=CHOICE{
encryptedPrivKey[0]EncryptedKey,
--私钥的实际值
keyGenParameters[1]KeyGenParameters,
--使私钥能够重新生成的参数
archiveRemGenPrivKey[2]BOOLEAN}
--如果sender希望receiver保存receiver对应请求所生成的密钥对中的私钥，则设为
真。
--如果不要被保存，则设为假。
EncryptedKey::=CHOICE{
encryptedValueEncryptedValue,
envelopedData[0]EnvelopedData}
--加密私钥必须被放在envelopedData中
EncryptedValue::=SEQUENCE{
intendedAlg[0]AlgorithmIdentifierOPTIONAL,
--被加密的值被使用的意指的算法
symmAlg[1]AlgorithmIdentifierOPTIONAL,
--用于加密值的对称算法
encSymmKey[2]BITSTRINGOPTIONAL,
--用于加密值的对称密钥（已加密）
keyAlg[3]AlgorithmIdentifierOPTIONAL,
--用于加密对称密钥的算法
valueHint[4]OCTETSTRINGOPTIONAL,
--一个有关encValue内容的简单的描述或标识符（它可能只对发送终端有意义，
--并且只有EncryptedValue以后可以被发送终端重新检验，它才可以用）
encValueBITSTRING}
KeyGenParameters::=OCTETSTRING
一种发送密钥的选择是发送有关如何使用KeyGenParameters选项重新产生密钥的信息
（例如，对许多RSA实行来说，可以发送第一个最初测试的随机数）。对于这个参数的实际
的语法可以定义在这个文档的接下来版本中，或定义在另一个标准中。
6．5旧证书ID（OldCertID）控制
如此项存在，则OldCertID详述了被当前证书请求所更新的证书。其语法为：
CertId::=SEQUENCE{
issuerGeneralName,
serialNumberINTEGER
}
6．6加密密钥（ProtocolEncryptionKey）控制
如此项存在，则protocolEncrKey详述了一个CA用于加密对CertReqMessages的回答的
密钥。此项能被用于当CA有发送给订户的需要加密的信息。这些信息中包括一个由CA生
成的让订户使用的私钥。protocolEncrKey的编码应为SubjectPublicKeyInfo。
7对象标识符（ObjectIdentifiers）
id-pkix的对象标识符为：
id-pkixOBJECTIDENTIFIER::={iso(1)identified-organization(3)
dod(6)internet(1)security(5)mechanisms(5)pkix(7)}
--用于InternetX.509PKI及其组件的部分
id-pkipOBJECTIDENTIFIER::{id-pkixpkip(5)}
--在CRMF中的注册登记控制（RegistrationControls）
id-regCtrlOBJECTIDENTIFIER::={id-pkipregCtrl(1)}
id-regCtrl-regTokenOBJECTIDENTIFIER::={id-regCtrl1}
id-regCtrl-authenticatorOBJECTIDENTIFIER::={id-regCtrl2}
id-regCtrl-pkiPublicationInfoOBJECTIDENTIFIER::={id-regCtrl3}
id-regCtrl-pkiArchiveOptionsOBJECTIDENTIFIER::={id-regCtrl4}
id-regCtrl-oldCertIDOBJECTIDENTIFIER::={id-regCtrl5}
id-regCtrl-protocolEncrKeyOBJECTIDENTIFIER::={id-regCtrl6}
--CRMF中的注册信息（RegistrationInfo）
id-regInfoOBJECTIDENTIFIER::={id-pkipid-regInfo(2)}
id-regInfo-asciiPairsOBJECTIDENTIFIER::={id-regInfo1}
--使用OCTETSTRING
id-regInfo-certReqOBJECTIDENTIFIER::={id-regInfo2}
--使用CertRequest
8对于安全的考虑
CRMF传送的安全性是基于或用于和CA通信的进程的安全结构。这些或进程
需要确保完整性，数据来源的真实性和信息的隐私。如果一个CRMF包括敏感的订户信息，
并且CA有一个终端实体所知的加密证书，那么强烈建议使用CRMF加密。
9参考
[HMAC]Krawczyk，H.，Bellare，M.和R.Canetti，"HMAC:Keyed-HashingforMessage
Authentication"（“HMAC：为了保证信息真实性的密钥Hash散列”），2104,1997.2。
10谢辞
作者非常感谢BarbaraFox，WarwickFord，RussHousley和JohnPawling所做的贡献。
他们的复审和建议进一步阐明和改善了本篇的实用功能。
附录A．构造dhMAC
本附录描述了计算Diffie-Hellman证书请求的POPOPrivKey结构中的dhMAC位串的方
法。
1终端产生一个DH公/私钥对
用于计算公钥的DH参数被详述在CA的DH证书中。
从CA的DH证书中，CApub=g^xmodp，这里g，p是已有的DH参数，而x是
CA私有的DH组件。
对终端E来说，DHprivatevalue=y，Epub=DHpublicvalue=g^ymodp。
2MAC进程有以下步骤组成
a） certReq项的值用DER编码，产生一个二进制串。这就是在[HMAC]中提
到的‘text’，它是HMAC-SHA1算法所应用的数据。
b） 计算共享的DHsecret，如下所示：sharedsecret=Kec=g^xymodp。终端E
计算CApub^y，CApub是来自于CA的DH证书；CA计算Epub^x，Epub是来自
于证书请求。
c） 密钥K来自于Kec，证书请求者名称，证书颁发者名称。如下所示：K=
SHA1(DER-encoded-subjectName|Kec|DER-encoded-issuerName)，这里‘|’的意
思是级连。如果在CA证书中subjectName为空，则替代使用
DER-encoded-subjectAltName。如果CA证书中issuerName为空，则替代使用
DER-encoded-issuerAltName。
d） 按照2104来用数据'text'计算HMAC-SHA1，SHA1(KXORopad,SHA1(K
ORipad,text))，此处opad=0x36重复64次，ipad=0x5C重复64次。也就是
说，
（1） 在K的末端填充0，来生成一个64字节的串（例如，若K为16字节长，
就要填充48个0字节）。
（2） XOR（异或）第1步生成的64字节K和ipad。
（3） 把‘text’加到第2步生成的64字节串上。
（4） 对第3步生成的字节串应用SHA1算法。
（5） XOR第1步生成的64字节K和opad。
（6） 把第4步中SHA1生成的结果加到第5步生成的64字节串上。
（7） 使用SHA1算法计算第6步中的产生值，最后输出结果。
例子代码在2104,2202中有。
e）d）的输出被编码为位串（"dhMAC")。
3验证拥有私钥（proof-of-possession）的进程需要CA执行
执行从a）到d），然后比较d）步的结果和CA收到的"dhMAC"值。如果它们匹配，则
有如下结论：
1） 终端拥有与证书请求中的公钥对应的私钥（因为终端需要私钥来计算sharedsecret）。
2） 只有CA能验证请求（CA需要自己的私钥来计算同样的sharedsecret）。这有助于防止
CA受骗。
参考文献
[2104]Krawczyk,H.,Bellare,M.andR.Canetti,"HMAC:Keyed
HashingforMessageAuthentication",2104,February
1997.
[2202]Cheng,P.andR.Glenn,"TestCasesforHMAC-MD5andHMAC-
SHA-1",2202,September1997.
谢词
此附录的细节由HemmaPrafullchandra所提供
AppendixB.UseofRegInfoforName-ValuePairs
The"value"fieldoftheid-regInfo-utf8PairsOCTETSTRING(with
"tag"fieldequalto12andappropriate"length"field)willcontain
aseriesofUTF8name/valuepairs.
ThisAppendixlistssomecommonexamplesofsuchpairsforthe
purposeofpromotinginteroperabilityamongindependent
implementationsofthisspecification.Itisrecognizedthatthis
listisnotexhaustiveandwillgrowwithtimeandimplementation
experience.
B.1.ExampleName/ValuePairs
WhenregInfoisusedtoconveyoneormorename-valuepairs(viaid-
regInfo-utf8Pairs),thefirstandsubsequentpairsSHALLbe
structuredasfollows:
[name?value][%name?value]*%
ThisstringisthenencodedintoanOCTETSTRINGandplacedintothe
regInfoSEQUENCE.
Reservedcharactersareencodedusingthe%xxmechanismof[1738],
unlesstheyareusedfortheirreservedpurposes.
Thefollowingtabledefinesarecommendedsetofnamedelements.
Thevalueinthecolumn"NameValue"istheexacttextstringthat
willappearintheregInfo.
NameValue
----------
version--versionofthisvariationofregInfouse
corp_company--companyaffiliationofsubscriber
org_unit--organizationalunit
mail_firstName--personalnamecomponent
mail_middleName--personalnamecomponent
mail_lastName--personalnamecomponent
mail_email--subscriber'semailaddress
jobTitle--jobtitleofsubscriber
employeeID--employeeidentificationnumberorstring
mailStop--mailstop
issuerName--nameofCA
subjectName--nameofSubject
validity--validityinterval
Forexample:
version?1%corp_company?Acme,Inc.%org_unit?Engineering%
mail_firstName?John%mail_lastName?Smith%jobTitle?TeamLeader%
mail_email?john@acme.com%
B.1.1.IssuerName,SubjectNameandValidityValueEncoding
Whentheyappearinid-regInfo-utf8Pairssyntaxasnamedelements,
theencodingofvaluesforissuerName,subjectNameandvaliditySHALL
usethefollowingsyntax.Thecharacters[]indicateanoptional
field,::=and|havetheirusualBNFmeanings,andallothersymbols
(exceptspaceswhichareinsignificant)outsidenon-terminalnames
areterminals.Alphabeticsarecase-sensitive.
issuerName::=
subjectName::=
