請求協議

傳統PKI 的 Owner 無法監督 CA 最大的問題在於無法取得有效證據，為此，

我們研究了違約證明協定(Proof of Violation, PoV)，在[19、20]兩篇論文中，PoV

原本是應用在雲端服務商與雲端服務使用者之間釐清責任歸屬的一套方法，透過

欄位說明，Operation 代表要進行的服務項目；PK 為 Public Key 代表 Owner

的PKI 公鑰；IndexValue 為憑證索引值，會放入Γ函式進行定位；CO 為 Clearence Order 的簡稱，代表 TP-Merkle Tree 的清算編號，是申訴的重要證據之一，後面 章節會詳細說明；H(Certificate)為憑證的雜湊值，代表此次互動要使用的憑證；

Status 代表憑證狀態。

接著根據Owner 對憑證相關需求，將基礎訊息擴充為三種不同請求協議，協

17

議中包含完整格式、互動的步驟，詳情如下所示。

第一段 申請憑證(Apply Certificate)

第一步：Owner 向 CA 發送一個 Apply Certificate 請求，簡稱𝐴𝐶𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}，格

式如下。

𝐴𝐶𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡} = (Apply | 𝑃𝐾_{𝑜𝑤𝑛𝑒𝑟} | Web IP | IndexValue | CO) Sign_Owner

* Web IP 代表要申請憑證的網站位址

第二步：CA 檢查𝐴𝐶𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}簽名是否正確

第三步：CA 檢查 Web IP 是否已註冊，若無註冊則產生新的數位憑證。

第四步：CA 使用 IndexValue 與Γ函式進行定位，再將 IndexValue 當作 Key、

憑證的雜湊值與狀態當作 Value，儲存到剛剛計算的 leaf node，

格式如下。

Key-Value pair = (IndexValue, H(Certificate) | Add) Sign_CA

第五步：CA 依據執行結果產生相應回條𝐴𝐶𝑀_{𝑟𝑒𝑝𝑙𝑦}，之後將回條以及憑證經 過簽名後回傳給 Owner，格式如下。

1. 𝐴𝐶𝑀_{𝑟𝑒𝑝𝑙𝑦} = (H(𝐴𝐶𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}) | H(Certificate) | Add ) Sign_CA

2. (Certificate)Sign_CA

18

第六步：Owner 檢查𝐴𝐶𝑀_{𝑟𝑒𝑝𝑙𝑦}簽名是否正確。

第七步：Owner 保存𝐴𝐶𝑀_{𝑟𝑒𝑝𝑙𝑦}，以用作之後進行申訴的證據。

第二段 變更狀態(Change Status)

此協定為Owner 進行憑證續約，或是想要暫停或撤銷憑證時使用，不過需要 注意的是，若要撤銷憑證，必須要先進入暫停狀態，代表Owner 必須執行兩次 Change Status 的請求，例如 Add  Pause  Revoked 或 Renew  Pause  Revoked。

第一步：Owner 向 CA 發送一個 Change Status 請求，簡稱𝐶𝑆𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}，格式

如下：

𝐶𝑆𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡} = (Change | Status |𝑃𝐾_{𝑜𝑤𝑛𝑒𝑟}| hash(certificate) | IndexValue | CO) Sign_Owner

第二步：CA 檢查𝐶𝑆𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}簽名是否正確。

第三步：CA 使用 IndexValue 計算定位，再到樹上相應位置檢查憑證及狀態 是否存在、正確。

第四步：CA 依據 Owner 填入得 Status，改變該憑證在 TP-Merkle Tree 上儲 存的狀態。

第五步：CA 依據執行結果產生相應回條𝐶𝑆𝑀_{𝑟𝑒𝑝𝑙𝑦}，之後將回條經過簽名後

19

回傳給 Owner，格式如下。

𝐶𝑆𝑀_{𝑟𝑒𝑝𝑙𝑦} = ( H(𝐶𝑆𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}) | Status ) Sign_CA

第六步：Owner 檢查𝐶𝑆𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}簽名是否正確

第七步：Owner 保存此回條，以用作之後進行申訴的證據。

第三段 更換金鑰(Replace Key)

若Owner 懷疑私鑰洩漏、或其他安全疑慮，可向 CA 提出更換 Public Key 的 請求。

第一步：Owner 向 CA 發送 Replace Key 請求，簡稱𝑅𝐾𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}，格式如下。

𝑅𝐾𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡} = ((Replace | 𝑃𝐾_{𝑜𝑤𝑛𝑒𝑟_𝑜𝑙𝑑} | 𝑃𝐾_{𝑜𝑤𝑛𝑒𝑟_𝑛𝑒𝑤}| hash(certificate) old | IndexValue | CO) Sign_Owner_old)Sign_Owner_old

* 𝑃𝐾_{𝑜𝑤𝑛𝑒𝑟_𝑜𝑙𝑑}代表原本的PK，𝑃𝐾_{𝑜𝑤𝑛𝑒𝑟_𝑛𝑒𝑤}代表要替換的PK，𝑅𝐾𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}必 需要使用新、舊兩把PK 都簽名過。

第二步：CA 檢查兩個簽名是否正確。

第三步：CA 使用 IndexValue 計算定位，再到樹上相應位置檢查憑證及狀態 是否存在、正確。

第四步：CA 使用新的 PK 建立新的數位憑證(certificate new)

20

第五步：CA 更新原本 TP-Merkle Tree 記錄的憑證雜湊值及狀態

第六步：CA 依據執行結果產生相應回條𝑅𝐾𝑀_{𝑟𝑒𝑝𝑙𝑦}，之後將回條及新的憑證

經過簽名後回傳給Owner，格式如下。

1. 𝑅𝐾𝑀_{𝑟𝑒𝑝𝑙𝑦} = ( H(𝑅𝐾𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}) | result | hash(certificate) new | Renew )Sign_CA

2. (Certificate new)Sign_CA

第七步：Owner 檢查𝑅𝐾𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}簽名是否正確。

第八步：Owner 保存此回條，以用作之後進行申訴的證據。