Enterprise phiên bản
Signature — Tài liệu tham chiếu chuyên sâu
Tổng quan nhanh
Phần tiêu đề “Tổng quan nhanh”Đây là tài liệu tham chiếu chuyên sâu cho trình tạo dài hạn của NextPDF Enterprise: cách một chữ ký B-LT hoặc B-LTA được lắp ráp, cách tài liệu thu hồi được thu thập và thực thi, cách dấu thời gian tài liệu neo tài liệu theo thời gian, và cách ranh giới Pro được thực thi. Nó ở mức hành vi và mức hợp đồng. Các kiểu triển khai Enterprise cụ thể được chủ ý không nêu tên ở đây; trang chỉ tham chiếu gói công khai và bề mặt hợp đồng của Core.
Tính khả dụng & cấp phép
Phần tiêu đề “Tính khả dụng & cấp phép”Năng lực này đi kèm trong NextPDF Enterprise (nextpdf/enterprise) và được kích hoạt bằng một license envelope cấp Enterprise. Một triển khai không có quyền đó sẽ không nạp các class của năng lực này. So sánh các phiên bản và mua license.
Ma trận cấp→phiên bản chính tắc: B-B là baseline được Core, Pro, và Enterprise tạo ra; B-T (có dấu thời gian) được Core, Pro, và Enterprise tạo ra — Core kèm theo đường dấu thời gian RFC 3161, nên B-T không cần gói premium nào; B-LT và B-LTA (DSS, VRI, dấu thời gian tài liệu) chỉ được tạo ra bởi Enterprise. Trong một triển khai chỉ có Pro, việc yêu cầu B-LT hoặc B-LTA sẽ fail closed: SignatureLevel::isAvailableInEnvironment của Core trả về false khi không có trình tạo dài hạn Enterprise, và trình điều phối của Core phát sinh một lỗi có tên thay vì âm thầm hạ cấp.
| Cấp PAdES | Bổ sung | Phiên bản trình tạo |
|---|---|---|
| B-B | Chữ ký CMS với các thuộc tính đã ký | Core, Pro, Enterprise |
| B-T | Dấu thời gian RFC 3161 đáng tin cậy trên giá trị chữ ký | Core, Pro, Enterprise |
| B-LT | Document Security Store với tài liệu xác thực | Chỉ Enterprise |
| B-LTA | Dấu thời gian tài liệu bao trùm DSS (vòng lặp lưu trữ) | Chỉ Enterprise |
Mô hình khái niệm
Phần tiêu đề “Mô hình khái niệm”Một chữ ký B-LT là một chữ ký B-T cộng với một Document Security Store. DSS là một từ điển cấp Catalog chứa các stream chứng chỉ, phản hồi OCSP, và CRL mà bên xác minh cần một khi chứng chỉ ký đã hết hạn — ISO 32000-2 §12.8.4.3. Xác thực dài hạn dùng hai loại từ điển — một DSS và một từ điển dấu thời gian tài liệu — ISO 32000-2 §12.8. Bản thân chữ ký CMS được lưu dưới dạng mã hóa DER trong /Contents — ISO 32000-2 §12.8.1.
Một chữ ký B-LTA bổ sung một dấu thời gian tài liệu bao trùm toàn bộ trạng thái tài liệu, bao gồm cả DSS, được ghi thông qua từ điển dấu thời gian tài liệu — ISO 32000-2 §12.8.5. ETSI EN 319 142-2 mô tả cùng cách kết hợp dài hạn đó — §5.5 — và phần hỗ trợ của trình xử lý — §6.3.3.3.
Quy trình của trình tạo
Phần tiêu đề “Quy trình của trình tạo”- Dựng chuỗi. Chứng chỉ của bên ký cùng với bất kỳ chứng chỉ trung gian nào do bên gọi cung cấp tạo thành chuỗi, bên ký trước, hướng tới trust anchor — RFC 5280 §6.1.
- Thu thập tài liệu thu hồi. Với mỗi chứng chỉ không phải gốc, trình tạo hỏi OCSP trước. Một phản hồi OCSP báo cáo
good,revoked, hoặcunknown— RFC 6960 §2.2 — và bị giới hạn theo thời gian bởithisUpdate/nextUpdate— RFC 6960 §4.2. Nếu OCSP không khả dụng, nó chuyển sang dùng một CRL, có hỗ trợ delta-CRL; một CRL gốc và một delta tùy chọn được thêm như các mục DSS riêng biệt. - Ghi DSS. Các chứng chỉ, phản hồi OCSP, và CRL được ghi như các đối tượng stream PDF riêng lẻ; các bản trùng được loại trùng theo content hash. Từ điển DSS tham chiếu chúng thông qua
/Certs,/OCSPs,/CRLs. - VRI theo từng chữ ký (tùy chọn bật). Một mục VRI, được lập khóa theo bản băm chữ hoa của giá trị
/Contentscủa chữ ký, lập chỉ mục các cert/OCSP/CRL cụ thể cho chữ ký đó, với một mục thời-điểm-xác-thực tùy chọn. VRI tắt theo mặc định: ETSI EN 319 142-1 V1.2.1 §5.4 khuyến nghị không dùng VRI trong DSS cho các tài liệu mới; một số bộ xác thực vẫn hiển thị trạng thái dài hạn tốt hơn khi có nó, nên bên gọi có thể bật. - Dấu thời gian tài liệu (B-LTA). Sau khi DSS được ghi, một từ điển
/DocTimeStampvới/SubFilter /ETSI.RFC3161được nối thêm cùng các placeholder ByteRange và/Contents. Sau khi toàn bộ tệp được lắp ráp xong, trình tạo tính digest SHA-256 trên ByteRange, yêu cầu một token RFC 3161 — §2.4.1 — và nhúng token DER;genTimelà thời điểm tạo token theo UTC — §2.4.2.
Thực thi thu hồi
Phần tiêu đề “Thực thi thu hồi”Trình tạo phân giải một chế độ thực thi theo thứ tự ưu tiên này: một chế độ thực thi có cấu trúc tường minh thắng; nếu không, một giá trị boolean tường minh (đã ngừng dùng) ánh xạ sang strict hoặc permissive; nếu không, mặc định là strict (fail-closed).
Dưới chế độ thực thi strict, việc thiếu một phản hồi OCSP và thiếu một CRL cho bất kỳ chứng chỉ không phải gốc nào sẽ phát sinh một lỗi thay vì chỉ phát ra một cảnh báo. Mặc định fail-closed tồn tại để một PDF “B-LT” không thể được tạo ra mà không có tài liệu thu hồi nào trong DSS trong khi vẫn quảng bá cấp dài hạn. Quy trình permissive (chỉ cảnh báo) phải được chọn bật một cách tường minh. Dưới chính sách mạng strict-offline, không có lượt truy xuất OCSP/CRL nào xảy ra; chỉ tài liệu nhúng trong DSS được dùng, và điều kiện thiếu-tài-liệu được xử lý bởi cùng quy tắc thực thi đó.
Vòng lặp lưu trữ
Phần tiêu đề “Vòng lặp lưu trữ”Dấu thời gian tài liệu B-LTA được neo bởi một chứng chỉ TSA mà bản thân nó sẽ hết hạn. Vòng lặp lưu trữ, chạy trước khi hết hạn đó, thu thập tài liệu thu hồi mới cho chuỗi chứng chỉ TSA, ghi lại DSS, tùy chọn thêm một mục VRI lập khóa theo bản băm chứng chỉ TSA, và thêm một dấu thời gian tài liệu mới bao trùm trạng thái đã cập nhật. Mỗi dấu thời gian mới bao trùm các dấu thời gian trước đó. Việc chạy vòng lặp theo lịch là một nghĩa vụ vận hành; trình tạo phát sinh một lỗi nếu vòng lặp được yêu cầu mà không có TSA nào được cấu hình hoặc dưới chính sách strict-offline. Toàn bộ bề mặt lưu trữ được ghi trên tài liệu tham chiếu chuyên sâu Archive.
Bề mặt API (chỉ hợp đồng công khai)
Phần tiêu đề “Bề mặt API (chỉ hợp đồng công khai)”| Kiểu | Loại | Vai trò | Độ ổn định | Từ |
|---|---|---|---|---|
SignerInterface | interface (NextPDF\Contracts) | Hợp đồng ký của Core | stable | 1.0.0 |
LtvManagerInterface | interface (NextPDF\Contracts) | Hợp đồng trình tạo dài hạn + vòng lặp lưu trữ được phân giải lúc chạy | stable | 1.0.0 |
TsaClientInterface | interface | Client RFC 3161 TSA mà trình tạo gọi | stable | 1.0.0 |
SignatureLevel | enum (NextPDF\Security\Signature) | Bộ chọn B-B, B-T, B-LT, B-LTA và bước dò tính khả dụng | stable | 1.0.0 |
SignatureLevel::requiresDss → true đối với B-LT, B-LTA. requiresDocumentTimestamp → chỉ true đối với B-LTA. requiresTimestamp → true đối với B-T, B-LT, B-LTA. Mã sản phẩm phụ thuộc vào các hợp đồng này; các class triển khai Enterprise cụ thể là nội bộ và không thuộc API công khai.
Tính phù hợp
Phần tiêu đề “Tính phù hợp”| Tuyên bố | Tiêu chuẩn | Điều khoản |
|---|---|---|
Chữ ký/dấu thời gian được lưu dưới dạng mã hóa DER trong /Contents. | ISO 32000-2 | §12.8.1 |
| LTV dùng một DSS và một từ điển dấu thời gian tài liệu. | ISO 32000-2 | §12.8 |
| DSS là từ điển là giá trị của khóa DSS trong document catalog; chứa Certs, OCSPs, CRLs. | ISO 32000-2 | §12.8.4.3 |
| Cấu trúc từ điển dấu thời gian tài liệu. | ISO 32000-2 | §12.8.5 |
| DSS + dấu thời gian tài liệu cho chữ ký dài hạn. | ETSI EN 319 142-2 | §5.5 |
| Trình xử lý hỗ trợ DSS + dấu thời gian tài liệu. | ETSI EN 319 142-2 | §6.3.3.3 |
| Yêu cầu RFC 3161 trả về TSTInfo; genTime là thời điểm tạo theo UTC. | RFC 3161 | §2.4.1, §2.4.2 |
| OCSP good/revoked/unknown được giới hạn bởi thisUpdate/nextUpdate. | RFC 6960 | §2.2, §4.2 |
| Các đầu vào xác thực đường dẫn tới một trust anchor. | RFC 5280 | §6.1 |
Mọi điều khoản đều được diễn giải lại. NextPDF không tái hiện văn bản quy phạm. NextPDF không đưa ra tuyên bố chứng nhận PAdES nào: trình tạo ghi ra các cấu trúc được căn chỉnh theo các cấp B-LT và B-LTA được định nghĩa trong ETSI EN 319 142; không có kết quả kiểm thử tính phù hợp hay chứng thực của bên thứ ba nào được tuyên bố. Phần các cấp baseline của ETSI EN 319 142-1 nằm ngoài bộ bằng chứng được trích dẫn, nên neo ETSI được trích dẫn là EN 319 142-2 và các neo ISO/RFC mang theo các tuyên bố về dài hạn và dấu thời gian — cùng lập trường công bố như tài liệu tham chiếu ký của Core. Việc một chữ ký đã tạo có xác minh được hay không là quyết định của bên xác minh dựa trên các trust anchor và chính sách độ tươi mới thu hồi của bên đó; trình tạo nhúng tài liệu và không khẳng định một kết quả đáng tin cậy.
Trường hợp ngoại lệ & hành vi ở chế độ FIPS
Phần tiêu đề “Trường hợp ngoại lệ & hành vi ở chế độ FIPS”Trường hợp ngoại lệ
Phần tiêu đề “Trường hợp ngoại lệ”- DSS phải được ghi trước dấu thời gian tài liệu; một dấu thời gian được ghi trước DSS sẽ không bao trùm tài liệu xác thực.
- Thực thi strict (mặc định) phát sinh một lỗi khi thiếu tài liệu thu hồi cho một chứng chỉ không phải gốc. Permissive là tùy chọn bật.
- B-LTA mà không có TSA nào được cấu hình sẽ phát sinh một lỗi thay vì tạo ra B-LT.
- Chính sách strict-offline: không có truy cập mạng OCSP/CRL/TSA; B-LTA không thể đạt được ở chế độ strict-offline.
- Token dấu thời gian tài liệu có một không gian dành riêng có giới hạn; một token vượt quá nó sẽ phát sinh một lỗi thay vì cắt cụt.
Hành vi ở chế độ FIPS
Phần tiêu đề “Hành vi ở chế độ FIPS”Hồ sơ chính sách mã hóa FIPS 140-3 là một năng lực Enterprise được ghi tài liệu cùng với module bảo mật. Trình tạo dài hạn chỉ thêm digest SHA-256 dùng cho dấu thời gian tài liệu và trao đổi RFC 3161; nguyên hàm ký thuộc về trình ký của Core. Dưới hồ sơ FIPS, vẫn tạo ra cùng các cấu trúc DSS, VRI, và dấu thời gian tài liệu; ràng buộc áp dụng cho các thuật toán ký và băm, không áp dụng cho bố cục DSS. Việc lưu giữ khóa bằng phần cứng thông qua PKCS#11 được ghi tài liệu cùng với module bảo mật và nằm ngoài phạm vi của trang này.
Hợp đồng hành vi
Phần tiêu đề “Hợp đồng hành vi”- Core tạo ra B-B và B-T (B-T bổ sung dấu thời gian RFC 3161 trên giá trị chữ ký). Pro tạo ra B-B và B-T thông qua cùng stack của Core. B-LT và B-LTA chỉ được tạo ra bởi Enterprise.
- Trình tạo ghi DSS (B-LT) và một dấu thời gian tài liệu bao trùm DSS (B-LTA). Nó nhúng tài liệu xác thực; nó không khẳng định một kết quả xác minh đáng tin cậy.
- Mặc định thực thi thu hồi fail-closed phát sinh một lỗi khi thiếu tài liệu thu hồi cho một chứng chỉ không phải gốc, trừ khi bên gọi chọn quy trình permissive.
- B-LTA yêu cầu một TSA đã cấu hình; nếu không có, bước B-LTA sẽ phát sinh một lỗi thay vì hạ xuống B-LT.
Phương án dự phòng Core
Phần tiêu đề “Phương án dự phòng Core”Trong một triển khai chỉ có Core, trình ký phần mềm tạo ra PAdES B-B và B-T thông qua SignerInterface; Core kèm theo đường dấu thời gian RFC 3161 nên B-T không cần gói premium nào. Core không có trình tạo DSS, VRI, hay dấu thời gian tài liệu nào; một yêu cầu B-LT hoặc B-LTA sẽ fail closed thông qua SignatureLevel::isAvailableInEnvironment trả về false.
Phương án dự phòng Pro
Phần tiêu đề “Phương án dự phòng Pro”Trong một triển khai chỉ có Pro, đường ký là baseline B-B/B-T cộng với các quy trình ký từ xa và bằng cloud-KMS. Pro không tạo ra DSS hay dấu thời gian tài liệu nào. RemoteSigningConfig mang theo enum SignatureLevel của Core, nhưng một cấp dài hạn (B-LT/B-LTA) là một giá trị được khai báo trước mà Pro không hành động; trình tạo dài hạn được phân giải lúc chạy thông qua hợp đồng của Core và đi kèm trong nextpdf/enterprise.
Lưu ý về ranh giới Enterprise
Phần tiêu đề “Lưu ý về ranh giới Enterprise”Chi tiết cơ chế nội bộ nằm trong tài liệu nội bộ của kho mã nguồn và nằm ngoài phạm vi của cẩm nang này.
Ranh giới triển khai
Phần tiêu đề “Ranh giới triển khai”NextPDF Enterprise nhúng tài liệu xác thực; nó tích hợp với các bộ phản hồi OCSP/CRL do bên gọi cung cấp và một TSA RFC 3161. Nó không vận hành, lưu trữ, hay bảo đảm tính sẵn sàng của các bộ phản hồi đó hoặc của TSA. Tính hợp lệ dài hạn phụ thuộc vào các bộ phản hồi, TSA, lịch vòng lặp lưu trữ, và người vận hành — không chỉ phụ thuộc vào riêng NextPDF Enterprise. Người vận hành sở hữu việc chọn TSA và khả năng truy cập TSA, quyền truy cập bộ phản hồi thu hồi hoặc tài liệu đã thu thập trước, chính sách mạng, và việc chạy vòng lặp lưu trữ trước khi mỗi chứng chỉ dấu thời gian hết hạn.
Ranh giới công bố
Phần tiêu đề “Ranh giới công bố”Trang này chỉ ghi tài liệu về hành vi quan sát được từ bên ngoài và bề mặt API công khai được hỗ trợ. Các đường dẫn namespace nội bộ, các class trợ giúp, các bảng cơ chế, các tên tệp runbook, và các tiền tố ticket nằm ngoài phạm vi.
Ranh giới tuân thủ pháp lý
Phần tiêu đề “Ranh giới tuân thủ pháp lý”Việc căn chỉnh theo các cấu trúc B-LT và B-LTA được định nghĩa trong ETSI EN 319 142 là một phát biểu cấu trúc, không phải một ý kiến pháp lý và cũng không phải một chứng nhận. NextPDF không đưa ra tuyên bố chứng nhận PAdES nào. Việc một chữ ký đã tạo có xác minh được hay không là quyết định của bên xác minh dựa trên các trust anchor và chính sách độ tươi mới thu hồi của bên đó.
Xem thêm
Phần tiêu đề “Xem thêm”- Signature (tổng quan năng lực)
- Tài liệu tham chiếu chuyên sâu Archive — bảo trì DSS/VRI, tình trạng LTV, vòng lặp lưu trữ.
- Bảo mật / Ký (Core) — CMS, RFC 3161, RFC 5280, OCSP/CRL.
- Bảo mật Pro — baseline B-B và ranh giới Enterprise.
- PAdES ánh xạ baseline