Przejdź do głównej zawartości

Podpis: PAdES B-LT / B-LTA, DSS, znaczniki czasu dokumentu

NextPDF Enterprise dodaje producenta walidacji długoterminowej działającego nad podpisem Core Cryptographic Message Syntax (CMS): Document Security Store (DSS), informacje walidacyjne dla każdego podpisu (VRI) oraz znaczniki czasu dokumentu. Struktury te rozszerzają bazowy podpis PDF Advanced Electronic Signatures (PAdES) z poziomu B-B do B-LT, a następnie do B-LTA. Ta strona opisuje zachowanie producenta: co zapisuje, czego nie rozstrzyga i gdzie przebiega granica Pro.

Okno terminala
composer require nextpdf/enterprise

nextpdf/enterprise zależy od nextpdf/core i nextpdf/pro. Pakiet jest rozwiązywany przy użyciu poświadczeń licencji NextPDF w Private Packagist.

Podpis bazowy PAdES obejmuje cztery poziomy. Każdy poziom dodaje materiał do poprzedniego. B-B to podpis CMS z atrybutami podpisanymi. B-T dodaje zaufany znacznik czasu RFC 3161 dla wartości podpisu. B-LT dodaje DSS, który zawiera certyfikaty, odpowiedzi Online Certificate Status Protocol (OCSP) oraz listy unieważnionych certyfikatów (CRL), których weryfikator potrzebuje po wygaśnięciu certyfikatu podpisującego. B-LTA dodaje znacznik czasu dokumentu obejmujący cały stan dokumentu, w tym DSS, dzięki czemu materiał walidacyjny pozostaje zakotwiczony w czasie.

Core tworzy strukturę CMS SignedData i przechowuje ją zakodowaną w DER we wpisie Contents słownika podpisu — ISO 32000-2 §12.8.1. Walidacja długoterminowa korzysta z dwóch typów słowników: dokumentowego magazynu zabezpieczeń oraz słownika znacznika czasu dokumentu — ISO 32000-2 §12.8. Producent Enterprise zapisuje DSS, który przechowuje materiał certyfikatów, OCSP oraz CRL — ISO 32000-2 §12.8.4.3 — a dla B-LTA słownik znacznika czasu dokumentu — ISO 32000-2 §12.8.5. ETSI EN 319 142-2 opisuje tę samą strukturę długoterminową: wpisy DSS wraz ze znacznikami czasu dokumentu dla podpisów długoterminowych — §5.5 — obsługiwane przez moduł obsługi podpisów — §6.3.3.3.

Producent zbiera materiał unieważnień dla każdego certyfikatu w łańcuchu. Najpierw odpytuje respondera OCSP; odpowiedź OCSP zgłasza good, revoked lub unknown — RFC 6960 §2.2 — a pola thisUpdate oraz nextUpdate wyznaczają aktualność statusu — RFC 6960 §4.2. Jeśli OCSP jest niedostępny, producent przechodzi na CRL. Producent przechodzi łańcuch od podpisującego w kierunku zakotwiczenia zaufania, kierując się danymi wejściowymi walidacji ścieżki — RFC 5280 §6.1.

Znacznik czasu dokumentu B-LTA to wymiana zgodna z RFC 3161 z urzędem znakowania czasem (TSA). W odpowiedzi zwracana jest wartość Time Stamp Information (TSTInfo) — RFC 3161 §2.4.1 — której pole genTime jest momentem w uniwersalnym czasie koordynowanym (UTC), w którym utworzono token — RFC 3161 §2.4.2. Token jest osadzony w słowniku /DocTimeStamp z /SubFilter /ETSI.RFC3161, który obejmuje cały plik.

To weryfikator rozstrzyga, czy utworzony podpis przechodzi weryfikację, korzystając ze skonfigurowanych zakotwiczeń zaufania i polityki unieważnień. Producent osadza materiał; nie deklaruje zaufanego wyniku. Granica ta jest ponownie przedstawiona poniżej tam, gdzie ma to znaczenie.

Kolejność ma znaczenie strukturalne: DSS musi zostać zapisany przed znacznikiem czasu dokumentu B-LTA, ponieważ znacznik czasu musi obejmować stan dokumentu zawierający już materiał walidacyjny. Poniższy przepływ pokazuje tę sekwencję producenta.

RFC 3161 TSAOCSP or CRL responderEnterprise LtvManagerCore CMS SignerRFC 3161 TSAOCSP or CRL responderEnterprise LtvManagerCore CMS SignerB-LT — embed validation materialalt[OCSP available][OCSP unavailable]B-LTA — anchor the DSS in timeCallersign byteRange1CMS SignedData — B-B or B-T2OCSP request per chain certificate3OCSP response — good, revoked or unknown4CRL fetch — fallback5CRL6Write DSS — certs + OCSP + CRL7TimeStampReq over file incl. DSS8TimeStampToken9Verify token, embed /DocTimeStamp10Long-term PDF — B-LT or B-LTA11Caller
Diagram

Z producenta walidacji długoterminowej Enterprise korzysta się przez kontrakt Core. Kod produkcyjny zależy od kontraktu, a nie od konkretnego typu implementacji Enterprise.

TypRodzajRolaStabilnośćOd wersji
SignerInterfaceinterfejs (NextPDF\Contracts)Główny kontrakt podpisywania używany przez wywołującychstabilny1.0.0
SignatureLevelwyliczenie (NextPDF\Security\Signature)Selektor poziomu PAdES: B-B, B-T, B-LT, B-LTAstabilny1.0.0
LtvManagerInterfaceinterfejs (NextPDF\Contracts)Kontrakt producenta walidacji długoterminowej rozwiązywany w czasie wykonywaniastabilny1.0.0
TsaClientInterfaceinterfejsKlient TSA zgodny z RFC 3161, wywoływany przez producenta do uzyskania znaczników czasu dokumentustabilny1.0.0

SignatureLevel::requiresDss() zwraca prawdę dla B-LT i B-LTA; SignatureLevel::requiresDocumentTimestamp() zwraca prawdę tylko dla B-LTA. Metoda Core SignatureLevel::isAvailableInEnvironment() zwraca fałsz dla B-LT i B-LTA, gdy długoterminowy producent Enterprise nie jest zainstalowany; orkiestrator Core kończy wtedy działanie w trybie fail-closed. Konkretne klasy producenta Enterprise są wewnętrzne i nie są częścią publicznego API; zależność opieraj na LtvManagerInterface oraz wyliczeniu.

examples/contracts/pades-blt-quickstart.php
<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
use NextPDF\Security\Signature\SignatureLevel;
/**
* Select the PAdES level for a long-term signature.
*
* B-LT embeds a DSS. B-LTA also adds a document timestamp.
* Both require the nextpdf/enterprise long-term producer at runtime.
*
* @return SignatureLevel The requested PAdES baseline level.
*/
function longTermLevel(): SignatureLevel
{
return SignatureLevel::PAdES_B_LTA;
}

Konfiguracja podpisywania zawiera poziom. Orkiestrator Core rozwiązuje długoterminowego producenta przez LtvManagerInterface w czasie wykonywania, więc kod aplikacji nie odwołuje się do typu Enterprise.

examples/contracts/pades-blt-production.php
<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
use NextPDF\Contracts\LtvManagerInterface;
use NextPDF\Contracts\SignerInterface;
use NextPDF\Exception\NextPdfException;
use Psr\Log\LoggerInterface;
final readonly class LongTermSigner
{
public function __construct(
private SignerInterface $signer,
private LtvManagerInterface $ltv,
private LoggerInterface $logger,
) {}
/**
* Sign, then embed the DSS and the B-LTA document timestamp.
*
* The order matters: the DSS is written first, then the document
* timestamp is taken over the document state that already includes it.
*
* @param string $byteRange The PDF byte range to sign.
*
* @throws NextPdfException When revocation material is missing under the
* fail-closed enforcement default, or when no TSA
* is configured for B-LTA.
*/
public function sign(string $byteRange): string
{
try {
$contents = $this->signer->sign($byteRange)->toHex();
// The orchestrator drives DSS collection and the document
// timestamp through the resolved LtvManagerInterface; revocation
// freshness and TSA reachability are operational inputs.
return $contents;
} catch (NextPdfException $e) {
$this->logger->error('long-term signing failed', ['reason' => $e->getMessage()]);
throw $e;
}
}
}

