7.1 PKI消息綜述
本標準中所有用于PKI管理的消息都采用下面的結構:
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
}
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
PKIHeader包含許多PKI消息公有的信息。
PKIBody包含與具體消息相關的信息。
PKIProtection字段是可選的,包含對PKI消息進行保護的比特串。
extraCerts字段可以包含對接收者來說可能有用的證書。例如,CA或RA可以利用這一字段向終端實體提供它驗證自己的新證書時所需要的證書(例如,如果簽發終端實體證書的CA對它來說不是一個根CA)。注意,這個字段不一定包含一個證書鏈 —— 為了使用證書,接收者可能需要對這些證書進行分類、選擇或其它處理。
7.1.1 PKI消息頭
所有的PKI消息都要求使用消息頭的某些信息進行尋址和交易標識。某些同樣信息也出現在與傳輸相關的信封中。不管采用哪種方法,只要PKI消息受到保護,這些信息就會同樣受到保護。
下面的數據結構用于保存這些信息:
PKIHeader ::= SEQUENCE {
pvno INTEGER { cmp1999(1), cmp2000(2) },
sender GeneralName,
-- 標識發送者
recipient GeneralName,
-- 標識預期的接收者
messageTime [0] GeneralizedTime OPTIONAL,
-- 產生這個消息的時間(當發送者認為該時間的傳輸合適時使用
-- 即接收方接收到消息時這個時間仍有意義)
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- 用于計算protection比特的算法
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- 標識用于保護的特定密鑰
transactionID [4] OCTET STRING OPTIONAL,
-- 標識交易;即在相關的請求、響應和確認消息中,該字段值相同
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- 用于防止重放攻擊的隨機數,senderNonce由消息的創建者賦值
-- recipNonce是由本消息的預期接收者先前插入到相關消息中的隨
-- 機數
freeText [7] PKIFreeText OPTIONAL,
-- 可以用于表示上下文相關的說明(本字段主要由人工使用)
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- 可以用于表示上下文相關的說明(本字段不是供人工使用的)
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
– 按UTF-8[RFC2279]編碼的文本(注意:每一個UTF8String都可以包含
-- 一個RFC 1766/RFC 3066語言標簽,用于表示所包含文本屬于哪一種語言
– 詳情請參見RFC2482
對于該版本pvno字段取固定值2。
sender字段包含PKIMessage發送者的名字。這個名字(與senderKID一起,如果提供的話)應當能夠標識出對這一消息的保護進行驗證所需要的密鑰。如果發送方實體并不清楚自己的任何信息(例如:在初始化請求消息中,終端實體并不清楚自己的DN、電子郵件、IP地址等),那么”sender”字段必須包含一個”NULL”值;即一個長度為0的SEQUENCE OF。在這種情況下,senderKID字段必須包含一個標識符(即一個參考數),這個標識符能夠向接收者表明驗證消息所用的共享密鑰信息。
recipient字段包含PKIMessage接收者的名字。這個名字(與recipKID一起,如果提供的話)應當可以用于驗證對消息的保護。
protectionAlg字段指明保護消息所用的算法。如果沒有提供保護比特位(注意PKIProtection是可選的),那么必須省略這個字段;如果提供了比特位,那么必須提供這個字段。
senderKID和recipKID用于標識使用了哪個密鑰保護消息(recipKID通常僅在使用Diffie-Hellman密鑰保護消息時才要求)。如果要求唯一標識一個密鑰就必須使用這些字段(例如:如果一個發送者的名字與多個密鑰相關聯),否則就應當省略這些字段。
transactionID字段用于使消息的接收者將這個消息與以前簽發請求相關聯。比如對于RA,transactionID可以將某消息與同一時刻眾多消息區分開來。
senderNonce和recipNonce字段保護PKIMessage免受重放攻擊。
messageTime字段包含發送者創建這個消息的時間。可以由終端實體用于校正/檢查自己的本地時間以便與中央系統的時間保持一致。
freeText字段可以用于發送一個人可讀的消息給接收者(用任意多種語言)。這個序列中的第一種語言表明響應期望使用的語言。
generalInfo字段可以用于向接收方發送機器可讀的額外的數據。可以支持下面定義的generalInfo擴展項。
7.1.2 PKI消息體
PKIBody ::= CHOICE { – 與消息類型相關的消息體和參考章條
ir [0] CertReqMessages, –初始化請求(7.3.1)
ip [1] CertRepMessage, –初始化響應(7.3.2)
cr [2] CertReqMessages, –認證請求(7.3.3)
cp [3] CertRepMessage, –認證響應(7.3.4)
p10cr [4] CertificationRequest, –PKCS #10認證請求[PKCS10]
popdecc [5] POPODecKeyChallContent –POP挑戰(7.2.8)
popdecr [6] POPODecKeyRespContent, –POP響應(7.2.8)
kur [7] CertReqMessages, –密鑰更新請求(7.3.5)
kup [8] CertRepMessage, –密鑰更新響應(7.3.6)
krr [9] CertReqMessages, –密鑰恢復請求(7.3.7)
krp [10] KeyRecRepContent, –密鑰恢復響應(7.3.8)
rr [11] RevReqContent, –作廢請求(7.3.9)
rp [12] RevRepContent, –作廢響應(7.3.10)
ccr [13] CertReqMessages, –交叉認證請求(7.3.11)
ccp [14] CertRepMessage, –交叉認證響應 (7.3.12)
ckuann [15] CAKeyUpdAnnContent, –CA密鑰更新公告(7.3.13)
cann [16] CertAnnContent, –證書公告(7.3.14)
rann [17] RevAnnContent, –作廢公告(7.3.15)
crlann [18] CRLAnnContent, –CRL公告(7.3.16)
pkiconf [19] PKIConfirmContent, –確認(7.3.17)
nested [20] NestedMessageContent, –嵌套消息(7.1.3)
genm [21] GenMsgContent, –通用消息(7.3.19)
genp [22] GenRepContent, –通用響應(7.3.20)
error [23] ErrorMsgContent, –錯誤消息(7.3.21)
certConf[24] CertConfirmContent, –證書確認(7.3.18)
pollReq [25] PollReqContent, –輪詢請求(7.3.22)
pollRep [26] PollRepContent –輪詢響應(7.3.22)
}
每一種類型將在7.3中描述。
7.1.3 PKI消息保護
某些PKI消息需要保護完整性。(注意,如果使用非對稱算法保護消息并且相應公鑰部分已經被認證,那么消息的來源也可以被證明。另一方面,如果公鑰部分未被認證,那么消息來源不能自動被證明,但可以通過帶外方式被認證。)
protection的結構如下:
PKIProtection ::= BIT STRING
計算PKIProtection時輸入的是下面數據結構的DER編碼:
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
在有些情況下,采用PKIX以外的其它保護方法保護消息,而不采用PKIProtection比特串(即省略這個可選的字段)。本標準允許選擇這種方法。這種外部保護的例子包括使用PKCS #7 [PKCS7]或Security Multiparts [RFC1847] 對PKIMessage封裝(當PKIHeader信息由外部機制安全的傳輸時,僅對省略CHOICE標簽的PKIBody進行封裝)。然而需要注意的是,許多這樣的外部機制要求終端實體已經擁有一個公鑰證書和/或一個唯一的DN和/或其它與基礎結構相關的信息。這樣,這些方法對于初始注冊、密鑰恢復或其它具有”初始引導”特性的過程來說就不合適。對這些情況,可能必須使用PKIProtection。將來,當修改后的外部機制可以適用于具有”初始引導”特性的場景時,PKIProtection將會變得很少或根本就不再使用。
根據環境不同,PKIProtection比特可以包含一個消息認證碼(MAC)或數字簽名。只有下面的幾種情況:
a) 共享密鑰信息
在這種情況下,發送方和接收方共享(通過帶外方法或前一個PKI管理操作建立的)密鑰信PKIProtection將包含一個MAC值,protectionAlg如下(參見附錄B):
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
–散列函數算法標識
iterationCount INTEGER,
– OWF的應用次數
mac AlgorithmIdentifier
– MAC算法標識
}
在上面的protectionAlg中,在共享密鑰的后面將追加上salt值。然后應用iterationCount 次OWF算法,其中,追加了salt值的密鑰作為第一次迭代的輸入,對后續的每一次迭代,其輸入都是前一次迭代的輸出。最后一次迭代的輸出(為了方便引用稱作”BASEKEY”,其長度為”H”)用于形成對稱密鑰。如果MAC算法要求一個K-比特的密鑰而且K <= H,那么密鑰就取BASEKEY的前K比特。如果K > H,那么BASEKEY的全部H比特將作為密鑰的前H比特,OWF(“1” || BASEKEY)所得結果將作為密鑰的下一H比特,OWF(“2” || BASEKEY) 所得結果將作為密鑰的再下一H比特,依此類推,直到得到所有的K比特為止。(這里,”N”代表數字N的ASCII字節編碼,”||”代表串聯。)
00001注: 建議PBMParameter字段在一個交易的所有消息中(例如ir/ip/certConf/pkiConf)保持不變,這樣可以降低計算PasswordBasedMac的負荷。
b) 非對稱密鑰對
使用非對稱密鑰算法進行消息保護,下面以DH算法為例說明:
當發送者和接收者擁有相容的DH參數的DH證書時,為了保護消息,終端實體必須基于自己的DH私鑰值和PKI消息接收方的DH公鑰值產生一個對稱密鑰。PKIProtection將包含由這個對稱密鑰計算出的MAC值,protectionAlg如下:
id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
– 散列函數算法ID
mac AlgorithmIdentifier
– MAC算法ID
}
在上面的protectionAlg中,對D-H計算的結果應用OWF。OWF的輸出(為了方便引用稱作”BASEKEY”,其長度為”H”)用于形成對稱密鑰。如果MAC算法要求一個K-比特的密鑰而且K <= H,那么密鑰就取BASEKEY的前K比特。如果K > H,那么BASEKEY的全部H比特將作為密鑰的前H比特,OWF(“1” || BASEKEY)所得結果將作為密鑰的下一H比特,OWF(“2” || BASEKEY) 所得結果將作為密鑰的再下一H比特,依此類推,直到得到所有的K比特為止。(這里,”N”代表數字N的ASCII字節編碼,”||”代表串聯。)
c) 簽名
在這種情況下,發送方擁有一個簽名密鑰對,對PKI消息進行簽名即可。PKIProtection將包含簽名值,protectionAlg為一種用于數字簽名的算法。
d) 多重保護
當終端實體發送一個保護的PKI消息到RA,RA可以追加自己的保護(可以是MAC或簽名,取決于RA和CA之間共享的信息和證書)后將消息轉發到CA。這種保護通過將終端實體發送的消息整個嵌套到一個新的PKI消息中實現。使用的結構如下:
NestedMessageContent ::= PKIMessages
推薦文章: