Weryfikacja podpisu: kryptograficzna weryfikacja AdES / PAdES

W skrócie

NextPDF Enterprise kryptograficznie weryfikuje podpisy cyfrowe. Warstwa weryfikująca odczytuje z pliku PDF strukturę Cryptographic Message Syntax (CMS) SignedData lub token znacznika czasu Request for Comments (RFC) 3161, ponownie wylicza skróty, sprawdza podpisy, wiąże każdy podpis z jego certyfikatem podpisującym oraz waliduje łańcuch certyfikatów, w tym przetwarzanie polityk certyfikatów, względem magazynu kotwic zaufania dostarczonego przez wywołującego. Ta strona opisuje zachowanie: określa, co jest weryfikowane, co jest odrzucane w trybie fail-closed, które algorytmy są obsługiwane i gdzie przebiega granica zaufania.

To funkcja odrębna od Walidacji, która uruchamia tylko do odczytu strukturalne kontrole polityk i celowo nie wykonuje żadnej kryptografii. To także odpowiednik weryfikacyjny producenta podpisu, który zapisuje struktury PDF Advanced Electronic Signatures (PAdES) B-LT / B-LTA.

Instalacja

composer require nextpdf/enterprise:^3

Przegląd koncepcyjny

Weryfikacja opiera się na dowodach i działa w trybie fail-closed: kontrola, której nie da się jednoznacznie potwierdzić, nie daje wyniku pozytywnego. Poniższe elementy składają się na jeden wynik zawarty w obiekcie ValidationReport.

Kryptograficzna weryfikacja CMS / tokenu znacznika czasu. Samodzielny, rygorystyczny stos DER o określonej długości parsuje strukturę CMS SignedData oraz token znacznika czasu RFC 3161. Token jest akceptowany tylko wtedy, gdy zawiera dokładnie jedną strukturę SignerInfo, jego podpisane atrybuty są rygorystycznie parsowane, certyfikat podpisującego można ustalić, atrybut message-digest zgadza się z ponownie wyliczonym skrótem, obowiązkowe powiązanie certyfikatu podpisującego (ESS signing-certificate-v2) jest spełnione, a podpis SignerInfo weryfikuje się względem ponownie otagowanych podpisanych atrybutów. Reguła dopasowania skrótu jest zgodna z modelem weryfikacji RFC 5652 §5.6 / §5.4: odbiorca ponownie wylicza skrót treści komunikatu, a podpis jest ważny tylko wtedy, gdy ta wartość jest równa podpisanemu atrybutowi messageDigest. Weryfikator nigdy nie ufa skrótowi dostarczonemu przez producenta.

Walidacja certyfikatu TSA w chwili genTime. Wartość genTime znacznika czasu to chwila UTC, w której token został utworzony (RFC 3161 §2.4.2). Certyfikat podpisujący TSA jest sprawdzany w tej właśnie chwili, a nie „teraz”: jego rozszerzone zastosowanie klucza musi być pojedynczym, krytycznym id-kp-timeStamping (RFC 3161 §2.3), a okno ważności, łańcuch, pochodzenie kotwicy zaufania oraz status unieważnienia są oceniane względem genTime. Łańcuch poprawny strukturalnie, który nie dociera do skonfigurowanej kotwicy zaufania, nigdy nie może uzasadnić wyniku pozytywnego.

Odłączone podstawowe podpisy dokumentu PAdES. Właściwy ekstraktor wykonuje rzeczywistą podstawową weryfikację Advanced Electronic Signatures (AdES) / PAdES dla odłączonego podpisu dokumentu: skrót komunikatu jest ponownie wyliczany dla podpisanego zakresu bajtów i porównywany, podpis jest weryfikowany, a powiązanie z certyfikatem podpisującym jest obowiązkowe. Zastępuje to wcześniejszy, wyłącznie strukturalny mechanizm zastępczy. Weryfikator znacznika czasu i ekstraktor podpisu dokumentu współdzielą jeden walidator ESS issuer-and-serial, dzięki czemu parsowanie powiązania certyfikatu nie może dać rozbieżnych wyników.

Łańcuch pokrycia archiwalnego DocTimeStamp. validateArchivalTimestampChain() sprawdza poprawność łańcucha zaufanych tokenów DocTimeStamp obejmujących zakresy bajtów pliku PDF jako dowód archiwalny B-LTA. Odcisk każdego tokenu jest powiązany z rzeczywistymi bajtami ByteRange, które obejmuje, łańcuch zachowuje rygorystyczną kolejność ETSI, łańcuch TSA każdego tokenu jest zakotwiczony w zaufaniu, a cały łańcuch musi obejmować plik aż do znacznika końca pliku. Pełne zaliczenie daje wyłącznie kompletny, zakotwiczony w zaufaniu łańcuch obejmujący plik do EOF.

Przetwarzanie polityk certyfikatów (RFC 5280 §6.1.4). Walidacja ścieżki stosuje pełne przetwarzanie polityk certyfikatów: drzewo polityk o strukturze węzłowej, mapowanie polityk z mechanizmem awaryjnym anyPolicy oraz zwijanie policyConstraints / inhibitAnyPolicy, obsługiwane przez działający w trybie fail-closed czytnik DER rozszerzeń polityk. Zmienne stanu przetwarzania ścieżki explicit_policy i inhibit_anyPolicy (RFC 5280 §6.1.2) decydują, czy wymagane jest niepuste drzewo prawidłowych polityk; krok końcowy przecina drzewo prawidłowych polityk ze zbiorem polityk początkowych użytkownika (RFC 5280 §6.1.4). Gdy nie ma wymaganych polityk, a anyPolicy jest akceptowane, przetwarzanie jest nieograniczone; to zachowanie domyślne, niezmienione względem wcześniejszych wersji.

Obsługiwane algorytmy

Warstwa weryfikująca akceptuje poniższy zestaw algorytmów i działa w trybie fail-closed dla wszystkiego poza nim: nieobsługiwany algorytm oznacza odrzuconą weryfikację i nigdy nie skutkuje cichym zaliczeniem.

Rodzina	Obsługa	Uwagi
RSA (PKCS#1 v1.5)	rsaEncryption z SHA-2 oraz identyfikatory OID sha*WithRSAEncryption	Akceptowane
ECDSA	krzywe P-256, P-384, P-521	Akceptowane
RSASSA-PSS	—	Nieobsługiwane → fail-closed
EdDSA	—	Nieobsługiwane → fail-closed
Skróty SHA-3	—	Nieobsługiwane → fail-closed
SHA-1	—	Słaby: podstawowy podpis, który weryfikuje się pod SHA-1, jest degradowany do błędu ograniczeń kryptograficznych, a nie zaliczany

Powierzchnia API

Z warstwy weryfikującej korzysta się przez publiczny silnik oraz kontrakty Core / Pki. Konkretne klasy strategii są wewnętrzne.

Typ	Rodzaj	Rola
AdESValidationEngine	klasa	Punkt wejścia warstwy weryfikującej: walidacja podpisu i łańcucha archiwalnego.
AdESValidationEngine::validateArchivalTimestampChain()	metoda	Sprawdza poprawność zaufanego łańcucha pokrycia DocTimeStamp obejmującego zakresy bajtów pliku PDF.
ValidationReport	wynik	Ustrukturyzowany wynik: ogólny status oraz ustalenia dla poszczególnych kontroli.
PathValidatorInterface	interfejs (NextPDF\…\Pki)	SPI walidacji ścieżki certyfikacji, od którego zależy silnik.
PathValidationOptions	obiekt wartości	Sterowanie przetwarzaniem polityk: requireExplicitPolicy, inhibitAnyPolicy, inhibitPolicyMapping, maxPolicyFanout.
TrustAnchorStoreInterface	interfejs	Dostarczony przez wywołującego zbiór zaufanych kotwic, względem którego oceniany jest łańcuch.

Metoda łańcucha archiwalnego ma następującą sygnaturę:

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

Metoda daje w pełni zaliczony wynik tylko wtedy, gdy łańcuch DocTimeStamp jest całkowicie zweryfikowany, zakotwiczony w zaufaniu i obejmuje plik aż do znacznika EOF.

CertificateChainValidator::validate() przyjmuje zbiór polityk początkowych (zbiór polityk początkowych użytkownika według RFC 5280). Domyślną wartością jest anyPolicy, które jest nieograniczone, więc zwykły łańcuch zachowuje dotychczasowe zachowanie. Przekaż jawny zbiór lub ustaw requireExplicitPolicy, aby wymusić niepuste drzewo prawidłowych polityk.

Przykład kodu — szybki start

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;

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

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

Przykład kodu — produkcja

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();
    }
}

Zmiany zachowania i uwagi dotyczące aktualizacji

Warstwa weryfikująca przeszła od akceptacji strukturalnej / czasowej do pełnej weryfikacji kryptograficznej. Jeśli polegasz na starszym, bardziej liberalnym zachowaniu, przejrzyj te zmiany.

• Fail-closed dla rozpoznawalnego, lecz nieweryfikowalnego znacznika czasu. Token DocTimeStamp lub token archiwalny, który wcześniej przechodził na podstawie przesłanek strukturalnych i czasowych, teraz wymaga pełnej weryfikacji kryptograficznej: podpisu, message-digest oraz powiązania z certyfikatem podpisującym. Token, który się nie weryfikuje, nie daje już pozytywnego dowodu istnienia; jest mapowany na wynik nieokreślony lub nieudany.
• Podstawowe podpisy SHA-1 są degradowane, a nie zaliczane. Podstawowy podpis dokumentu, który się weryfikuje, ale używa SHA-1, jest zgłaszany jako błąd ograniczeń kryptograficznych, a nie jako pełne zaliczenie.
• Przetwarzanie polityk certyfikatów według RFC 5280 §6.1.4 jest egzekwowane. Łańcuch, którego explicit_policy osiąga zero przy pustym drzewie prawidłowych polityk, teraz kończy się niepowodzeniem, także wtedy, gdy wynika to z wewnątrzłańcuchowego policyConstraints requireExplicitPolicy. Domyślne, nieograniczone łańcuchy (brak wymaganych polityk, akceptowane anyPolicy) pozostają bez zmian.
• Zmiana sygnatury konstruktora (zerwanie zgodności wstecznej). AdESValidationEngine::__construct() typuje teraz swój parametr $chainValidator jako SPI Pki\PathValidatorInterface, z leniwą wartością domyślną Pki\CertificateChainValidator::withDefaults(). Wcześniej był to konkretny Ltv\CertificateChainValidator. Wywołujący, który wstrzykiwał konkretny walidator LTV, musi zamiast tego wstrzyknąć implementację SPI Pki. Walidator Pki opakowuje ten sam strukturalny silnik ścieżki i dodaje ograniczenia nazw oraz przetwarzanie polityk; dla zgodnych z normą danych domyślnych nie zmienia zachowania.

Przypadki brzegowe i pułapki

• Nieobsługiwany algorytm ≠ wynik nierozstrzygający. RSASSA-PSS, EdDSA i SHA-3 są odrzucane w trybie fail-closed, a nie odraczane. Jeśli podpisujący ich używają, ta warstwa weryfikująca nie zwróci wyniku pozytywnego.
• Zaufanie jest względne wobec kotwicy. Weryfikacja zawsze odnosi się do magazynu kotwic zaufania, który dostarczasz. Pusty lub błędny zbiór kotwic daje wynik „brak zaufania”, niezależnie od poprawności kryptograficznej.
• genTime, a nie teraz. Certyfikat TSA jest oceniany w chwili genTime tokenu. Certyfikat TSA, który od tego czasu wygasł, nadal może uzasadnić token utworzony, gdy był ważny; certyfikat jeszcze nieważny w chwili genTime nie może.
• Pokrycie do EOF. Łańcuch archiwalny musi obejmować dokument aż do jego znacznika EOF. Znacznik czasu, który obejmuje tylko prefiks pliku, nie ustanawia pokrycia całego dokumentu.
• „Nieudowodnione unieważnienie” to nie „Good”. Werdykt Valid wymaga jednoznacznie nieunieważnionego statusu. Jeśli zarówno OCSP, jak i CRL zwracają Unknown lub Unavailable, nawet podpis poprawny kryptograficznie, prawidłowy w łańcuchu i zakotwiczony w zaufaniu rozstrzyga się jako Indeterminate. Dostarcz osadzony materiał Good OCSP/CRL dla certyfikatu podpisującego, aby osiągnąć Valid.

Wydajność