DSS musi zostać zapisany przed znacznikiem czasu dokumentu. Znacznik czasu B-LTA obejmuje cały plik, w tym DSS, co zakotwicza w czasie sam materiał walidacyjny.

  • Brak materiału unieważnień domyślnie powoduje zakończenie w trybie fail-closed. Gdy nie ustawiono trybu egzekwowania, producent traktuje brak odpowiedzi OCSP oraz brak CRL dla dowolnego certyfikatu poza korzeniem jako błąd, a nie ostrzeżenie. Zapobiega to zapisaniu dokumentu deklarującego poziom długoterminowy bez materiału unieważnień w DSS. Przepływ permisywny jest opcjonalny i ogranicza się do ostrzeżeń.
  • B-LTA wymaga TSA. Znacznik czasu dokumentu to dwukierunkowa wymiana RFC 3161. Bez skonfigurowanego klienta TSA krok B-LTA zgłasza błąd, zamiast po cichu tworzyć B-LT.
  • Kolejność ma znaczenie strukturalne. Znacznik czasu dokumentu dodawaj dopiero po zapisaniu DSS. Znacznik czasu utworzony przed DSS nie obejmuje materiału walidacyjnego.
  • Uruchomienia w środowisku odizolowanym. Przy ścisłej polityce sieciowej offline producent nie wykonuje żadnego pobrania OCSP/CRL ani żądania TSA; korzysta wyłącznie z materiału już osadzonego w DSS. B-LTA, który wymaga świeżego tokenu TSA, jest nieosiągalny w trybie ścisłego offline.
  • VRI jest opcjonalne. Indywidualne VRI dla podpisu nie jest zapisywane domyślnie. Niektóre walidatory lepiej prezentują status długoterminowy, gdy VRI jest obecne; włącz je, gdy potrzebuje go docelowy weryfikator.

Koszt zbudowania DSS skaluje się wraz z długością łańcucha i liczbą pobranych odpowiedzi unieważnień. Każde pobranie OCSP lub CRL to jeden obieg sieciowy; wcześniej zebrany lub buforowany materiał eliminuje te obiegi. Uruchomienie B-LTA dodaje jeden obieg TSA na znacznik czasu dokumentu. Budżet 1500 ms czasu rzeczywistego obejmuje pojedynczy podpis długoterminowy z rozgrzanymi połączeniami OCSP/CRL oraz TSA; przy zimnych lub wolnych responderach to one mają największy wpływ na czas rzeczywisty. Profil odtwarzalności to structural: znaczniki czasu osadzają momenty podpisania i ostemplowania, więc dwa uruchomienia różnią się tymi bajtami, podczas gdy struktura dokumentu jest identyczna.

  • Zaufanie to decyzja weryfikatora. Producent osadza certyfikaty, OCSP oraz CRL. To, czy podpis przejdzie weryfikację, zależy od weryfikatora, jego zakotwiczeń zaufania i polityki aktualności unieważnień. NextPDF nie dostarcza wbudowanej listy zaufania.
  • Aktualność unieważnień jest ograniczona w czasie. Okna ważności OCSP thisUpdate/nextUpdate oraz CRL wyznaczają, jak długo osadzony materiał pozostaje użyteczny. Pętla archiwizacyjna ponownie stempluje przed wygaśnięciem certyfikatu znacznika czasu; odpowiadasz za jej obsługę zgodnie z harmonogramem.
  • Domyślny tryb fail-closed. Domyślne ścisłe egzekwowanie unieważnień zapobiega deklarowaniu poziomu długoterminowego bez materiału, który tę deklarację potwierdza.
  • Zobacz sekcję modelu zagrożeń Enterprise oraz Archiwum: DSS, VRI, kondycja LTV.

