7.2 公共數據結構

在定義PKIBody中的特定類型之前，我們先定義一些多處使用的數據結構。

7.2.1　被申請的證書內容

各種PKI管理消息都要求消息的發起者指明證書里存放的某些字段的值。CertTemplate結構體使得EE或者RA可以盡可能地指定它們所希望申請到的證書里的內容。CertTemplate結構體與證書的內容完全一致，但所有的字段都是可選的。

00001注： 即使消息的發起者指明了它所申請的證書的所有內容，CA機構仍然可以自由改動實際發放的證書的字段值。如果申請者不能接受被修改后的證書，那么申請者必須回送一個certConf消息，其中或者不包括該證書（通過一個CertHash），或者包含該證書（通過一個CertHash）但同時狀態置為“rejected”。CertHash和certConf消息的定義以及使用參見7.3.18。

CertTemplate語法見附錄D及RFC2511。

7.2.2　加密值

在PKI消息中發送加密值（在本標準中，加密值限于私鑰或者證書）時采用EncryptedValue數據結構。

EncryptedValue的語法見RFC2511。

使用該數據結構要求創建者和期望的接收者分別都能夠進行加密和解密操作。典型情況下，這意味著發送者和接收者擁有，或者能夠產生共享的秘密密鑰。

如果PKIMessage的接收者已經擁有用于解密的私鑰，則encSymmKey字段可以包含用接收者的公鑰加密的會話密鑰（session key）。

7.2.3　PKI消息的狀態編碼和失敗信息

所有的響應消息都包含某些狀態信息。下面定義了相應的值：

PKIStatus ::= INTEGER {

accepted (0),

– 表示得到了所要求的數據

grantedWithMods (1),

– 得到的數據與所要求的類似，但申請者有責任確定有無差別

rejection (2),

– 無法得到的數據，在該消息的其它地方有更多的信息

waiting (3),

– 請求的包體尚未被處理，期望稍后將獲取結果（注意：對具有該狀態的響應，恰當的處理方式– 可以是使用3.3.22中定義的輪詢請求/響應PKIMessages；使用底層的傳輸層輪詢機制也是一種– 可行的方法

revocationWarning (4),

– 本消息包含一個即將作廢的警告信息

revocationNotification (5),

– 通知已經作廢

keyUpdateWarning (6)

– 在密鑰更新請求消息中oldCertId指示的密鑰已經更新

}

響應者可以使用下列語法以提供有關失敗狀況的更多信息。

PKIFailureInfo ::= BIT STRING {

– 因為多種情況可能導致失敗，所以在需要時可以加入更多的代碼

badAlg (0),

– 不可識別或者不支持的算法標識符

badMessageCheck (1),

– 完整性檢查失敗（例如，簽名驗證不成功）

badRequest (2),

– 不允許或不支持的交易

badTime (3),

– 根據本地策略，請求中的messageTime與系統時間不夠接近

badCertId (4),

– 無法找到與提供的條件匹配的證書

badDataFormat (5),

– 提交的數據格式錯誤

wrongAuthority (6),

– 請求中指明的權威機構與本響應的創建者不同

incorrectData (7),

– 申請者的數據錯誤 (用于公證服務)

missingTimeStamp (8),

– 在要求存在時戳的時候沒有提供（根據策略要求）

badPOP (9),

– 擁有證明失敗

}

PKIStatusInfo ::= SEQUENCE {

status PKIStatus,

statusString PKIFreeText OPTIONAL,

failInfo PKIFailureInfo OPTIONAL

}

7.2.4　證書標識

CertId數據結構用于鑒別特定的證書。

CertId的語法見RFC2511。

7.2.5　“帶外”根證書公鑰

每個根CA必須能夠通過一些“帶外”方式來發布它的當前公鑰。雖然這樣的方法不在本文描述的范圍之內，我們定義了支持這種方法的數據結構。

一般而言，有兩種可能的方法：CA機構直接發布它的自簽名證書；或者可以通過目錄服務器（或其它類似方式）獲得自簽名證書，同時CA發布自簽名證書的哈希值用于（由使用者）在使用（CA證書）之前進行完整性校驗。

OOBCert ::= Certificate

該證書中的值域有如下限制：

—— 證書必須是自簽名的(即，簽名必須可以用SubjectPublicKeyInfo中的值來驗證)；

—— 主體字段和簽發者字段的值必須完全相同；

—— 如果主體字段為空，則主體可替換名和簽發者可替換名擴展項必須同時存在，并且具有完全相同的值；

—— 所有其它擴展項的值必須符合自簽名證書的要求（比如，主體和簽發者的密鑰標識符必須完全相同）。

OOBCertHash ::= SEQUENCE {

hashAlg [0] AlgorithmIdentifier OPTIONAL,

certId [1] CertId OPTIONAL,

hashVal BIT STRING

– hashVal是對由certID所標識的自簽名證書進行運算得出的值

}

散列（哈希）值的目的在于：任何（通過帶外方式）安全獲取到散列（哈希）值的用戶都能驗證該CA的自簽名證書。

7.2.6　歸檔選項

請求者可以用PKIArchiveOptions結構體來指明它們希望PKI歸檔某私鑰。

PKIArchiveOptions的語法見RFC2511。

7.2.7　發布信息

