此備忘錄的狀況
此文檔為因特網社區具體描述了一個因特網標準途徑協議，并且請求改善的討論和建
議。為了確保此協議的標準化狀態，請參考當前版本的因特網官方協議標準（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-subjectNameKecDER-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,::=andhavetheirusualBNFmeanings,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

END

FullCopyrightStatement

Copyright(C)TheInternetSociety(1999).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.