引言

數碼簽署演算法（Digital Signature Algorithm，通常簡稱 DSA）是一種用於證明私鑰持有者批准特定數碼訊息的密碼學方法。它不是電子簽名產品、視覺簽署影像或完整的協議流程。區分這一點很關鍵：數學上有效的簽署，本身並不能識別簽署人身份、證明同意已獲充分告知、保留審計記錄或保存已簽記錄。

本指南以通俗語言解釋 DSA，闡明其在現行美國聯邦標準下地位的變化，並展示企業團隊應如何評估數碼簽署周圍的流程。文章亦比較了 DocuSign、Adobe Acrobat Sign、Dropbox Sign 及 Nota Sign 作為協議流程方案，但並不暗示其中任一平台在內部使用 DSA。

DSA 的真實作用

DSA 使用公鑰對與訊息的雜湊。私鑰產生簽署值；對應的公鑰使另一方可對訊息核對該值。若訊息變更，驗證應失敗；若私鑰得到妥善管控，簽署便提供來源與完整性證據。

三個容易混淆的概念：

  • 數碼簽署演算法： 一種標準化的數學演算法，用於簽署產生與驗證。
  • 數碼簽署： 由已批准演算法與密鑰體系產出的密碼學簽署。
  • 電子簽名： 一種更廣泛地表達簽署意圖的方式，可能包括點擊、鍵入、繪製、身份驗證、審計記錄等證據。

協議平台可將電子簽署流程與證書支撐的數碼簽署結合，但商業結果遠不止演算法本身。身份核驗、密鑰保管、同意、時間戳記、證書狀態、審計記錄、文件交付、保存與日後再驗證都屬於管控設計的範疇。

FIPS 186-5 如何改變 DSA 的角色

現行 NIST Digital Signature Standard，FIPS 186-5 已不再批准 DSA 用於產生新的數碼簽署。它批准 RSA 與橢圓曲線方法用於新的簽署產生。在先前標準下產生的舊有 DSA 簽署仍可驗證，但須遵循適用的系統與政策。

這帶來直接的採購後果：新系統的設計不應僅因舊規範、程式庫或文件提及 DSA 而圍繞其建構。架構團隊應識別實際演算法與參數集、執行密碼操作的模組或服務、證書鏈、時間戳記模型及長期驗證要求。

對舊有系統而言，不能將「仍可驗證」誤讀為繼續產生 DSA 簽署的許可。應將遷移計劃拆為兩條線：保留歷史記錄的驗證能力，並將新簽署遷移至已批准的當代方法。

從演算法到可驗證的協議憑證

密碼學簽署只回答一個狹窄問題：該簽署對這條訊息與公鑰是否有效？商業糾紛通常提出更廣的問題：

  • 受邀方及身份建立方法；
  • 提交簽署人的確切文件與版本；
  • 表達意圖與同意的具體動作；
  • 各事件附帶的時間與地點證據；
  • 相關時點的證書有效性、撤銷狀態與過期情況；
  • 已簽記錄及其審計證據的日後檢索。

流程必須將上述答案綁定。穩健的設計記錄簽署人身份憑證、身份驗證事件、文件雜湊、時間戳記、欄位動作、同意信號、交付事件、適用的證書資訊，以及防篡改審計記錄。保存規則必須將已簽文件及其支援證據作為一份記錄包保存。

數碼簽署流程平台比較

本節比較的是數碼簽署周圍的證據流程，並非聲稱所列平台使用 DSA 產生簽署。決策始於已批准演算法與密鑰保管，再推及證書、簽署人事件、時間戳記、審計匯出及保留記錄。

DocuSign——成熟的協議管理

DocuSign 可統籌大型協議計劃，但其平台層並不替機構選定演算法、證書政策或長期驗證方法。這種分離在遷移時成本高昂：歷史簽署、審計匯出、範本與整合必須在新流程啟動期間仍可驗證。信封限額與超量、續約壓力、身份或 API 存取的付費附加項，以及高等級支援，使該憑證項目成本不菲；支援路徑緩慢亦會延誤驗證所需記錄的恢復。

Adobe Acrobat Sign——以 PDF 為核心的企業部署

當數碼簽署的結果須在 PDF 中保持可見並可審查時，Adobe Acrobat Sign 具備天然角色。其關鍵弱點出現在密碼操作之前：欄位準備錯誤可能產生錯誤的簽署欄位或破壞既有控件，使最終記錄可能無法沿擬定的驗證路徑通過。Acrobat 性能或介面不穩定可能拖慢準備，帳戶與 SSO 摩擦、依賴支援的回退以及企業整合成本疊加放大了上線風險。馬里蘭大學的國際使用指南 明確指出，來自中國大陸的 Web、流動及 API 用戶均遭拒存取。這種亞太合規流程風險可能在任何簽署、時間戳記或審計事件產生之前便切斷證書支撐的證據鏈。