Weryfikacja przebiega w procesie, na dostarczonych bajtach pliku PDF oraz osadzonym materiale walidacyjnym; koszt rośnie wraz z długością łańcucha i liczbą znaczników czasu. Weryfikacja nie wykonuje żadnych obiegów sieciowych. Materiał unieważnienia i zaufania pochodzi z tego, co dostarcza wywołujący, lub z tego, co jest osadzone w dokumencie. Weryfikacja jest deterministyczna: te same dane wejściowe i te same kotwice zaufania dają ten sam raport.

Uwagi dotyczące bezpieczeństwa

• Fail-closed jest domyślny. Każdy krok akceptacji odrzuca materiał, którego nie potrafi jednoznacznie zweryfikować. Zapobiega to ogłaszaniu przez dokument ważności, której silnik nie ustalił.
• Dopisanie po znaczniku czasu jest blokowane przez pokrycie do EOF. Ponieważ odcisk każdego archiwalnego znacznika czasu jest powiązany z rzeczywistymi bajtami ByteRange, a łańcuch musi sięgać EOF, treść dopisana po znaczniku czasu nie jest przez niego objęta i nie zyskuje jego wagi dowodowej.
• Traktuj dane wejściowe jako wrogie. Bajty pliku PDF, osadzone CMS oraz tokeny znacznika czasu z niezaufanych źródeł są parsowane przez rygorystyczny czytnik DER o określonej długości, który odrzuca zniekształcone lub zakodowane na nieokreśloną długość dane.

Rezydencja danych i ograniczanie PII

Weryfikacja przebiega lokalnie, w procesie, bez wejścia/wyjścia sieciowego. Certyfikaty i podpisy zawierają tożsamość podmiotu; zastosuj własne mechanizmy przechowywania i minimalizacji wobec raportów i wszelkich wyodrębnionych danych certyfikatu.

Bezpieczna telemetria i czyszczenie logów

Ustalenia zawierają identyfikatory kontroli i statusy. Niektóre diagnostyki mogą odzwierciedlać nazwy podmiotów certyfikatów lub numery seryjne; wyczyść albo zredaguj te pola, zanim przekażesz logi do współdzielonych ujść.

Granice zakresu

Podaj te granice w danych widocznych dla użytkownika, aby wynik pozytywny nie był interpretowany zbyt szeroko.

• validateArchivalTimestampChain() dowodzi pokrycia zakresu bajtów, a nie osiągalności xref. Ustanawia, że zaufany łańcuch znaczników czasu kryptograficznie obejmuje zakresy bajtów dokumentu aż do EOF. Nie wykonuje analizy osiągalności obiektów na poziomie xref ani startxref; jest to celowo poza zakresem. Reguła pokrycia do EOF wraz z zakotwiczeniem w zaufaniu blokuje ataki polegające na dopisaniu po znaczniku czasu, ale nie zastępuje analizy grafu obiektów.
• Celowo poza zakresem. Rekordy dowodowe (RFC 4998 / RFC 6283); weryfikacja tokenów znacznika czasu RSASSA-PSS, EdDSA lub SHA-3; integracja list zaufanych (TSL) i kwalifikowanego TSA; oraz pobieranie unieważnień TSA przez sieć nie są zapewniane przez tę warstwę weryfikującą. Unieważnienie jest oceniane na podstawie materiału już dostępnego weryfikatorowi.

Zgodność

Zachowanie	Odniesienie	Status
Wartość podpisu / token znacznika czasu przechowywany w postaci DER w /Contents	ISO 32000-2 §12.8.1	Parsowane i weryfikowane
Słownik znacznika czasu dokumentu	ISO 32000-2 §12.8.5	Odczytywany dla łańcucha archiwalnego
Odbiorca ponownie wylicza skrót treści; musi on być równy atrybutowi messageDigest	RFC 5652 §5.6 / §5.4	Egzekwowane
Certyfikat TSA niesie pojedynczy krytyczny EKU id-kp-timeStamping	RFC 3161 §2.3	Sprawdzane w chwili genTime
genTime to chwila utworzenia w UTC	RFC 3161 §2.4.2	Używana jako chwila walidacji
Zmienne stanu przetwarzania polityk (explicit_policy, inhibit_anyPolicy)	RFC 5280 §6.1.2	Przetwarzane
Krok końcowy przecina drzewo prawidłowych polityk ze zbiorem polityk początkowych użytkownika	RFC 5280 §6.1.4	Egzekwowane
Wpisy DSS i znaczniki czasu dokumentu dla podpisów długoterminowych	ETSI EN 319 142-2 §5.5	Walidowane jako dowód archiwalny

Wszystkie klauzule są sparafrazowane. NextPDF nie odtwarza tekstu normatywnego; w sprawie miarodajnego brzmienia należy sięgnąć do opublikowanych norm. NextPDF nie zgłasza żadnego roszczenia o certyfikację AdES / PAdES. Warstwa weryfikująca implementuje kontrole kryptograficzne opisane przez cytowane specyfikacje; nie jest certyfikowaną usługą walidacji i nie wytwarza atestacji strony trzeciej.

Zachowanie w trybie FIPS

Gdy profil Enterprise FIPS jest aktywny, ograniczenie dotyczy algorytmów skrótu i podpisu akceptowanych przez weryfikator. Logika weryfikacji, w tym ponowne wyliczanie skrótu, kontrole podpisu, powiązanie certyfikatu i walidacja ścieżki, pozostaje bez zmian.

Model zagrożeń

Zasób	Przeciwnik	Ryzyko	Środek zaradczy
Token znacznika czasu	Sfałszowany lub zmieniony token	Fałszywy dowód istnienia	Pełna weryfikacja kryptograficzna; fail-closed dla wszystkiego nieweryfikowalnego
Certyfikat TSA	Niezaufany wystawca	Pozorne zaufanie, którego weryfikator nie powinien zapewniać	Łańcuch zwalidowany do kotwicy dostarczonej przez wywołującego w chwili genTime; niezaufany łańcuch nigdy nie jest akceptowany
Bajty dokumentu	Dopisanie po znaczniku czasu	Treść zyskuje wagę znacznika czasu bez pokrycia	Odcisk powiązany z rzeczywistymi bajtami ByteRange + reguła pokrycia do EOF
Słaby algorytm	Degradacja do SHA-1 / nieobsługiwanego schematu	Słaby podpis odczytany jako ważny	SHA-1 zdegradowane; RSASSA-PSS / EdDSA / SHA-3 w trybie fail-closed

Brama edycji

Ta warstwa weryfikująca jest funkcją Enterprise i jest dostarczana w pakiecie nextpdf/enterprise. NextPDF Core wykrywa obecność podpisu i wytwarza podpisy B-B / B-T, ale nie zapewnia tej kryptograficznej warstwy weryfikującej. Uzyskaj licencję.

Flaga funkcji licencyjnej

Warstwa weryfikująca jest objęta bramą edycji Enterprise (license_feature_flag: enterprise). Jest rozwiązywana przez kontrakty Core i Pki; publiczny interfejs programowania aplikacji (API) nie zmienia się przy aktualizacji edycji.

Kontrakt zachowania

• Token CMS lub znacznika czasu jest akceptowany tylko z dokładnie jedną strukturą SignerInfo, rygorystycznie sparsowanymi podpisanymi atrybutami, rozwiązanym certyfikatem podpisującego, zgodnym message-digest, obowiązkowym powiązaniem certyfikatu podpisującego oraz weryfikującym się podpisem SignerInfo.
• Certyfikat TSA jest walidowany w chwili genTime tokenu: pojedynczy krytyczny EKU id-kp-timeStamping, okno ważności, zakotwiczony w zaufaniu łańcuch oraz status unieważnienia.
• Werdykt Valid dodatkowo wymaga jednoznacznie nieunieważnionego statusu: co najmniej jednego miarodajnego Good (zweryfikowanej jako dobra odpowiedzi OCSP lub świeżej CRL umieszczającej numer seryjny poza niewygasłą listą). Status, który jest jedynie nieudowodnionym unieważnieniem, gdy OCSP i CRL są oba Unknown lub Unavailable, rozstrzyga się jako Indeterminate, nigdy Valid (ETSI EN 319 102-1: niedostępny status unieważnienia → INDETERMINATE). Ponieważ ścieżka awaryjna CRL poświadcza jedynie świeżość listy, a nie unieważnienie dla danego numeru seryjnego, łańcuch oparty wyłącznie na CRL bez dobrego OCSP jest zwykle Indeterminate.
• validateArchivalTimestampChain() osiąga w pełni zaliczony wynik wyłącznie dla kompletnego, zakotwiczonego w zaufaniu łańcucha DocTimeStamp obejmującego plik do EOF; dowodzi pokrycia zakresu bajtów, a nie osiągalności xref.
• Przetwarzanie polityk certyfikatów jest zgodne z RFC 5280 §6.1.4; domyślne nieograniczone łańcuchy pozostają bez zmian.
• Obsługiwane algorytmy to RSA (PKCS#1 v1.5 z SHA-2) i ECDSA (P-256/384/521); RSASSA-PSS, EdDSA i SHA-3 działają w trybie fail-closed; SHA-1 jest zdegradowane.

Status skanowania NDA

Ta publiczna strona opisuje wyłącznie zewnętrznie obserwowalne zachowanie warstwy weryfikującej. Wskazuje publiczny silnik, kontrakty Pki / kotwic zaufania oraz metodę validateArchivalTimestampChain() poprzez obsługiwaną powierzchnię. Konkretne elementy wewnętrzne DER, CMS, procesora polityk oraz walidatora ścieżki znajdują się w bramkowanym, szczegółowym dokumencie referencyjnym objętym umową o zachowaniu poufności (NDA).

Rozwiązanie awaryjne Core

NextPDF Core wykrywa obecność podpisu i wytwarza podpisy B-B / B-T, ale nie weryfikuje kryptograficznie CMS ani tokenów znacznika czasu, nie sprawdza łańcucha archiwalnego ani nie uruchamia przetwarzania polityk według RFC 5280 §6.1.4. Wdrożenie oparte wyłącznie na Core nie ma równoważnej warstwy weryfikującej; zobacz Bezpieczeństwo / Podpisywanie (Core).

Rozwiązanie awaryjne Pro

NextPDF Pro dodaje strategie podpisywania i obsługę e-faktur, ale nie zapewnia tej kryptograficznej warstwy weryfikującej; walidacja łańcucha archiwalnego i przetwarzanie polityk certyfikatów są dostarczane wyłącznie w nextpdf/enterprise.

Uwaga o granicy Enterprise

Warstwa weryfikująca jest opisana na poziomie zachowania. Rygorystyczny stos DER, parser CMS, procesor polityk oraz elementy wewnętrzne walidatora ścieżki są poza zakresem powierzchni publicznej i nie są tu odtwarzane.

Granica wdrożenia

Weryfikacja zależy od magazynu kotwic zaufania i wszelkiego materiału unieważnienia, który dostarcza wywołujący lub który jest osadzony w dokumencie. NextPDF Enterprise ocenia ten materiał; nie prowadzi listy zaufania, TSA ani usługi unieważnień. Operator odpowiada za wybór kotwic oraz świeżość osadzonego materiału unieważnienia.

Granica zgodności prawnej

Ta strona jest oznaczona export_control_class: legal-review-required; dotyczy weryfikacji kryptograficznej. Akceptacja prawna jest wymagana przed ustawieniem flagi publish. Pozytywny wynik weryfikacji to kryptograficzne stwierdzenie dotyczące podpisów i znaczników czasu dokumentu. Nie jest opinią prawną, ustaleniem kwalifikacji eIDAS ani certyfikacją. NextPDF nie zgłasza żadnego roszczenia o certyfikację AdES / PAdES. W sprawie obowiązków regulacyjnych skonsultuj się z własnymi doradcami ds. zgodności i prawnymi.

Zobacz też

• Podpis: producent PAdES B-LT / B-LTA — warstwa produkująca.
• Walidacja — strukturalne kontrole polityk w procesie (bez kryptografii).
• Archiwum: kondycja DSS, VRI, LTV — długoterminowe archiwizowanie i kondycja LTV.
• Bezpieczeństwo / Podpisywanie (Core) — CMS, RFC 3161, walidacja ścieżki RFC 5280, OCSP/CRL.
• Mapowanie bazowe PAdES — B-B, B-T, B-LT, B-LTA w różnych edycjach.
• PAdES · DSS · LTV — terminy ze słownika.