Enterprise Edition

Vertrauenslisten (TSL)

Auf einen Blick

Die EU-Signaturvalidierung beginnt mit einer veröffentlichten Tatsache: welche Anbieter qualifizierten Status besitzen. Diese Tatsache steht in Vertrauenslisten (TSLs) — signierten XML-Dokumenten, die jeder Mitgliedstaat veröffentlicht und die über die Liste der Vertrauenslisten der EU (LOTL) indexiert werden. NextPDF\Enterprise\Security\Tsl\TslPolicyEnforcer verwandelt eine TSL-URL oder rohes XML in ein TslDocument, auf das Sie sich verlassen können. Es ruft über abgesichertes HTTPS ab, prüft die XMLDSig-Signatur gegen von Ihnen verankerte Anker, parst gehärtetes XML und weist veraltete Listen ab. Ein weiterer Aufruf, TslTrustAnchorProvider::buildBundle(), wandelt aktive CA/QC-Dienste in ein versioniertes Vertrauensanker-Bündel um. Jedes Gate schlägt fail-closed fehl; jede Ablehnung ist eine typisierte Ausnahme.

Diese Seite verantwortet die Listenverarbeitung und die Ankerableitung. Die Zertifikatspfad-Validierung ist unter Signaturprüfung beschrieben. Das Mapping der eIDAS-Vertrauensniveaus ist unter eIDAS-Vertrauensniveaus beschrieben. Die Vertrauensbindung von Containern ist unter ASiC-Vertrauensbindung beschrieben.

Verfügbarkeit & Lizenzierung

Diese Funktion wird in NextPDF Enterprise (nextpdf/enterprise) ausgeliefert und wird mit einer Lizenzhülle der Enterprise-Stufe aktiviert. Eine Bereitstellung ohne diese Berechtigung lädt die Klassen der Funktion nicht. Editionen vergleichen und Lizenz erwerben.

Installation

composer require nextpdf/enterprise

Die Aktivierung erfordert Ihre Enterprise-Lizenzhülle. Siehe Installieren und authentifizieren. Die Klassen auf dieser Seite liegen unter NextPDF\Enterprise\Security\Tsl; die Netzwerkrichtlinien-Typen liegen unter NextPDF\Enterprise\Security. Der Online-Abruf benötigt zusätzlich einen beliebigen PSR-18-Client und eine PSR-17-Factory (zum Beispiel guzzlehttp/guzzle).

Konzeptioneller Überblick

Nach Artikel 22 der eIDAS-Verordnung veröffentlicht jeder Mitgliedstaat eine Vertrauensliste seiner qualifizierten Vertrauensdiensteanbieter, signiert oder gesiegelt für die automatisierte Verarbeitung. ETSI TS 119 612 definiert das XML-Format. Die Liste ist nur so vertrauenswürdig, wie drei Prüfungen sie machen: ihre Signatur, ihre Struktur und ihre Aktualität. NextPDF führt sie in genau dieser Reihenfolge als eine Pipeline aus:

Abrufen — TslFetcher ruft das XML ausschließlich über HTTPS ab. Ein SSRF-Wächter validiert den Host vor jedem Egress. Antworten sind größenbegrenzt, und ein PSR-16-Cache ermöglicht ETag-Revalidierung sowie Lesevorgänge im Air-Gap-Betrieb.
Prüfen — TslSignatureVerifier prüft die eingebettete XMLDSig-Signatur. Das Signaturzertifikat muss zu einem von Ihnen out-of-band verankerten Vertrauensanker führen; nichts im Dokument selbst wird für sich genommen vertraut.
Parsen — TslXmlParser extrahiert die Scheme-Information und jeden TSP-Dienst in ein unveränderliches TslDocument. Dokumente mit DOCTYPE werden abgewiesen, bevor irgendeine Entity-Tabelle aufgebaut wird.
Durchsetzen — der NextUpdate-Zeitpunkt der Liste darf nicht verstrichen sein. Eine veraltete Liste wird verworfen, niemals konsumiert.

TslPolicyEnforcer setzt alle vier zusammen; ein von ihm stammendes TslDocument hat jedes Gate passiert. Von dort aus filtert TslTrustAnchorProvider::buildBundle() Dienste, die sich sowohl im Status granted befinden als auch vom CA/QC-Typ sind, und gibt ein EnterpriseCaTrustAnchorBundle aus: verankerte PEM-Anker, eine Version tsl-<territory>-seq<N> und einen SHA-256-Integritäts-Digest. Dieses Bündel ist es, das die Pfadvalidierung und die ASiC-Vertrauensbindung konsumieren.

Dieselbe Maschinerie deckt den LOTL-Workflow ab. Prüfen Sie die LOTL gegen einen manuell verankerten Anker; prüfen Sie dann jede mitgliedstaatliche TSL gegen die Signaturzertifikate, die die LOTL für sie deklariert.

Warum es so funktioniert

Die tragende Entscheidung ist ein festes, minimales Prüfprofil anstelle von allgemeinem XMLDSig. Flexible XML-Signaturverarbeitung — beliebige Transform-Ketten, vom Angreifer deklarierte ID-Referenzen, Algorithmenagilität — ist der Ort, an dem Prüfer historisch scheitern. Deshalb akzeptiert der Prüfer genau ein Verarbeitungsmodell: exklusives C14N, eine wurzelabdeckende Referenz und die Zwei-Transform-Pipeline [enveloped-signature, exclusive-C14N], während alles andere fail-closed abgewiesen wird. Vertrauen bootstrappt niemals aus dem Dokument selbst: KeyInfo-Zertifikate führen immer nur zu von Ihnen konfigurierten Ankern. Die Aktualität liegt auf dem TslDocument selbst, sodass jeder Konsumentenpfad sie durchsetzt statt eines einzelnen optionalen Mitwirkenden. Das Ergebnis ist ein kleiner Kern, der testbar, deterministisch und ehrlich darüber ist, was er ablehnt.

Hintergrund zum Design: Qualifizierte Signaturen, erklärt.

API-Oberfläche

`TslPolicyEnforcer`

Der orchestrierte Einstiegspunkt: Abruf, Prüfung, Parsen und Aktualitätscheck in einem Aufruf.

public function __construct(
    private readonly TslFetcher $fetcher,
    private readonly TslSignatureVerifier $verifier,
    private readonly TslXmlParser $parser,
) {}

public function fetchAndVerify(string $url): TslDocument

public function verifyXml(string $xml): TslDocument

Wirft oder scheitert mit: TslFetchException und NextPDF\Enterprise\Security\NetworkPolicyViolation aus der Abrufstufe; TslSignatureException aus der Signaturprüfung; TslParseException aus dem Parsen, aus einem nicht-kanonischen NextUpdate-Wert oder aus einer veralteten Liste. Beide Methoden geben nur dann ein TslDocument zurück, wenn jedes Gate passiert wurde. Das Aktualitätsgate vergleicht hier NextUpdate gegen die aktuelle Systemuhr.

`TslFetcher`

HTTP-Fetcher mit ETag-basiertem Caching und einem Netzwerkrichtlinien-Gate.

public function __construct(
    private readonly ClientInterface $httpClient,
    private readonly RequestFactoryInterface $requestFactory,
    private readonly ?CacheInterface $cache = null,
    private readonly int $defaultTtlSeconds = 3600,
    private readonly int $maxBytes = 16_777_216,
    private readonly NetworkPolicy $networkPolicy = NetworkPolicy::ONLINE,
) {}

public function fetch(string $url): string

Wirft oder scheitert mit: TslFetchException bei einer Nicht-HTTPS-URL, einem abgewiesenen (SSRF-)Host, einem HTTP-Fehlerstatus, einer überdimensionierten Antwort oder einem leeren Body; NetworkPolicyViolation, wenn NetworkPolicy::STRICT_OFFLINE aktiv ist und kein gecachter Body existiert. Gecachte Bodys erfüllen die 304 Not Modified-Revalidierung und sind die einzigen Bodys, die unter STRICT_OFFLINE ausgeliefert werden. Cache-Einträge leben $defaultTtlSeconds lang.

`TslSignatureVerifier`

XMLDSig-Prüfer für signierte Vertrauenslisten.

public function __construct(
    private readonly array $trustAnchorsPem,
    private readonly int $clockTolerance = 0,
)

public function verify(string $xml): string

verify() gibt das PEM des Signaturzertifikats zurück, nachweislich verkettet mit einem der $trustAnchorsPem. Der Konstruktor wirft InvalidArgumentException, wenn die Ankerliste leer ist. $clockTolerance weitet das Gültigkeitsfenster des Zertifikats symmetrisch, in Sekunden.

