本文引自：
http://www.infosecurity.org.cn/article/pki/standard/23547.html
?
此備忘錄的狀況
此文檔為因特網(wǎng)社區(qū)詳細(xì)描述了一個(gè)因特網(wǎng)標(biāo)準(zhǔn)途徑
協(xié)議
，并且請(qǐng)求改善的討論和建
議。為了確保此
協(xié)議
的標(biāo)準(zhǔn)化狀態(tài)，請(qǐng)參考當(dāng)前版本的因特網(wǎng)官方
協(xié)議
標(biāo)準(zhǔn)（
STD1
）。本備
忘錄的發(fā)布是不受限制的。
版權(quán)通知
版權(quán)所屬因特網(wǎng)社會(huì)（
1999
），保留全部權(quán)力。
目錄
1
摘要
2
2
略讀
2
3
證書請(qǐng)求信息
(CertReqMessage)
的語法
2
4
擁有私鑰的證明
(POP) 3
4
．
1
簽名密鑰
3
4
．
2
加密密鑰
3
4
．
3協(xié)議
密鑰
4
4
．
4POP
語法
4
5CertRequest
語法
6
6Controls
語法
7
6
．
1
注冊(cè)號(hào)（
RegistrationToken
）控制
7
6
．
2
鑒定者（
Authenticator
）控制
7
6
．
4
文檔選項(xiàng)（
ArchiveOptions
）控制
8
6
．
5
舊證書
ID
（
OldCertID
）控制
9
6
．
6協(xié)議
加密密鑰（
ProtocolEncryptionKey
）控制
9
7
對(duì)象標(biāo)識(shí)符（
ObjectIdentifiers
）
10
8
對(duì)于安全的考慮
10
9
參考
10
10
謝辭
11
附錄
A
．構(gòu)造
dhMAC 11
AppendixB.UseofRegInfoforName-ValuePairs 12
AppendixC.ASN.1StructuresandOIDs 15
FullCopyrightStatement 21
1
摘要
本文描述了證書請(qǐng)求消息格式
(CRMF)
。它被用來向
CA
傳遞一個(gè)產(chǎn)生
X.509
證書請(qǐng)求
(
可能通過
RA)
。請(qǐng)求消息一般包括公鑰和有關(guān)的登記信息。
2
略讀
證書請(qǐng)求構(gòu)成的步驟如下：
1)
產(chǎn)生
CertRequest
值，其值包括：公鑰，所有或部分的終端實(shí)體（
EE
）的名字，其他所
要求的證書值域，以及與登記過程相連系的控制信息。
2)
可以通過計(jì)算
CertRequest
的值來證明擁有與所請(qǐng)求的證書的公鑰相連系的私鑰，即可
計(jì)算出
POP
（
proofofpossession
，擁有私鑰的證明）的值。
3)
以上兩項(xiàng)所需要的其他登記信息，這些信息和
POP
值，
CertRequest
結(jié)構(gòu)組成證書請(qǐng)求
信息。
4)
證書請(qǐng)求信息被秘密傳遞給
CA
，傳遞的方法不是本文敘述的范圍。
3
證書請(qǐng)求信息
(CertReqMessage)
的語法
證書請(qǐng)求信息由證書請(qǐng)求，一個(gè)可選的檢驗(yàn)項(xiàng)，以及一個(gè)可選的登記信息項(xiàng)。
CertReqMessages::=SEQUENCESIZE(1..MAX)OFCertReqMsg
CertReqMsg::=SEQUENCE{
certReqCertRequest,
popProofOfPossessionOPTIONAL,
--
其內(nèi)容依賴于密鑰類型
regInfoSEQUENCESIZE(1..MAX)ofAttributeTypeAndValueOPTIONAL}
POP
用來證明證書請(qǐng)求者確實(shí)擁有所對(duì)應(yīng)的私鑰。此項(xiàng)可由
certReq
計(jì)算出來，其內(nèi)容和結(jié)
構(gòu)隨公鑰算法的類型和運(yùn)作模式的改變而改變。
regInfo
項(xiàng)僅包括與證書請(qǐng)求有關(guān)的補(bǔ)充信
息。它還可包括請(qǐng)求者的聯(lián)系信息，布告信息，或?qū)ψC書請(qǐng)求有用的輔助信息。直接與證書
內(nèi)容有關(guān)的信息應(yīng)該包括在
certReq
中。然而若
RA
包含另外的
certReq
內(nèi)容，這可以使
pop
項(xiàng)無效。因此其余證書想要的數(shù)據(jù)可以由
regInfo
提供。
4
擁有私鑰的證明
(POP)
為了防止某些攻擊以及允許
CA/RA
檢驗(yàn)終端實(shí)體和密鑰對(duì)之間對(duì)應(yīng)的有效性，
PKI
管
理操作使終端實(shí)體有能力證明擁有
(
也就是說能用
)
與證書公鑰所對(duì)應(yīng)的私鑰。
CA/RA
在證書
交換中可自由選擇如何實(shí)施
POP
（例如帶外的方法或
CRMF
的帶內(nèi)的方法），也就是說這可
以是一個(gè)策略問題。然而，因?yàn)楝F(xiàn)在有許多非
PKIX
的操作
協(xié)議
在使用（例如許多電子郵件
協(xié)議
），它們并不檢驗(yàn)終端實(shí)體和私鑰之間的對(duì)應(yīng)性，這要求
CA/RA
必須通過一些方法來實(shí)
施
POP
。這種對(duì)應(yīng)性僅能被
CA/RA
假設(shè)為已證實(shí)，直到普遍存在可操作的
協(xié)議
（如簽名，
加密，
協(xié)議
密鑰對(duì)），這樣才能證明對(duì)應(yīng)性的存在。因此若
CA/RA
沒有證實(shí)對(duì)應(yīng)性，在英特
網(wǎng)
PKI
中的證書將沒有意義。
依照證書所要求的密鑰類型，
POP
可用不同方法實(shí)現(xiàn)。若密鑰可用于多種目的（如
RSA
密鑰），那么
POP
可用任何一種方式實(shí)現(xiàn)。
本文考慮到
POP
被
CA
或
RA
或兩者都驗(yàn)證的情況。一些策略可能要求
CA
在認(rèn)證過程
中檢驗(yàn)
POP
。在此過程中，
RA
必須提交
CertRequest
和
POP
給
CA
，并且作為一種選擇也
可以檢驗(yàn)
POP
。若策略不要求
CA
檢驗(yàn)
POP
，那么
RA
應(yīng)該提交終端實(shí)體的請(qǐng)求和證明給
CA
。如果這不可能的話（例如，
RA
用帶外的方法檢驗(yàn)
POP
），那么
RA
可以向
CA
證明所
要求的證明已經(jīng)被驗(yàn)證。若
CA
使用帶外的方法證明
POP
（例如人工傳遞
CA
所生成私鑰），
那么
POP
項(xiàng)不會(huì)被用。
4
．
1
簽名密鑰
對(duì)簽名密鑰來說，終端實(shí)體用簽名來證明擁有私鑰。
4
．
2
加密密鑰
對(duì)加密密鑰來說，終端實(shí)體提供私鑰給
CA/RA
，或?yàn)榱俗C明擁有私鑰被要求解密。解
密通過直接或間接來完成。直接的方法是
RA/CA
發(fā)布一個(gè)隨機(jī)測(cè)試，終端實(shí)體被要求立即
做出回答。間接的方法是發(fā)布一個(gè)被加密的證書，讓終端實(shí)體來證明它有能力對(duì)證書解密。
CA
發(fā)布的證書使用一種僅能被指定終端實(shí)體使用的格式。
4
．
3協(xié)議
密鑰
對(duì)
協(xié)議
密鑰來說，終端實(shí)體使用
4.2
節(jié)中的
3
種方法來加密密鑰。對(duì)于直接和間接的方
法，為了證明終端實(shí)體擁有私鑰（也就是對(duì)加密的證書解密或?qū)Πl(fā)布的測(cè)試做出回答），終
端實(shí)體和
PKI
管理機(jī)構(gòu)（即
CA/RA
）必須建立一個(gè)共享的密鑰。注意：這并不需要任何限
制強(qiáng)加在被
CA
鑒定的密鑰上，特別是對(duì)于
Diffie-Hellman
密鑰，終端實(shí)體可自由選擇它的
算法參數(shù)，例如必要時(shí)
CA
能產(chǎn)生一個(gè)帶有正確參數(shù)的短期密鑰對(duì)（如一次性密鑰對(duì)）。
終端實(shí)體也可以
MAC
（與密鑰有關(guān)的單向散列函數(shù)稱為
MAC
，即消息鑒別碼）證書請(qǐng)
求（使用共享的由
Diffie-Hellman
算法計(jì)算出的密鑰）作為第四個(gè)可選擇的事物來證明
POP
。
只要
CA
已經(jīng)有了
DH
證書，這個(gè)證書已經(jīng)被終端實(shí)體知道，并且終端實(shí)體愿意使用
CA
的
DH
參數(shù)，這個(gè)選項(xiàng)就可以使用。
4
．
4POP
語法
ProofOfPossession::=CHOICE{
raVerified[0]NULL,
--
用于是否
RA
已經(jīng)證明請(qǐng)求者擁有私鑰
signature[1]POPOSigningKey,
keyEncipherment[2]POPOPrivKey,
keyAgreement[3]POPOPrivKey}
這個(gè)選項(xiàng)可以使用
POPOSigningKey::=SEQUENCE{
poposkInput[0]POPOSigningKeyInputOPTIONAL,
algorithmIdentifierAlgorithmIdentifier,
signatureBITSTRING}
--
簽名
signature
（使用
algorithmIdentifier
所指的算法）是基于
poposkInput
的
DER
編碼值。
--
注意：如果
certReq
中的
CertTemplate
結(jié)構(gòu)包含主體和公鑰值，那么
--poposkInput
必須省略掉，并且
signature
必須通過
certReq
的
DER
編碼值計(jì)算出來。
--
如果
certReq
中的
CertTemplate
結(jié)構(gòu)沒有包含主體和公鑰值，
poposkInput
必須存在
--
并被簽名。
--
這種策略保證了公鑰不會(huì)同時(shí)存在于
poposkInput
和
certReq
中的
CertTemplate
結(jié)
構(gòu)。
POPOSigningKeyInput::=SEQUENCE{
authInfoCHOICE{
sender[0]GeneralName,
--
用于當(dāng)存在一個(gè)被證實(shí)的
sender
的標(biāo)識(shí)符時(shí)（例如一個(gè)來自于以前頒發(fā)并且
現(xiàn)在
--
仍有效的證書的
DN
（可辨認(rèn)名））
publicKeyMACPKMACValue},
--
用于當(dāng)現(xiàn)在不存在一個(gè)被證實(shí)的
sender
的
GeneralName
時(shí)；
--publicKeyMAC
包括一個(gè)基于密碼的消息鑒別碼（
MAC
），
--
它是基于
publicKey
的
DER
編碼值。
publicKeySubjectPublicKeyInfo}
PKMACValue::=SEQUENCE{
algIdAlgorithmIdentifier,
--
算法是基于密碼的
MAC{1284011353376613}
，參數(shù)為
PBMParameter
。
valueBITSTRING}
POPOPrivKey::=CHOICE{
thisMessage[0]BITSTRING,
--
此項(xiàng)含有擁有私鑰的證明，并且此項(xiàng)包括私鑰本身（被加密）。
subsequentMessage[1]SubsequentMessage,
dhMAC[2]BITSTRING}
--
僅用于
協(xié)議
密鑰，在此項(xiàng)中證明擁有私鑰，此項(xiàng)包括一個(gè)基于來自終端實(shí)體的私
有的
--DH
鑰和
CA
的公共的
DH
鑰的密鑰的
MAC
（基于
certReq
的參數(shù)的
DER
編碼值，
它
--
必須都包括
subject
和公鑰）；
dhMAC
必須根據(jù)附錄
A
中的說明計(jì)算出來。
SubsequentMessage::=INTEGER{
encrCert(0),
--
要求結(jié)果證書為了終端實(shí)體被加密，接著
POP
將被一個(gè)確認(rèn)消息所證實(shí)
challengeResp(1)}
--
要求為了證明擁有私鑰，
CA/RA
參與進(jìn)和終端實(shí)體之間的回答挑戰(zhàn)的交流。
含有此規(guī)格的
協(xié)議
若要成為一個(gè)完整的
協(xié)議
將包括確認(rèn)和回答挑戰(zhàn)的消息。
4
．
4
．
1
基于密碼的
MAC
的使用
當(dāng)
publicKeyMAC
被用于
POPOSigningKeyInput
中來證明請(qǐng)求的真實(shí)性，下述的算法將
被使用。
PBMParameter::=SEQUENCE{
saltOCTETSTRING,
owfAlgorithmIdentifier,
--
使用單向函數(shù)的算法標(biāo)識(shí)符（建議使用
SHA-1
算法
)
iterationCountINTEGER,
--OWF
被應(yīng)用的次數(shù)
macAlgorithmIdentifier
--MAC
的算法標(biāo)識(shí)符
(
例如
DES-MAC,Triple-DES-MAC[PKCS11],
}--
或
HMAC[RFC2104,RFC2202])
使用
PBMParameter
來計(jì)算
publicKeyMAC
，由此來證明公鑰證書請(qǐng)求來源的過程可以
由兩部分組成。第一部分使用共享的秘密信息來生成一個(gè)
MAC
密鑰。第二部分散列公鑰，
并用
MAC
密鑰來產(chǎn)生一個(gè)確認(rèn)值。
第一部分算法的初始化假設(shè)存在一個(gè)共享的分布在一個(gè)可信任的位于
CA/RA
和終端實(shí)
體之間的方式的秘密。
salt
值被加之與此共享的秘密，并使用
iterationCount
次單向散列函
數(shù)。這樣，此共享的秘密作為第一次輸入，接下來每一次重復(fù)計(jì)算中，上一次的輸出作為這
一次的輸入，最后產(chǎn)生密鑰
K
。
在第二部分中，
K
和公鑰作為輸入來產(chǎn)生
publicKeyMAC
，如下所示：
publicKeyMAC=Hash(KXORopad,Hash(KXORipad,publickey))
，
opad
、
ipad
定義于
RFC2104
。
單向散列函數(shù)的算法標(biāo)識(shí)符是
SHA-1{13143226}
，
MAC
的算法標(biāo)識(shí)符是
HMAC-SHA1{136155812}
。
5CertRequest
語法
CertRequest
由請(qǐng)求標(biāo)識(shí)符、證書內(nèi)容模板和一組可選的控制信息組成。
CertRequest::=SEQUENCE{
certReqIdINTEGER,--
使請(qǐng)求和回答相匹配的標(biāo)識(shí)符
certTemplateCertTemplate,--
所發(fā)布證書的選擇域
controlsControlsOPTIONAL}--
有關(guān)證書發(fā)布的屬性信息
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}--
至少存在一個(gè)
Time::=CHOICE{
utcTimeUTCTime,
generalTimeGeneralizedTime}
6Controls
語法
證書請(qǐng)求的產(chǎn)生可以包括一個(gè)或多個(gè)有關(guān)請(qǐng)求過程的控制值。
Controls::=SEQUENCESIZE(1..MAX)OFAttributeTypeAndValue
以下的控制被定義為：
regToken
，
authenticator
，
pkiPublicationInfo
，
pkiArchiveOptions
，
oldCertID
，
protocolEncrKey
（這些項(xiàng)被認(rèn)為可以超時(shí)擴(kuò)展）。
6
．
1
注冊(cè)號(hào)（
RegistrationToken
）控制
regToken
控制包含以前的信息（或是基于秘密的評(píng)估或是基于了解的信息），這些信息
往往被
CA
用于在頒發(fā)證書前驗(yàn)證請(qǐng)求者身份。一收到包含
regToken
的證書請(qǐng)求，
CA
就驗(yàn)
證這些信息，以便確認(rèn)在證書請(qǐng)求中的聲稱的身份。
RegToken
可以被
CA
生成，并在帶外提供給訂戶，或者對(duì)
CA
和訂戶都可用。任何帶
外的交換的安全性應(yīng)該足夠應(yīng)付如
CA
接受了某人的干擾信息而沒有接受原本訂戶的信息
這樣的冒險(xiǎn)。
RegToken
控制將典型的僅被用于終端實(shí)體進(jìn)入
PKI
的初始化上，而
authenticator
控制
（見
6
．
2
節(jié)）將不僅用于初始化，而且將用于接下來的證書請(qǐng)求上。
在一些使用例子中，
regToken
可能是一個(gè)文本字符串或是一個(gè)數(shù)，如隨機(jī)數(shù)。這個(gè)值接
下來能被作為二進(jìn)制數(shù)或是一個(gè)二進(jìn)制數(shù)的字符串表示來編碼。不管數(shù)的屬性，為了確保值
的統(tǒng)一的編碼，
regToken
的編碼將用
UTF8
。
6
．
2
鑒定者（
Authenticator
）控制
Authenticator
控制包含一些用于行為基礎(chǔ)的信息，這些信息用來在和
CA
交流中產(chǎn)生非
密碼的身份檢查。例子有：母親未婚時(shí)的名字，社會(huì)安全號(hào)的最后
4
個(gè)數(shù)字，或其他和訂戶
的
CA
共享的
知識(shí)
信息；這些信息的散列；或其他用于該目的的信息。
Authenticator
控制值
可由
CA
或訂戶生成。
在一些使用例子中，
Authenticator
可能是一個(gè)文本字符串或是一個(gè)數(shù)，如隨機(jī)數(shù)。這個(gè)
值接下來能被作為二進(jìn)制數(shù)或是一個(gè)二進(jìn)制數(shù)的字符串表示來編碼。不管數(shù)的屬性，為了確
保值的統(tǒng)一的編碼，
Authenticator
的編碼將用
UTF8
。
6
．
3
頒發(fā)信息（
PublicationInformation
）控制
pkiPublicationInfo
控制使訂戶可以控制
CA
證書的發(fā)布。它被定義為如下語法：
PKIPublicationInfo::=SEQUENCE{
actionINTEGER{
dontPublish(0),
pleasePublish(1)},
pubInfosSEQUENCESIZE(1..MAX)OFSinglePubInfoOPTIONAL}
--
如果
action
是
"dontPublish"
，
pubInfos
必須不存在。
--(
如果
action
是
"pleasePublish"
，并且
pubInfos
被刪除，
--action
被設(shè)為
"dontCare"
。）
SinglePubInfo::=SEQUENCE{
pubMethodINTEGER{
dontCare(0),
x500(1),
web(2),
ldap(3)},
pubLocationGeneralNameOPTIONAL}
如果選擇
dontPublish
項(xiàng)，請(qǐng)求者指示
PKI
不要發(fā)布證書（這表示請(qǐng)求者要自己發(fā)布證
書）。
如果選擇
dontCare
項(xiàng)，或者如果
PKIPublicationInfo
控制被從請(qǐng)求中刪除，請(qǐng)求者指示
PKI
可以用任何它選擇的方法發(fā)布證書。
如果請(qǐng)求者除了希望
CA
能夠在其他存放處使證書有效，還希望證書至少出現(xiàn)在一些地
方，那就要為
pubInfos
設(shè)置兩個(gè)
SinglePubInfo
值，一個(gè)是
x500
、
web
或
ldap
，另一個(gè)是
dontCare
。
如果
pubLocation
被用的話，此項(xiàng)表示請(qǐng)求者愿意證書在這些地方被發(fā)現(xiàn)（注意，
GeneralName
可包括例如
URL
和
IP
地址等）。
6
．
4
文檔選項(xiàng)（
ArchiveOptions
）控制
pkiArchiveOptions
控制使訂戶能夠應(yīng)用這樣的信息，這些信息用于建立一個(gè)對(duì)應(yīng)于證書
請(qǐng)求公鑰的私鑰的文檔。它的語法定義如下：
PKIArchiveOptions::=CHOICE{
encryptedPrivKey[0]EncryptedKey,
--
私鑰的實(shí)際值
keyGenParameters[1]KeyGenParameters,
--
使私鑰能夠重新生成的參數(shù)
archiveRemGenPrivKey[2]BOOLEAN}
--
如果
sender
希望
receiver
保存
receiver
對(duì)應(yīng)請(qǐng)求所生成的密鑰對(duì)中的私鑰，則設(shè)為
真。
--
如果不要被保存，則設(shè)為假。
EncryptedKey::=CHOICE{
encryptedValueEncryptedValue,
envelopedData[0]EnvelopedData}
--
加密私鑰必須被放在
envelopedData
中
EncryptedValue::=SEQUENCE{
intendedAlg[0]AlgorithmIdentifierOPTIONAL,
--
被加密的值被使用的意指的算法
symmAlg[1]AlgorithmIdentifierOPTIONAL,
--
用于加密值的對(duì)稱算法
encSymmKey[2]BITSTRINGOPTIONAL,
--
用于加密值的對(duì)稱密鑰（已加密）
keyAlg[3]AlgorithmIdentifierOPTIONAL,
--
用于加密對(duì)稱密鑰的算法
valueHint[4]OCTETSTRINGOPTIONAL,
--
一個(gè)有關(guān)
encValue
內(nèi)容的簡(jiǎn)單的描述或標(biāo)識(shí)符（它可能只對(duì)發(fā)送終端有意義，
--
并且只有
EncryptedValue
以后可以被發(fā)送終端重新檢驗(yàn)，它才可以用）
encValueBITSTRING}
KeyGenParameters::=OCTETSTRING
一種發(fā)送密鑰的選擇是發(fā)送有關(guān)如何使用
KeyGenParameters
選項(xiàng)重新產(chǎn)生密鑰的信息
（例如，對(duì)許多
RSA
實(shí)行來說，可以發(fā)送第一個(gè)最初測(cè)試的隨機(jī)數(shù)）。對(duì)于這個(gè)參數(shù)的實(shí)際
的語法可以定義在這個(gè)文檔的接下來版本中，或定義在另一個(gè)標(biāo)準(zhǔn)中。
6
．
5
舊證書
ID
（
OldCertID
）控制
如此項(xiàng)存在，則
OldCertID
詳述了被當(dāng)前證書請(qǐng)求所更新的證書。其語法為：
CertId::=SEQUENCE{
issuerGeneralName,
serialNumberINTEGER
}
6
．
6協(xié)議
加密密鑰（
ProtocolEncryptionKey
）控制
如此項(xiàng)存在，則
protocolEncrKey
詳述了一個(gè)
CA
用于加密對(duì)
CertReqMessages
的回答的
密鑰。此項(xiàng)能被用于當(dāng)
CA
有發(fā)送給訂戶的需要加密的信息。這些信息中包括一個(gè)由
CA
生
成的讓訂戶使用的私鑰。
protocolEncrKey
的編碼應(yīng)為
SubjectPublicKeyInfo
。
7
對(duì)象標(biāo)識(shí)符（
ObjectIdentifiers
）
id-pkix
的對(duì)象標(biāo)識(shí)符為：
id-pkixOBJECTIDENTIFIER::={iso(1)identified-organization(3)
dod(6)internet(1)security(5)mechanisms(5)pkix(7)}
--
用于
InternetX.509PKI協(xié)議
及其組件的部分
id-pkipOBJECTIDENTIFIER::{id-pkixpkip(5)}
--
在
CRMF
中的注冊(cè)登記控制（
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
中的注冊(cè)信息（
RegistrationInfo
）
id-regInfoOBJECTIDENTIFIER::={id-pkipid-regInfo(2)}
id-regInfo-asciiPairsOBJECTIDENTIFIER::={id-regInfo1}
--
使用
OCTETSTRING
id-regInfo-certReqOBJECTIDENTIFIER::={id-regInfo2}
--
使用
CertRequest
8
對(duì)于安全的考慮
CRMF
傳送的安全性是基于
協(xié)議
或用于和
CA
通信的進(jìn)程的安全結(jié)構(gòu)。這些
協(xié)議
或進(jìn)程
需要確保完整性，數(shù)據(jù)來源的真實(shí)性和信息的隱私。如果一個(gè)
CRMF
包括敏感的訂戶信息，
并且
CA
有一個(gè)終端實(shí)體所知的加密證書，那么強(qiáng)烈建議使用
CRMF
加密。
9
參考
[HMAC]Krawczyk
，
H.
，
Bellare
，
M.
和
R.Canetti
，
"HMAC:Keyed-HashingforMessage
Authentication"
（
“HMAC
：為了保證信息真實(shí)性的密鑰
Hash
散列
”
），
RFC2104,1997.2
。
10
謝辭
作者非常感謝
BarbaraFox
，
WarwickFord
，
RussHousley
和
JohnPawling
所做的貢獻(xiàn)。
他們的復(fù)審和建議進(jìn)一步闡明和改善了本篇的實(shí)用功能。
附錄
A
．構(gòu)造
dhMAC
本附錄描述了計(jì)算
Diffie-Hellman
證書請(qǐng)求的
POPOPrivKey
結(jié)構(gòu)中的
dhMAC
位串的方
法。
1
終端產(chǎn)生一個(gè)
DH
公
/
私鑰對(duì)
用于計(jì)算公鑰的
DH
參數(shù)被詳述在
CA
的
DH
證書中。
從
CA
的
DH
證書中，
CApub=g^xmodp
，這里
g
，
p
是已有的
DH
參數(shù)，而
x
是
CA
私有的
DH
組件。
對(duì)終端
E
來說，
DHprivatevalue=y
，
Epub=DHpublicvalue=g^ymodp
。
2MAC
進(jìn)程有以下步驟組成
a
）
certReq
項(xiàng)的值用
DER
編碼，產(chǎn)生一個(gè)二進(jìn)制串。這就是在
[HMAC]
中提
到的
‘text’
，它是
HMAC-SHA1
算法所應(yīng)用的數(shù)據(jù)。
b
）
計(jì)算共享的
DHsecret
，如下所示：
sharedsecret=Kec=g^xymodp
。終端
E
計(jì)算
CApub^y
，
CApub
是來自于
CA
的
DH
證書；
CA
計(jì)算
Epub^x
，
Epub
是來自
于證書請(qǐng)求。
c
）
密鑰
K
來自于
Kec
，證書請(qǐng)求者名稱，證書頒發(fā)者名稱。如下所示：
K=
SHA1(DER-encoded-subjectName|Kec|DER-encoded-issuerName)
，這里
‘|’
的意
思是級(jí)連。如果在
CA
證書中
subjectName
為空，則替代使用
DER-encoded-subjectAltName
。如果
CA
證書中
issuerName
為空，則替代使用
DER-encoded-issuerAltName
。
d
）
按照
RFC2104
來用數(shù)據(jù)
'text'
計(jì)算
HMAC-SHA1
，
SHA1(KXORopad,SHA1(K
ORipad,text))
，此處
opad=0x36
重復(fù)
64
次，
ipad=0x5C
重復(fù)
64
次。也就是
說，
（
1
）
在
K
的末端填充
0
，來生成一個(gè)
64
字節(jié)的串（例如，若
K
為
16
字節(jié)長(zhǎng)，
就要填充
48
個(gè)
0
字節(jié)）。
（
2
）
XOR
（異或）第
1
步生成的
64
字節(jié)
K
和
ipad
。
（
3
）
把
‘text’
加到第
2
步生成的
64
字節(jié)串上。
（
4
）
對(duì)第
3
步生成的字節(jié)串應(yīng)用
SHA1
算法。
（
5
）
XOR
第
1
步生成的
64
字節(jié)
K
和
opad
。
（
6
）
把第
4
步中
SHA1
生成的結(jié)果加到第
5
步生成的
64
字節(jié)串上。
（
7
）
使用
SHA1
算法計(jì)算第
6
步中的產(chǎn)生值，最后輸出結(jié)果。
例子代碼在
RFC2104,RFC2202
中有。
e
）
d
）的輸出被編碼為位串（
"dhMAC")
。
3
驗(yàn)證擁有私鑰（
proof-of-possession
）的進(jìn)程需要
CA
執(zhí)行
執(zhí)行從
a
）到
d
），然后比較
d
）步的結(jié)果和
CA
收到的
"dhMAC"
值。如果它們匹配，則
有如下結(jié)論：
1
）
終端擁有與證書請(qǐng)求中的公鑰對(duì)應(yīng)的私鑰（因?yàn)榻K端需要私鑰來計(jì)算
sharedsecret
）。
2
）
只有
CA
能驗(yàn)證請(qǐng)求（
CA
需要自己的私鑰來計(jì)算同樣的
sharedsecret
）。這有助于防止
CA
受騙。
參考文獻(xiàn)
[RFC2104]Krawczyk,H.,Bellare,M.andR.Canetti,"HMAC:Keyed
HashingforMessageAuthentication",RFC2104,February
1997.
[RFC2202]Cheng,P.andR.Glenn,"TestCasesforHMAC-MD5andHMAC-
SHA-1",RFC2202,September1997.
謝詞
此附錄的細(xì)節(jié)由
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
?
?