附錄E(資料性附錄) 使用“口令短語”
撤銷請求必須合并采用合適的安全機制,包括恰當的驗證,用于減少拒絕服務攻擊發生成功的可能性。對請求的數字簽名(本標準中在支持撤銷請求的情況下必須支持)能夠滿足驗證要求,但是在某些情況下需要有替代機制(例如,私鑰已經不能訪問,但是終端實體希望在重新認證另一個密鑰對之前請求撤銷)。為了滿足這些情況,在本標準中,如果支持撤銷請求并且在需要撤銷之前請求者和響應者之間可以建立共享的秘密信息,那么要求必須支持對請求的PasswordBasedMAC(以符合給定環境的本地安全策略)。
“Revocation Passphrase”是已經在某些環境中使用的一種機制,在這種機制中,一個足夠平均的值(例如,相對長的passphrase而不是短的password)在撤銷之前就在且僅在實體和CA/RA之間共享,并且在以后用于驗證撤銷請求。
在本標準中,是否支持下列用于建立共享秘密信息(例如,revocation passphrase)的技術是可選的。在CMP消息中的準確使用如下:
—— OID以及在7.3.19.9中指定的OID以及值可在任何時間在GenMsg消息中發送,或者也可以在任何時間任何一個PKIMessage的PKIHeader的generalInfo字段中發送。(特別地,EncryptedValue可以在certConf消息頭中發送EncryptedValue,certConf該消息是用于確認已經接受了在初始化請求和證書請求消息中所請求的證書。)這表明表示revocation passphrase由終端實體(例如即,encValue字段的解密后的字節)選擇給為相關的CA/RA選擇的revocation passphrase;另外,傳輸也使用適當的加密機制來完成秘密字符進行傳輸(因為passphrase使用CA/RA的protocolEncryptionKey加密)。
—— 如果CA/RA在GenMsg中接收到revocation passphrase(OID以及在7.3.19.9中指定的OID以及值),它必須構造并發送GenRep消息,這個消息包含了在7.3.19.9中指定OID(值為空)。如果CA/RA在任何一個PKIMessage的PKIHeader的generalInfo字段中接收到revocation passphrase,它必須包含在相應響應PKIMessage的PKIHeader的generalInfo字段中的包含該OID(值為空)。如果CA/RA由于某種原因不能返回適當的響應消息,那么它必須返回狀態為“rejection”的錯誤消息,同時可以給出選的一組failInfo原因 reason set。
—— EncryptedValue 的valueHint字段可以包含了一個密鑰標識符(由實體選擇,同時還帶有passphrase本身)用于幫助以后獲得對正確的passphrase的檢索(例如,當撤銷請求由實體構造并且由CA/RA接收)。
—— 撤銷請求消息用PasswordBasedMAC來保護,用revocation passphrase作為密鑰。如果合適的話,PKIHeader中的senderKID字段可以包含valueHint中的值。
使用以上技術,revocation passphrase可以在任何時候在不請求額外消息或者帶外交互的情況下進行初始化建立和更新,而不要求額外消息或帶外交互。例如,撤銷請求消息本身(通過使用revocation passphrase作為密鑰的MAC來保護和驗證,使用revocation passphrase作為密鑰)可以在PKIHeader中包含一個新的revocation passphrase以用于驗證以后對實體的其它證書的撤銷請求。在某些情況下,這種機制優于其它可能會在撤銷請求消息中顯示會暴露passphrase的機制,因為這可能會引起允許拒絕服務攻擊,所以在這種情況下顯示暴露的passphrase會被未授權的第三方用于驗證對實體別的證書的撤銷請求。然而,由于在請求消息中沒有顯示暴露passphrase,因此不要求在產生撤銷請求的時候總是更新passphrase(也就是說,在不同的時候對不同證書的撤銷請求的驗證可以使用同一個passphrase)。
另外,以上技術可以在不使用簽名的情況下依然對整個撤銷請求消息提供強加密保護。簡單顯示通過暴露revocation passphrase來驗證撤銷請求的技術不對請求消息的字段提供加密保護(因此請求撤銷一個證書的請求可能會被未授權的第三方修改,而請求撤銷該實體的另一個證書)。
推薦文章: