簽署數據並附加證書 VS 簽署數據和證書
我目前正在寫我的碩士論文，我需要為應用程序開發一個許可模組。
許可證本身是使用 RSA 私鑰簽名的JSON Web 令牌。
由於我們要求經銷商也應該能夠創建和簽署有效許可證，因此我考慮使用我的公司擁有根 CA 並為每個經銷商創建中間證書的 PKI（以便他們可以簽署他們的許可證）。根證書將成為最終二進製文件的一部分（在該二進製文件中“隱藏”根證書是完全不同的故事）。為了讓應用程序驗證許可證，它需要檢查許可證的簽名並需要驗證整個證書鏈 - 這意味著證書鏈（當然根證書除外）需要成為許可證的一部分。
對於我的實際問題：我應該
- 僅簽署 JSON Web 令牌，然後將證書鏈附加到許可證或
- 將證書鏈包含到 JSON Web 令牌中，然後完全簽署所有內容？
我已經閱讀了一些文章說不應該散列秘密/通過一些討論MAC-then-encrypt 與 encrypt-then-MAC 的文章，但它們都不能應用於我的問題（因為沒有秘密，也不涉及加密）。
即使我是否只簽署 JWT 或兩者的組合（JWT + 證書鏈）沒有區別，我也需要提供一些支持和解釋最終決定的論據。
假設您使用的是標準 PKI 證書標準，而不是採用自己的方法，那麼將證書鏈包含在簽名所涵蓋的 JWT 中並沒有真正的安全優勢。
每個（非根）證書都由頒發證書籤名。所以它已經被一個可以追溯到你的根證書的簽名所覆蓋。在 JWT 中再次簽名不會提供任何額外的保護。
在 JWT 的簽名部分中包含證書鏈，我也看不到任何特定的安全風險。存在簽名以證明已知消息的真實性。因此，當簽名文本已知時，必須是安全的。因此，包含已知證書鏈不會引入任何特定風險。
因此，您確實需要從其他應用程序設計考慮因素中做出決定。
在 JWT 中包含證書鏈有一個優勢，我可以看到，您可以使用標準庫解析消息，而不必對其進行預處理。
然而，在大多數情況下，將證書鏈包含在 JWT 中的缺點會大大超過這些缺點：
- 您簽署的內容比您需要的多得多，因此浪費了一些 CPU
- 您無法將令牌與證書鏈分開。這可能會降低應用程序設計的靈活性。
E隨著時間的推移，您可能希望能夠僅在您知道證書鏈已被處理的應用程序部分處理許可證，或者允許動態解析它。通過將證書鏈排除在已簽名的 JWT 之外，您可以更輕鬆地將這兩個問題分開，由應用程序的不同部分處理。
如果您將來想對令牌進行加密而不僅僅是對其進行簽名，這也將有所幫助。通過保持證書鏈分開，您可以在解密和檢查令牌之前使用它，這將更容易設置驗證常式。