Das akzeptierte Profil ist fest. Signaturalgorithmen: die Allowlist ALLOWED_SIG_ALG (rsa-sha256/384/512, ecdsa-sha256/384/512). Digests: die Allowlist ALLOWED_DIGEST_ALG (SHA-256, SHA-384, SHA-512). Kanonisierung: ausschließlich exklusives C14N 1.0. SHA-1 und MD5 werden als unsupported_algorithm abgewiesen.

Wirft oder scheitert mit: TslSignatureException, die einen maschinenlesbaren reason trägt:

Reason-Code	Bedeutung
`missing_signature`	Das Dokument hat kein `ds:Signature`-Element.
`untrusted_signer`	Das `KeyInfo`-Zertifikat führt nicht zu einem konfigurierten Anker.
`invalid_signature`	Struktureller Defekt oder die RSA-/ECDSA-Prüfung schlug fehl.
`digest_mismatch`	Der Referenz-Digest stimmt nicht mit dem kanonisierten Dokument überein.
`unsupported_algorithm`	Signatur- oder Digest-Algorithmus außerhalb der Allowlist.
`unsupported_transform`	Kanonisierungs- oder Transform-Pipeline außerhalb des festen Profils.
`expired_anchor`	Ein Kettenzertifikat liegt außerhalb seines Gültigkeitsfensters oder seine Gültigkeit ist nicht parsbar.

`TslXmlParser`

Signatur-agnostischer Strukturparser. Aufrufer MÜSSEN vor dem Vertrauen auf seine Ausgabe prüfen; TslPolicyEnforcer erzwingt diese Reihenfolge für Sie.

public function parse(string $xml): TslDocument

Wirft oder scheitert mit: TslParseException, wenn das XML einen DOCTYPE deklariert (XXE- und Entity-Expansion-Härtung), nicht geparst werden kann, die Wurzel TrustServiceStatusList fehlt oder eine ungültige TSLSequenceNumber trägt. Die Klasse stellt die Namespace-Konstanten NS_TSL, NS_DSIG und NS_TSL_X bereit.

`TslDocument` und `TspService`

TslDocument ist ein unveränderliches Wertobjekt: schemeTerritory, schemeOperatorName, tslType, sequenceNumber, issueDateTime, nextUpdate, tspServices und rawXmlSha256 (Nachweis-Hash über die rohen Bytes).

public function isStale(DateTimeImmutable $now): bool

public function assertFresh(DateTimeImmutable $now): void

public function servicesOfType(string $serviceTypeIdentifier): array

public function activeServices(): array

Wirft oder scheitert mit: isStale() und assertFresh() werfen TslParseException, wenn nextUpdate kein kanonischer UTC-dateTime mit einem expliziten Z oder numerischen Offset ist; eine veraltete Liste lässt assertFresh() werfen. activeServices() gibt nur Dienste im Status granted zurück. servicesOfType() filtert nach ETSI-Dienstetyp-URI.

Jeder TspService-Eintrag stellt tspName, serviceName, serviceTypeIdentifier, serviceStatus, statusStartingTime, serviceCertificatePem, qualifiers und additionalServiceInformation bereit, sowie:

public function isGranted(): bool

public function isQualifiedCa(): bool

Nützliche Konstanten: TspService::STATUS_GRANTED, TspService::STATUS_WITHDRAWN, TspService::TYPE_CA_QC, TspService::TYPE_OCSP_QC, TspService::TYPE_TSA_QTST. Qualifier-URIs (zum Beispiel TspServiceQualifier::FOR_ESIG, FOR_ESEAL, QSCD_STATEMENT, NO_QSCD) erscheinen auf TspServiceQualifier für die eIDAS-Mapping-Schicht.

`TslTrustAnchorProvider` und das Anker-Bündel

public function buildBundle(TslDocument $tsl, DateTimeImmutable $now): EnterpriseCaTrustAnchorBundle

Wirft oder scheitert mit: TslParseException, wenn die TSL bei $now veraltet ist, wenn nextUpdate kein kanonischer UTC-Wert ist oder wenn die Liste keine aktiven CA/QC-Dienste enthält.

