Xác thực chữ ký theo lô

Tổng quan nhanh

NextPDF Enterprise xác thực chữ ký số trên nhiều tài liệu PDF trong một lời gọi. NextPDF\Enterprise\Signature\BatchSignatureValidator::validate() nhận một danh sách tài liệu và trả về một BatchValidationReport. Mọi chữ ký đều đi qua cùng một pipeline fail-closed: xác thực CMS bằng mật mã trên dải byte đã ký, xác thực chuỗi chứng chỉ neo tin cậy, và kiểm tra thu hồi OCSP/CRL. Báo cáo mang chi tiết theo từng tài liệu và từng chữ ký — CertChainStatus, RevocationStatus, TimestampStatus — để công cụ tuân thủ có thể tái suy ra mọi phán quyết từ bằng chứng đã ghi lại của nó.

Mô hình phán quyết cố ý nghiêm ngặt. Một chữ ký chỉ là Valid khi mọi bằng chứng được thiết lập một cách khẳng định. Thiếu bằng chứng thu hồi cho ra Indeterminate, không bao giờ Valid. Trang này bao quát bộ điều phối lô và các kiểu kết quả của nó. Phía xác minh AdES cho tài liệu đơn được ghi trong Xác minh chữ ký. Việc nhúng vật liệu xác thực dài hạn được ghi trong Archive.

Khả dụng & cấp phép

Năng lực này đi kèm trong NextPDF Enterprise (nextpdf/enterprise) và kích hoạt bằng một phong bì giấy phép cấp Enterprise. Một triển khai không có quyền này sẽ không nạp các lớp của năng lực. So sánh các phiên bản và lấy giấy phép.

Cài đặt

composer require nextpdf/enterprise

Metapackage nextpdf/premium cũng giải quyết gói Enterprise. Việc kích hoạt dùng phong bì giấy phép Enterprise của bạn; xem Cấp phép và kích hoạt. Các kiểu lô tự động nạp dưới NextPDF\Enterprise\Signature. Không cần phần mở rộng PHP nào ngoài mức nền của engine.

Tổng quan khái niệm

Một lời gọi tới validate() xử lý một danh sách các giá trị DocumentSignatureInput. Mỗi đầu vào mang một định danh tài liệu, các byte PDF thô, và các neo tin cậy mã hóa PEM tùy chọn. Bộ xác thực trích xuất các từ điển chữ ký của mỗi tài liệu và chạy ba giai đoạn cho từng chữ ký.

Giai đoạn 1 — xác thực bằng mật mã. Khối CMS/PKCS#7 tách rời từ /Contents được xác minh trên các byte mà /ByteRange bao phủ. Bộ xác minh tự tính lại phần tóm lược nội dung và so sánh nó với thuộc tính đã ký messageDigest. Nó không bao giờ tin một phần tóm lược mà bên tạo cung cấp (RFC 5652 §5.6). Giá trị chữ ký phải xác minh được, và chứng chỉ ký phải được gắn với CMS. Thiếu hoặc dị dạng /Contents hay /ByteRange, một CMS không thể phân tích, một phần tóm lược không khớp, hay một lần kiểm tra chữ ký thất bại — tất cả đều fail closed. Một chữ ký xác minh được dưới SHA-1 bị coi là yếu và không bao giờ là một lần đạt trọn vẹn.

Giai đoạn 2 — xác thực chuỗi và neo tin cậy. Chuỗi bên ký được khôi phục từ CMS được xác thực như đường dẫn chứng thực dự kiến. Các trustedCerts bạn cung cấp là đầu vào neo tin cậy, theo nghĩa RFC 5280 §6.1.1: điểm cuối chuỗi phải khớp một neo được cung cấp bằng vân tay DER SHA-256. Một chuỗi nhất quán về mặt cấu trúc nhưng điểm cuối không phải là một neo đã cấu hình thì không bao giờ được báo là tin cậy. Khi không có neo dùng được, chỉ phán quyết cấu trúc được báo cáo, và CertChainStatus::$trusted giữ nguyên false.

Giai đoạn 3 — thu hồi. Thu hồi chạy trên chuỗi đã khôi phục sau khi xác thực, phản ánh mô hình ETSI EN 319 102-1 nơi việc kiểm tra thu hồi diễn ra sau khi xác thực đường dẫn thành công (clause 5.2.6.2). OCSP là chính: chỉ một phản hồi được xác minh bằng mật mã mới được tính, là Good hoặc Revoked. Đường dẫn CRL là dự phòng và chứng thực độ tươi mới của danh sách. Khi không có client nào được cấu hình, trạng thái là unavailable.

Phán quyết theo từng chữ ký là một SignatureValidationStatus. Bảng phân loại phản ánh mô hình trạng thái ETSI EN 319 102-1 (TOTAL-PASSED / TOTAL-FAILED / INDETERMINATE) ở mức chi tiết từng chữ ký:

Bằng chứng	Phán quyết
Chứng chỉ được xác nhận đã thu hồi	Invalid (quyết định, bất kể các kiểm tra khác)
Xác thực CMS thất bại, không khôi phục được vật liệu bên ký	Error
Xác thực CMS thất bại, có mặt vật liệu bên ký	Invalid
Đã xác thực, nhưng chuỗi không hợp lệ	Invalid (hoặc Error khi không có chuỗi)
Đã xác thực và chuỗi hợp lệ, nhưng không có neo tin cậy được xác nhận	Indeterminate
Đã xác thực, chuỗi hợp lệ, tin cậy, nhưng không có xác nhận không-thu-hồi kết luận	Indeterminate
Tất cả những điều trên được thiết lập khẳng định	Valid

Quy tắc không-thu-hồi kết luận. “Chưa được chứng minh là đã thu hồi” không giống với “được chứng minh là không thu hồi”. Một phán quyết Valid đòi hỏi ít nhất một kết quả thu hồi Good. Một phản hồi OCSP verified-good là dạng kết luận: nó khẳng định trạng thái của chính chứng chỉ bên ký. Một CRL được chấp nhận bằng mật mã, còn tươi mới cũng thỏa mãn cổng này trong bản triển khai này, nhưng chỉ như một chứng thực độ tươi mới và tính toàn vẹn — đường dẫn không phân tích các mục theo từng số sê-ri, nên nó không cung cấp đảm bảo thu hồi theo từng số sê-ri và không bao giờ một phán quyết revoked khẳng định. Hãy cấu hình OCSP ở bất cứ đâu mà việc phát hiện thu hồi khẳng định là quan trọng: một triển khai chỉ có CRL sẽ không làm hiện một chứng chỉ đã thu hồi như Invalid. Khi cả kết quả OCSP và CRL đều là Unknown hoặc Unavailable, trạng thái thu hồi là chưa xác định, và phán quyết là Indeterminate. Điều này tuân theo ETSI EN 319 102-1: thông tin trạng thái thu hồi không khả dụng cho ra INDETERMINATE, không bao giờ là một lần đạt (clause 5.1.3, TRY_LATER). Đây là một sự làm cứng hành vi trong 3.1.0 có tác động đến tương thích ngược: các bản phát hành trước có thể báo Valid mà không có bằng chứng thu hồi kết luận. Các triển khai không cấu hình client OCSP hay CRL nào giờ thường thấy Indeterminate ở nơi trước đây họ thấy Valid.

Hai ranh giới định khung năng lực này một cách trung thực. Thứ nhất, bộ xác thực lô không đánh giá các token dấu thời gian nhúng: TimestampStatus trong kết quả lô luôn là trạng thái vắng mặt. Đánh giá dấu thời gian RFC 3161 thuộc về phía xác minh tài liệu đơn; xem Xác minh chữ ký. Thứ hai, trang này là xác thực chỉ đọc. Nhúng vật liệu DSS/VRI cho hiệu lực dài hạn là năng lực Archive.

Vì sao nó hoạt động theo cách này

Quyết định chịu tải là một bộ tạo phán quyết fail-closed. Valid chỉ được đúc từ bằng chứng khẳng định trên cả ba trục: xác thực bằng mật mã, một chuỗi neo tin cậy, và không-thu-hồi kết luận. Bất cứ điều gì chưa được thiết lập đều xuống cấp thành Indeterminate thay vì mặc định thành một lần đạt, đó là tư thế EN 319 102-1 cho vật liệu thu hồi bị thiếu. Thông lượng lô không bao giờ mua lại sự nghiêm ngặt: lớp lô là điều phối trên cùng một bộ xác minh CMS đã được kiểm toán dùng cho một tài liệu đơn, nên một lần chạy 1.000 tài liệu áp dụng cùng một mật mã. Báo cáo cũng tách bằng chứng khỏi phán quyết — CertChainStatus và RevocationStatus ghi lại các đầu vào mà mỗi phán quyết dựa trên, để một kiểm toán viên có thể tái suy ra nó về sau.

Bối cảnh thiết kế: Ký ở quy mô lớn, không thỏa hiệp.

Bề mặt API

Tất cả các ký hiệu bên dưới là public API trong nextpdf/enterprise 3.1.0.

BatchSignatureValidator

final class BatchSignatureValidator
{
    public function __construct(
        ?SignatureExtractor $extractor = null,
        ?CertificateChainValidator $chainValidator = null,
        private readonly ?OcspClient $ocspClient = null,
        private readonly ?CrlFetcher $crlFetcher = null,
        ?CmsSignatureDataExtractor $cmsExtractor = null,
        private readonly ClockInterface $clock = new SystemClock(),
    )

    public function validate(array $inputs): BatchValidationReport
}

Ném hoặc thất bại với: validate() ném \InvalidArgumentException nếu danh sách đầu vào rỗng, và \OverflowException khi lô vượt quá 1.000 tài liệu. Một tài liệu không phải là PDF phân tích được thì không ném; nó trở thành một kết quả Error theo từng tài liệu. $clock là một Psr\Clock\ClockInterface PSR-20 dùng cho quyết định độ tươi mới của CRL, nên các phán quyết là tất định dưới một đồng hồ kiểm thử được đóng băng.

DocumentSignatureInput

final readonly class DocumentSignatureInput
{
    public string $documentId;

    public function __construct(
        string $documentId,
        public string $pdfData,
        public array $trustedCerts = [],
    )
}

Ném hoặc thất bại với: \InvalidArgumentException nếu $documentId là chuỗi rỗng. $trustedCerts là một danh sách chứng chỉ neo tin cậy mã hóa PEM.

BatchValidationReport

final readonly class BatchValidationReport
{
    public function __construct(
        public array $documents,
        public int $totalDocuments,
        public int $totalSignatures,
        public int $totalValid,
        public int $totalInvalid,
        public float $durationMs,
    )

    public function allValid(): bool

    public function hasDocumentsWithoutSignatures(): bool

    public function toJson(?CertPiiGuard $piiGuard = null): string
}

Ném hoặc thất bại với: toJson() ném \JsonException nếu mã hóa thất bại. allValid() là true chỉ khi có chữ ký và không có chữ ký nào là non-valid. Theo mặc định toJson() áp dụng một NextPDF\Enterprise\Signature\Eidas\CertPiiGuard với chế độ riêng-tư-mặc-định, che tên bên ký, nhà phát hành gốc, tên TSA, và chẩn đoán vấn đề chuỗi; xem Mức đảm bảo eIDAS để biết API của guard.

DocumentValidationResult và DocumentValidationStatus

final readonly class DocumentValidationResult
{
    public function __construct(
        public string $documentId,
        public DocumentValidationStatus $status,
        public array $signatures,
        public int $validCount,
        public int $invalidCount,
    )

    public function hasSignatures(): bool

    public function totalSignatures(): int
}

enum DocumentValidationStatus: string
{
    case AllValid = 'all_valid';
    case SomeInvalid = 'some_invalid';
    case AllInvalid = 'all_invalid';
    case NoSignatures = 'no_signatures';
    case Error = 'error';
}

Ném hoặc thất bại với: không có gì. Value object bất biến và backed enum.

SignatureValidationResult và SignatureValidationStatus

final readonly class SignatureValidationResult
{
    public function __construct(
        public SignatureValidationStatus $status,
        public CertChainStatus $certChain,
        public TimestampStatus $timestamp,
        public RevocationStatus $revocation,
        public string $signer,
        public string $level = '',
        public string $subFilter = '',
        public string $reason = '',
    )

    public function isValid(): bool
}

enum SignatureValidationStatus: string
{
    case Valid = 'valid';
    case Invalid = 'invalid';
    case Indeterminate = 'indeterminate';
    case Error = 'error';
}

Ném hoặc thất bại với: không có gì. $signer là chủ thể chứng chỉ được CMS xác minh khi xác thực đạt, ngược lại là chuỗi rỗng. $level là một nhãn dẫn xuất từ SubFilter (ví dụ B-B cho ETSI.CAdES.detached), không phải một xác định về mức tuân thủ AdES.

CertChainStatus

final readonly class CertChainStatus
{
    public function __construct(
        public bool $valid,
        public bool $trusted,
        public int $chainLength,
        public string $rootIssuer,
        public array $issues = [],
    )

    public function hasIssues(): bool
}

Ném hoặc thất bại với: không có gì. $trusted chỉ được đặt khi có một lần trúng thành viên neo tin cậy được xác nhận, không bao giờ từ việc danh sách neo không rỗng.

RevocationStatus và RevocationCheckResult

final readonly class RevocationStatus
{
    public function __construct(
        public RevocationCheckResult $ocspStatus,
        public RevocationCheckResult $crlStatus,
        public bool $isRevoked,
        public ?DateTimeImmutable $revocationDate = null,
    )

    public static function unavailable(): self

    public function hasConclusiveGood(): bool
}

enum RevocationCheckResult: string
{
    case Good = 'good';
    case Revoked = 'revoked';
    case Unknown = 'unknown';
    case Unavailable = 'unavailable';
}

Ném hoặc thất bại với: không có gì từ các thành viên được hiển thị. Lớp này cũng phơi bày các static factory được kiểm-chứng-bằng-bằng-chứng (good(), revoked(), fromResults()), chúng ném \InvalidArgumentException khi trạng thái được tuyên bố mâu thuẫn với bằng chứng OCSP/CRL — một kết quả revoked không bao giờ có thể được đúc thành not-revoked, hay ngược lại. hasConclusiveGood() là true chỉ cho một trạng thái not-revoked nơi ít nhất một kiểm tra là Good.

TimestampStatus

final readonly class TimestampStatus
{
    public function __construct(
        public bool $present,
        public bool $valid,
        public ?DateTimeImmutable $timestampTime = null,
        public string $tsaName = '',
        public array $issues = [],
    )

    public static function absent(): self
}

Ném hoặc thất bại với: không có gì. Trong kết quả lô, đây luôn là trạng thái absent(); xem Trường hợp biên & bẫy ngầm.

Mẫu mã — Bắt đầu nhanh

Xác thực một tài liệu và đọc báo cáo. Mẫu này dùng một PDF chưa ký, nên đầu ra là tất định.

batch-quick-start.php

<?php

declare(strict_types=1);

require __DIR__ . '/vendor/autoload.php';

use NextPDF\Enterprise\Signature\BatchSignatureValidator;
use NextPDF\Enterprise\Signature\DocumentSignatureInput;

// A minimal, unsigned PDF: the validator reports it as no_signatures.
$unsigned = "%PDF-1.7\n1 0 obj\n<< /Type /Catalog >>\nendobj\ntrailer\n<< /Root 1 0 R >>\n%%EOF\n";

$validator = new BatchSignatureValidator();

try {
    $report = $validator->validate([
        new DocumentSignatureInput(documentId: 'doc-001', pdfData: $unsigned),
    ]);
} catch (\InvalidArgumentException $e) {
    // Empty input list, or an empty documentId.
    echo 'Rejected: ' . $e->getMessage() . "\n";
    exit(1);
}

echo 'Documents: ' . $report->totalDocuments . "\n";
echo 'Signatures: ' . $report->totalSignatures . "\n";

foreach ($report->documents as $doc) {
    echo $doc->documentId . ': ' . $doc->status->value . "\n";
}

echo 'All valid: ' . ($report->allValid() ? 'yes' : 'no') . "\n";
echo 'Unsigned documents: ' . ($report->hasDocumentsWithoutSignatures() ? 'yes' : 'no') . "\n";

Đầu ra mong đợi:

Documents: 1
Signatures: 0
doc-001: no_signatures
All valid: no
Unsigned documents: yes

Lưu ý rằng allValid() báo no ở đây: nó đòi hỏi ít nhất một chữ ký và không có kết quả non-valid nào, nên một tập chữ ký rỗng không bao giờ đạt một cách âm thầm.

Mẫu mã — Sản xuất

Xác thực một thư mục hợp đồng đã ký với các client thu hồi, neo tin cậy, chia lô, và một báo cáo JSON được bảo vệ PII.

batch-validate-contracts.php

<?php

declare(strict_types=1);

require __DIR__ . '/vendor/autoload.php';

use NextPDF\Enterprise\Security\Ltv\CrlFetcher;
use NextPDF\Enterprise\Security\Ltv\OcspClient;
use NextPDF\Enterprise\Security\Ltv\OcspResponseCache;
use NextPDF\Enterprise\Signature\BatchSignatureValidator;
use NextPDF\Enterprise\Signature\DocumentSignatureInput;
use NextPDF\Enterprise\Signature\SignatureValidationStatus;

// Any PSR-18 client works; Guzzle shown here.
$httpClient = new \GuzzleHttp\Client(['timeout' => 10]);

// Revocation clients make a conclusive non-revoked (Good) result reachable.
// Without them, every verdict tops out at Indeterminate. The response cache
// lets repeat signers across the batch resolve without extra network calls.
$validator = new BatchSignatureValidator(
    ocspClient: new OcspClient($httpClient, cache: new OcspResponseCache()),
    crlFetcher: new CrlFetcher($httpClient),
);

// Trust anchors are an input: the chain terminus must match one of these.
$anchors = [(string) file_get_contents('/etc/nextpdf/trust/enterprise-root.pem')];

$inputs = [];
foreach (glob('/var/contracts/signed/*.pdf') ?: [] as $path) {
    $inputs[] = new DocumentSignatureInput(
        documentId: basename($path),
        pdfData: (string) file_get_contents($path),
        trustedCerts: $anchors,
    );
}

$exit = 0;

// One call is capped at 1,000 documents; chunk larger runs.
foreach (array_chunk($inputs, 1000) as $batch) {
    try {
        $report = $validator->validate($batch);
        // Signer PII is redacted by default in the serialized report.
        file_put_contents('/var/log/nextpdf/batch-report.jsonl', $report->toJson() . PHP_EOL, FILE_APPEND); // one JSON document per line
    } catch (\InvalidArgumentException | \OverflowException $e) {
        fwrite(STDERR, 'Batch rejected: ' . $e->getMessage() . "\n");
        exit(2);
    } catch (\JsonException $e) {
        fwrite(STDERR, 'Report encoding failed: ' . $e->getMessage() . "\n");
        exit(3);
    }

    foreach ($report->documents as $doc) {
        foreach ($doc->signatures as $sig) {
            if ($sig->status !== SignatureValidationStatus::Valid) {
                $exit = 1;
                fwrite(STDERR, sprintf(
                    "%s: %s (chain trusted: %s, revoked: %s)\n",
                    $doc->documentId,
                    $sig->status->value,
                    $sig->certChain->trusted ? 'yes' : 'no',
                    $sig->revocation->isRevoked ? 'yes' : 'no',
                ));
            }
        }
    }
}

exit($exit);

Đầu ra mong đợi (stderr, cho một tài liệu có bằng chứng thu hồi không khả dụng; các dòng khác thay đổi theo đầu vào của bạn):

contract-0042.pdf: indeterminate (chain trusted: yes, revoked: no)

Báo cáo JSON tuần tự hóa các trường danh tính bên ký qua CertPiiGuard mặc định, nên một mục theo từng chữ ký trông như thế này (trích đoạn, minh họa):

{
    "status": "indeterminate",
    "signer": "[REDACTED]",
    "level": "B-B",
    "subFilter": "ETSI.CAdES.detached"
}

Trường hợp biên & bẫy ngầm

• Một danh sách đầu vào rỗng ném \InvalidArgumentException; hơn 1.000 tài liệu trong một lời gọi ném \OverflowException. Chia nhỏ các lần chạy lớn hơn, như trong mẫu sản xuất.
• Nâng cấp từ các bản phát hành trước: khi không có client OCSP hay CRL được cấu hình, thu hồi là unavailable, nên không chữ ký nào có thể đạt Valid. Các bản phát hành trước báo Valid ở đây; 3.1.0 báo Indeterminate (xem Tổng quan khái niệm).
• Các bộ đếm ở mức tài liệu là nghiêm ngặt: chỉ Valid tăng validCount. Invalid, Indeterminate, và Error đều tăng invalidCount. Một tài liệu mà chữ ký duy nhất của nó là Indeterminate do đó báo all_invalid. Hãy gác theo status từng chữ ký khi sự phân biệt đó quan trọng.
• Kiểm tra OCSP chỉ chạy khi chuỗi đã khôi phục có ít nhất hai chứng chỉ, vì truy vấn cần nhà phát hành. Một chuỗi một-chứng-chỉ rơi xuống đường dẫn CRL hoặc unavailable.
• crlStatus không bao giờ báo revoked trong kết quả lô. Dự phòng CRL chỉ chứng thực độ tươi mới của danh sách; một kết quả revoked có thẩm quyền đến từ OCSP.
• timestamp luôn là absent() trong kết quả lô. Bộ xác thực lô không đánh giá các token RFC 3161 nhúng; dùng Xác minh chữ ký để đánh giá dấu thời gian.
• signer rỗng khi xác thực thất bại. Khi được đặt, nó là subject CN (hoặc O) của chứng chỉ được CMS xác minh — không bao giờ là chuỗi /Name chưa xác thực từ từ điển chữ ký.
• Các mục trustedCerts phải là chứng chỉ PEM. Một danh sách neo rỗng hoặc dị dạng cho ra một phán quyết chuỗi chỉ-cấu-trúc với trusted: false, giới hạn phán quyết ở mức Indeterminate.
• Các byte không bắt đầu bằng một header PDF tạo ra một trạng thái error theo từng tài liệu với không chữ ký nào — không có ngoại lệ.
• toJson() che PII theo mặc định. Chỉ truyền new CertPiiGuard(disclosePii: true) ở nơi bạn có một cơ sở pháp lý được ghi chép để xử lý danh tính bên ký.

Ghi chú bảo mật

• Bộ tạo phán quyết fail-closed. Valid đòi hỏi tất cả: xác thực CMS đã xác minh trên phần tóm lược /ByteRange, một chuỗi hợp lệ, thành viên neo tin cậy được xác nhận, và một trạng thái non-revoked kết luận. Mọi kiểm tra chưa được thiết lập đều xuống cấp phán quyết; không có gì mặc định thành một lần đạt.
• Không rửa danh tính. Bên ký được báo cáo là chủ thể chứng chỉ được gắn bằng mật mã. Mục /Name là siêu dữ liệu do kẻ tấn công kiểm soát và không bao giờ được làm hiện như bên ký.
• Các thuật toán yếu không bao giờ đạt. Một chữ ký SHA-1 xác minh được vẫn được báo là non-valid; tính hợp lệ mật mã dưới một phần tóm lược yếu không được rửa thành một lần đạt trọn vẹn.
• Tin cậy là một đầu vào, không phải một suy diễn. Các neo bạn cung cấp được đối chiếu với điểm cuối chuỗi bằng vân tay DER SHA-256 (RFC 5280 §6.1.1). Tính tự-nhất-quán của một chuỗi, hay chỉ một danh sách neo không rỗng, không bao giờ thiết lập tin cậy.
• Thu hồi có tính quyết định. Một tuyên bố revoked đã xác minh buộc Invalid bất kể mọi kiểm tra khác; bằng chứng không khả dụng buộc Indeterminate.
• Riêng tư theo mặc định trong đầu ra tuần tự hóa. toJson() che signer CN, root issuer DN, tên TSA, và chẩn đoán vấn đề chuỗi trừ khi bạn chọn không tham gia, hiện thực hóa việc giảm thiểu dữ liệu theo GDPR Article 5(1)(c) tại ranh giới tuần tự hóa.
• Thời gian tất định. Quyết định độ tươi mới của CRL đọc đồng hồ PSR-20 được tiêm vào, không phải đồng hồ tường của máy chủ, nên các phán quyết thu hồi có thể tái lập dưới kiểm thử.

Tuân thủ

NextPDF Enterprise hiện thực hành vi được thông tin bởi ETSI EN 319 102-1 (mô hình trạng thái xác thực ba giá trị và quy tắc rằng thông tin thu hồi không khả dụng cho ra INDETERMINATE), RFC 5652 §5.6 (tính lại phần tóm lược ở phía xác minh), và RFC 5280 §6.1 (các neo tin cậy như đầu vào của bên tin cậy vào xác thực đường dẫn). Hỗ trợ không phải là tuân thủ, và tuân thủ không phải là chứng nhận. NextPDF không nắm giữ chứng nhận nào và không cấp gì. Bộ xác thực lô không phải là một dịch vụ xác thực đủ điều kiện, và các trạng thái của nó là các phán quyết kỹ thuật thẳng hàng với bảng phân loại EN 319 102-1 — không phải các chỉ báo TOTAL-PASSED/TOTAL-FAILED/INDETERMINATE từ một quy trình xác thực clause 5 đầy đủ. Đặc biệt, chế độ lô không thực hiện xử lý bằng-chứng-tồn-tại hay dấu thời gian; phía xác minh tài liệu đơn bao phủ phần đó.

Hành vi chế độ FIPS

Bộ xác thực lô không tham vấn chính sách chế độ FIPS nào, và việc bật chế độ FIPS không thay đổi các phán quyết lô. Việc xử lý thuật toán ở phía xác minh của nó là cố định và fail-closed: các chữ ký yếu (SHA-1) không bao giờ được báo Valid, có hay không có chế độ FIPS. Chính sách chế độ FIPS của Enterprise gác phía ký/tạo, được ghi trong FIPS 140 — Deep Reference. Hỗ trợ FIPS 140 là một tuyên bố năng lực, không phải một khẳng định xác thực hay chứng nhận.

Hợp đồng hành vi

• validate() ném \InvalidArgumentException cho một danh sách rỗng và \OverflowException trên 1.000 tài liệu. Các tài liệu dị dạng không bao giờ ném; chúng tạo ra các kết quả error theo từng tài liệu.
• Valid đòi hỏi phép hội: CMS được xác minh bằng mật mã, chuỗi hợp lệ, thành viên neo tin cậy được xác nhận, và RevocationStatus::hasConclusiveGood() là true.
• Một chứng chỉ đã-xác-nhận-thu-hồi có tính quyết định: phán quyết là Invalid bất kể mọi bằng chứng khác.
• Cả hai kiểm tra thu hồi Unknown/Unavailable nghĩa là Indeterminate, không bao giờ Valid (làm cứng 3.1.0, tác động tương thích ngược).
• Một chữ ký đã xác thực, chuỗi hợp lệ nhưng không có neo tin cậy được xác nhận là Indeterminate — xác thực, tin cậy chưa được thiết lập.
• signer là chủ thể được CMS xác minh hoặc chuỗi rỗng; mục /Name không bao giờ được dùng.
• timestamp luôn là trạng thái vắng mặt trong kết quả lô.
• validCount chỉ đếm Valid; tất cả trạng thái khác đếm vào invalidCount, và trạng thái tài liệu tổng hợp từ các bộ đếm đó.
• toJson() áp dụng CertPiiGuard với chế độ riêng-tư-mặc-định trừ khi một guard được truyền một cách tường minh.
• Các tổng của báo cáo là các tổng chính xác trên các kết quả từng tài liệu; durationMs là thời gian tường đo được cho lô.

Dự phòng Core

Module Security / Signing của NextPDF Core là phía tạo: nó tạo các chữ ký CMS, áp dụng các dấu thời gian RFC 3161, và xác thực chuỗi và thu hồi cho vật liệu nó nhúng lúc ký. Core không đi kèm bộ điều phối lô phía xác minh: không có báo cáo đa tài liệu, không có bảng phân loại trạng thái tổng hợp, không có phán quyết thu hồi OCSP/CRL cho tài liệu bên thứ ba, và không có tuần tự hóa báo cáo được bảo vệ PII. Chỉ với Core, bạn sẽ tự trích xuất và xác minh từng chữ ký và xây dựng báo cáo của riêng mình. Phía xác minh tài liệu đơn của Enterprise (Xác minh chữ ký) và bộ điều phối lô này cung cấp lớp đó.

Ranh giới công bố

Trang này ghi lại chỉ hành vi quan sát được từ bên ngoài và bề mặt public API được hỗ trợ. Các đường dẫn không gian tên nội bộ, các lớp trợ giúp, các bảng cơ chế, các tên tệp runbook, và các tiền tố phiếu nằm ngoài phạm vi.

Xem thêm

• Xác minh chữ ký — phía xác minh mật mã AdES/PAdES cho tài liệu đơn, bao gồm xác thực dấu thời gian và chuỗi lưu trữ
• Archive — nhúng vật liệu DSS/VRI và dấu thời gian tài liệu cho hiệu lực dài hạn
• Validation — các kiểm tra chính sách cấu trúc chỉ đọc, không có mật mã
• Signature — Deep Reference — deep reference của module Signature
• Mức đảm bảo eIDAS — API CertPiiGuard và ánh xạ mức đảm bảo
• Ký ở quy mô lớn, không thỏa hiệp — bài luận Insider về thiết kế ký và xác thực khối lượng lớn
• Xác thực một chữ ký đúng cách — bài luận Insider về vì sao xác thực fail-closed quan trọng