Xác minh chữ ký: phía xác minh mật mã AdES / PAdES

Tổng quan nhanh

NextPDF Enterprise xác minh chữ ký số bằng mật mã. Phía xác minh đọc Cryptographic Message Syntax (CMS) SignedData hoặc token dấu thời gian Request for Comments (RFC) 3161 từ PDF, tính lại các digest, kiểm tra chữ ký, gắn từng chữ ký với chứng chỉ ký tương ứng, rồi kiểm tra chuỗi chứng chỉ, bao gồm cả xử lý chính sách chứng chỉ, đối chiếu với kho trust anchor do bên gọi cung cấp. Trang này mô tả hành vi đó: nội dung nào được xác minh, nội dung nào bị từ chối theo nguyên tắc fail-closed, thuật toán nào được hỗ trợ, và ranh giới tin cậy nằm ở đâu.

Việc này tách biệt với Validation, nơi chạy các kiểm tra chính sách cấu trúc chỉ đọc và chủ ý không thực hiện mật mã. Đây cũng là phía xác minh tương ứng với trình tạo chữ ký, nơi ghi các cấu trúc PDF Advanced Electronic Signatures (PAdES) B-LT / B-LTA.

Cài đặt

composer require nextpdf/enterprise:^3

Tổng quan khái niệm

Việc xác minh dựa trên bằng chứng và tuân theo nguyên tắc fail-closed: một kiểm tra không thể được xác lập một cách khẳng định thì không tạo ra kết quả tích cực. Các phần dưới đây được tổng hợp thành một kết quả duy nhất trong ValidationReport.

Xác minh mật mã CMS / token dấu thời gian. Một ngăn xếp DER nghiêm ngặt, khép kín, dùng độ dài xác định sẽ phân tích CMS SignedData và token dấu thời gian RFC 3161. Một token chỉ được chấp nhận khi nó mang đúng một SignerInfo, các thuộc tính đã ký được phân tích nghiêm ngặt, chứng chỉ của bên ký được phân giải, thuộc tính message-digest khớp với digest được tính lại, ràng buộc signing-certificate bắt buộc (ESS signing-certificate-v2) được thiết lập, và chữ ký SignerInfo xác minh được trên các thuộc tính đã ký sau khi được gắn lại thẻ. Quy tắc khớp digest tuân theo mô hình xác minh RFC 5652 §5.6 / §5.4: bên nhận tính lại message digest của nội dung, và chữ ký chỉ hợp lệ khi giá trị đó bằng với thuộc tính đã ký messageDigest. Trình xác minh không bao giờ tin một digest do bên tạo cung cấp.

Kiểm tra chứng chỉ TSA tại genTime. genTime của dấu thời gian là thời điểm UTC mà token được tạo ra (RFC 3161 §2.4.2). Chứng chỉ ký của TSA được kiểm tra tại thời điểm đó, không phải tại “bây giờ”: extended key usage của chứng chỉ phải là một id-kp-timeStamping duy nhất, mang tính critical (RFC 3161 §2.3), còn thời hạn hiệu lực, chuỗi, nguồn gốc trust-anchor và tình trạng thu hồi đều được đánh giá theo genTime. Một chuỗi đúng cấu trúc nhưng không dẫn tới trust anchor đã cấu hình thì không bao giờ có thể hỗ trợ kết quả tích cực.

Chữ ký tài liệu cơ bản PAdES tách rời. Một bộ trích xuất chuyên biệt thực hiện xác minh cơ bản Advanced Electronic Signatures (AdES) / PAdES thực sự cho chữ ký tài liệu tách rời: message digest được tính lại trên dải byte đã ký rồi được so sánh, chữ ký được xác minh, và ràng buộc signing-certificate là bắt buộc. Việc này thay thế phương án dự phòng chỉ-cấu-trúc trước đây. Trình xác minh dấu thời gian và bộ trích xuất chữ ký tài liệu dùng chung một trình kiểm tra issuer-and-serial của ESS, nên việc phân tích ràng buộc chứng chỉ không thể lệch nhau.

Chuỗi phủ DocTimeStamp lưu trữ. validateArchivalTimestampChain() kiểm tra một chuỗi các token DocTimeStamp được tin cậy trên các dải byte của PDF làm bằng chứng lưu trữ B-LTA. Imprint của mỗi token được gắn với chính các byte ByteRange mà nó phủ, chuỗi tuân theo thứ tự ETSI nghiêm ngặt, chuỗi TSA của từng token đều được neo vào trust anchor, và chuỗi phải phủ tệp đến tận điểm đánh dấu cuối tệp. Chuỗi chỉ đạt trạng thái thông qua hoàn toàn khi đầy đủ, được neo vào trust anchor, và phủ đến cuối tệp.

Xử lý chính sách chứng chỉ (RFC 5280 §6.1.4). Việc kiểm tra đường dẫn áp dụng xử lý chính sách chứng chỉ đầy đủ: cây chính sách có cấu trúc nút, ánh xạ chính sách với phương án dự phòng anyPolicy, và việc hợp nhất policyConstraints / inhibitAnyPolicy, được hỗ trợ bởi trình đọc DER cho phần mở rộng chính sách theo nguyên tắc fail-closed. Các biến trạng thái xử lý đường dẫn explicit_policy và inhibit_anyPolicy (RFC 5280 §6.1.2) xác định liệu có cần một cây valid-policy không rỗng hay không; bước kết thúc lấy giao của cây valid-policy với user-initial-policy-set (RFC 5280 §6.1.4). Khi không có chính sách bắt buộc và anyPolicy được chấp nhận, việc xử lý không bị ràng buộc; đây là mặc định và không thay đổi so với hành vi trước đây.

Các thuật toán được hỗ trợ

Phía xác minh chấp nhận tập thuật toán dưới đây và fail closed với mọi thứ ngoài tập đó: thuật toán không được hỗ trợ đồng nghĩa với một lần xác minh bị từ chối, không bao giờ là một lần thông qua ngầm.

Họ thuật toán	Được hỗ trợ	Ghi chú
RSA (PKCS#1 v1.5)	rsaEncryption với SHA-2, và các sha*WithRSAEncryption OID	Được chấp nhận
ECDSA	các đường cong P-256, P-384, P-521	Được chấp nhận
RSASSA-PSS	—	Không được hỗ trợ → fail-closed
EdDSA	—	Không được hỗ trợ → fail-closed
Các digest SHA-3	—	Không được hỗ trợ → fail-closed
SHA-1	—	Yếu: một chữ ký cơ bản xác minh được bằng SHA-1 sẽ bị hạ cấp thành lỗi crypto-constraints, không phải là một lần thông qua

Bề mặt API

Bạn dùng phía xác minh thông qua engine công khai và các contract Core / Pki. Các lớp strategy cụ thể là thành phần nội bộ.

Kiểu	Loại	Vai trò
AdESValidationEngine	class	Điểm vào của phía xác minh: kiểm tra chữ ký và chuỗi lưu trữ.
AdESValidationEngine::validateArchivalTimestampChain()	method	Kiểm tra một chuỗi phủ DocTimeStamp được tin cậy trên các dải byte của PDF.
ValidationReport	kết quả	Kết quả có cấu trúc: trạng thái tổng thể cùng với các phát hiện theo từng kiểm tra.
PathValidatorInterface	interface (NextPDF\…\Pki)	SPI kiểm tra đường dẫn chứng nhận mà engine phụ thuộc vào.
PathValidationOptions	value object	Các tùy chọn xử lý chính sách: requireExplicitPolicy, inhibitAnyPolicy, inhibitPolicyMapping, maxPolicyFanout.
TrustAnchorStoreInterface	interface	Tập các anchor được tin cậy do bên gọi cung cấp để đối chiếu chuỗi.

Phương thức kiểm tra chuỗi lưu trữ có chữ ký như sau:

public function validateArchivalTimestampChain(
    string $pdfBytes,
    array $dssData = [],
    ?TrustAnchorStoreInterface $anchors = null,
): ValidationReport;

Phương thức này chỉ đạt trạng thái thông qua hoàn toàn khi chuỗi DocTimeStamp được xác minh đầy đủ, được neo vào trust anchor, và phủ tệp đến tận điểm đánh dấu EOF của nó.

CertificateChainValidator::validate() nhận một tập initial-policy (user-initial-policy-set theo RFC 5280). Mặc định là anyPolicy, vốn không bị ràng buộc, nên một chuỗi thông thường không bị ảnh hưởng. Hãy truyền một tập rõ ràng, hoặc đặt requireExplicitPolicy, để yêu cầu cây valid-policy không rỗng.

Ví dụ mã — bắt đầu nhanh

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;

$report = $engine->validateArchivalTimestampChain($pdfBytes, [], $trustAnchors);

if ($report->isTotalPassed()) {
    // A complete, trust-anchored, EOF-covering DocTimeStamp chain.
}

Ví dụ mã — sản xuất

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;
use Psr\Log\LoggerInterface;

final readonly class ArchivalEvidenceCheck
{
    public function __construct(
        private AdESValidationEngine $engine,
        private LoggerInterface $logger,
    ) {}

    public function check(string $pdfBytes, TrustAnchorStoreInterface $anchors): bool
    {
        $report = $this->engine->validateArchivalTimestampChain($pdfBytes, [], $anchors);

        foreach ($report->findings as $finding) {
            $this->logger->info('archival.finding', [
                'check'  => $finding->checkId,
                'status' => $finding->status->value,
            ]);
        }

        // A positive result proves byte-range coverage by a trusted timestamp
        // chain — it is one input to your decision, not a legal conclusion.
        return $report->isTotalPassed();
    }
}

Thay đổi hành vi & ghi chú nâng cấp

Phía xác minh đã chuyển từ chấp nhận dựa trên cấu trúc / thời gian sang xác minh mật mã đầy đủ. Nếu bạn đang dựa vào hành vi cũ, dễ dãi hơn, hãy xem lại các thay đổi này.

• Fail-closed với một dấu thời gian nhận-biết-được-nhưng-không-xác-minh-được. Một DocTimeStamp hoặc token lưu trữ trước đây thông qua dựa trên cấu trúc và thời gian thì nay phải được xác minh mật mã đầy đủ: chữ ký, message-digest, và ràng buộc signing-certificate. Một token không xác minh được nữa thì không còn tạo ra bằng chứng tồn tại tích cực; nó được ánh xạ thành kết quả không xác định hoặc thất bại.
• Chữ ký cơ bản SHA-1 bị hạ cấp, không được thông qua. Một chữ ký tài liệu cơ bản xác minh được nhưng dùng SHA-1 sẽ được báo cáo là lỗi crypto-constraints, không phải một lần thông qua hoàn toàn.
• Việc xử lý chính sách chứng chỉ RFC 5280 §6.1.4 được thực thi. Một chuỗi có explicit_policy chạm tới không cùng với cây valid-policy rỗng thì nay thất bại, kể cả khi một policyConstraints nội bộ-chuỗi requireExplicitPolicy dẫn tới điều đó. Các chuỗi mặc định, không bị ràng buộc (không có chính sách bắt buộc, anyPolicy được chấp nhận) không bị ảnh hưởng.
• Thay đổi chữ ký của constructor (BC break). AdESValidationEngine::__construct() nay định kiểu tham số $chainValidator của nó là SPI Pki\PathValidatorInterface, mặc định lười (lazy) thành Pki\CertificateChainValidator::withDefaults(). Trước đây, tham số này là Ltv\CertificateChainValidator cụ thể. Bên gọi từng tiêm trình kiểm tra LTV cụ thể thì nay phải tiêm bản hiện thực SPI Pki. Trình kiểm tra Pki bao bọc cùng một engine đường dẫn cấu trúc, đồng thời thêm name constraints và xử lý chính sách; với các đầu vào mặc định tuân thủ, nó là một no-op.

Trường hợp đặc biệt & lưu ý

• Thuật toán không được hỗ trợ ≠ không kết luận. RSASSA-PSS, EdDSA, và SHA-3 bị từ chối theo nguyên tắc fail-closed, không bị trì hoãn xử lý. Nếu các bên ký của bạn dùng chúng, phía xác minh này sẽ không trả về kết quả tích cực.
• Tin cậy là tương đối với anchor. Việc xác minh luôn phụ thuộc vào kho trust anchor mà bạn cung cấp. Một tập anchor rỗng hoặc sai sẽ tạo ra kết quả không-tin-cậy, bất kể dữ liệu có đúng về mặt mật mã hay không.
• genTime, không phải bây giờ. Chứng chỉ TSA được đánh giá tại genTime của token. Một chứng chỉ TSA đã hết hạn sau thời điểm đó vẫn có thể hỗ trợ token được tạo khi chứng chỉ còn hiệu lực; chứng chỉ chưa có hiệu lực tại genTime thì không thể.
• Phủ đến EOF. Chuỗi lưu trữ phải phủ tài liệu đến tận điểm đánh dấu EOF của nó. Một dấu thời gian chỉ phủ phần đầu của tệp thì không xác lập việc phủ toàn-tài-liệu.
• Không-chứng-minh-được-bị-thu-hồi không phải là Good. Một phán quyết Valid cần trạng thái không-bị-thu-hồi một cách chắc chắn. Nếu cả OCSP và CRL đều trả về Unknown hoặc Unavailable, thì ngay cả chữ ký vững chắc về mật mã, hợp lệ về chuỗi, được neo vào trust anchor cũng được phân giải thành Indeterminate. Hãy cung cấp dữ liệu Good OCSP/CRL nhúng cho chứng chỉ của bên ký để đạt Valid.

Hiệu năng

Việc xác minh chạy trong tiến trình trên các byte PDF được cung cấp và dữ liệu xác minh được nhúng; chi phí tỷ lệ với độ dài chuỗi và số lượng dấu thời gian. Việc xác minh không thực hiện bất kỳ chuyến đi-về qua mạng nào. Dữ liệu thu hồi và tin cậy đến từ những gì bên gọi cung cấp hoặc những gì được nhúng trong tài liệu. Việc xác minh có tính tất định: cùng đầu vào và cùng trust anchor sẽ tạo ra cùng một báo cáo.

Ghi chú bảo mật

• Fail-closed là mặc định. Mỗi bước chấp nhận đều từ chối dữ liệu mà nó không thể xác minh một cách khẳng định. Điều này ngăn tài liệu tự thể hiện là hợp lệ khi engine chưa từng xác lập điều đó.
• Tấn công nối-thêm-sau-dấu-thời-gian bị đánh bại bởi việc phủ đến EOF. Vì imprint của mỗi dấu thời gian lưu trữ được gắn với chính các byte ByteRange và chuỗi phải chạm tới EOF, nội dung được nối thêm sau một dấu thời gian thì không được dấu thời gian đó phủ và không có sức nặng chứng cứ của nó.
• Coi đầu vào là thù địch. Các byte PDF, CMS nhúng, và token dấu thời gian từ nguồn không tin cậy được phân tích bởi trình đọc DER nghiêm ngặt dùng độ dài xác định, vốn từ chối mã hóa sai định dạng hoặc độ dài không xác định.

Cư trú dữ liệu & giảm thiểu PII

Việc xác minh diễn ra cục bộ trong tiến trình, không có I/O qua mạng. Chứng chỉ và chữ ký mang danh tính của subject; hãy áp dụng các biện pháp lưu giữ và tối giản của riêng bạn cho báo cáo và mọi dữ liệu chứng chỉ được trích xuất.

Telemetry an toàn & làm sạch log

Các phát hiện mang định danh kiểm tra và trạng thái. Một số chẩn đoán có thể lặp lại tên subject của chứng chỉ hoặc số serial; hãy làm sạch hoặc che các trường đó trước khi chuyển tiếp log tới các đích dùng chung.

Ranh giới phạm vi

Hãy nêu các ranh giới này trong đầu ra hướng-người-dùng để kết quả tích cực không bị diễn giải quá mức.

• validateArchivalTimestampChain() chứng minh việc phủ dải byte, không phải khả năng truy cập xref. Nó xác lập bằng mật mã rằng một chuỗi dấu thời gian được tin cậy phủ các dải byte của tài liệu đến EOF. Nó không phân tích khả năng truy cập đối tượng ở mức xref hoặc startxref; đó là điều ngoài phạm vi theo thiết kế. Quy tắc phủ đến EOF, cùng với việc neo trust anchor, đánh bại các cuộc tấn công nối-thêm-sau-dấu-thời-gian, chứ không phải phân tích đồ thị đối tượng.
• Ngoài phạm vi theo thiết kế. Evidence Records (RFC 4998 / RFC 6283); việc xác minh token dấu thời gian RSASSA-PSS, EdDSA, hoặc SHA-3; tích hợp trusted-list (TSL) và qualified-TSA; và việc lấy thông tin thu hồi TSA trực tuyến đều không được phía xác minh này cung cấp. Việc thu hồi được đánh giá từ dữ liệu đã sẵn có với trình xác minh.

Tuân thủ

Hành vi	Tham chiếu	Trạng thái
Giá trị chữ ký / token dấu thời gian được lưu mã hóa DER trong /Contents	ISO 32000-2 §12.8.1	Đã phân tích và xác minh
Từ điển dấu thời gian tài liệu	ISO 32000-2 §12.8.5	Đọc cho chuỗi lưu trữ
Bên nhận tính lại digest của nội dung; nó phải bằng với thuộc tính messageDigest	RFC 5652 §5.6 / §5.4	Được thực thi
Chứng chỉ TSA mang một EKU id-kp-timeStamping đơn lẻ, critical	RFC 3161 §2.3	Được kiểm tra tại genTime
genTime là thời điểm tạo theo UTC	RFC 3161 §2.4.2	Được dùng làm thời điểm kiểm tra
Các biến trạng thái xử lý chính sách (explicit_policy, inhibit_anyPolicy)	RFC 5280 §6.1.2	Được xử lý
Bước kết thúc lấy giao của cây valid-policy với user-initial-policy-set	RFC 5280 §6.1.4	Được thực thi
Các mục DSS và dấu thời gian tài liệu cho các chữ ký dài hạn	ETSI EN 319 142-2 §5.5	Được kiểm tra làm bằng chứng lưu trữ

Tất cả các điều khoản đều được diễn giải lại. NextPDF không tái tạo văn bản quy phạm; hãy tham khảo các tiêu chuẩn đã công bố để biết nội dung chính thức. NextPDF không đưa ra tuyên bố chứng nhận AdES / PAdES nào. Phía xác minh hiện thực các kiểm tra mật mã được mô tả trong các đặc tả được trích dẫn; nó không phải là dịch vụ xác minh được chứng nhận và không tạo ra chứng thực của bên thứ ba.

Hành vi ở chế độ FIPS

Khi hồ sơ FIPS của Enterprise đang hoạt động, ràng buộc áp dụng cho các thuật toán digest và chữ ký mà trình xác minh chấp nhận. Logic xác minh, bao gồm việc tính lại digest, kiểm tra chữ ký, ràng buộc chứng chỉ, và kiểm tra đường dẫn, không thay đổi.

Mô hình mối đe dọa

Tài sản	Đối thủ	Rủi ro	Biện pháp giảm thiểu
Token dấu thời gian	Token bị giả mạo hoặc bị thay đổi	Một bằng chứng tồn tại sai	Xác minh mật mã đầy đủ; fail-closed với mọi thứ không xác minh được
Chứng chỉ TSA	Bên cấp không tin cậy	Sự tin cậy bề ngoài mà trình xác minh không nên khẳng định	Chuỗi được kiểm tra tới anchor do bên gọi cung cấp tại genTime; chuỗi không tin cậy không bao giờ thông qua
Các byte tài liệu	Nối-thêm-sau-dấu-thời-gian	Nội dung có được sức nặng của một dấu thời gian mà không được phủ	Imprint được gắn với chính các byte ByteRange + quy tắc phủ đến EOF
Thuật toán yếu	Hạ cấp xuống SHA-1 / phương án không được hỗ trợ	Một chữ ký yếu bị hiểu là hợp lệ	SHA-1 bị hạ cấp; RSASSA-PSS / EdDSA / SHA-3 fail-closed

Cổng phiên bản

Phía xác minh này là năng lực của Enterprise và đi kèm trong gói nextpdf/enterprise. NextPDF Core phát hiện sự hiện diện của chữ ký và tạo các chữ ký B-B / B-T, nhưng không cung cấp phía xác minh mật mã này. Nhận giấy phép.

Cờ tính năng giấy phép

Phía xác minh được cổng-hóa bởi phiên bản Enterprise (license_feature_flag: enterprise). Nó được phân giải thông qua các contract Core và Pki; giao diện lập trình ứng dụng (API) công khai không thay đổi khi nâng cấp phiên bản.

Hợp đồng hành vi

• Một token CMS hoặc dấu thời gian chỉ được chấp nhận với đúng một SignerInfo, các thuộc tính đã ký được phân tích nghiêm ngặt, một chứng chỉ ký được phân giải, một message-digest khớp, ràng buộc signing-certificate bắt buộc, và một chữ ký SignerInfo xác minh được.
• Chứng chỉ TSA được kiểm tra tại genTime của token: một EKU id-kp-timeStamping đơn lẻ, critical, thời hạn hiệu lực, chuỗi được neo vào trust anchor, và tình trạng thu hồi.
• Một phán quyết Valid còn yêu cầu trạng thái không-bị-thu-hồi một cách chắc chắn: ít nhất một Good có thẩm quyền (một phản hồi OCSP được xác-minh-là-good, hoặc một CRL mới đặt số serial nằm ngoài danh sách chưa hết hạn). Một trạng thái chỉ là không-chứng-minh-được-bị-thu-hồi, khi cả OCSP và CRL đều là Unknown hoặc Unavailable, sẽ phân giải thành Indeterminate, không bao giờ là Valid (ETSI EN 319 102-1: tình trạng thu hồi không-có-sẵn → INDETERMINATE). Bởi vì đường dẫn dự phòng CRL chỉ chứng thực độ mới của danh sách chứ không phải tình trạng thu hồi theo từng-serial, một chuỗi chỉ-CRL mà không có Good OCSP thường là Indeterminate.
• validateArchivalTimestampChain() chỉ đạt trạng thái thông qua hoàn toàn đối với một chuỗi DocTimeStamp đầy đủ, được neo vào trust anchor, và phủ đến EOF; nó chứng minh việc phủ dải byte, không phải khả năng truy cập xref.
• Việc xử lý chính sách chứng chỉ tuân theo RFC 5280 §6.1.4; các chuỗi mặc định không bị ràng buộc thì không bị ảnh hưởng.
• Các thuật toán được hỗ trợ là RSA (PKCS#1 v1.5 với SHA-2) và ECDSA (P-256/384/521); RSASSA-PSS, EdDSA, và SHA-3 fail closed; SHA-1 bị hạ cấp.

Tình trạng rà soát NDA

Trang công khai này chỉ mô tả hành vi của phía xác minh có thể quan sát từ bên ngoài. Nó nêu tên engine công khai, các contract Pki / trust-anchor, và phương thức validateArchivalTimestampChain() thông qua bề mặt được hỗ trợ. Phần nội bộ DER, CMS, bộ xử lý chính sách, và path-validator cụ thể nằm trong tài liệu tham khảo chuyên sâu được cổng-hóa, theo thỏa thuận bảo mật (NDA).

Phương án dự phòng Core

NextPDF Core phát hiện sự hiện diện của chữ ký và tạo các chữ ký B-B / B-T, nhưng không xác minh mật mã CMS hoặc token dấu thời gian, không kiểm tra chuỗi lưu trữ, cũng không chạy xử lý chính sách RFC 5280 §6.1.4. Một triển khai chỉ-Core không có phía xác minh tương đương; xem Security / Signing (Core).

Phương án dự phòng Pro

NextPDF Pro bổ sung các strategy ký và xử lý hóa đơn điện tử, nhưng không cung cấp phía xác minh mật mã này; kiểm tra chuỗi lưu trữ và xử lý chính sách chứng chỉ chỉ đi kèm trong nextpdf/enterprise.

Ghi chú ranh giới Enterprise

Phía xác minh được mô tả ở mức hành vi. Ngăn xếp DER nghiêm ngặt, trình phân tích CMS, bộ xử lý chính sách, và phần nội bộ path-validator nằm ngoài phạm vi bề mặt công khai và không được tái tạo ở đây.

Ranh giới triển khai

Việc xác minh phụ thuộc vào kho trust anchor và mọi dữ liệu thu hồi mà bên gọi cung cấp hoặc được nhúng trong tài liệu. NextPDF Enterprise đánh giá dữ liệu đó; nó không vận hành trust list, TSA, hay dịch vụ thu hồi. Đơn vị vận hành chịu trách nhiệm chọn anchor và bảo đảm độ mới của dữ liệu thu hồi được nhúng.

Ranh giới tuân thủ pháp lý

Trang này được đánh dấu export_control_class: legal-review-required; nó liên quan đến xác minh mật mã. Phê duyệt pháp lý là bắt buộc trước khi cờ publish được đặt. Một kết quả xác minh tích cực là phát biểu mật mã về chữ ký và dấu thời gian của tài liệu. Nó không phải là ý kiến pháp lý, xác định chuẩn năng lực eIDAS, hay chứng nhận. NextPDF không đưa ra tuyên bố chứng nhận AdES / PAdES nào. Hãy tham khảo cố vấn tuân thủ và pháp lý của riêng bạn về các nghĩa vụ pháp lý của bạn.

Xem thêm

• Signature: trình tạo PAdES B-LT / B-LTA — phía tạo.
• Validation — kiểm tra chính sách cấu trúc trong tiến trình (không mật mã).
• Archive: DSS, VRI, sức khỏe LTV — lưu trữ dài hạn và sức khỏe LTV.
• Security / Signing (Core) — CMS, RFC 3161, kiểm tra đường dẫn RFC 5280, OCSP/CRL.
• Ánh xạ baseline PAdES — B-B, B-T, B-LT, B-LTA trên các phiên bản.
• PAdES · DSS · LTV — thuật ngữ glossary.