BC-Hinweis — die Aktualitätsregel von buildBundle($now). buildBundle() erfordert den Validierungszeitpunkt und ruft TslDocument::assertFresh($now) auf, bevor ein einziger Anker extrahiert wird. Frühere Revisionen konnten Anker aus einem vom Parser erzeugten TslDocument ohne jede Aktualitätsprüfung ableiten. Aufrufer, die gecachte oder archivierte Listen einspeisten, müssen nun den Zeitpunkt übergeben, zu dem ihre Validierung läuft; eine zu diesem Zeitpunkt veraltete Liste wirft, anstatt stillschweigend Vertrauensanker zu setzen.

Das zurückgegebene EnterpriseCaTrustAnchorBundle ist ein schreibgeschütztes Wertobjekt: anchorsPem (die PEM-Anker), bundleVersion (tsl-<territory>-seq<N>) und bundleSha256 (Integritäts-Digest über die kanonisierte PEM-Verkettung). Beziehen Sie es von buildBundle(); konstruieren Sie es nicht von Hand — der Konstruktor wirft InvalidArgumentException bei einer Digest-Abweichung oder fehlerhaftem PEM.

public function containsFingerprint(string $anchorDerSha256Hex): bool

public static function computeBundleSha256(array $anchorsPem): string

Codebeispiel — Schnellstart

Authentifizieren und konsumieren Sie eine lokal gespiegelte Vertrauensliste. Für diesen Pfad wird keine HTTP-Abhängigkeit benötigt: prüfen, parsen und dann die Aktualität zu Ihrem Validierungszeitpunkt gaten.

<?php

declare(strict_types=1);

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

use NextPDF\Enterprise\Security\Tsl\TslParseException;
use NextPDF\Enterprise\Security\Tsl\TslSignatureException;
use NextPDF\Enterprise\Security\Tsl\TslSignatureVerifier;
use NextPDF\Enterprise\Security\Tsl\TslXmlParser;

// The list-signing certificate, pinned OUT-OF-BAND. Never take it from the list itself.
$pinnedAnchorPem = (string) file_get_contents(__DIR__ . '/tsl-signer-anchor.pem');

// A trusted-list XML document you mirrored locally.
$tslXml = (string) file_get_contents(__DIR__ . '/member-state-tsl.xml');

try {
    // 1. Authenticate: XMLDSig must verify AND the signer must chain to the pinned anchor.
    (new TslSignatureVerifier(trustAnchorsPem: [$pinnedAnchorPem]))->verify($tslXml);

    // 2. Parse the now-authenticated bytes.
    $tsl = (new TslXmlParser())->parse($tslXml);

    // 3. Freshness: refuse a list whose NextUpdate has passed.
    $tsl->assertFresh(new DateTimeImmutable('now', new DateTimeZone('UTC')));
} catch (TslSignatureException $e) {
    fwrite(STDERR, "TSL rejected ({$e->reason}): {$e->getMessage()}" . PHP_EOL);
    exit(1);
} catch (TslParseException $e) {
    fwrite(STDERR, 'TSL unusable: ' . $e->getMessage() . PHP_EOL);
    exit(1);
}

echo "Territory: {$tsl->schemeTerritory}\n";
echo "Sequence: {$tsl->sequenceNumber}\n";
echo 'Active services: ' . count($tsl->activeServices()) . "\n";

Erwartete Ausgabe (Werte variieren je nach Liste):

Territory: DE
Sequence: 127
Active services: 143

Codebeispiel — Produktion

Verdrahten Sie die vollständige Online-Pipeline: abgesicherter Abruf mit Caching, Signaturprüfung, Parsen, Aktualität und dann Ableitung des Anker-Bündels. Jede Fehlerklasse wird abgefangen und eindeutig gemeldet.

<?php

declare(strict_types=1);

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

use GuzzleHttp\Client;
use GuzzleHttp\Psr7\HttpFactory;
use NextPDF\Enterprise\Security\NetworkPolicy;
use NextPDF\Enterprise\Security\NetworkPolicyViolation;
use NextPDF\Enterprise\Security\Tsl\TslFetchException;
use NextPDF\Enterprise\Security\Tsl\TslFetcher;
use NextPDF\Enterprise\Security\Tsl\TslParseException;
use NextPDF\Enterprise\Security\Tsl\TslPolicyEnforcer;
use NextPDF\Enterprise\Security\Tsl\TslSignatureException;
use NextPDF\Enterprise\Security\Tsl\TslSignatureVerifier;
use NextPDF\Enterprise\Security\Tsl\TslTrustAnchorProvider;
use NextPDF\Enterprise\Security\Tsl\TslXmlParser;
use Symfony\Component\Cache\Adapter\FilesystemAdapter;
use Symfony\Component\Cache\Psr16Cache;