Pobieranie OCSP i CRL kontaktuje się z responderami wskazanymi w każdym certyfikacie; te punkty końcowe oraz TSA widzą metadane żądania. We wdrożeniu z ograniczeniami rezydencji danych zbierz materiał unieważnień z wyprzedzeniem i działaj w ścisłej polityce offline, aby przy podpisywaniu nie kontaktowano się z żadnym responderem ani TSA. Certyfikaty zawierają tożsamość podmiotu. Producent osadza certyfikaty wymagane do walidacji i nie dodaje tożsamości poza łańcuchem; nie usuwa pól podmiotu z dostarczonego certyfikatu.

Diagnostyka producenta zgłasza poziom, pozycję w łańcuchu oraz warunek braku materiału. Nie loguje kluczy prywatnych ani pełnych treści certyfikatów. Po podłączeniu rejestratora PSR-3 utrzymuj szczegółowość logów diagnostycznych przepływów podpisywania na poziomie nieprodukcyjnym i czyść adresy URL responderów, jeśli ujawniają wewnętrzną infrastrukturę. Osadzone bajty OCSP/CRL traktuj jako treść dokumentu, a nie treść logu.

Profil polityki kryptograficznej Federal Information Processing Standards (FIPS) 140-3 to funkcja Enterprise udokumentowana wraz z modułem bezpieczeństwa. Producent walidacji długoterminowej nie dodaje własnego prymitywu kryptograficznego poza skrótem SHA-256 używanym do znacznika czasu dokumentu i wymianą RFC 3161; prymityw podpisujący należy do modułu podpisującego Core. Gdy profil FIPS jest aktywny, tworzone są te same struktury DSS oraz znacznika czasu dokumentu; ograniczenie dotyczy bazowych algorytmów podpisywania i skrótu, a nie układu DSS.

ZasóbPrzeciwnikRyzykoŚrodek ograniczający
Materiał unieważnień DSSAkceptacja nieaktualnego materiałuWeryfikator ufa nieaktualnym danym unieważnieńPola aktualności OCSP/CRL wyznaczają ważność; pętla archiwizacyjna ponownie stempluje przed wygaśnięciem
Znacznik czasu dokumentu B-LTANaruszenie TSA lub nieosiągalny TSABrak wiarygodnego zakotwiczenia czasuTSA wybrany przez wywołującego; B-LTA kończy się w trybie fail-closed, gdy nie skonfigurowano TSA
Deklaracja długoterminowaCichy brak materiału„Długoterminowy” PDF bez danych unieważnieńDomyślne egzekwowanie fail-closed zgłasza błąd zamiast ostrzeżenia
Weryfikacja podpisuBłędnie skonfigurowane zaufanie weryfikatoraPozorna ważność, której weryfikator nie powinien deklarowaćProducent oświadcza, że jedynie osadza materiał; decyzja o zaufaniu należy do weryfikatora
DeklaracjaStandardKlauzulareference_id
Wartość podpisu (lub token znacznika czasu) jest przechowywana zakodowana w DER w /Contents.ISO 32000-2§12.8.1
Walidacja długoterminowa korzysta z DSS oraz słownika znacznika czasu dokumentu.ISO 32000-2§12.8
DSS przechowuje certyfikaty, odpowiedzi OCSP oraz CRL.ISO 32000-2§12.8.4.3
Znacznik czasu dokumentu korzysta ze słownika znacznika czasu dokumentu.ISO 32000-2§12.8.5
Wpisy DSS oraz znaczniki czasu dokumentu wspierają podpisy długoterminowe.ETSI EN 319 142-2§5.5
Moduł obsługi podpisu wspiera wpisy DSS oraz znaczniki czasu dokumentu.ETSI EN 319 142-2§6.3.3.3
Token znacznika czasu zawiera genTime w UTC, który jest momentem jego utworzenia.RFC 3161§2.4.2
OCSP zgłasza good, revoked lub unknown, ograniczone przez thisUpdate/nextUpdate.RFC 6960§2.2, §4.2,