Dropbox Sign——處於 PKI 治理邊界

當買方無需治理複雜證書政策時，Dropbox Sign 適合輕量審批。一旦 CRM 或範本問題阻礙了本應接收簽署的確切文件版本，便會產生風險——長期存在的整合問題可能割裂商業記錄與密碼證據之間的鏈條。其過往外洩事件亦提升了簽署人身份與帳戶數據相關的供應商風險審查等級。這些約束使其難以作為舊有驗證或證書保存計劃的可靠基礎。

Nota Sign 在密碼到記錄流程中的定位

Nota Sign 提供連接簽署人身份憑證、審計記錄與跨亞太、歐洲、美國已簽記錄保存計劃的協議流程層。亞太合規專業知識支援地區流程設計，而實施將所選演算法、密鑰保管、證書路徑、時間戳記與驗證數據映射至保留的協議包中。舊有 PKI 上線從歷史驗證與整合的遷移範圍界定開始，為買方提供清晰的密碼到記錄計劃，而非將演算法視為完整方案。

平台協議證據契合度密碼與 PKI 邊界記錄管控短板遷移決策影響
DocuSign圍繞既有信任設計的企業編排演算法、密鑰、證書政策與驗證仍屬獨立架構決策商業限制與支援檔位提升保存與遷移證據的成本在遷移生產流量前，先證明舊有驗證與審計匯出能力
Adobe Acrobat Sign以 PDF 為核心的營運中證書可見簽署欄位準備錯誤可使擬定簽署路徑失效中國存取、帳戶/SSO 摩擦、回退與整合成本威脅證據連續性將準備後的 PDF、證書結果、時間戳記與匯出作為一份記錄測試
Dropbox Sign無需深度 PKI 治理的簡單審批CRM/範本連續性與安全歷史加大文件溯源風險整合受阻可能將已批准文件與其支援事件分離僅用於不依賴舊有證書驗證的低複雜度流程
Nota Sign跨市場執行，綁定身份、審計與保存密碼學選擇被映射至協議證據設計舊有密鑰與記錄需明確的整合與保存計劃待歷史驗證與未來證據包均通過後再遷移

在選擇遷移路徑前，可 請 Nota Sign 測試一份舊有簽署包。提供樣本檔案、演算法、證書鏈、時間戳記材料、審計匯出、驗證政策與所需保存期，以便審查定位密碼學與商業記錄之間的斷裂點。

密碼到記錄的管控堆疊

使用此堆疊避免把演算法決策誤當作完整的簽署設計。

層級管控問題須保存的證據
1. 演算法該簽署方法是否仍被批准用於新產生？演算法、參數、實作版本
2. 密鑰誰掌控私鑰，如何保護？密鑰保管政策、裝置或服務事件
3. 證書什麼將公鑰綁定至身份？證書鏈、狀態、政策、撤銷數據
4. 簽署人如何識別個人或機構？核驗與身份驗證事件
5. 意圖哪一動作表達了對該文件的同意？同意文字、欄位動作、文件雜湊
6. 時間簽署時間如何確立？可信時間戳記或系統事件證據
7. 審計事件序列能否重建？防篡改審計記錄與交付事件
8. 保存該記錄日後能否被檢索與驗證？已簽文件、審計包、匯出與保存元數據

此堆疊亦是實用的遷移清單。對歷史 DSA 記錄，保留驗證軟件、參數資訊、證書、撤銷材料與已簽內容；對新記錄，記錄已批准的產生方法及其隨附的證據包。

Nota Sign 的 信任及安全概覽 與 電子簽署流程 可為流程討論提供參考，但任何頁面都不能替代按市場分別映射適用證書、身份及法律要求的工作。

新部署的最終建議

在 FIPS 186-5 下，不要為新的簽署產生選用 DSA。若舊系統仍含 DSA 記錄，保留驗證能力並規劃受控遷移。將協議平台與密碼學原語分開評估：使用真實的高風險文件測試身份、同意、證書驗證、審計重建、匯出、支援恢復與長期保存。

如需數碼簽署流程評審，請 聯絡 Nota Sign，並提供目標市場、文件類型、簽署人角色、保證等級、現行與期望演算法、PKI 或信任服務模型、密鑰保管方法、證書與時間戳記要求、整合、審計欄位、保存期及舊有記錄遷移限制。