本文引自:
				
						http://www.infosecurity.org.cn/article/pki/standard/23547.html
				
		
		
				
						
						 
				
		
		
				
						此备忘录的状况
				
				
						
				
				
						此文档为因特网社区详细描述了一个因特网标准途径
						
								
								
								
										
												协议
										
								
						
						,并且请求改善的讨论和建
				
				
						
				
				
						议。为了确保此
						
								
								
								
										
												协议
										
								
						
						的标准化状态,请参考当前版本的因特网官方
						
								
								
								
										
												协议
										
								
						
						标准(
						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[RFC2104,RFC2202])
						使用
						PBMParameter
						来计算
						publicKeyMAC
						,由此来证明公钥证书请求来源的过程可以
				
				
						
				
				
						由两部分组成。第一部分使用共享的秘密信息来生成一个
						MAC
						密钥。第二部分散列公钥,
				
				
						
				
				
						并用
						MAC
						密钥来产生一个确认值。
				
				
						
				
				
						第一部分算法的初始化假设存在一个共享的分布在一个可信任的位于
						CA/RA
						和终端实
				
				
						
				
				
						体之间的方式的秘密。
						salt
						值被加之与此共享的秘密,并使用
						iterationCount
						次单向散列函
				
				
						
				
				
						数。这样,此共享的秘密作为第一次输入,接下来每一次重复计算中,上一次的输出作为这
				
				
						
				
				
						一次的输入,最后产生密钥
						K
						。
				
				
						
				
				
						在第二部分中,
						K
						和公钥作为输入来产生
						publicKeyMAC
						,如下所示:
				
				
						
						publicKeyMAC=Hash(KXORopad,Hash(KXORipad,publickey))
				
				
						,
						opad
						、
						ipad
						定义于
				
				
						
						RFC2104
				
				
						。
				
				
						
				
				
						单向散列函数的算法标识符是
						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
						散列
						”
						),
						RFC2104,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
				
				
						)
						
						
						按照
						RFC2104
						来用数据
						'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
						步中的产生值,最后输出结果。
				
				
						
				
				
						例子代码在
						RFC2104,RFC2202
						中有。
				
				
						
						e
				
				
						)
						d
						)的输出被编码为位串(
						"dhMAC")
						。
				
				
						
						
						3
				
				
						验证拥有私钥(
						proof-of-possession
						)的进程需要
						CA
						执行
				
				
						
				
				
						执行从
						a
						)到
						d
						),然后比较
						d
						)步的结果和
						CA
						收到的
						"dhMAC"
						值。如果它们匹配,则
				
				
						
				
				
						有如下结论:
				
				
						
						1
				
				
						)
						
						
						终端拥有与证书请求中的公钥对应的私钥(因为终端需要私钥来计算
						sharedsecret
						)。
				
				
						
						2
				
				
						)
						
						
						只有
						CA
						能验证请求(
						CA
						需要自己的私钥来计算同样的
						sharedsecret
						)。这有助于防止
				
				
						
						CA
				
				
						受骗。
				
				
						
						
				
				
						参考文献
				
				
						
						
						[RFC2104]Krawczyk,H.,Bellare,M.andR.Canetti,"HMAC:Keyed