// Any PSR-18 client, PSR-17 factory, and PSR-16 cache work; these are examples.
$enforcer = new TslPolicyEnforcer(
    fetcher: new TslFetcher(
        httpClient: new Client(),
        requestFactory: new HttpFactory(),
        cache: new Psr16Cache(new FilesystemAdapter('tsl')),
        defaultTtlSeconds: 3600,
        maxBytes: 16_777_216,
        networkPolicy: NetworkPolicy::ONLINE,
    ),
    verifier: new TslSignatureVerifier(
        trustAnchorsPem: [(string) file_get_contents(__DIR__ . '/tsl-signer-anchor.pem')],
        clockTolerance: 300,
    ),
    parser: new TslXmlParser(),
);

// Use the official publication URL for your scheme territory (HTTPS required).
$tslUrl = 'https://trusted-lists.example.eu/member-state-tsl.xml';
$now = new DateTimeImmutable('now', new DateTimeZone('UTC'));

try {
    $tsl = $enforcer->fetchAndVerify($tslUrl);
    $bundle = (new TslTrustAnchorProvider())->buildBundle($tsl, $now);
} catch (NetworkPolicyViolation $e) {
    // Air-gapped posture: egress forbidden and no cached body available.
    fwrite(STDERR, 'Network policy: ' . $e->getMessage() . PHP_EOL);
    exit(75);
} catch (TslFetchException $e) {
    // Transport layer: SSRF-rejected URL, HTTP error, oversized or empty body.
    fwrite(STDERR, 'Fetch failed: ' . $e->getMessage() . PHP_EOL);
    exit(1);
} catch (TslSignatureException $e) {
    // Authentication layer: treat as a potential attack, not a retry case.
    fwrite(STDERR, "Signature rejected ({$e->reason}): {$e->getMessage()}" . PHP_EOL);
    exit(1);
} catch (TslParseException $e) {
    // Structure or freshness: stale list, malformed NextUpdate, no active CA/QC services.
    fwrite(STDERR, 'List unusable: ' . $e->getMessage() . PHP_EOL);
    exit(1);
}

printf(
    "Anchor bundle %s: %d anchors (sha256 %s...)\n",
    $bundle->bundleVersion,
    count($bundle->anchorsPem),
    substr($bundle->bundleSha256, 0, 12),
);

Erwartete Ausgabe (Werte variieren je nach Liste):

Anchor bundle tsl-de-seq127: 96 anchors (sha256 4b0e2a9f31c8...)

Erfassen Sie bundleVersion und bundleSha256 bei jeder Validierung, die Sie gegen das Bündel durchführen. Sie benennen die exakte Ankermenge hinter jedem Urteil.

Grenzfälle & Fallstricke

Das Aktualitätsgate des Enforcers verwendet die aktuelle Uhr. fetchAndVerify() und verifyXml() weisen eine Liste ab, deren NextUpdate bereits verstrichen ist. Für die historische Validierung gegen eine archivierte Liste steuern Sie TslSignatureVerifier und TslXmlParser direkt an und rufen dann assertFresh() mit dem vergangenen Zeitpunkt auf, den Ihre Nachweise stützen.
buildBundle() bestätigt die Aktualität bei Ihrem $now erneut. Eine Liste, die den Enforcer passiert hat, kann hier dennoch abgewiesen werden, wenn Ihr Validierungszeitpunkt später liegt. Siehe den BC-Hinweis oben.
Setzen Sie trustAnchorsPem niemals aus der Liste, die Sie gerade prüfen. Der Anker muss aus einer out-of-band verankerten Quelle stammen (für die LOTL) oder aus einer bereits geprüften übergeordneten Liste (für mitgliedstaatliche TSLs). Alles andere macht die Prüfung zirkulär.
Ein DOCTYPE an beliebiger Stelle ist fatal. Konforme TSLs tragen niemals eine DTD, daher weist der Parser jeden DOCTYPE ab, bevor libxml eine Entity-Tabelle aufbaut. Dies ist gewollte Härtung, keine Parser-Beschränkung.
Fehlende strukturelle Felder degradieren sicher. Ein Dienst ohne lesbaren Status wird als withdrawn behandelt und kann so niemals zum Anker werden. Ein fehlendes Scheme-Territorium parst als unknown. Fail-closed-Standardwerte halten fehlerhafte Einträge aus dem Vertrauensmaterial heraus.
Intermediates müssen echte CAs sein. Beim Kettenaufbau wird ein Kandidaten-Issuer ohne basicConstraints cA=TRUE (oder mit keyUsage ohne keyCertSign) übersprungen. Ein in KeyInfo eingeschmuggeltes Endentitätszertifikat kann nicht als Pfad-Intermediate dienen. Ketten sind auf Tiefe 8 begrenzt.
NextUpdate muss kanonisches UTC sein. Ein Wert ohne explizites Z oder numerischen Offset wirft TslParseException. Er wird niemals in der lokalen Zeitzone des Servers reinterpretiert.
Große Listen und das Byte-Limit. Antworten werden bis zu $maxBytes (Standard 16 MiB) gelesen. Erhöhen Sie das Limit im Konstruktor, falls die Liste Ihres Schemas größer ist; eine Trunkierung zeigt sich als Signaturfehler, niemals als stilles Akzeptieren.
clockTolerance weitet nur. Es fügt den Zertifikatsgültigkeitsprüfungen symmetrischen Spielraum hinzu. Es lockert nicht das listenweite Aktualitätsgate.

