跳到內容

合格簽章完整解析

Spec: ETSI EN 319 411-2 Spec: ETSI EN 319 411-1 Spec: ETSI EN 319 421 Evidence: Standard-backed

「合格」是歐盟 eIDAS 規章下的法律地位,而不是函式庫能授予的屬性。它必須由多個當事方各自完成特定工作才會成立:合格憑證、合格簽章建立裝置、合格信任服務提供者,以及已公布的信任清單。本頁會說明這些角色,並清楚指出 NextPDF 精確而有限的責任範圍,以及那些它不會、也不能扮演的角色。

一個 qualified electronic signature 在其適用管轄範圍內,享有法律所賦予的效力。這也是「合格」吸引人的原因,也正是草率宣稱它很危險的原因。假設某個工作流程被描述為能產生合格簽章,但鏈中缺了某個角色——憑證並非合格、裝置並非 QSCD、提供者並未列於信任清單上。那麼這些簽章便不是合格的。這道缺口通常會在最關鍵的時刻浮現:一場爭議、一次稽核、一項跨境承認檢查。

困難之處在於:一個完全有效的進階簽章與一個合格簽章,在 PDF 檢視器中可能看起來一模一樣。差別在於憑證、裝置、提供者與信任清單——而這些都不是簽署引擎提供的。整件工作的核心,在於精準辨認哪個當事方掌握哪項保證。

  • 合格是一條鏈,而非一項功能。 它需要一份由合格信任服務提供者簽發的合格憑證、在 QSCD 上簽署,並且可透過信任清單查得。少了其中任何一項,結果便不再是合格的。
  • QSCD 是強制的。 依合格憑證政策,簽章必須由合格簽章建立裝置建立。 Spec: ETSI EN 319 411-2, §6.3.5
  • 唯一控制權屬於簽署者與裝置。 私鑰必須處於簽署者的唯一控制之下,保存在能保護私鑰並代表使用者簽署的裝置中。 Spec: ETSI EN 319 411-1, §6.3.5
  • NextPDF 的部分有限而誠實。 它會組裝結構正確的 PDF 簽章,並且可以嵌入受信任的時間戳記與長期驗證材料。它並非 QSCD、並非(合格的)信任服務提供者,而且它不簽發憑證、不營運信任清單,也不授予合格地位。

一個 qualified electronic signature——在 eIDAS 之下——由彼此獨立的責任構成。NextPDF 只佔其中一格;其餘格子則屬於引擎之外的當事方與標準。

  1. Step 1 of 5: eIDAS Regulation (EU) 910/2014 defines "qualified" and its legal effect — the legal frame
  2. Step 2 of 5: ETSI EN 319 411-1 / 411-2 qualified certificate policy; QSCD mandatory; sole control
  3. Step 3 of 5: ETSI EN 319 412-5 qualified-certificate profile — the QC statements
  4. Step 4 of 5: ETSI EN 319 421 / RFC 3161 trusted time from a TSP issuing time-stamps
  5. Step 5 of 5: ISO 32000-2 §12.8 the PDF signature carrier NextPDF builds
一個 qualified electronic signature 依序所走過的那條鏈,以及每一環節由誰掌握:合格憑證、QSCD、合格信任服務提供者與信任清單都不是簽署引擎——NextPDF 只負責組裝 PDF 簽章載體,並可加上受信任的時間與驗證材料。
  • 合格憑證。 簽發給簽署者,內含 QC 聲明;這些聲明會以機器可讀形式標示它是用於電子簽章的合格憑證,並識別簽發它的合格信任服務提供者。 Spec: ETSI EN 319 412-5, §4.2 NextPDF 不會簽發它。
  • QSCD。 合格簽章建立裝置——以 ETSI 的用語來說,是保管使用者私鑰、防止私鑰洩漏,並代表使用者執行簽署的安全密碼裝置。 Spec: ETSI EN 319 411-1, §3.1 NextPDF 是透過這類裝置簽署的軟體;引擎本身不是 QSCD,軟體金鑰路徑也不是。
  • 合格信任服務提供者。 QTSP 簽發合格憑證,且其本身受到監督;政策要求基於這些憑證的簽章僅能由一個 QSCD 建立。 Spec: ETSI EN 319 411-2, §6.3.5 NextPDF 不是信任服務提供者。
  • 信任清單。 信賴方用來確認提供者與服務曾具合格地位的已公布證據。NextPDF 既不營運信任清單,也不為其背書。