請求者可以用PKIPublicationInfo結構體來指明它們希望PKI發布證書。

PKIPublicationInfo的語法見RFC2511。

7.2.8　擁有證明結構體

如果是為簽名密鑰對申請證書（即申請一個驗證證書），則可以使用POPOSigningKey結構體來證明對簽名私鑰的擁有。

POPOSigningKey的語法見附錄D及RFC2511，但注意本標準中POPOSigningKeyInput存在下面的語義約定：

POPOSigningKeyInput ::= SEQUENCE {

authInfo CHOICE {

sender [0] GeneralName,

– 取自PKIHeader (僅當發送者的身份鑒別已通過某種方式（如以前發布的、當前處于有效狀態的– 證書中的DN）建立之后使用)

publicKeyMAC PKMACValue

– 發送者當前沒有已鑒別通過的通用名（GeneralName）存在時使用；publicKeyMAC包含一個基于– 口令的針對公鑰的DER編碼的MAC值(使用PKIHeader 中的protectionAlg算法標識)

},

publicKey SubjectPublicKeyInfo

– 取自CertTemplate

}

另一方面，如果為加密密鑰對申請證書（即申請一個加密證書），則可以使用下列三種方式之一來證明對解密私鑰的擁有。

a) 通過在證書請求中包含加密后的私鑰（在PKIArchiveOptions控制結構體中）。

b) CA不直接返回證書，而是返回加密后的證書（即，返回的證書用一個隨機產生的對稱密鑰加密，而對稱密鑰本身用證書請求中包含的公鑰來加密）—— 這是6.3.2中提到的“間接”方式。終端實體通過使用源自該對稱密鑰的密鑰計算PKIConfirm消息的MAC值，來向CA機構證明它擁有解密私鑰。（當PKIMessage 消息中包含不止一個CertReqMsg證書請求，并且每個CertReqMsg使用不同的對稱密鑰時，MAC計算使用源自所有這些對稱密鑰的一個密鑰。）計算MAC的操作使用7.1定義的PasswordBasedMac AlgId。

c) 讓EE在CertReqMessages和CertRepMessage 之間參與挑戰－響應協議（使POPODecKeyChall和POPODecKeyResp消息；參照下文）—— 這是6.3.2中提到的“直接”方式。（這種方式典型的應用環境是RA驗證POP，然后代表終端實體向CA發送認證請求。在這種情況下，CA相信RA在為終端實體申請證書之前已經正確地驗證了POP。）完整地協議如下所示（注意req’不一定要將req封裝為嵌套消息）：

        EE            RA            CA

         ---- req ---->

         <--- chall ---

         ---- resp --->

                        ---- req' --->

                        <--- rep -----

                        ---- conf --->

                        <--- ack -----

         <--- rep -----

         ---- conf --->

         <--- ack -----

這一協議顯然比前面的方式2中給定的3次交換要長，但它允許本地注冊機構（LRA）介入，并使得POP驗證通過之前并不真正生成證書。

如果為密鑰協商密鑰對（KAK）申請證書，則POP的驗證可以使用對加密密鑰對驗證的三種方式中的任何一種，但要做下列變化： (1) 前面描述的第二種方式中的括號中的文本變為：（即，證書由根據CA的KAK私鑰和認證請求中的公鑰生成的對稱密鑰加密）； (2)下面Challenge結構描述中的challenge字段的第一個括號中的文本改為：（使用PreferredSymmAlg（見7.3.19.4）和一個對稱密鑰，該密鑰基于CA的KAK私鑰和認證請求中的公鑰而產生）。此外，如果CA已經擁有一個為終端實體所知的D-H證書，POP可以使用RFC2511中定義的POPOSigningKey結構體(其中，alg 字段取值為DHBasedMAC，簽名字段取值為MAC)作為證明POP的第四種方式。

用于解密私鑰POP的挑戰－響應消息定義如下。注意，挑戰－響應交換通過PKIHeader中的transactionID以及對PKIMessage的保護（MAC或簽名）與前面的認證請求消息（以及后續的認證響應和確認消息）相關聯。

POPODecKeyChallContent ::= SEQUENCE OF Challenge

– 每個加密密鑰認證請求對應一個Challenge（次序與請求出現在CertReqMessages中的次序保持– 一致）

Challenge ::= SEQUENCE {

owf AlgorithmIdentifier OPTIONAL,

– 在第一個Challenge中必須存在；而在POPODecKeyChallContent隨后的Challenge中可以省略

–（如果省略的話，則使用前一個Challenge中的owf字段。）

witness OCTET STRING,

– 對隨機產生的整數A應用單向函數(owf)的結果。注意每個Challenge都必須使用不同的整數

challenge OCTET STRING

– 加密后的Rand（使用認證請求中的公鑰加密），Rand定義如下

– Rand ::= SEQUENCE {

– int INTEGER,

– 上面提到的隨機產生的整數A

– sender GeneralName

– 發送者的名稱(與PKIHeader中的相同)

– }

}

POPODecKeyRespContent ::= SEQUENCE OF INTEGER

– 每個加密密鑰認證請求對應一個整數 (這些整數的順序與請求出現在CertReqMessages中的順– 序保持一致)。收到的整數（上面提到的A）被返回給相應Challenge的發送者