Sicherheitshinweise

Immer vor dem Parsen prüfen. TslXmlParser ist per Design signatur-agnostisch. TslPolicyEnforcer ordnet die Prüfung zuerst an; wenn Sie die Teile selbst zusammensetzen, behalten Sie diese Reihenfolge bei.
SSRF-Verteidigung in der Tiefe. fetch() erfordert https:// und validiert den Host gegen private, Loopback-, Link-Local-, CGN- und Cloud-Metadaten-Bereiche, mit A- und AAAA-DNS-Auflösung zur Minderung von Rebinding. Eine abgewiesene URL wirft vor jedem Egress.
XXE- und Entity-Expansion-Härtung. Dokumente mit DOCTYPE werden abgewiesen, bevor die Entity-Tabelle existiert, und erneut nach dem Laden. Das Laden von Netzwerk-Entities ist deaktiviert; externe Entities werden niemals substituiert.
Striktes XMLDSig-Profil. Ausschließlich exklusives C14N; genau das Transform-Paar [enveloped-signature, exclusive-C14N]; die geprüfte Referenz muss die Dokumentwurzel abdecken; der enveloped-Transform entfernt nur die geprüfte Signatur und bewahrt Geschwister-Signaturen. Veraltete Algorithmen (SHA-1, MD5) werden abgewiesen.
Ketten-Disziplin. Jedes Kettenglied — Signierer, Intermediates und der Fall des direkten Ankers — wird auf zeitliche Gültigkeit geprüft, fail-closed bei nicht parsbaren Gültigkeitsgrenzen. Schleifen werden erkannt; die Tiefe ist begrenzt.
Air-Gap-Haltung. Unter NetworkPolicy::STRICT_OFFLINE führt der Abrufpfad überhaupt keinen ausgehenden Egress durch; nur ein zuvor gecachter Body darf ausgeliefert werden, und alles andere wirft NetworkPolicyViolation fail-fast.
Bündel-Digests erkennen Beschädigung, nicht Manipulation. bundleSha256 wird bei der Konstruktion validiert und erkennt Übertragungsdrift. Wenn der Digest aus denselben Ankern abgeleitet wird, die er schützt, ist er kein unabhängiger Manipulationsnachweis. Verankern Sie Digests out-of-band, wenn Sie Bündel zwischen Systemen transportieren.

Konformität

Die Pipeline konsumiert Vertrauenslisten so, wie ETSI TS 119 612 sie definiert: sie authentifiziert die Signatur des Scheme-Betreibers (§5.7), parst die Scheme-Information und die Strukturen der Anbieterliste (§5.3, §5.4, §5.5), setzt die UTC-dateTime-Regeln durch (§5.1.3) und verwirft Listen, deren NextUpdate verstrichen ist (§5.3.15). Dies unterstützt das eIDAS-Artikel-22-Modell signierter, maschinenverarbeitbarer Vertrauenslisten. Der Kettenaufbau wendet die RFC-5280-Gates für Basic-Constraints und Key-Usage auf Kandidaten-Issuer an.

