Przejdź do głównej zawartości
getnextpdf.com

Enterprise edycja

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

NextPDF Enterprise dodaje producenta długoterminowego ponad podpisem Core Cryptographic Message Syntax (CMS): Document Security Store (DSS), informacje związane z walidacją (VRI) dla każdego podpisu oraz znaczniki czasu dokumentu. Te struktury podnoszą podpis bazowy PDF Advanced Electronic Signatures (PAdES) z B-B do B-LT, a następnie do B-LTA. Ta strona opisuje zachowanie. Określa, co producent zapisuje, o czym nie decyduje i gdzie zaczyna się granica Pro.

Ta funkcja jest dostarczana w NextPDF Enterprise (nextpdf/enterprise) i aktywuje się za pomocą koperty licencyjnej w warstwie Enterprise. Wdrożenie bez tego uprawnienia nie ładuje klas tej funkcji. Porównaj edycje i uzyskaj licencję.

NextPDF Core tworzy poziomy bazowe 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 z Core, aby dodać nieopisany atrybut signature-time-stamp do wartości podpisu (PadesBtTimestamper, zweryfikowane fikstursami). Poziomy B-LT i B-LTA — producent DSS, VRI oraz znacznika czasu dokumentu — są funkcją Enterprise i nie są tworzone przez Core ani Pro. We wdrożeniu wyłącznie z Pro żądanie B-LT lub B-LTA kończy się bezpiecznym zamknięciem z komunikatem nazywającym brakujący komponent Enterprise, ponieważ SignatureLevel::isAvailableInEnvironment() zwraca false, gdy producent długoterminowy Enterprise jest nieobecny.

Poziom PAdESDodajeEdycja producenta
B-BPodpis CMS z podpisanymi atrybutamiCore, Pro, Enterprise
B-TZnacznik czasu podpisu RFC 3161 na wartości podpisu (strukturalny; nie kwalifikowany eIDAS)Core, Pro, Enterprise
B-LTDocument Security Store z materiałem walidacyjnymTylko Enterprise (nextpdf/enterprise)
B-LTAZnaczniki czasu dokumentu dla ważności archiwalnejTylko Enterprise (nextpdf/enterprise)

To jest kanoniczna macierz poziom→warstwa: B-B jest poziomem bazowym tworzonym przez każdą edycję; B-T (ze znacznikiem czasu) jest również tworzony przez Core i Pro (Pro komponuje stos RFC 3161 z Core); B-LT i B-LTA są wyłącznie Enterprise. Producent B-T jest strukturalny; nie jest to certyfikowana zgodność ETSI EN 319 142-1 ani deklaracja kwalifikowana eIDAS. Odpowiada to opublikowanej tabeli warstw na stronie zabezpieczeń Pro.

Okno terminala
composer require nextpdf/enterprise

nextpdf/enterprise zależy od nextpdf/core i nextpdf/pro. Rozwiąż pakiet za pomocą swoich danych uwierzytelniających licencji NextPDF na Private Packagist.

Podpis bazowy PAdES ma cztery poziomy. Każdy poziom dodaje materiał do poprzedniego. B-B to podpis CMS z podpisanymi atrybutami. B-T dodaje zaufany znacznik czasu RFC 3161 na wartości podpisu. B-LT dodaje DSS, który przenosi certyfikaty, odpowiedzi Online Certificate Status Protocol (OCSP) oraz listy unieważnień 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 buduje CMS SignedData i przechowuje je w kodowaniu DER we wpisie Contents słownika podpisu — ISO 32000-2 §12.8.1. Walidacja długoterminowa używa dwóch typów słowników: document security store oraz słownika znacznika czasu dokumentu — ISO 32000-2 §12.8. Producent Enterprise zapisuje DSS, który przechowuje materiał certyfikatów, OCSP i CRL — ISO 32000-2 §12.8.4.3 — oraz, 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 oraz znaczniki czasu dokumentu dla podpisów długoterminowych — §5.5 — obsługiwane przez handler podpisu — §6.3.3.3.

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

