Pro Edition
Sicherheit — Ausführliche Referenz
Auf einen Blick
Abschnitt betitelt „Auf einen Blick“Dies ist die Deep Reference für die NextPDF-Pro-Sicherheitsoberfläche: Maskierung zur Erzeugungszeit, Textebenen-PII-Erkennung, die Remote- und Cloud-KMS-Signiersitzung, mehrparteiisches sequenzielles Signieren, der CAdES- und XAdES-Ingest-Pfad, die PAdES-B-B-Baseline-Stufe und PAdES-B-T-Signierunterstützung (eine B-B-Signatur plus einen RFC 3161 signature-time-stamp auf dem Signaturwert). Sie nennt den Public-API-Vertrag, das extern beobachtbare Verhalten und die Enterprise-B-LT/B-LTA-Grenze. Sie ist auf Verhaltensebene; sie zitiert keine internen Implementierungspfade.
Verfügbarkeit & Lizenzierung
Abschnitt betitelt „Verfügbarkeit & Lizenzierung“Diese Fähigkeit wird in NextPDF Pro (nextpdf/pro) ausgeliefert und wird mit einer Lizenz-Envelope der Pro-Stufe aktiviert. Ein Deployment ohne diese Berechtigung lädt die Klassen der Fähigkeit nicht. Editionen vergleichen und Lizenz erwerben.
Core liefert den Software-CMS-Signierer, den RFC 3161-Zeitstempel-Client, die RFC 5280-Pfadvalidierung sowie die OCSP- und CRL-Sperrprüfung. Pro ergänzt die hier beschriebene Maskierung, PII-Erkennung, Remote- und Cloud-KMS-Signieroberfläche sowie PAdES-B-T-Signierunterstützung (es setzt den Core-RFC 3161-Stack zusammen, um einen signature-time-stamp hinzuzufügen). Das Capability-Flag für diese Oberfläche ist pro: Ein Deployment ohne aktive Pro-Berechtigung lädt diese Klassen nicht, der Core-Signiervertrag funktioniert weiterhin unverändert, und Code, der vom Core-Vertrag abhängt, bricht nicht, wenn die Berechtigung fehlt.
Installation
Abschnitt betitelt „Installation“composer require nextpdf/pro:^3Verhaltensvertrag
Abschnitt betitelt „Verhaltensvertrag“Die Maskierungs-Engine wendet eine geordnete Regelliste auf Text an, bevor die Seite geschrieben wird. Eine Regel matcht ein PCRE-Muster und ersetzt einen Treffer in einem von drei Modi:
- BlackBox — entfernt den getroffenen Text aus dem Content-Stream und reserviert einen Füllbereich. Dieser Modus entfernt die zugrunde liegenden Textobjekte, wie getestet.
- Asterisks — ersetzt jedes getroffene Zeichen durch ein Sternchen und erhält die Zeichenanzahl.
- FixedLabel — ersetzt den gesamten Treffer durch ein konfigurierbares Label, standardmäßig
[REDACTED].
Eine Regel wird aus einem exakten Literal über MaskingRule::exactMatch (das Literal wird regex-escaped) oder aus einem benutzerdefinierten PCRE-Muster über MaskingRule::regex erstellt. MaskingConfig hält die geordnete Regelliste, einen Standardmodus und die Füllfarbe. MaskingConfig::fromArray parst eine Konfigurations-Map und verwirft stillschweigend einen Regeleintrag, der kein verwendbares String-Muster besitzt, statt den gesamten Import scheitern zu lassen.
Die PII-Oberfläche extrahiert die PDF-Textebene und wendet dann eingebaute Muster für E-Mail-Adressen, Telefonnummern, US-amerikanische Social-Security-Nummern und Kreditkartennummern an. Sie gibt ein strukturiertes Ergebnis zurück: einen Boolean, ob ein Treffer gefunden wurde, eine Trefferanzahl, die maskierte Textansicht und die Liste der gescannten Typen. Der Aufrufer kann den Scan auf eine Teilmenge der vier Typen beschränken. Die Oberfläche überschreibt nicht die gerenderten Seiten-Glyphen; eine gescannte Seite ohne Textebene liefert keine Treffer. Behandeln Sie das Ergebnis als Textebenen-Mustererkennung der konfigurierten Typen, nicht als vollständige Entfernung personenbezogener Daten und nicht als Aussage zur regulatorischen Compliance.
Die Signiersitzung ist zweiphasig. RemoteSigningSession::create öffnet eine Sitzung. prepare berechnet den Dokument-Digest über die beiden ByteRange-Regionen und baut dann die signierten CMS-Attribute. complete ruft die Strategie auf und bettet das Ergebnis ein; suspend serialisiert die Sitzung, sodass ein Worker sie später mit resume und completeWithRawSignature fortsetzen kann. Die Sitzung baut eine CMS-SignedData zusammen und speichert sie DER-codiert im Eintrag Contents des Signatur-Dictionarys — ISO 32000-2 §12.8.1. Wird ein parsbares X.509-Zertifikat bereitgestellt, emittiert die Sitzung den vollständigen Satz obligatorischer PAdES-B-B-signierter Attribute: content-type, message-digest, signing-time, signing-certificate-v2 und ein Algorithm-Protection-Attribut — RFC 5652 §5.3 und RFC 5652 §5. Der Prüfer berechnet den Inhalts-Digest neu und vergleicht ihn mit dem message-digest-Attribut; der Vergleich muss übereinstimmen, damit die Signatur gültig ist — RFC 5652 §5.4.
Wenn die konfigurierte PAdES-Stufe B-T ist (RemoteSigningConfig::default->withLevel(SignatureLevel::PAdES_B_T) oder über SequentialSigner::withTimestamping) und ein Zeitstempelanbieter verdrahtet ist, bettet die Sitzung zusätzlich genau einen RFC 3161 signature-time-stamp als unsigniertes CMS-Attribut auf dem ersten SignerInfo ein. Ein signature-time-stamp ist ein unsigniertes Attribut, das ein Zeitstempel-Token trägt, das auf dem digitalen Signaturwert für einen Unterzeichner berechnet wurde — ETSI EN 319 122-1 §5.3; sein MessageImprint ist der Hash des SignerInfo-Signaturfeldwerts ohne den ASN.1-Tag und die Länge — ETSI EN 319 122-1 §5.3 und RFC 3161 Appendix A (OID id-aa-timeStampToken = 1.2.840.113549.1.9.16.2.14). Weil der Zeitstempel ein unsigniertes Attribut ist, sind die B-B-signierten Attribute, der message-digest, der SignerInfo-Signaturwert und der PDF-/ByteRange byte-identisch zur B-B-Ausgabe; nur die CMS wächst um das unsignierte Attribut, und der für B-T reservierte /Contents-Platz wird angehoben, damit es hineinpasst. Das Token wird vom konfigurierten Zeitstempelanbieter angefordert (dem standardmäßigen Core-RFC 3161-Client oder einem vom Aufrufer bereitgestellten Anbieter). Auf dem Standardanbieterpfad ist der Imprint-Digest SHA-256; die SHA-1-gebundene Legacy-Form ESSCertID v1 wird abgelehnt und ESSCertIDv2 wird verlangt — RFC 5816 §1. Ein TSA-Fehler, eine abgelehnte Anfrage, ein fehlerhafter Nonce- oder Message-Imprint-Echo, ein fehlerhaftes oder Token mit nicht unterstütztem Algorithmus oder ein Token, das die kryptografische Verifikation nicht besteht, erscheint als typisierte PadesBt-Ausnahme, wobei die ursprüngliche Core-Ausnahme als vorheriges Throwable erhalten bleibt. NextPDF Pro implementiert PAdES-B-T-Signierunterstützung gemäß ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 und RFC 5816 und ist fixture-verifiziert; es behauptet keine unabhängige ETSI EN 319 142-1-Zertifizierung und behauptet keine rechtliche Dokumentgültigkeit.
SequentialSigner koordiniert mehrparteiisches Signieren. Jeder Unterzeichner ist eine separate Inkrementelle-Update-Revision. Der erste Unterzeichner kann eine Zertifizierungssignatur mit einer über certifyFirst gesetzten DocMDP-Einschränkung sein. PadesWrapper ingestiert eine bestehende Signatur: fromCades bettet eine CMS-Struktur direkt ein, fromXades parst ein XAdES-Dokument und wiederverwendet dessen Kernsignaturmaterial, und detect wählt automatisch nach Format aus. Der XAdES-Pfad wiederverwendet das Zertifikat, die Kette, den Signaturwert und den Algorithmus; er überträgt keine qualifizierenden XAdES-Eigenschaften.
Öffentliche API-Oberfläche
Abschnitt betitelt „Öffentliche API-Oberfläche“composer require nextpdf/pro:^3| Typ | Art | Rolle | Stabilität | Seit |
|---|---|---|---|---|
RemoteSigningSession | class | Zweiphasige Remote- oder asynchrone Signiersitzung | stable | 1.9.0 |
RemoteSigningConfig | class | Immutable Sitzungskonfiguration, einschließlich PAdES-Stufe und Algorithmus | stable | 1.9.0 |
SequentialSigner | class | Mehrparteiisches sequenzielles Signieren mit DocMDP-Unterstützung | stable | 1.9.0 |
SequentialSigningResult | class | Ergebnis eines sequenziellen Laufs: PDF-Bytes, Kette, Anzahl, Vollständigkeit | stable | 1.9.0 |
SigningStrategy | interface | Der Signiermechanismus-Vertrag, den eine Sitzung aufruft | stable | 1.9.0 |
PadesWrapper | class | Umhüllt eine bestehende CAdES- oder XAdES-Signatur für die PAdES-Einbettung | stable | 1.9.0 |
KmsSignerInterface | interface (SPI) | Vertrag für Drittanbieter-HSM- und KMS-Treiber; erweitert den Core-HSM-Signiervertrag | stable | 2.1.0 |
SignatureAlgorithm | enum | Pro-Signaturalgorithmus-OIDs und Digest-Namen | stable | 2.1.0 |
GenerationTimeMasker | class | Regelgesteuerte Maskierung, angewendet bevor die Seite geschrieben wird | stable | 1.9.0 |
MaskingConfig | class | Immutable Maskierungskonfiguration | stable | 1.9.0 |
MaskingRule | class | Eine einzelne Maskierungsregel (Literal oder PCRE) | stable | 1.9.0 |
MaskingMode | enum | BlackBox, Asterisks, FixedLabel | stable | 1.9.0 |
SigningStrategy-Vertrag
Abschnitt betitelt „SigningStrategy-Vertrag“Eine Strategie operiert auf den DER-codierten signierten Attributen und gibt die rohen Signatur-Bytes zurück. Die Sitzung, nicht die Strategie, baut die CMS-SignedData zusammen. Eine Strategie stellt das DER des Unterzeichnerzertifikats, das DER der Kette geordnet von leaf nach root, die Signaturalgorithmus-OID, den Digest-Algorithmus-Namen und ein isAsync-Flag bereit, das eine Strategie markiert, deren Sitzung serialisiert und fortgesetzt werden kann.
KmsSignerInterface-SPI
Abschnitt betitelt „KmsSignerInterface-SPI“KmsSignerInterface erweitert den Core-HSM-Signiervertrag. Es ergänzt eine stabile providerId für die Registry-Suche, eine Methode signWithVersion mit einem expliziten Per-Call-Schlüsselversionsparameter sowie supportsAlgorithm und supportedAlgorithms, sodass ein Aufrufer die Algorithmuskompatibilität vor dem Signieraufruf ermittelt. Die reservierten eingebauten Anbieterbezeichner sind aws-kms, azure-keyvault, gcp-kms, pkcs11, openssl-cli und openssl-engine. Ein Drittanbietertreiber muss seinen Bezeichner mit einem Namespace versehen, um eine Kollision zu vermeiden. Die Standard-Schlüsselversionssemantik variiert je nach Anbieter: Ein Alias-auflösender Anbieter löst den aktiven Schlüssel aus dem Alias auf, wenn die Version null ist; ein Anbieter, der die neueste aktivierte Version auswählt, tut dies über seinen Transport; ein Anbieter ohne serverseitiges Konzept einer aktiven Version muss eine in seiner Konfiguration fixierte Version verwenden und muss einen Schlüsselverwaltungsfehler auslösen, wenn weder der Aufruf noch die Konfiguration eine Version fixiert. Eine nicht-leere Version fixiert diese Version, und der Anbieter muss einen Schlüsselverwaltungsfehler auslösen, wenn die Version unbekannt, deaktiviert oder widerrufen ist.
Sonderfälle & Fallstricke
Abschnitt betitelt „Sonderfälle & Fallstricke“- Eine erzeugte Signatur ist keine verifizierte Signatur. Die Pfadvalidierung läuft beim Prüfer mit den Vertrauensankern und Basic-Constraint-Prüfungen dieses Prüfers — RFC 5280 §6.1. Der Erzeuger kann das Ergebnis nicht zusichern.
- Die Sitzung hat einen Legacy-Fallback mit drei Attributen für synthetische Nicht-X.509-Zertifikats-Bytes. Produktionsstrategien liefern stets echtes X.509-DER, sodass der vollständige B-B-Attributsatz der Produktionspfad ist. Der Fallback existiert nur für die historische DER-Mechanik-Testoberfläche.
- Die CMS-Struktur muss in den reservierten
Contents-Platz passen. Die B-B-SignedData mit einer vollständigen Zertifikatskette hat eine Größe; die Sitzung löst einen Overflow-Fehler aus, wenn die zusammengebaute CMS den reservierten Hex-Platz überschreitet. Bemessen Sie den reservierten Platz entsprechend. Für B-T vergrößert das eingebettete RFC 3161-Token (dominiert durch die TSA-Zertifikatskette) die CMS; der für B-T reservierte Platz wird automatisch angehoben, und ein zu klein konfigurierter Platz scheitert fail-closed mit einem typisierten Konfigurationsfehler, statt zu truncieren. MaskingConfig::fromArrayverwirft einen Eintrag ohne verwendbares String-Muster, statt den Import scheitern zu lassen. Validieren Sie die Konfigurationsquelle, wenn ein stillschweigendes Verwerfen inakzeptabel ist.- Der BlackBox-Maskierungsmodus emittiert eine leere Ersetzung für den getroffenen Lauf und entfernt den zugrunde liegenden Text. Eine Regel, die einen Wert nicht matcht, maskiert ihn nicht; die Engine sichert nicht zu, dass alle sensiblen Inhalte gefunden werden.
- B-T erfordert einen verdrahteten Zeitstempelanbieter. Auf dem Standard-Core-RFC 3161-Anbieterpfad ist der Imprint-Digest SHA-256; ein Nicht-SHA-256-Imprint-Digest auf diesem Pfad wird mit einem typisierten Konfigurationsfehler abgelehnt, statt stillschweigend herabgestuft zu werden, und ein vom Aufrufer bereitgestellter benutzerdefinierter Anbieter darf legitim einen anderen zugelassenen Digest verwenden. Eine Zeitstempel-
serialNumberist pro Token einer gegebenen Time-Stamping Authority eindeutig, undgenTimeist der UTC-Zeitpunkt, zu dem das Token erstellt wurde — RFC 3161 §2.4.1, §2.4.2. Langzeitvalidierungsmaterial für B-LT/B-LTA bleibt ein Anliegen der Enterprise-Grenze; Pro erzeugt keinen DSS, kein VRI und keinen Dokument-Zeitstempel. - OCSP
unknownist nichtgood, und die Aktualität des Status ist durchthisUpdateundnextUpdatebegrenzt — RFC 6960 §2.2, §4.2.
Verhalten im FIPS-Modus
Abschnitt betitelt „Verhalten im FIPS-Modus“Pro wählt den Algorithmus aus dem konfigurierten Signaturalgorithmus und der Strategie. Wenn gegen ein FIPS-validiertes KMS oder HSM konfiguriert, läuft die kryptografische Operation in dieser validierten Grenze, und der Algorithmussatz ist derjenige, den diese Grenze erlaubt. NextPDF Pro führt strukturelle CMS-Zusammenstellung und Digest-Berechnung durch; es ist kein FIPS-validiertes kryptografisches Modul und erhebt keinen FIPS-Zertifizierungsanspruch. Ein Deployment, das eine FIPS-Haltung erfordert, muss ein FIPS-validiertes KMS oder HSM konfigurieren, und das FIPS 140-3-Kryptorichtlinienprofil ist eine Enterprise-Fähigkeit.
Export-Control-Haltung
Abschnitt betitelt „Export-Control-Haltung“Dieses Modul betrifft kryptografische Funktionalität; behandeln Sie es in Ihrer eigenen Prüfung als sicherheitsrelevant.
Enterprise-Grenze
Abschnitt betitelt „Enterprise-Grenze“NextPDF Pro erzeugt die B-B-Baseline und die B-T-Stufe. Für B-B baut die Sitzung eine CMS-SignedData mit dem B-B-signierten Attributsatz zusammen und wendet keinen Zeitstempel an. Für B-T fügt sie genau einen RFC 3161 signature-time-stamp als unsigniertes CMS-Attribut hinzu, berechnet auf dem digitalen Signaturwert für einen Unterzeichner — ETSI EN 319 122-1 §5.3. NextPDF Pro implementiert dies gemäß ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 und RFC 5816 und ist fixture-verifiziert; es behauptet keine unabhängige ETSI EN 319 142-1-Zertifizierung, -Konformität oder -Compliance und behauptet keine rechtliche Dokumentgültigkeit.
Die Stufen B-LT und B-LTA sind Enterprise-Fähigkeiten und werden nicht von Pro erzeugt. B-LT und B-LTA fügen einen Document Security Store und Dokument-Zeitstempel für die Langzeit-Archivierungsvalidierung hinzu — ETSI EN 319 142-2 §5.5. Ein Signatur-Handler, der diese Stufen erzeugt, unterstützt DSS-Einträge und Dokument-Zeitstempel — ETSI EN 319 142-2 §6.3.3.3. Die Pro-RemoteSigningConfig kann eine Stufe oberhalb von B-T (B-LT oder B-LTA) tragen, die einen Document Security Store anfordert, doch Pro liefert diesen Erzeuger nicht aus und handelt nicht danach; eine solche Stufe ist ein vorwärts-deklarierter Wert. Der Core-Signierfluss löst den Langzeit-Erzeuger zur Laufzeit über den Core-Vertrag auf, und dieser Erzeuger wird im Paket nextpdf/enterprise ausgeliefert. In einem Pro-only-Deployment scheitert eine Anforderung von B-LT oder B-LTA fail-closed mit einer Meldung, die die fehlende Enterprise-Komponente benennt. Pro erzeugt keinen DSS, kein VRI-Dictionary, keinen Dokument-Zeitstempel und keine Archivierungsschleife und erhebt keinen Langzeitvalidierungsanspruch (LTV). Auch die Verwahrung von Schlüsseln in Hardware über PKCS#11 sowie das FIPS 140-3-Kryptorichtlinienprofil sind Enterprise-Fähigkeiten. Diese Seite dokumentiert nicht die Enterprise-Langzeitvalidierungsimplementierung; sie nennt nur die Grenze und den öffentlichen Paketnamen.
| PAdES-Stufe | Fügt hinzu | Erzeuger-Edition |
|---|---|---|
| B-B | CMS-Signatur mit signierten Attributen | Core, Pro |
| B-T | Ein unsigniertes RFC 3161-signature-time-stamp-Attribut auf dem Signaturwert | Core, Pro |
| B-LT | Document Security Store mit Validierungsmaterial | Enterprise (nextpdf/enterprise) |
| B-LTA | Dokument-Zeitstempel für Archivierungsgültigkeit | Enterprise (nextpdf/enterprise) |
Publikationsgrenze
Abschnitt betitelt „Publikationsgrenze“Diese Seite dokumentiert ausschließlich extern beobachtbares Verhalten und die unterstützte öffentliche API-Oberfläche. Interne Namespace-Pfade, Hilfsklassen, Mechanismustabellen, Runbook-Dateinamen und Ticket-Präfixe liegen außerhalb des Geltungsbereichs.
Core-Fallback
Abschnitt betitelt „Core-Fallback“Ein Deployment ohne die Pro-Berechtigung behält den Core-Signiervertrag. Code, der vom Core-Vertrag SignerInterface abhängt, signiert weiterhin mit dem Software-CMS-Signierer auf der B-B-Baseline. Die Maskierung, PII-Erkennung sowie die Remote- und Cloud-KMS-Strategien sind ohne das Pro-Paket nicht vorhanden, und ein Aufruf in diese Typen ist ein harter Abhängigkeitsfehler, kein stillschweigendes No-op.
Datenresidenz & PII-Minderungen
Abschnitt betitelt „Datenresidenz & PII-Minderungen“Die Maskierungs- und PII-Oberflächen laufen in-process. Für die Maskierung oder PII-Erkennung verlässt kein Dokumentinhalt den Host. Eine Cloud-KMS-Strategie sendet den Signierte-Attribute-Digest, nicht das Dokument, für die Signieroperation an den Anbieter. Die PII-Erkennung erfolgt mustergesteuert auf den konfigurierten Typen und entfernt die zugrunde liegenden Textobjekte für den BlackBox-Modus, wie getestet. Sie ist keine vollständige Garantie zur Entfernung personenbezogener Daten und keine Aussage zur regulatorischen Compliance.
Sichere Telemetrie & Log-Bereinigung
Abschnitt betitelt „Sichere Telemetrie & Log-Bereinigung“Die Bibliothek löst typisierte Ausnahmen mit strukturellen Meldungen aus. Sie schreibt keinen Dokumentinhalt und keine erkannten PII-Werte in Ausnahmemeldungen oder Logs. Ein Deployment, das rund um den Signierpfad protokolliert, sollte strukturelle Felder protokollieren, nicht Dokument-Bytes.
Konformität
Abschnitt betitelt „Konformität“| Anspruch | Standard | Klausel |
|---|---|---|
Die CMS-Signatur wird DER-codiert im Eintrag Contents des Signatur-Dictionarys gespeichert. | ISO 32000-2 | §12.8.1 |
| Der Prozess der Message-Digest-Berechnung; signierte Attribute tragen content-type und message-digest. | RFC 5652 | §5.4 |
| Der Prüfer darf sich nicht auf vom Aussteller berechnete Digests verlassen; er berechnet unabhängig neu und vergleicht (Signaturverifikationsprozess). | RFC 5652 | §5.6 |
| SignerInfo trägt den Digest-Algorithmus-Identifier und den Block der signierten Attribute. | RFC 5652 | §5 |
| Eine Zeitstempelanfrage gibt eine TSTInfo-Struktur zurück. | RFC 3161 | §2.4.1 |
| Eine Zeitstempel-serialNumber ist pro Token einer gegebenen TSA eindeutig. | RFC 3161 | §2.4.2 |
| Die Zeitstempel-genTime ist der UTC-Zeitpunkt, zu dem das Token erstellt wurde. | RFC 3161 | §2.4.2 |
| Ein PAdES-B-T-signature-time-stamp ist ein unsigniertes Attribut, das ein auf dem digitalen Signaturwert für einen Unterzeichner berechnetes Zeitstempel-Token trägt (Pro erzeugt B-T). | ETSI EN 319 122-1 | §5.3 |
| Der signature-time-stamp-Imprint ist der Hash des SignerInfo-Signaturfeldwerts ohne den ASN.1-Tag und die Länge. | ETSI EN 319 122-1 | §5.3 |
Das signature-time-stamp-Token nutzt die id-aa-timeStampToken-OID; sein MessageImprint ist ein Hash des SignerInfo-Signaturfeldwerts. | RFC 3161 | Appendix A |
| Auf der Prüfseite bindet NextPDF den MessageImprint eines signature-time-stamp an den SignerInfo-Signaturwert und scheitert fail-closed bei einer Abweichung, einem fehlenden/duplizierten Token oder einem SHA-1-Imprint (strikte Verifikation, keine Zertifizierung). | RFC 3161 | Appendix A |
| ESSCertIDv2 ersetzt das SHA-1-gebundene Legacy-ESSCertID; der strikte B-T-Pfad erfordert ESSCertIDv2. | RFC 5816 | §1 |
| Die Zertifizierungspfadvalidierung prüft Basic Constraints und Pfadeingaben bis zu einem Vertrauensanker. | RFC 5280 | §6.1 |
| OCSP meldet certStatus als good, revoked oder unknown. | RFC 6960 | §2.2 |
| Die OCSP-Statusaktualität ist durch thisUpdate und nextUpdate begrenzt. | RFC 6960 | §4.2 |
| B-LT und B-LTA fügen einen Document Security Store und Dokument-Zeitstempel für die Langzeitvalidierung hinzu (Enterprise-Grenze). | ETSI EN 319 142-2 | §5.5 |
| Ein Signatur-Handler, der Langzeitstufen erzeugt, unterstützt DSS-Einträge und Dokument-Zeitstempel (Enterprise-Grenze). | ETSI EN 319 142-2 | §6.3.3.3 |
Alle Klauseln sind paraphrasiert. NextPDF gibt keinen normativen Text wieder. Konsultieren Sie die veröffentlichten Standards für den verbindlichen Wortlaut. NextPDF Pro implementiert PAdES-B-T-Signierunterstützung gemäß ETSI EN 319 122-1 §5.3 (signature-time-stamp), RFC 3161, RFC 5652 und RFC 5816 und ist fixture-verifiziert. ETSI EN 319 142-1 (der Teil zu den PAdES-Baseline-Stufen) liegt außerhalb der zitierten Evidenzmenge; NextPDF Pro behauptet daher keine unabhängige ETSI EN 319 142-1-Zertifizierung, -Konformität oder -Compliance und behauptet keine rechtliche Dokumentgültigkeit. Diese Seite nennt die erzeugte Struktur, die Standards, die die B-T-Unterstützung implementiert, und die Enterprise-B-LT/B-LTA-Grenze, nicht eine zertifizierte Konformitätsstufe.
Siehe auch
Abschnitt betitelt „Siehe auch“- Core-Signierung — der CMS-Signierer, RFC 3161-Zeitstempel, RFC 5280-Pfadvalidierung, OCSP und CRL.
- PAdES-Klauselzuordnung — B-B, B-T, B-LT, B-LTA über alle Editionen.
- Sicherheit (Fähigkeitsübersicht) — die öffentliche Pro-Sicherheitsfähigkeitsseite.
- CMS · PAdES · RFC 3161 timestamp · KMS · DSS — Glossarbegriffe.