HashingforMessageAuthentication",RFC2104,February
1997.
[RFC2202]Cheng,P.andR.Glenn,"TestCasesforHMAC-MD5andHMAC-
SHA-1",RFC2202,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[RFC1738],
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::=<names>
subjectName::=<names>
<names>::=<name>|<names>:<name>
<validity>::=validity?[<notbefore>]-[<notafter>]
<notbefore>::=<time>
<notafter>::=<time>
Where<time>isUTCtimeintheformYYYYMMDD[HH[MM[SS>].HH,MM,
andSSdefaultto00andareomittedifattheandofvalue00.
Examplevalidityencoding:
validity?-19991231%
isavalidityintervalwithnovaluefornotBeforeandavalueof
December31,1999fornotAfter.
Eachnamecomprisesasinglecharacternameformidentifierfollowed
byanamevalueofoneorUTF8characters.Withinanamevalue,when
itisnecessarytodisambiguateacharacterwhichhasformatting
significanceatanouterlevel,theescapesequence%xxSHALLbe
used,wherexxrepresentsthehexvaluefortheencodingconcerned.
Thepercentsymbolisrepresentedby%%.
<name>::=X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>
Nameformsandvalueformatsareasfollows:
X.500directorynameform(identifier"X"):
<xname>::=<rdns>
<rdns>::=<rdn>|<rdns>,<rdn>
<rdn>::=<avas>
<avas>::=<ava>|<avas>+<ava>
<ava>::=<attyp>=<avalue>
<attyp>::=OID.<oid>|<stdat>
Standardattributetype<stdat>isanalphabeticattributetype
identifierfromthefollowingset:
C(country)
L(locality)
ST(stateorprovince)
O(organization)
OU(organizationalunit)
CN(commonname)
STREET(streetaddress)
E(E-mailaddress).
<avalue>isanamecomponentintheformofaUTF8characterstring
of1to64characters,withtherestrictionthatintheIA5subsetof
UTF8onlythecharactersofASN.1PrintableStringmaybeused.
Othernameform(identifier"O"):
<oname>::=<oid>,<utf8string>
E-mailaddress(rfc822name)nameform(identifier"E"):
<ename>::=<ia5string>
DNSnameform(identifier"D"):
<dname>::=<ia5string>
URInameform(identifier"U"):
<uname>::=<ia5string>
IPaddress(identifier"I"):
<iname>::=<oid>
Forexample:
issuerName?XOU=OurCA,O=Acme,C=US%
subjectName?XCN=JohnSmith,O=Acme,C=US,E=john@acme.com%
References
[RFC1738]Berners-Lee,T.,Masinter,L.andM.McCahill,
"UniformResourceLocators(URL)",RFC1738,December1994.
AppendixC.ASN.1StructuresandOIDs
PKIXCRMF{iso(1)identified-organization(3)dod(6)internet(1)
security(5)mechanisms(5)pkix(7)id-mod(0)id-mod-crmf(5)}
CRMFDEFINITIONSIMPLICITTAGS::=
BEGIN
IMPORTS
--DirectoryAuthenticationFramework(X.509)
Version,AlgorithmIdentifier,Name,Time,
SubjectPublicKeyInfo,Extensions,UniqueIdentifier
FROMPKIX1Explicit88{iso(1)identified-organization(3)dod(6)
internet(1)security(5)mechanisms(5)pkix(7)id-mod(0)
id-pkix1-explicit-88(1)}
--CertificateExtensions(X.509)
GeneralName
FROMPKIX1Implicit88{iso(1)identified-organization(3)dod(6)
internet(1)security(5)mechanisms(5)pkix(7)id-mod(0)
id-pkix1-implicit-88(2)}
--CryptographicMessageSyntax
EnvelopedData
FROMCryptographicMessageSyntax{iso(1)member-body(2)
us(840)rsadsi(113549)pkcs(1)pkcs-9(9)smime(16)
modules(0)cms(1)};
CertReqMessages::=SEQUENCESIZE(1..MAX)OFCertReqMsg
CertReqMsg::=SEQUENCE{
certReqCertRequest,
popProofOfPossessionOPTIONAL,
--contentdependsuponkeytype
regInfoSEQUENCESIZE(1..MAX)OFAttributeTypeAndValueOPTIONAL}
CertRequest::=SEQUENCE{
certReqIdINTEGER,--IDformatchingrequestandreply
certTemplateCertTemplate,--Selectedfieldsofcerttobeissued
controlsControlsOPTIONAL}--Attributesaffectingissuance
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}--atleastoneMUSTbepresent
Controls::=SEQUENCESIZE(1..MAX)OFAttributeTypeAndValue
AttributeTypeAndValue::=SEQUENCE{
typeOBJECTIDENTIFIER,
valueANYDEFINEDBYtype}
ProofOfPossession::=CHOICE{
raVerified[0]NULL,
--usediftheRAhasalreadyverifiedthattherequesterisin
--possessionoftheprivatekey
signature[1]POPOSigningKey,
keyEncipherment[2]POPOPrivKey,
keyAgreement[3]POPOPrivKey}
POPOSigningKey::=SEQUENCE{
poposkInput[0]POPOSigningKeyInputOPTIONAL,
algorithmIdentifierAlgorithmIdentifier,
signatureBITSTRING}
--Thesignature(using"algorithmIdentifier")isonthe
--DER-encodedvalueofpoposkInput.NOTE:IftheCertReqMsg
--certReqCertTemplatecontainsthesubjectandpublicKeyvalues,
--thenpoposkInputMUSTbeomittedandthesignatureMUSTbe
--computedontheDER-encodedvalueofCertReqMsgcertReq.If
--theCertReqMsgcertReqCertTemplatedoesnotcontainthepublic
--keyandsubjectvalues,thenpoposkInputMUSTbepresentand
--MUSTbesigned.Thisstrategyensuresthatthepublickeyis
--notpresentinboththepoposkInputandCertReqMsgcertReq
--CertTemplatefields.
POPOSigningKeyInput::=SEQUENCE{
authInfoCHOICE{
sender[0]GeneralName,
--usedonlyifanauthenticatedidentityhasbeen
--establishedforthesender(e.g.,aDNfroma
--previously-issuedandcurrently-validcertificate
publicKeyMACPKMACValue},
--usedifnoauthenticatedGeneralNamecurrentlyexistsfor
--thesender;publicKeyMACcontainsapassword-basedMAC
--ontheDER-encodedvalueofpublicKey
publicKeySubjectPublicKeyInfo}--fromCertTemplate
PKMACValue::=SEQUENCE{
algIdAlgorithmIdentifier,
--algorithmvalueshallbePasswordBasedMac{1284011353376613}
--parametervalueisPBMParameter
valueBITSTRING}
PBMParameter::=SEQUENCE{
saltOCTETSTRING,
owfAlgorithmIdentifier,
--AlgIdforaOne-WayFunction(SHA-1recommended)
iterationCountINTEGER,
--numberoftimestheOWFisapplied
macAlgorithmIdentifier
--theMACAlgId(e.g.,DES-MAC,Triple-DES-MAC[PKCS11],
}--orHMAC[RFC2104,RFC2202])
POPOPrivKey::=CHOICE{
thisMessage[0]BITSTRING,
--posessionisproveninthismessage(whichcontainstheprivate
--keyitself(encryptedfortheCA))
subsequentMessage[1]SubsequentMessage,
--possessionwillbeproveninasubsequentmessage
dhMAC[2]BITSTRING}
--forkeyAgreement(only),possessionisproveninthismessage
--(whichcontainsaMAC(overtheDER-encodedvalueofthe
--certReqparameterinCertReqMsg,whichMUSTincludebothsubject
--andpublicKey)basedonakeyderivedfromtheendentity's
--privateDHkeyandtheCA'spublicDHkey);
--thedhMACvalueMUSTbecalculatedasperthedirectionsgiven
--inAppendixA.
SubsequentMessage::=INTEGER{
encrCert(0),
--requeststhatresultingcertificatebeencryptedforthe
--endentity(followingwhich,POPwillbeprovenina
--confirmationmessage)
challengeResp(1)}
--requeststhatCAengageinchallenge-responseexchangewith
--endentityinordertoproveprivatekeypossession
--Objectidentifierassignments--
id-pkixOBJECTIDENTIFIER::={iso(1)identified-organization(3)
dod(6)internet(1)security(5)mechanisms(5)7}
--arcforInternetX.509PKIprotocolsandtheircomponents
id-pkipOBJECTIDENTIFIER::={id-pkix5}
--RegistrationControlsinCRMF
id-regCtrlOBJECTIDENTIFIER::={id-pkip1}
--Thefollowingdefinitionmaybeuncommentedforusewith
--ASN.1compilerswhichdonotunderstandUTF8String.
--UTF8String::=[UNIVERSAL12]IMPLICITOCTETSTRING
id-regCtrl-regTokenOBJECTIDENTIFIER::={id-regCtrl1}
--withsyntax:
RegToken::=UTF8String
id-regCtrl-authenticatorOBJECTIDENTIFIER::={id-regCtrl2}
--withsyntax:
Authenticator::=UTF8String
id-regCtrl-pkiPublicationInfoOBJECTIDENTIFIER::={id-regCtrl3}
--withsyntax:
PKIPublicationInfo::=SEQUENCE{
actionINTEGER{
dontPublish(0),
pleasePublish(1)},
pubInfosSEQUENCESIZE(1..MAX)OFSinglePubInfoOPTIONAL}
--pubInfosMUSTNOTbepresentifactionis"dontPublish"
--(ifactionis"pleasePublish"andpubInfosisomitted,
--"dontCare"isassumed)
SinglePubInfo::=SEQUENCE{
pubMethodINTEGER{
dontCare(0),
x500(1),
web(2),
ldap(3)},
pubLocationGeneralNameOPTIONAL}
id-regCtrl-pkiArchiveOptionsOBJECTIDENTIFIER::={id-regCtrl4}
--withsyntax:
PKIArchiveOptions::=CHOICE{
encryptedPrivKey[0]EncryptedKey,
--theactualvalueoftheprivatekey
keyGenParameters[1]KeyGenParameters,
--parameterswhichallowtheprivatekeytobere-generated
archiveRemGenPrivKey[2]BOOLEAN}
--settoTRUEifsenderwishesreceivertoarchivetheprivate
--keyofakeypairwhichthereceivergeneratesinresponseto
--thisrequest;settoFALSEifnoarchivalisdesired.
EncryptedKey::=CHOICE{
encryptedValueEncryptedValue,
envelopedData[0]EnvelopedData}
--TheencryptedprivatekeyMUSTbeplacedintheenvelopedData
--encryptedContentInfoencryptedContentOCTETSTRING.
EncryptedValue::=SEQUENCE{
intendedAlg[0]AlgorithmIdentifierOPTIONAL,
--theintendedalgorithmforwhichthevaluewillbeused
symmAlg[1]AlgorithmIdentifierOPTIONAL,
--thesymmetricalgorithmusedtoencryptthevalue
encSymmKey[2]BITSTRINGOPTIONAL,
--the(encrypted)symmetrickeyusedtoencryptthevalue
keyAlg[3]AlgorithmIdentifierOPTIONAL,
--algorithmusedtoencryptthesymmetrickey
valueHint[4]OCTETSTRINGOPTIONAL,
--abriefdescriptionoridentifieroftheencValuecontent
--(maybemeaningfulonlytothesendingentity,andusedonly
--ifEncryptedValuemightbere-examinedbythesendingentity
--inthefuture)
encValueBITSTRING}
--theencryptedvalueitself
KeyGenParameters::=OCTETSTRING
id-regCtrl-oldCertIDOBJECTIDENTIFIER::={id-regCtrl5}
--withsyntax:
OldCertId::=CertId
CertId::=SEQUENCE{
issuerGeneralName,
serialNumberINTEGER}
id-regCtrl-protocolEncrKeyOBJECTIDENTIFIER::={id-regCtrl6}
--withsyntax:
ProtocolEncrKey::=SubjectPublicKeyInfo
--RegistrationInfoinCRMF
id-regInfoOBJECTIDENTIFIER::={id-pkip2}
id-regInfo-utf8PairsOBJECTIDENTIFIER::={id-regInfo1}
--withsyntax
UTF8Pairs::=UTF8String
id-regInfo-certReqOBJECTIDENTIFIER::={id-regInfo2}
--withsyntax
CertReq::=CertRequest