Unterstützung ist nicht Konformität, und Konformität ist nicht Zertifizierung. NextPDF implementiert die auf dieser Seite beschriebenen Prüfungen; es wurde von keiner Stelle gegen ETSI TS 119 612, eIDAS oder irgendeinen anderen Standard zertifiziert, und NextPDF besitzt keine Zertifizierung und gewährt keine. Das Konsumieren einer Vertrauensliste über diese API macht eine Signatur für sich genommen nicht „qualifiziert” oder rechtswirksam. Ob Ihr vollständiger Validierungsprozess eine rechtliche oder beschaffungsbezogene Anforderung erfüllt, ist eine Feststellung für Ihre Prüfer.

Verhalten im FIPS-Modus

Die TSL-Signaturprüfung führt RSA- und ECDSA-Prüfungen prozessintern über die gebündelte Krypto-Bibliothek aus. Sie wird nicht durch den Enterprise-FIPS-Modus-Laufzeitwächter geleitet, und das Aktivieren des FIPS-Modus ändert ihr Verhalten nicht. Sie ist kein FIPS-validierter kryptografischer Dienst, und es wird keine FIPS-140-Zertifizierung beansprucht. Bereitstellungen mit FIPS-Verpflichtungen sollten diese API entsprechend abgrenzen und siehe FIPS-140-2/3-Kryptografierichtlinie.

Verhaltensvertrag

fetch() führt Egress nur für HTTPS-URLs durch, die die SSRF-Validierung bestehen, liest höchstens $maxBytes und respektiert die konfigurierte NetworkPolicy; unter STRICT_OFFLINE wird nur ein gecachter Body jemals zurückgegeben.
Keine Parser-Ausgabe wird zu Vertrauensmaterial, bevor verify() erfolgreich ist; TslPolicyEnforcer garantiert diese Reihenfolge.
verify() gibt das Signierer-PEM nur zurück, wenn Digest und Signaturprüfung unter dem festen Profil aufgehen und der Signierer innerhalb von Tiefe 8 und mit jedem zeitlich gültigen Glied zu einem konfigurierten Anker führt.
Der Enforcer weist jede Liste ab, deren NextUpdate zur aktuellen Uhr verstrichen ist; buildBundle() bestätigt die Aktualität zum vom Aufrufer gelieferten Zeitpunkt erneut, bevor Anker abgeleitet werden.
Anker leiten sich ausschließlich aus Diensten im Status granted mit dem CA/QC-Dienstetyp ab; eine leere aktive Menge wirft, anstatt ein leeres Bündel zu liefern.
Jeder Fehler ist eine typisierte Ausnahme (TslFetchException, NetworkPolicyViolation, TslSignatureException mit einem Reason-Code, TslParseException); keine Methode gibt ein partielles oder ungeprüftes Dokument zurück.

Core-Fallback

NextPDF Core validiert PDF-Signaturen gegen Vertrauensanker, die Sie explizit über seinen CaTrustAnchorBundle-Vertrag verankern — siehe Core-Sicherheit. Core hat keine Vertrauenslisten-Funktion: kein TSL-Abruf, keine XMLDSig-Listenauthentifizierung, kein ETSI-TS-119-612-Parsing und keine Ankerableitung aus qualifizierten Diensteinträgen. Mit Core allein pflegen Sie Ihre Ankermenge von Hand; ihre Ableitung aus authentifizierten EU-Vertrauenslisten erfordert NextPDF Enterprise.

Veröffentlichungsgrenze

Diese Seite dokumentiert ausschließlich extern beobachtbares Verhalten und die unterstützte öffentliche API-Oberfläche. Interne Namespace-Pfade, Hilfsklassen, Mechanismus-Tabellen, Runbook-Dateinamen und Ticket-Präfixe liegen außerhalb des Geltungsbereichs.

Siehe auch

ASiC-Vertrauensbindung — bindet Container-Signierer an die Anker-Bündel, die diese Seite ableitet.
eIDAS-Vertrauensniveaus — mappt TspService-Nachweise auf Vertrauensniveaus (Levels of Assurance).
Signaturprüfung — die Prüfseite, die Vertrauensanker für die Pfadvalidierung konsumiert.
Sicherheit — Tiefenreferenz — die vertragsnahe Referenz des Enterprise-Sicherheitsmoduls.
Qualifizierte Signaturen, erklärt — warum Vertrauenslisten das EU-Vertrauensmodell verankern.
Langzeitvalidierung — warum Validierungszeitpunkt und bewahrte Nachweise wichtig sind.