在那條鏈中,NextPDF 的工作有限而具體。它組裝 PDF 簽章:放置簽章欄位、計算位元組範圍,並建構那個 CMS SignedData,也就是標準要求 Contents 項目必須保存的內容。 Spec: ISO 32000-2, §12.8 當簽署金鑰位於 QSCD 上時,NextPDF 會經由 HSM 支援的簽署 中所描述的同一道硬體接縫透過該裝置簽署,而金鑰則始終留在裝置上。

NextPDF 也可以嵌入讓簽章得以長期維持的兩項要素:來自時間戳記機構的受信任時間戳記,以及讓簽章保持可驗證的長期驗證材料。時間戳記是受信任第三方對於某項資料在某個特定時刻之前即已存在的證明 Spec: RFC 3161, §1 ;在歐盟框架中,該機構是在一項適用於簽發時間戳記之信任服務提供者的政策下營運的。 Spec: ETSI EN 319 421, §1 NextPDF 請求並嵌入這個權杖。它並不營運該時間戳記機構;單是嵌入一個時間戳記,也不會讓簽章成為合格的。

Evidence: Standard-backed 合格憑證政策對 QSCD 的要求很明確: 訂戶(或代管的 TSP)的義務規定數位簽章由一個 QSCD 建立。 Spec: ETSI EN 319 411-2, §6.3.5 裝置本身被定義為保管使用者私鑰、防止私鑰洩漏,並代表使用者執行簽署的裝置 Spec: ETSI EN 319 411-1, §3.1 ;對自然人而言, 私鑰必須處於簽署者的唯一控制之下。 Spec: ETSI EN 319 411-1, §6.3.5 簽署函式庫無法代替那條鏈履行任何一項義務。

Evidence: Standard-backed 讓一份憑證成為合格的, 是憑證中攜帶的 QC 聲明;其中包含機器可讀的指示,表明它是作為一份用於電子簽章的合格憑證所簽發,並包含識別簽發它的合格信任服務提供者的資料。 Spec: ETSI EN 319 412-5, §4.2 一個使用憑證來建構簽章的函式庫,並不會讓這份憑證成為合格的;資格來自簽發它的 QTSP。

Evidence: Standard-backed 受信任時間也有自己的提供者角色。RFC 3161 將時間戳記機構定義為一個受信任的第三方,它為某項資料在某個時間點提供存在性證明 Spec: RFC 3161, §1 ETSI EN 319 421 訂定了適用於簽發時間戳記之信任服務提供者的政策與安全要求,這些時間戳記可支援數位簽章或證明某項資料在某個特定時間之前即已存在。 Spec: ETSI EN 319 421, §1 NextPDF 嵌入來自這樣一個提供者的權杖;該提供者若具合格地位, 也屬於該提供者,而非引擎。

沒有任何 API 能「讓一個簽章成為合格的」;任何暗示相反結論的程式碼範例,本身就會是錯誤。這裡真正有用的,是一份審查者可以使用的責任檢核清單:

鏈中的環節由誰掌握NextPDF 的部分
簽發合格憑證合格信任服務提供者使用它;不簽發它
在 QSCD 上簽署簽署者+裝置透過它簽署;本身不是 QSCD
私鑰唯一控制簽署者+裝置當金鑰在 QSCD 上時,絕不持有該金鑰
提供者/服務屬合格QTSP +監督對此不作任何主張
可透過信任清單查得信任清單營運者不營運,也不檢查
PDF 簽章結構良好簽署引擎這是 NextPDF 的格子
嵌入受信任時間戳記時間戳記機構請求並嵌入該權杖
長期驗證材料signing/validation 流程可以嵌入它(見「相關文件」)

只要引擎那一格之上的任何一列未被滿足,結果充其量就是一個有效的進階簽章,而非合格簽章。NextPDF 可以確實完成自己掌握的每一列,卻仍然無法讓簽章成為合格,因為這個地位並非引擎所能授予。

「NextPDF 會產生合格簽章。」

不會,而且精確措辭至關重要。NextPDF 會產生結構正確的 PDF 簽章,並且相容於在 QSCD 上簽署以及嵌入合格提供者的時間戳記。某個特定簽章是否合格取決於部署:它取決於一份合格憑證、一個 QSCD、一個合格信任服務提供者,以及信任清單地位——而這些當中沒有一項是引擎所提供或認證的。正確的說法是「NextPDF 組裝簽章;合格地位來自憑證、裝置與提供者。」任何比這更強的說法,都是在過度宣稱一種軟體無法授予的法律地位。