Znacznik czasu dokumentu B-LTA to wymiana RFC 3161 z urzędem znaczników czasu (TSA). Żądanie zwraca wartość Time Stamp Information (TSTInfo) — RFC 3161 §2.4.1 — której genTime jest momentem uniwersalnego czasu koordynowanego (UTC) utworzenia tokenu — RFC 3161 §2.4.2. Token jest osadzony w słowniku /DocTimeStamp z /SubFilter /ETSI.RFC3161, który obejmuje cały plik.

Weryfikator decyduje, czy utworzony podpis weryfikuje się, używając skonfigurowanych kotwic zaufania i polityki unieważnień. Producent osadza materiał; nie stwierdza zaufanego wyniku. Ta granica jest ponownie wyjaśniona tam, gdzie ma to znaczenie, poniżej.

Kolejność jest kluczowa: DSS musi zostać zapisany przed znacznikiem czasu dokumentu B-LTA, ponieważ znacznik czasu musi obejmować stan dokumentu, który już zawiera 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

Ważność długoterminowa ma jedną twardą regułę kolejności: znacznik czasu dokumentu musi obejmować materiał walidacyjny. Dlatego DSS jest zawsze zapisywany jako pierwszy, a znacznik czasu B-LTA jest pobierany nad stanem pliku, który już go zawiera. Odwróć tę kolejność, a znacznik czasu nie ochroni niczego, co weryfikator odczyta lata później — certyfikaty, OCSP i CRL znalazłyby się poza jego zasięgiem. Producent zatem osadza materiał i zakotwicza go w czasie, ale nie posuwa się do stwierdzenia zaufanego wyniku; ta decyzja należy do weryfikatora i jego kotwic zaufania. Bezpieczne zamknięcie, gdy brakuje materiału unieważnień, oznacza, że dokument deklarujący poziom długoterminowy nigdy nie zostanie dostarczony bez dowodów popierających tę deklarację. Rezultatem jest podpis, który strona trzecia może ponownie sprawdzić długo po wygaśnięciu certyfikatu podpisującego, bez kontaktowania się z pierwotnymi responderami.

Tło projektowe: Walidacja długoterminowa.

Producenta długoterminowego Enterprise wykorzystujesz poprzez kontrakt Core. Kod produkcyjny zależy od kontraktu, a nie od konkretnego typu implementacji Enterprise.

TypRodzajRolaStabilnośćOd
SignerInterfaceinterfejs (NextPDF\Contracts)Kontrakt podpisu Core dla wywołującychstable1.0.0
SignatureLevelenum (NextPDF\Security\Signature)Selektor poziomu PAdES: B-B, B-T, B-LT, B-LTAstable1.0.0
LtvManagerInterfaceinterfejs (NextPDF\Contracts)Kontrakt producenta walidacji długoterminowej rozwiązywany w czasie wykonaniastable1.0.0
TsaClientInterfaceinterfejsKlient TSA RFC 3161, który producent wywołuje dla znaczników czasu dokumentustable1.0.0

SignatureLevel::requiresDss() jest true dla B-LT i B-LTA; SignatureLevel::requiresDocumentTimestamp() jest true tylko dla B-LTA. Core SignatureLevel::isAvailableInEnvironment() zwraca false dla B-LT i B-LTA, gdy producent długoterminowy Enterprise nie jest zainstalowany; orkiestrator Core kończy wtedy bezpiecznym zamknięciem. Konkretne klasy producenta Enterprise są wewnętrzne i nie stanowią części publicznego API; zależ od LtvManagerInterface oraz enuma.

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 podpisu przenosi poziom. Orkiestrator Core rozwiązuje producenta długoterminowego poprzez LtvManagerInterface w czasie wykonania, więc kod aplikacji nie odwołuje się do typu Enterprise.