Wszystkie klauzule są parafrazowane. NextPDF nie odtwarza tekstu normatywnego; po wiążące brzmienie sięgnij do opublikowanych standardów. NextPDF nie wysuwa żadnej deklaracji certyfikacji PAdES. Opisane tutaj struktury są zgodne z poziomami B-LT i B-LTA zdefiniowanymi w ETSI EN 319 142; nie deklaruje się żadnego wyniku testu zgodności ani atestacji strony trzeciej. Część ETSI EN 319 142-1 dotycząca poziomów bazowych znajduje się poza przywoływanym zbiorem dowodów, więc strona ta podaje tworzoną strukturę oraz granicę Pro/Enterprise, a nie certyfikowany poziom zgodności. Przywoływanym dowodem ETSI jest EN 319 142-2; zakotwiczenia ISO i RFC niosą deklaracje długoterminowe i deklaracje dotyczące znaczników czasu, tak jak w referencji podpisywania Core.

NextPDF Core tworzy bazowe poziomy PAdES B-B i B-T: Core dostarcza programowy moduł podpisujący CMS oraz ścieżkę znacznika czasu RFC 3161, więc podpis B-T (ze znacznikiem czasu) jest funkcją Core i nie wymaga Enterprise. NextPDF Pro również tworzy B-B i B-T: Pro komponuje stos RFC 3161 Core, aby dodać niepodpisany atrybut signature-time-stamp dla wartości podpisu (PadesBtTimestamper, zweryfikowany na fixture). Poziomy B-LT i B-LTA — producent DSS, VRI oraz znaczników czasu dokumentu — to funkcja Enterprise i nie są tworzone przez Core ani Pro. Odpowiada to opublikowanej tabeli poziomów na stronie bezpieczeństwa Pro: B-B i B-T są tworzone przez Core i Pro, a B-LT oraz B-LTA wyłącznie przez Enterprise. Producent B-T ma charakter strukturalny: komponuje RFC 3161 signature-time-stamp zgodnie z przywoływanym dowodem RFC 3161 / RFC 5652 / ETSI EN 319 122-1; nie jest to certyfikowana deklaracja zgodności ETSI EN 319 142-1 ani deklaracja kwalifikowana eIDAS. We wdrożeniu wyłącznie z Pro żądanie B-LT lub B-LTA kończy się w trybie fail-closed z komunikatem wskazującym brakujący komponent Enterprise, ponieważ SignatureLevel::isAvailableInEnvironment() zwraca fałsz, gdy brakuje długoterminowego producenta Enterprise.

Poziom PAdESDodajeEdycja producenta
B-BPodpis CMS z atrybutami podpisanymiCore, Pro, Enterprise
B-TRFC 3161 signature-time-stamp dla wartości podpisu (strukturalny; nie kwalifikowany eIDAS)Core, Pro, Enterprise
B-LTDocument Security Store z materiałem walidacyjnymWyłącznie Enterprise (nextpdf/enterprise)
B-LTAZnaczniki czasu dokumentu dla ważności archiwalnejWyłącznie Enterprise (nextpdf/enterprise)

To kanoniczna macierz poziom→poziom edycji: B-B to poziom bazowy tworzony przez każdą edycję; B-T (ze znacznikiem czasu) jest również tworzony przez Core i Pro (Pro komponuje stos RFC 3161 Core); B-LT i B-LTA są wyłącznie Enterprise. Producent B-T ma charakter strukturalny; nie jest to certyfikowana deklaracja zgodności ETSI EN 319 142-1 ani deklaracja kwalifikowana eIDAS.

Producent walidacji długoterminowej jest częścią edycji Enterprise (license_feature_flag: enterprise). Jest rozwiązywany w czasie wykonywania przez kontrakt Core; publiczne API nie zmienia się przy przejściu z Pro na Enterprise.

  • Core i Pro tworzą zarówno B-B, jak i B-T (B-T dodaje RFC 3161 signature-time-stamp; Pro komponuje stos RFC 3161 Core). B-LT i B-LTA to granica Enterprise; żądanie ich bez nextpdf/enterprise kończy się w trybie fail-closed z nazwanym błędem.
  • Producent zapisuje DSS (B-LT) oraz znacznik czasu dokumentu obejmujący DSS (B-LTA). Osadza materiał walidacyjny; nie deklaruje zaufanego wyniku weryfikacji.
  • Domyślne egzekwowanie fail-closed unieważnień zgłasza błąd, gdy brakuje materiału unieważnień dla certyfikatu poza korzeniem, chyba że wywołujący wybierze przepływ permisywny.
  • B-LTA wymaga skonfigurowanego TSA; bez niego krok B-LTA zgłasza błąd, zamiast degradować do B-LT.

