Handtekeningverificatie: cryptografische verificatie voor AdES / PAdES

In één oogopslag

NextPDF Enterprise verifieert digitale handtekeningen cryptografisch. De verificatiezijde leest Cryptographic Message Syntax (CMS) SignedData of een Request for Comments (RFC) 3161-tijdstempeltoken uit de PDF, herberekent de digests, controleert de handtekeningen, bindt elke handtekening aan het bijbehorende ondertekeningscertificaat en valideert de certificaatketen, inclusief certificaatbeleidsverwerking, tegen een door de aanroeper aangeleverde trust-anchor-store. Deze pagina beschrijft dat gedrag: wat wordt geverifieerd, wat fail-closed wordt afgewezen, welke algoritmen worden ondersteund en waar de vertrouwensgrens ligt.

Deze pagina staat los van Validatie, die alleen-lezen structurele beleidscontroles uitvoert en bewust geen cryptografie toepast. Daarnaast is ze de verificatiezijde-tegenhanger van de Handtekeningproducent, die PDF Advanced Electronic Signatures (PAdES) B-LT / B-LTA-structuren schrijft.

Installatie

composer require nextpdf/enterprise:^3

Conceptueel overzicht

Verificatie is op bewijs gebaseerd en fail-closed: een controle die niet positief kan worden vastgesteld, levert geen positief resultaat op. De volgende onderdelen worden samengevoegd tot één uitkomst die wordt gedragen door een ValidationReport.

Cryptografische verificatie van CMS / tijdstempeltoken. Een zelfstandige, strikte DER-stack met bepaalde lengte parseert de CMS SignedData en het RFC 3161-tijdstempeltoken. Een token wordt alleen geaccepteerd als het precies één SignerInfo bevat, de bijbehorende ondertekende attributen strikt kunnen worden geparset, het ondertekenaarscertificaat kan worden opgelost, het message-digest-attribuut overeenkomt met de herberekende digest, de verplichte signing-certificate-binding (ESS signing-certificate-v2) standhoudt en de SignerInfo-handtekening verifieert over de opnieuw getagde ondertekende attributen. De regel voor digest-matching volgt het verificatiemodel uit RFC 5652 §5.6 / §5.4: de ontvanger herberekent de message digest van de inhoud, en de handtekening is alleen geldig wanneer die waarde gelijk is aan het ondertekende attribuut messageDigest. Een verificateur vertrouwt nooit op een digest die door de producent is aangeleverd.

Validatie van het TSA-certificaat op genTime. De genTime van de tijdstempel is het UTC-tijdstip waarop het token is gemaakt (RFC 3161 §2.4.2). Het TSA-ondertekeningscertificaat wordt op dat tijdstip gevalideerd, niet op “nu”: het extended key usage moet een enkele, kritieke id-kp-timeStamping zijn (RFC 3161 §2.3), en het geldigheidsvenster, de keten, de trust-anchor-herkomst en de intrekkingsstatus worden allemaal tegen genTime geëvalueerd. Een structureel correct opgebouwde keten die geen geconfigureerd trust anchor bereikt, kan nooit een positieve uitkomst ondersteunen.

Losgekoppelde basis-PAdES-documenthandtekeningen. Een concrete extractor voert daadwerkelijke basisverificatie van Advanced Electronic Signatures (AdES) / PAdES uit voor een losgekoppelde documenthandtekening: de message digest wordt over de ondertekende byte range herberekend en vergeleken, de handtekening wordt geverifieerd en de signing-certificate-binding is verplicht. Dit vervangt de eerdere, uitsluitend structurele terugval. De tijdstempelverificateur en de documenthandtekening-extractor delen één ESS issuer-and-serial-validator, zodat het parseren van de certificaatbinding niet uiteenloopt.

DocTimeStamp-dekkingsketen voor archivering. validateArchivalTimestampChain() valideert een keten van vertrouwde DocTimeStamp-tokens over de PDF-byte ranges als B-LTA-archiefbewijs. De imprint van elk token is gebonden aan de feitelijke ByteRange-bytes die het dekt, de keten volgt strikte ETSI-ordening, de TSA-keten van elk token is trust-anchored en de keten moet het bestand tot aan de end-of-file-markering dekken. Een volledig geslaagde uitkomst wordt alleen bereikt voor een complete, trust-anchored keten die tot aan EOF dekt.

