8.6 交叉認證

請求者CA作為交叉證書的主體，而響應者CA作為交叉證書的發布者。

請求者CA在發起交叉認證操作之前必須已建立并在運行中。

交叉認證方案基本上是單向的操作；也就是說，當成功時，這個操作會導致一個新的交叉證書的產生。如果需要產生“雙向”的交叉證書，那么每一個CA都要發起一個交叉認證操作（或者使用另一種方案）。

這個方案適合于下面兩種情況：兩個CA已經驗證過對方的簽名（它們有共同的信任點）；或者能對認證請求起源進行帶外驗證。詳細描述：

交叉認證由作為響應者的CA發起。作為響應者的CA管理員鑒別它想交叉認證的CA，同時由響應者CA設備產生授權碼。響應者的CA管理員用帶外方法把授權碼傳遞給請求者的CA管理員。請求者的CA管理員在請求者CA處輸入授權碼來發起在線交換。

授權碼用于認證和完整性目的驗證。它是這樣實現的：利用授權碼產生對稱密鑰，然后使用此對稱密鑰對所有的交換消息產生消息認證碼（MAC）。（如果CA可以通過某些方法檢索和驗證請求的公鑰，那么認證也可以通過使用簽名來代替MAC。）

請求者CA用一個新的隨機數（請求者隨機數）產生交叉認證請求（ccr）以發起交換。然后，請求者CA給響應者CA發送ccr消息。消息字段使用基于認證碼的MAC來防止修改。

收到ccr消息之后，響應者CA驗證消息和MAC，保存請求者隨機數，并且產生自己的隨機數（響應者隨機數）。然后產生（如果需要就存檔）一個新的包含請求者CA公鑰的請求者證書，同時用響應者CA簽名私鑰進行簽名。響應者CA用交叉認證響應（ccp）消息進行響應。消息中的字段使用基于認證碼的MAC來防止修改。

收到ccp消息之后，請求者CA驗證消息（包括收到的隨機數）和MAC。請求者CA用certConf消息進行響應。消息中的字段使用基于認證碼的MAC來防止修改。請求者CA把請求者的該（交叉認證）證書寫入證書庫為今后的證書路徑構建提供幫助。

收到certConf消息之后，響應者CA驗證消息和MAC，同時使用PKIConfirm消息發回一個確認。它也會公布請求者的（交叉認證）證書為今后路徑構建提供幫助。

ccr消息必須包含一個“完整”的認證請求，也就是說，請求者CA必須規定好除了序列號的所有的字段（包括，例如：BasicConstraints擴展）。ccp消息應該包含響應者CA的驗證證書－如果存在，請求者CA必須驗證這個證書（例如，通過帶外機制）。

可以設想一種更為簡單的非交互式的交叉認證模型，在這個模型中發布者CA從證書庫中獲得主體CA的公鑰，并通過帶外機制進行驗證，然后產生和公布交叉證書而不需要主體CA的參與。在很多環境中這個模型是非常合理的，但是因為它不需要任何協議消息交換，所以詳細描述不在本標準的范圍之內。

交叉認證的消息結構見附錄C。