這道邊界要直白說清楚,不淡化:

  • NextPDF 是什麼。 它是一個 PDF 2.0 簽署引擎。它依照 Spec: ISO 32000-2, §12.8 建構簽章,在有可用裝置時透過該裝置簽署,並且可以嵌入時間戳記與長期驗證材料。
  • NextPDF 不是什麼。並非 QSCD、並非一個合格(或任何)信任服務提供者、並非一個憑證機構,也並非一個信任清單營運者。它不評估、不確認,也不授予合格地位。
  • 「符合」並非「已認證」。 這是一項結構性陳述:NextPDF 建構符合 PDF 簽章標準的簽章,並且可以攜帶 AdES 設定檔所預期的那些元素。它並非在認證任何由此產生的簽章是合格的,也不能取代那些——共同——使其成立的 QSCD、憑證、提供者與信任清單條件。
  • 管轄範圍至關重要。 「合格」及其法律效力是由 eIDAS 規章在其適用範圍內所定義的。本頁是一份工程說明,而非法律意見。某個簽章對於特定用途是否具法律充分性,是適用法律與當事方法律顧問的問題,而非函式庫文件的問題。
Qualified-signature support — edition availability
Edition Availability
Core

Core 建構 PDF 簽章載體與 CMS 容器。它本身不會對合格地位有所貢獻。

Pro

Pro 加入受管理金鑰簽署與簽章增強;這些能力是在行為層級描述的。它仍然不是 QSCD 或信任服務提供者。

Enterprise

Enterprise 加入透過 PKCS#11 的硬體權杖簽署,因此簽署金鑰可以存放在部署中作為 QSCD 營運的裝置上。引擎透過該裝置簽署;合格地位仍然屬於憑證、 裝置與提供者——絕不屬於引擎。

迷你常見問答

進階簽章與合格簽章是同一回事嗎? 不是。它們在檢視器中可能看起來一模一樣。合格簽章還需要一份合格憑證、一個 QSCD,以及一個合格信任服務提供者;進階簽章則不需要。差別在於那條鏈,而不在 PDF 位元組。

在 HSM 上簽署會讓簽章成為合格的嗎? 光是這樣不會。QSCD 是必要的,但並非充分。憑證必須是一份來自合格信任服務提供者的合格憑證,而且裝置必須符合該部署的 QSCD 標準。通用的 HSM 並不會自動成為 QSCD。

加入一個時間戳記會讓簽章成為合格的嗎? 不會。受信任的時間戳記會強化持久性與時間證明;它並不提供那些定義合格地位的憑證、裝置或提供者條件。它對於長期設定檔是必要的,但對於合格地位並非充分。

NextPDF 能告訴我我的簽章是否合格嗎? 不能。引擎對於合格地位不作任何主張。確立合格地位是憑證、裝置、提供者、信任清單與適用法律的問題——在引擎的責任範圍之外。

  • 合格電子簽章(Qualified electronic signature)——在 eIDAS 規章之下,由 QSCD 建立並基於一份合格憑證的進階電子簽章;一種法律地位,而非一項軟體功能。
  • eIDAS——歐盟關於電子識別與信任服務的第 910/2014 號規章 (EU);定義「合格」及其效力的法律框架。
  • QSCD(合格簽章建立裝置)——一個符合 eIDAS 標準的裝置;以 ETSI 的用語來說,是保管使用者金鑰、保護它,並代表使用者簽署的安全密碼裝置。
  • 合格憑證(Qualified certificate)——由合格信任服務提供者所簽發,且其 QC 聲明會以機器可讀方式標示該憑證為用於電子簽章之合格憑證。
  • QTSP(合格信任服務提供者)——一個受監督的信任服務提供者,簽發合格憑證並提供相關的合格服務。
  • 信任清單(Trusted list)——信賴方用來確認某個提供者與服務曾具合格地位的已公布證據。
  • 唯一控制(Sole control)——一項義務,要求自然人簽署者的私鑰保管在該簽署者的唯一控制之下。
  • 時間戳記機構(Time Stamp Authority,TSA——一個為某項資料在某個時間點提供存在性證明的受信任第三方(RFC 3161)。