examples/security/pades-blta-production.php
<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
use NextPDF\Core\Document;
use NextPDF\Exception\NextPdfException;
use NextPDF\Security\Signature\CertificateInfo;
use NextPDF\Security\Signature\SignatureLevel;
use NextPDF\Security\Timestamp\TsaClient;
use Psr\Http\Client\ClientInterface;
use Psr\Log\LoggerInterface;
/**
* Produce a PAdES B-LTA signature through the high-level Document seam, which
* drives the Core PadesOrchestrator and the Enterprise long-term producer in the
* load-bearing order: sign, write the DSS (LtvManager::enableLtv), then add the
* /DocTimeStamp over the state that already includes it (::addDocumentTimestamp).
*/
final readonly class LongTermSigner
{
public function __construct(
private TsaClient $tsa, // RFC 3161 TSA client (required for B-T and above).
private ClientInterface $http, // PSR-18 client that fetches OCSP/CRL for the DSS.
private LoggerInterface $logger,
) {}
/**
* Sign at B-LTA and return the long-term-signed PDF bytes; requesting B-LTA
* without the nextpdf/enterprise producer fails closed rather than downgrading.
*
* @throws NextPdfException Fail-closed: enterprise producer absent
* (SignatureLevelUnreachableException), no HTTP client
* (SignatureException), or missing material (LtvException).
*/
public function sign(CertificateInfo $certInfo): string
{
try {
$document = Document::createStandalone();
$document->addPage();
$document->setSignature($certInfo, SignatureLevel::PAdES_B_LTA, $this->tsa, $this->http);
return $document->getPdfData();
} catch (NextPdfException $e) {
$this->logger->error('long-term B-LTA 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.

  • Brakujący materiał unieważnień domyślnie kończy się bezpiecznym zamknięciem. Gdy nie ustawiono żadnego trybu wymuszania, producent traktuje brakującą odpowiedź OCSP i brakujący CRL dla dowolnego certyfikatu innego niż główny 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 tylko ostrzegawczy.
  • B-LTA wymaga TSA. Znacznik czasu dokumentu to wymiana w obie strony RFC 3161. Bez skonfigurowanego klienta TSA krok B-LTA zgłasza błąd, zamiast po cichu tworzyć B-LT.
  • Kolejność jest kluczowa. Dodaj znacznik czasu dokumentu dopiero po zapisaniu DSS. Znacznik czasu pobrany przed DSS nie obejmuje materiału walidacyjnego.
  • Uruchomienia w sieci odizolowanej (air-gapped). W ramach ścisłej polityki sieci offline producent nie wykonuje żadnego pobrania OCSP/CRL ani żadnego żądania TSA; używa wyłącznie materiału już osadzonego w DSS. B-LTA, które wymaga świeżego tokenu TSA, jest nieosiągalne w trybie ściśle offline.
  • VRI jest opcjonalne. VRI dla każdego podpisu nie jest zapisywane domyślnie. Niektóre walidatory lepiej wyświetlają status długoterminowy, gdy VRI jest obecne; włącz je, gdy docelowy weryfikator tego potrzebuje.

Koszt montażu DSS skaluje się z długością łańcucha i liczbą pobranych odpowiedzi unieważnień. Każde pobranie OCSP lub CRL to jedna wymiana sieciowa w obie strony; wcześniej zebrany lub buforowany materiał usuwa te wymiany. Uruchomienie B-LTA dodaje jedną wymianę TSA w obie strony dla znacznika czasu dokumentu. Budżet czasu ściany 1500 ms obejmuje pojedynczy podpis długoterminowy z rozgrzanymi połączeniami OCSP/CRL i TSA; zimne lub wolne respondery dominują czas ściany. Profil odtwarzalności to structural: znaczniki czasu osadzają momenty podpisania i stemplowania, więc dwa uruchomienia różnią się tymi bajtami, podczas gdy struktura dokumentu jest identyczna.

  • Zaufanie to decyzja weryfikatora. Producent osadza certyfikaty, OCSP i CRL. To, czy podpis się weryfikuje, zależy od weryfikatora, jego kotwic zaufania i jego polityki aktualności unieważnień. NextPDF nie dostarcza żadnej wbudowanej listy zaufania.
  • Aktualność unieważnień jest ograniczona czasowo. Pola OCSP thisUpdate/nextUpdate oraz okna ważności CRL ograniczają, jak długo osadzony materiał pozostaje przydatny. Pętla archiwizacji ponownie stempluje przed wygaśnięciem certyfikatu znacznika czasu; jesteś odpowiedzialny za jej terminowe obsługiwanie.
  • Domyślne bezpieczne zamknięcie. Domyślne ścisłe wymuszanie unieważnień zapobiega składaniu deklaracji długoterminowej bez materiału, który ją popiera.
  • Zobacz sekcję modelu zagrożeń Enterprise oraz Archiwum: DSS, VRI, kondycja LTV.

Pobieranie OCSP i CRL kontaktuje respondery nazwane w każdym certyfikacie; te punkty końcowe oraz TSA widzą metadane żądania. We wdrożeniu ograniczonym rezydencją danych zbierz wcześniej materiał unieważnień i uruchamiaj w ramach polityki ściśle offline, aby żaden responder ani TSA nie był kontaktowany w czasie podpisywania. Certyfikaty niosą tożsamość podmiotu. Producent osadza certyfikaty wymagane do walidacji i nie dodaje tożsamości poza łańcuchem; nie usuwa pól podmiotu z certyfikatu, który dostarczasz.

Diagnostyka producenta zgłasza poziom, pozycję w łańcuchu oraz warunek brakującego materiału. Nie zapisuje kluczy prywatnych ani pełnych treści certyfikatów. Gdy podłączasz logger PSR-3, utrzymuj logi diagnostyczne na nieprodukcyjnym poziomie szczegółowości dla przepływów podpisywania i czyść adresy URL responderów, jeśli ujawniają wewnętrzną infrastrukturę. Traktuj osadzone bajty OCSP/CRL jako treść dokumentu, a nie treść logu.

Profil polityki kryptograficznej Federal Information Processing Standards (FIPS) 140-3 jest funkcją Enterprise udokumentowaną wraz z modułem bezpieczeństwa. Producent długoterminowy nie dodaje żadnego własnego prymitywu kryptograficznego poza skrótem SHA-256 używanym do znacznika czasu dokumentu i wymiany RFC 3161; prymitywem podpisu jest prymityw modułu podpisującego Core. Gdy profil FIPS jest aktywny, tworzone są te same struktury DSS i znacznika czasu dokumentu; ograniczenie dotyczy leżących u podstaw algorytmów podpisu i skrótu, a nie układu DSS.

ZasóbPrzeciwnikRyzykoŚrodek zaradczy
Materiał unieważnień DSSAkceptacja przestarzałego materiałuWeryfikator ufa wygasłym danym unieważnieńPola aktualności OCSP/CRL ograniczają ważność; pętla archiwizacji ponownie stempluje przed wygaśnięciem
Znacznik czasu dokumentu B-LTAKompromitacja TSA lub nieosiągalny TSABrak wiarygodnej kotwicy czasuTSA wybierany przez wywołującego; B-LTA kończy bezpiecznym zamknięciem, gdy nie skonfigurowano TSA
Deklaracja długoterminowaCiche brakowanie materiału„Długoterminowy” PDF bez danych unieważnieńDomyślne wymuszanie bezpiecznego zamknięcia zgłasza błąd zamiast ostrzeżenia
Weryfikacja podpisuBłędnie skonfigurowane zaufanie weryfikatoraPozorna ważność, której weryfikator nie powinien stwierdzaćProducent oświadcza, że osadza tylko materiał; decyzja o zaufaniu należy do weryfikatora
DeklaracjaStandardKlauzula
Wartość podpisu (lub token znacznika czasu) jest przechowywana w kodowaniu DER w /Contents.ISO 32000-2§12.8.1
Walidacja długoterminowa używa DSS oraz słownika znacznika czasu dokumentu.ISO 32000-2§12.8
DSS przechowuje certyfikaty, odpowiedzi OCSP i CRL.ISO 32000-2§12.8.4.3
Znacznik czasu dokumentu używa słownika znacznika czasu dokumentu.ISO 32000-2§12.8.5
Wpisy DSS i znaczniki czasu dokumentu obsługują podpisy długoterminowe.ETSI EN 319 142-2§5.5
Handler podpisu obsługuje wpisy DSS i znaczniki czasu dokumentu.ETSI EN 319 142-2§6.3.3.3
Token znacznika czasu niesie 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; w celu uzyskania miarodajnego brzmienia należy zapoznać się z opublikowanymi standardami. NextPDF nie składa żadnej deklaracji certyfikacji PAdES. Struktury opisane tutaj 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 cytowanym zestawem dowodów, więc ta strona podaje utworzoną strukturę oraz granicę Pro/Enterprise, a nie certyfikowany poziom zgodności. Cytowanym dowodem ETSI jest EN 319 142-2; kotwice ISO i RFC niosą deklaracje długoterminowe i deklaracje znacznika czasu, tak jak w referencji podpisu Core.

  • Core i Pro obydwa tworzą B-B i B-T (B-T dodaje znacznik czasu podpisu RFC 3161; Pro komponuje stos RFC 3161 z Core). B-LT i B-LTA są granicą Enterprise; żądanie ich bez nextpdf/enterprise kończy się bezpiecznym zamknięciem z nazwanym błędem.
  • Producent zapisuje DSS (B-LT) oraz znacznik czasu dokumentu nad DSS (B-LTA). Osadza materiał walidacyjny; nie stwierdza zaufanego wyniku weryfikacji.
  • Domyślne bezpieczne zamknięcie przy wymuszaniu unieważnień zgłasza błąd, gdy brakuje materiału unieważnień dla certyfikatu innego niż główny, chyba że wywołujący zdecyduje się na przepływ permisywny.
  • B-LTA wymaga skonfigurowanego TSA; bez niego krok B-LTA zgłasza błąd, zamiast degradować do B-LT.

Ta strona dokumentuje wyłącznie zewnętrznie obserwowalne zachowanie oraz obsługiwaną publiczną powierzchnię API. Wewnętrzne ścieżki przestrzeni nazw, klasy pomocnicze, tabele mechanizmów, nazwy plików runbooków oraz prefiksy zgłoszeń są poza zakresem.

We wdrożeniu wyłącznie z Core programowy moduł podpisujący tworzy PAdES B-B i B-T za pomocą lokalnego klucza lub klucza dostarczonego przez kontrakt strategii podpisu Core. Core dostarcza ścieżkę znacznika czasu RFC 3161, więc B-T jest osiągalne bez żadnego pakietu premium. Core nie ma producenta DSS, VRI ani znacznika czasu dokumentu; żądanie B-LT lub B-LTA kończy się bezpiecznym zamknięciem z nazwanym błędem. Zobacz Bezpieczeństwo / Podpisywanie (Core).

We wdrożeniu wyłącznie z Pro obsługiwaną ścieżką podpisu jest bazowy poziom Pro B-B oraz poziom Pro B-T (Pro komponuje stos RFC 3161 z Core, aby dodać nieopisany atrybut signature-time-stamp), plus jego zdalne i chmurowe strategie podpisu z usługą 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ę bezpiecznym zamknięciem z komunikatem nazywającym brakujący komponent Enterprise. Zobacz Bezpieczeństwo Pro, aby poznać powierzchnię podpisu Pro.

Producent DSS, VRI oraz znacznika czasu dokumentu jest opisany wyłącznie na poziomie zachowania. Wewnętrzna logika kolejności montażu DSS, wewnętrzne mechanizmy kluczowania VRI dla każdego podpisu oraz wewnętrzne mechanizmy harmonogramowania pętli archiwizacji 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 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 archiwizacji oraz operatora — a nie od samego NextPDF Enterprise. Operator jest odpowiedzialny za wybór i osiągalność TSA, dostęp do responderów unieważnień lub wcześniej zebrany materiał, politykę sieci oraz uruchamianie pętli archiwizacji przed wygaśnięciem każdego certyfikatu znacznika czasu.

Dotyczy podpisu kryptograficznego i walidacji długoterminowej. Zgodność ze strukturami B-LT i B-LTA zdefiniowanymi w ETSI EN 319 142 jest stwierdzeniem strukturalnym, a nie opinią prawną ani certyfikacją. NextPDF nie składa żadnej deklaracji certyfikacji PAdES. Skonsultuj się ze swoimi doradcami ds. zgodności i prawnymi w sprawie swoich zobowiązań regulacyjnych.