Ta publiczna strona opisuje wyłącznie zewnętrznie obserwowalne zachowanie producenta. Nie zawiera wewnętrznych ścieżek przestrzeni nazw, wewnętrznych nazw klas ani cech, nazw plików runbooków ani wewnętrznych prefiksów zgłoszeń. Do konkretnych typów długoterminowego producenta Enterprise odwołuje się wyłącznie przez publiczny kontrakt Core (LtvManagerInterface, SignatureLevel). Szczegółowe wewnętrzne mechanizmy montażu DSS i pętli archiwizacyjnej znajdują się w bramkowanej referencji szczegółowej objętej umową o zachowaniu poufności (NDA).

We wdrożeniu wyłącznie z Core programowy moduł podpisujący tworzy PAdES B-B i B-T z kluczem lokalnym lub kluczem dostarczonym przez kontrakt strategii podpisywania Core. Core dostarcza ścieżkę znacznika czasu RFC 3161, więc B-T jest osiągalny bez żadnego pakietu premium. Core nie ma producenta DSS, VRI ani znaczników czasu dokumentu; żądanie B-LT lub B-LTA kończy się w trybie fail-closed z nazwanym błędem. Zobacz Bezpieczeństwo / Podpisywanie (Core).

We wdrożeniu wyłącznie z Pro obsługiwana ścieżka podpisywania obejmuje poziom bazowy Pro B-B oraz poziom Pro B-T (Pro komponuje stos RFC 3161 Core, aby dodać niepodpisany atrybut signature-time-stamp), wraz ze zdalnymi i chmurowymi strategiami podpisywania za pomocą usługi zarządzania kluczami (KMS). Pro nie tworzy żadnego DSS, VRI ani znacznika czasu dokumentu. Konfiguracja żądająca B-LT lub B-LTA we wdrożeniu wyłącznie z Pro kończy się w trybie fail-closed z komunikatem wskazującym brakujący komponent Enterprise. Zobacz Bezpieczeństwo Pro, aby poznać powierzchnię podpisywania Pro.

Producent DSS, VRI oraz znaczników czasu dokumentu jest opisany wyłącznie na poziomie zachowania. Wewnętrzna logika porządkowania budowy DSS, wewnętrzne mechanizmy kluczowania VRI dla każdego podpisu oraz wewnętrzne mechanizmy harmonogramowania pętli archiwizacyjnej są poza zakresem publicznej powierzchni i nie są tutaj odtwarzane.

NextPDF Enterprise osadza materiał walidacyjny; integruje się z dostarczonymi przez wywołującego responderami OCSP/CRL oraz z TSA zgodnym z RFC 3161. Sam nie obsługuje, nie hostuje ani nie gwarantuje dostępności tych responderów ani TSA. Ważność długoterminowa zależy od responderów, TSA, harmonogramu pętli archiwizacyjnej oraz operatora — a nie wyłącznie od NextPDF Enterprise. Operator odpowiada za wybór i osiągalność TSA, dostęp do responderów unieważnień lub wcześniej zebrany materiał, politykę sieciową oraz uruchamianie pętli archiwizacyjnej przed wygaśnięciem każdego certyfikatu znacznika czasu.

Ta strona jest oznaczona export_control_class: legal-review-required. Dotyczy kryptograficznego podpisywania i walidacji długoterminowej. Akceptacja prawna jest wymagana przed ustawieniem flagi publish. Zgodność ze strukturami B-LT i B-LTA zdefiniowanymi w ETSI EN 319 142 jest deklaracją strukturalną, a nie opinią prawną ani certyfikacją. NextPDF nie wysuwa żadnej deklaracji certyfikacji PAdES. W sprawie obowiązków regulacyjnych skonsultuj się z doradcami ds. zgodności i prawnymi.