本文引自：
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
?
?