Certificaatbeleidsverwerking (RFC 5280 §6.1.4). Padvalidatie past volledige certificaatbeleidsverwerking toe: een uit nodes opgebouwde beleidsboom, policy mapping met de anyPolicy-fallback en het samenvouwen van policyConstraints / inhibitAnyPolicy, ondersteund door een fail-closed DER-lezer voor de beleidsextensie. De toestandsvariabelen voor padverwerking explicit_policy en inhibit_anyPolicy (RFC 5280 §6.1.2) bepalen of een niet-lege valid-policy-boom vereist is; de afrondingsstap snijdt de valid-policy-boom met de user-initial-policy-set (RFC 5280 §6.1.4). Zonder vereiste beleidsregels, en als anyPolicy wordt geaccepteerd, is de verwerking onbeperkt; dat is de standaard en blijft ongewijzigd ten opzichte van eerder gedrag.

Ondersteunde algoritmen

De verificatiezijde accepteert de onderstaande set algoritmen en faalt gesloten voor alles daarbuiten: een niet-ondersteund algoritme is een afgewezen verificatie, nooit een stilzwijgende goedkeuring.

Familie	Ondersteund	Opmerkingen
RSA (PKCS#1 v1.5)	rsaEncryption met SHA-2, en de sha*WithRSAEncryption-OID’s	Geaccepteerd
ECDSA	curves P-256, P-384, P-521	Geaccepteerd
RSASSA-PSS	—	Niet ondersteund → fail-closed
EdDSA	—	Niet ondersteund → fail-closed
SHA-3-digests	—	Niet ondersteund → fail-closed
SHA-1	—	Zwak: een basishandtekening die onder SHA-1 verifieert, wordt gedegradeerd tot een crypto-constraints-fout, niet tot een goedkeuring

API-oppervlak

Je gebruikt de verificatiezijde via de openbare engine en de Core / Pki-contracten. Concrete strategieklassen zijn intern.

Type	Soort	Rol
AdESValidationEngine	class	Het toegangspunt van de verificatiezijde: validatie van handtekening en archiefketen.
AdESValidationEngine::validateArchivalTimestampChain()	method	Valideert een vertrouwde DocTimeStamp-dekkingsketen over de PDF-byte ranges.
ValidationReport	resultaat	De gestructureerde uitkomst: de algehele status plus bevindingen per controle.
PathValidatorInterface	interface (NextPDF\…\Pki)	De certification-path-validation-SPI waarop de engine vertrouwt.
PathValidationOptions	value object	Sturingsopties voor beleidsverwerking: requireExplicitPolicy, inhibitAnyPolicy, inhibitPolicyMapping, maxPolicyFanout.
TrustAnchorStoreInterface	interface	De door de aanroeper aangeleverde set vertrouwde anchors waartegen de keten wordt geëvalueerd.

De archiefketenmethode heeft deze signatuur:

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

Een volledig geslaagde uitkomst wordt alleen bereikt als de DocTimeStamp-keten volledig is geverifieerd, trust-anchored is en het bestand tot aan de EOF-markering dekt.

CertificateChainValidator::validate() neemt een initiële beleidsset (de RFC 5280-user-initial-policy-set). De standaard is anyPolicy; die is onbeperkt, zodat het gedrag voor een gewone keten ongewijzigd blijft. Geef een expliciete set door, of stel requireExplicitPolicy in om een niet-lege valid-policy-boom te vereisen.

Codevoorbeeld — Snelstart

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;

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

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

Codevoorbeeld — Productie

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

Gedragswijzigingen en upgrade-aandachtspunten

De verificatiezijde is overgegaan van structurele / temporele acceptatie naar volledige cryptografische verificatie. Als je op het oudere, soepelere gedrag vertrouwt, neem deze wijzigingen dan door.

• Fail-closed bij een herkenbare maar niet-verifieerbare tijdstempel. Een DocTimeStamp of archieftoken dat voorheen op structurele en temporele gronden slaagde, vereist nu volledige cryptografische verificatie: handtekening, message-digest en de signing-certificate-binding. Een token dat niet verifieert, levert niet langer positief bewijs van bestaan op; het leidt tot een onbepaalde of mislukte uitkomst.
• SHA-1-basishandtekeningen worden gedegradeerd, niet goedgekeurd. Een basisdocumenthandtekening die verifieert maar SHA-1 gebruikt, wordt gerapporteerd als een crypto-constraints-fout in plaats van een volledige goedkeuring.
• Certificaatbeleidsverwerking volgens RFC 5280 §6.1.4 wordt afgedwongen. Een keten waarvan explicit_policy nul bereikt met een lege valid-policy-boom faalt nu, ook wanneer keteninterne policyConstraints requireExplicitPolicy dit veroorzaakt. Standaard onbeperkte ketens (geen vereiste beleidsregels, anyPolicy geaccepteerd) blijven ongewijzigd.
• Wijziging van de constructorsignatuur (BC-break). AdESValidationEngine::__construct() typeert de parameter $chainValidator nu als de Pki\PathValidatorInterface-SPI, met als lazy standaardwaarde Pki\CertificateChainValidator::withDefaults(). Dit was voorheen de concrete Ltv\CertificateChainValidator. Een aanroeper die de concrete LTV-validator injecteerde, moet in plaats daarvan de Pki-SPI-implementatie injecteren. De Pki-validator omhult dezelfde structurele padengine en voegt name constraints en beleidsverwerking toe; voor conforme standaardinvoer heeft ze geen effect.

Randgevallen en valkuilen

• Niet-ondersteund algoritme ≠ onbeslist. RSASSA-PSS, EdDSA en SHA-3 worden fail-closed afgewezen, niet uitgesteld. Als je ondertekenaars deze gebruiken, geeft deze verificatiezijde geen positief resultaat terug.
• Vertrouwen is anchor-relatief. Verificatie is altijd relatief ten opzichte van de trust-anchor-store die u aanlevert. Een lege of onjuiste anchorset levert een niet-vertrouwde uitkomst op, ongeacht de cryptografische juistheid.
• genTime, niet nu. Het TSA-certificaat wordt beoordeeld op de genTime van het token. Een TSA-certificaat dat sindsdien is verlopen, kan nog steeds een token ondersteunen dat is gemaakt toen het geldig was; een certificaat dat op genTime nog niet geldig was, kan dat niet.
• EOF-dekking. De archiefketen moet het document tot aan de EOF-markering dekken. Een tijdstempel die alleen een prefix van het bestand dekt, vestigt geen dekking van het volledige document.
• Niet-bewezen-ingetrokken is niet Good. Een Valid-oordeel vereist een sluitende niet-ingetrokken-status. Als zowel OCSP als CRL Unknown of Unavailable teruggeven, komt zelfs een cryptografisch correcte, keten-geldige, trust-anchored handtekening uit op Indeterminate. Lever ingesloten OCSP/CRL-Good-materiaal voor het ondertekenaarscertificaat mee om Valid te bereiken.

Prestaties

Verificatie wordt in-process uitgevoerd over de aangeleverde PDF-bytes en het ingesloten validatiemateriaal; de kosten schalen met de ketenlengte en het aantal tijdstempels. Verificatie maakt geen netwerk-round-trips. Intrekkings- en vertrouwensmateriaal komt uit wat de aanroeper aanlevert of wat in het document is ingesloten. Verificatie is deterministisch: dezelfde invoer en dezelfde trust anchors leveren hetzelfde rapport op.

Beveiligingsnotities

• Fail-closed is de standaard. Elke acceptatiestap weigert materiaal dat ze niet positief kan verifiëren. Dit voorkomt dat een document geldigheid claimt die de engine nooit heeft vastgesteld.
• Append-after-timestamp wordt verijdeld door EOF-dekking. Omdat de imprint van elke archieftijdstempel is gebonden aan de feitelijke ByteRange-bytes en de keten EOF moet bereiken, wordt inhoud die na een tijdstempel is toegevoegd er niet door gedekt en krijgt die inhoud niet de bewijskracht ervan.
• Behandel invoer als vijandig. PDF-bytes, ingesloten CMS en tijdstempeltokens uit niet-vertrouwde bronnen worden geparseerd door een strikte DER-lezer met bepaalde lengte die misvormde coderingen of coderingen met onbepaalde lengte afwijst.

Dataresidentie en PII-mitigaties

Verificatie is in-process en lokaal, zonder netwerk-I/O. Certificaten en handtekeningen bevatten de identiteit van het subject; pas je eigen bewaar- en minimalisatiebeleid toe op rapporten en eventueel geëxtraheerde certificaatgegevens.

Veilige telemetrie en logopschoning

Bevindingen bevatten controle-ID’s en statussen. Sommige diagnostische gegevens kunnen subject-namen of serienummers van certificaten weergeven; schoon die velden op of redigeer ze voordat je logs doorstuurt naar gedeelde sinks.

Scope-grenzen

Vermeld deze grenzen in gebruikersgerichte uitvoer, zodat een positief resultaat niet wordt overschat.

• validateArchivalTimestampChain() bewijst byte-range-dekking, niet xref-bereikbaarheid. Ze stelt vast dat een vertrouwde tijdstempelketen de byte ranges van het document cryptografisch dekt tot EOF. Ze voert geen xref-niveau- of startxref-object-bereikbaarheidsanalyse uit; dat valt opzettelijk buiten de scope. De EOF-dekkingsregel verijdelt samen met trust anchoring append-after-timestamp-aanvallen; hij is geen objectgraafanalyse.
• Opzettelijk buiten de scope. Evidence Records (RFC 4998 / RFC 6283); verificatie van RSASSA-PSS-, EdDSA- of SHA-3-tijdstempeltokens; integratie van trusted-list (TSL) en gekwalificeerde TSA; en online ophalen van TSA-intrekkingen worden door deze verificatiezijde niet geleverd. Intrekking wordt geëvalueerd op basis van materiaal dat al voor de verificateur beschikbaar is.

Conformiteit

Gedrag	Referentie	Status
Handtekeningwaarde / tijdstempeltoken DER-gecodeerd opgeslagen in /Contents	ISO 32000-2 §12.8.1	Geparseerd en geverifieerd
Document timestamp dictionary	ISO 32000-2 §12.8.5	Gelezen voor de archiefketen
De ontvanger herberekent de digest van de inhoud; deze moet gelijk zijn aan het messageDigest-attribuut	RFC 5652 §5.6 / §5.4	Afgedwongen
Het TSA-certificaat draagt een enkele kritieke id-kp-timeStamping-EKU	RFC 3161 §2.3	Gecontroleerd op genTime
genTime is het UTC-tijdstip van aanmaak	RFC 3161 §2.4.2	Gebruikt als het validatietijdstip
Toestandsvariabelen voor beleidsverwerking (explicit_policy, inhibit_anyPolicy)	RFC 5280 §6.1.2	Verwerkt
De afrondingsstap snijdt de valid-policy-boom met de user-initial-policy-set	RFC 5280 §6.1.4	Afgedwongen
DSS-entries en document time-stamps voor langdurige handtekeningen	ETSI EN 319 142-2 §5.5	Gevalideerd als archiefbewijs

Alle clausules zijn geparafraseerd. NextPDF geeft geen normatieve tekst weer; raadpleeg de gepubliceerde normen voor de gezaghebbende formulering. NextPDF doet geen AdES- / PAdES-certificeringsclaim. De verificatiezijde implementeert de cryptografische controles die in de geciteerde specificaties zijn beschreven; het is geen gecertificeerde validatiedienst en levert geen attestatie door derden.

Gedrag in FIPS-modus

Wanneer het Enterprise FIPS-profiel actief is, geldt de beperking voor de digest- en handtekeningalgoritmen die de verificateur accepteert. De verificatielogica, inclusief het herberekenen van de digest, handtekeningcontroles, certificaatbinding en padvalidatie, blijft ongewijzigd.

Dreigingsmodel

Asset	Tegenstander	Risico	Mitigatie
Tijdstempeltoken	Vervalst of gewijzigd token	Een vals bewijs van bestaan	Volledige cryptografische verificatie; fail-closed bij alles wat niet verifieerbaar is
TSA-certificaat	Niet-vertrouwde uitgever	Schijnvertrouwen dat de verificateur niet zou mogen bevestigen	Keten wordt gevalideerd tot een door de aanroeper aangeleverd anchor op genTime; een niet-vertrouwde keten slaagt nooit
Documentbytes	Append-after-timestamp	Inhoud krijgt het gewicht van een tijdstempel zonder dekking	Imprint gebonden aan feitelijke ByteRange-bytes + EOF-dekkingsregel
Zwak algoritme	Downgrade naar SHA-1 / niet-ondersteund schema	Een zwakke handtekening die als geldig wordt geaccepteerd	SHA-1 gedegradeerd; RSASSA-PSS / EdDSA / SHA-3 fail-closed

Editie-poort

Deze verificatiezijde is een Enterprise-functie en wordt geleverd in het nextpdf/enterprise-pakket. NextPDF Core detecteert de aanwezigheid van een handtekening en produceert B-B / B-T-handtekeningen, maar levert deze cryptografische verificatiezijde niet. Licentie verkrijgen.

Licentie-feature-flag

De verificatiezijde is afgeschermd achter de Enterprise-editie (license_feature_flag: enterprise). Ze loopt via de Core- en Pki-contracten; de openbare application programming interface (API) verandert niet bij een editie-upgrade.

Gedragscontract

• Een CMS- of tijdstempeltoken wordt alleen geaccepteerd met precies één SignerInfo, strikt geparseerde ondertekende attributen, een opgelost ondertekenaarscertificaat, een overeenkomende message-digest, de verplichte signing-certificate-binding en een verifiërende SignerInfo-handtekening.
• Het TSA-certificaat wordt gevalideerd op de genTime van het token: een enkele kritieke id-kp-timeStamping-EKU, geldigheidsvenster, trust-anchored keten en intrekking.
• Een Valid-oordeel vereist bovendien een sluitende niet-ingetrokken-status: minstens één gezaghebbende Good (een verified-good OCSP-respons, of een verse CRL die het serienummer buiten een niet-verlopen lijst plaatst). Een status die slechts niet-bewezen-ingetrokken is, waarbij OCSP en CRL beide Unknown of Unavailable zijn, komt uit op Indeterminate, nooit Valid (ETSI EN 319 102-1: revocation status-unavailable → INDETERMINATE). Omdat het CRL-fallback-pad alleen de versheid van de lijst aantoont en niet de intrekking per serienummer, is een keten met alleen CRL en zonder een Good OCSP doorgaans Indeterminate.
• validateArchivalTimestampChain() bereikt alleen een volledig geslaagde uitkomst voor een complete, trust-anchored DocTimeStamp-keten die tot EOF dekt; ze bewijst byte-range-dekking, niet xref-bereikbaarheid.
• Certificaatbeleidsverwerking volgt RFC 5280 §6.1.4; standaard onbeperkte ketens blijven ongewijzigd.
• Ondersteunde algoritmen zijn RSA (PKCS#1 v1.5 met SHA-2) en ECDSA (P-256/384/521); RSASSA-PSS, EdDSA en SHA-3 falen gesloten; SHA-1 wordt gedegradeerd.

NDA-scanstatus

Deze openbare pagina beschrijft uitsluitend extern waarneembaar gedrag van de verificatiezijde. Ze noemt de openbare engine, de Pki- / trust-anchor-contracten en de methode validateArchivalTimestampChain() via het ondersteunde API-oppervlak. De concrete interne werking van de DER, CMS, policy-processor en path-validator bevindt zich in de afgeschermde diepe referentie onder de geheimhoudingsovereenkomst (NDA).

Core-terugval

NextPDF Core detecteert de aanwezigheid van een handtekening en produceert B-B / B-T-handtekeningen, maar verifieert CMS- of tijdstempeltokens niet cryptografisch, valideert geen archiefketen en voert geen RFC 5280 §6.1.4-beleidsverwerking uit. Een implementatie met alleen Core heeft geen equivalente verificatiezijde; zie Beveiliging / Ondertekening (Core).

Pro-terugval

NextPDF Pro voegt ondertekeningsstrategieën en e-invoice-verwerking toe, maar levert deze cryptografische verificatiezijde niet; validatie van de archiefketen en certificaatbeleidsverwerking worden uitsluitend in nextpdf/enterprise geleverd.

Enterprise-grensnotitie

De verificatiezijde wordt op gedragsniveau beschreven. De strikte DER-stack, de CMS-parser, de policy-processor en de interne werking van de path-validator vallen buiten de scope van het openbare API-oppervlak en worden hier niet weergegeven.

Implementatiegrens

Verificatie is afhankelijk van de trust-anchor-store en eventueel intrekkingsmateriaal dat de aanroeper aanlevert of dat in het document is ingesloten. NextPDF Enterprise evalueert dat materiaal; het beheert geen trust list, geen TSA en geen intrekkingsdienst. De operator is verantwoordelijk voor de anchorselectie en de versheid van het ingesloten intrekkingsmateriaal.

Grens voor juridische naleving

Deze pagina is gemarkeerd als export_control_class: legal-review-required; ze betreft cryptografische verificatie. Juridische goedkeuring is vereist voordat de publish-flag wordt ingesteld. Een positief verificatieresultaat is een cryptografische uitspraak over de handtekeningen en tijdstempels van het document. Het is geen juridisch advies, geen eIDAS-kwalificatiebepaling en geen certificering. NextPDF doet geen AdES- / PAdES-certificeringsclaim. Raadpleeg je eigen compliance- en juridische adviseurs voor je wettelijke verplichtingen.

Zie ook

• Handtekening: PAdES B-LT / B-LTA-producent — de producentzijde.
• Validatie — in-process structurele beleidscontroles (geen cryptografie).
• Archief: DSS, VRI, LTV-gezondheid — langdurige archivering en LTV-gezondheid.
• Beveiliging / Ondertekening (Core) — CMS, RFC 3161, RFC 5280-padvalidatie, OCSP/CRL.
• PAdES-baselinemapping — B-B, B-T, B-LT, B-LTA over alle edities.
• PAdES · DSS · LTV — woordenlijsttermen.