Enterprise édition

Validation de signatures par lots

En bref

NextPDF Enterprise valide les signatures numériques de nombreux documents PDF en un seul appel. NextPDF\Enterprise\Signature\BatchSignatureValidator::validate() prend une liste de documents et renvoie un BatchValidationReport. Chaque signature passe par le même pipeline fail-closed : authentification cryptographique CMS sur la plage d’octets signée, validation de la chaîne de certificats ancrée à la confiance et vérification de révocation OCSP/CRL. Le rapport porte le détail par document et par signature — CertChainStatus, RevocationStatus, TimestampStatus — afin que l’outillage de conformité puisse re-dériver chaque verdict à partir des preuves enregistrées.

Le modèle de verdict est délibérément strict. Une signature est Valid uniquement lorsque toutes les preuves sont affirmativement établies. Une preuve de révocation manquante produit Indeterminate, jamais Valid. Cette page couvre l’orchestrateur de lots et ses types de résultat. Le côté vérification AdES mono-document est documenté dans Vérification de signature. L’intégration de matériel de validation à long terme est documentée dans Archive.

Disponibilité et licence

Cette capacité est livrée dans NextPDF Enterprise (nextpdf/enterprise) et s’active avec une enveloppe de licence de niveau Enterprise. Un déploiement dépourvu de ce droit ne charge pas les classes de la capacité. Comparer les éditions et obtenir une licence.

Installation

composer require nextpdf/enterprise

Le métapaquet nextpdf/premium résout également le paquet Enterprise. L’activation utilise ton enveloppe de licence Enterprise ; voir Licence et activation. Les types de lot s’autochargent sous NextPDF\Enterprise\Signature. Aucune extension PHP au-delà de la base du moteur n’est requise.

Vue d’ensemble conceptuelle

Un seul appel à validate() traite une liste de valeurs DocumentSignatureInput. Chaque entrée porte un identifiant de document, les octets bruts du PDF et des ancres de confiance optionnelles encodées en PEM. Le validateur extrait les dictionnaires de signature de chaque document et exécute trois étapes par signature.

Étape 1 — authentification cryptographique. Le blob CMS/PKCS#7 détaché issu de /Contents est vérifié sur les octets que couvre /ByteRange. Le vérificateur recalcule lui-même le condensé du contenu et le compare à l’attribut signé messageDigest. Il ne fait jamais confiance à un condensé fourni par le producteur (RFC 5652 §5.6). La valeur de signature doit se vérifier, et le certificat de signature doit être lié au CMS. Un /Contents ou /ByteRange absent ou malformé, un CMS non analysable, une divergence de condensé ou un contrôle de signature échoué échouent tous de manière fermée. Une signature qui se vérifie sous SHA-1 est traitée comme faible et n’est jamais une réussite complète.

Étape 2 — validation de chaîne et ancrage de confiance. La chaîne du signataire récupérée depuis le CMS est validée en tant que chemin de certification prospectif. Les trustedCerts que tu fournis sont l’entrée d’ancre de confiance, au sens de la RFC 5280 §6.1.1 : le terminus de la chaîne doit correspondre à une ancre fournie par empreinte DER SHA-256. Une chaîne structurellement cohérente dont le terminus n’est pas une ancre configurée n’est jamais rapportée comme approuvée. Sans ancres utilisables, seul le verdict structurel est rapporté, et CertChainStatus::$trusted reste false.

Étape 3 — révocation. La révocation s’exécute sur la chaîne récupérée après l’authentification, à l’image du modèle ETSI EN 319 102-1 où la vérification de révocation suit une validation de chemin réussie (clause 5.2.6.2). OCSP est primaire : seule une réponse cryptographiquement vérifiée compte, en tant que Good ou Revoked. Le chemin CRL est le repli et atteste la fraîcheur de la liste. Lorsqu’aucun des deux clients n’est configuré, le statut est unavailable.

Le verdict par signature est un SignatureValidationStatus. La taxonomie reflète le modèle de statut ETSI EN 319 102-1 (TOTAL-PASSED / TOTAL-FAILED / INDETERMINATE) à la granularité par signature :

Preuve	Verdict
Certificat confirmé révoqué	`Invalid` (décisif, quels que soient les autres contrôles)
Échec de l’authentification CMS, aucun matériel de signataire récupéré	`Error`
Échec de l’authentification CMS, matériel de signataire présent	`Invalid`
Authentifié, mais la chaîne ne se valide pas	`Invalid` (ou `Error` sans chaîne)
Authentifié et chaîne valide, mais aucune ancre de confiance confirmée	`Indeterminate`
Authentifié, chaîne valide, approuvé, mais aucune non-révocation concluante	`Indeterminate`
Tout ce qui précède affirmativement établi	`Valid`

La règle de non-révocation concluante. « Non prouvé révoqué » n’est pas la même chose que « prouvé non révoqué ». Un verdict Valid requiert au moins un résultat de révocation Good. Une réponse OCSP vérifiée-bonne est la forme concluante : elle atteste le statut propre du certificat du signataire. Une CRL fraîche, cryptographiquement acceptée, satisfait elle aussi cette barrière dans cette implémentation, mais uniquement en tant qu’attestation de fraîcheur et d’intégrité — le chemin n’analyse pas les entrées par numéro de série, il ne fournit donc aucune garantie de révocation par numéro de série et jamais de verdict revoked positif. Configure OCSP partout où la détection positive de révocation importe : un déploiement CRL uniquement ne fera pas apparaître un certificat révoqué comme Invalid. Lorsque les résultats OCSP et CRL sont tous deux Unknown ou Unavailable, le statut de révocation est indéterminé, et le verdict est Indeterminate. Cela suit ETSI EN 319 102-1 : une information de statut de révocation indisponible aboutit à INDETERMINATE, jamais à une réussite (clause 5.1.3, TRY_LATER). Il s’agit d’un durcissement de comportement en 3.1.0 avec un impact sur la compatibilité ascendante : les versions antérieures pouvaient rapporter Valid sans preuve de révocation concluante. Les déploiements qui ne configurent aucun client OCSP ou CRL voient désormais couramment Indeterminate là où ils voyaient auparavant Valid.

Deux limites encadrent honnêtement cette capacité. Premièrement, le validateur de lots n’évalue pas les jetons d’horodatage intégrés : TimestampStatus dans les résultats de lot est toujours l’état absent. L’évaluation d’horodatage RFC 3161 relève du côté vérification mono-document ; voir Vérification de signature. Deuxièmement, cette page concerne une validation en lecture seule. L’intégration de matériel DSS/VRI pour la validité à long terme relève de la capacité Archive.

Pourquoi ça fonctionne ainsi

La décision porteuse est un producteur de verdict fail-closed. Valid n’est forgé qu’à partir de preuves affirmatives sur les trois axes : authentification cryptographique, chaîne ancrée à la confiance et non-révocation concluante. Tout élément non établi se dégrade en Indeterminate plutôt que de retomber sur une réussite par défaut, ce qui correspond à la posture EN 319 102-1 face à un matériel de révocation manquant. Le débit par lots ne rachète jamais la rigueur : la couche de lot est une orchestration au-dessus du même vérificateur CMS audité que celui utilisé pour un document unique, si bien qu’une exécution de 1,000 documents applique une cryptographie identique. Le rapport sépare également la preuve du verdict — CertChainStatus et RevocationStatus enregistrent les entrées sur lesquelles repose chaque verdict, afin qu’un auditeur puisse le re-dériver ultérieurement.

Contexte de conception : Signer à grande échelle, sans compromis.

Surface d’API

Tous les symboles ci-dessous font partie de l’API publique de nextpdf/enterprise 3.1.0.

`BatchSignatureValidator`

final class BatchSignatureValidator
{
    public function __construct(
        ?SignatureExtractor $extractor = null,
        ?CertificateChainValidator $chainValidator = null,
        private readonly ?OcspClient $ocspClient = null,
        private readonly ?CrlFetcher $crlFetcher = null,
        ?CmsSignatureDataExtractor $cmsExtractor = null,
        private readonly ClockInterface $clock = new SystemClock(),
    )

    public function validate(array $inputs): BatchValidationReport
}

Lève ou échoue avec : validate() lève \InvalidArgumentException si la liste d’entrée est vide, et \OverflowException lorsque le lot dépasse 1,000 documents. Un document qui n’est pas un PDF analysable ne lève pas d’exception ; il devient un résultat Error par document. Le $clock est un Psr\Clock\ClockInterface PSR-20 utilisé pour la décision de fraîcheur CRL, de sorte que les verdicts sont déterministes sous une horloge de test figée.

`DocumentSignatureInput`

final readonly class DocumentSignatureInput
{
    public string $documentId;

    public function __construct(
        string $documentId,
        public string $pdfData,
        public array $trustedCerts = [],
    )
}

Lève ou échoue avec : \InvalidArgumentException si $documentId est une chaîne vide. $trustedCerts est une liste de certificats d’ancre de confiance encodés en PEM.

`BatchValidationReport`

final readonly class BatchValidationReport
{
    public function __construct(
        public array $documents,
        public int $totalDocuments,
        public int $totalSignatures,
        public int $totalValid,
        public int $totalInvalid,
        public float $durationMs,
    )

    public function allValid(): bool

    public function hasDocumentsWithoutSignatures(): bool

    public function toJson(?CertPiiGuard $piiGuard = null): string
}

Lève ou échoue avec : toJson() lève \JsonException si l’encodage échoue. allValid() vaut true uniquement lorsqu’il y a des signatures et qu’aucune n’est non valide. Par défaut, toJson() applique un NextPDF\Enterprise\Signature\Eidas\CertPiiGuard respectueux de la vie privée par défaut, qui masque le nom du signataire, l’émetteur racine, le nom de la TSA et les diagnostics de problème de chaîne ; voir Niveaux de garantie eIDAS pour l’API du garde.

`DocumentValidationResult` et `DocumentValidationStatus`

final readonly class DocumentValidationResult
{
    public function __construct(
        public string $documentId,
        public DocumentValidationStatus $status,
        public array $signatures,
        public int $validCount,
        public int $invalidCount,
    )

    public function hasSignatures(): bool

    public function totalSignatures(): int
}

enum DocumentValidationStatus: string
{
    case AllValid = 'all_valid';
    case SomeInvalid = 'some_invalid';
    case AllInvalid = 'all_invalid';
    case NoSignatures = 'no_signatures';
    case Error = 'error';
}

Lève ou échoue avec : rien. Objet valeur immuable et énumération adossée à une valeur.

`SignatureValidationResult` et `SignatureValidationStatus`

final readonly class SignatureValidationResult
{
    public function __construct(
        public SignatureValidationStatus $status,
        public CertChainStatus $certChain,
        public TimestampStatus $timestamp,
        public RevocationStatus $revocation,
        public string $signer,
        public string $level = '',
        public string $subFilter = '',
        public string $reason = '',
    )

    public function isValid(): bool
}

enum SignatureValidationStatus: string
{
    case Valid = 'valid';
    case Invalid = 'invalid';
    case Indeterminate = 'indeterminate';
    case Error = 'error';
}

Lève ou échoue avec : rien. $signer est le sujet du certificat vérifié par le CMS lorsque l’authentification a réussi, sinon la chaîne vide. $level est une étiquette dérivée du SubFilter (par exemple B-B pour ETSI.CAdES.detached), et non une détermination de conformité AdES.

`CertChainStatus`

final readonly class CertChainStatus
{
    public function __construct(
        public bool $valid,
        public bool $trusted,
        public int $chainLength,
        public string $rootIssuer,
        public array $issues = [],
    )

    public function hasIssues(): bool
}

Lève ou échoue avec : rien. $trusted n’est défini que sur une correspondance confirmée d’appartenance à une ancre de confiance, jamais du fait qu’une liste d’ancres soit non vide.

`RevocationStatus` et `RevocationCheckResult`

final readonly class RevocationStatus
{
    public function __construct(
        public RevocationCheckResult $ocspStatus,
        public RevocationCheckResult $crlStatus,
        public bool $isRevoked,
        public ?DateTimeImmutable $revocationDate = null,
    )

    public static function unavailable(): self

    public function hasConclusiveGood(): bool
}

enum RevocationCheckResult: string
{
    case Good = 'good';
    case Revoked = 'revoked';
    case Unknown = 'unknown';
    case Unavailable = 'unavailable';
}

Lève ou échoue avec : rien pour les membres présentés. La classe expose également des fabriques statiques vérifiées par les preuves (good(), revoked(), fromResults()), qui lèvent \InvalidArgumentException lorsque le statut revendiqué contredit la preuve OCSP/CRL — un résultat révoqué ne peut jamais être forgé comme non révoqué, ni l’inverse. hasConclusiveGood() vaut true uniquement pour un statut non révoqué où au moins un contrôle est Good.

`TimestampStatus`

final readonly class TimestampStatus
{
    public function __construct(
        public bool $present,
        public bool $valid,
        public ?DateTimeImmutable $timestampTime = null,
        public string $tsaName = '',
        public array $issues = [],
    )

    public static function absent(): self
}

Lève ou échoue avec : rien. Dans les résultats de lot, c’est toujours l’état absent() ; voir Cas limites et pièges.

Exemple de code — Démarrage rapide

Valide un document et lis le rapport. Cet exemple utilise un PDF non signé, de sorte que la sortie est déterministe.

<?php

declare(strict_types=1);

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

use NextPDF\Enterprise\Signature\BatchSignatureValidator;
use NextPDF\Enterprise\Signature\DocumentSignatureInput;

// A minimal, unsigned PDF: the validator reports it as no_signatures.
$unsigned = "%PDF-1.7\n1 0 obj\n<< /Type /Catalog >>\nendobj\ntrailer\n<< /Root 1 0 R >>\n%%EOF\n";

$validator = new BatchSignatureValidator();

try {
    $report = $validator->validate([
        new DocumentSignatureInput(documentId: 'doc-001', pdfData: $unsigned),
    ]);
} catch (\InvalidArgumentException $e) {
    // Empty input list, or an empty documentId.
    echo 'Rejected: ' . $e->getMessage() . "\n";
    exit(1);
}

echo 'Documents: ' . $report->totalDocuments . "\n";
echo 'Signatures: ' . $report->totalSignatures . "\n";

foreach ($report->documents as $doc) {
    echo $doc->documentId . ': ' . $doc->status->value . "\n";
}

echo 'All valid: ' . ($report->allValid() ? 'yes' : 'no') . "\n";
echo 'Unsigned documents: ' . ($report->hasDocumentsWithoutSignatures() ? 'yes' : 'no') . "\n";

Sortie attendue :

Documents: 1
Signatures: 0
doc-001: no_signatures
All valid: no
Unsigned documents: yes

Remarque que allValid() rapporte no ici : il requiert au moins une signature et aucun résultat non valide, de sorte qu’un ensemble de signatures vide ne passe jamais silencieusement.

Exemple de code — Production

Valide un répertoire de contrats signés avec des clients de révocation, des ancres de confiance, un découpage en lots et un rapport JSON protégeant les données personnelles.

<?php

declare(strict_types=1);

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

use NextPDF\Enterprise\Security\Ltv\CrlFetcher;
use NextPDF\Enterprise\Security\Ltv\OcspClient;
use NextPDF\Enterprise\Security\Ltv\OcspResponseCache;
use NextPDF\Enterprise\Signature\BatchSignatureValidator;
use NextPDF\Enterprise\Signature\DocumentSignatureInput;
use NextPDF\Enterprise\Signature\SignatureValidationStatus;

// Any PSR-18 client works; Guzzle shown here.
$httpClient = new \GuzzleHttp\Client(['timeout' => 10]);

// Revocation clients make a conclusive non-revoked (Good) result reachable.
// Without them, every verdict tops out at Indeterminate. The response cache
// lets repeat signers across the batch resolve without extra network calls.
$validator = new BatchSignatureValidator(
    ocspClient: new OcspClient($httpClient, cache: new OcspResponseCache()),
    crlFetcher: new CrlFetcher($httpClient),
);

// Trust anchors are an input: the chain terminus must match one of these.
$anchors = [(string) file_get_contents('/etc/nextpdf/trust/enterprise-root.pem')];

$inputs = [];
foreach (glob('/var/contracts/signed/*.pdf') ?: [] as $path) {
    $inputs[] = new DocumentSignatureInput(
        documentId: basename($path),
        pdfData: (string) file_get_contents($path),
        trustedCerts: $anchors,
    );
}

$exit = 0;

// One call is capped at 1,000 documents; chunk larger runs.
foreach (array_chunk($inputs, 1000) as $batch) {
    try {
        $report = $validator->validate($batch);
        // Signer PII is redacted by default in the serialized report.
        file_put_contents('/var/log/nextpdf/batch-report.jsonl', $report->toJson() . PHP_EOL, FILE_APPEND); // one JSON document per line
    } catch (\InvalidArgumentException | \OverflowException $e) {
        fwrite(STDERR, 'Batch rejected: ' . $e->getMessage() . "\n");
        exit(2);
    } catch (\JsonException $e) {
        fwrite(STDERR, 'Report encoding failed: ' . $e->getMessage() . "\n");
        exit(3);
    }

    foreach ($report->documents as $doc) {
        foreach ($doc->signatures as $sig) {
            if ($sig->status !== SignatureValidationStatus::Valid) {
                $exit = 1;
                fwrite(STDERR, sprintf(
                    "%s: %s (chain trusted: %s, revoked: %s)\n",
                    $doc->documentId,
                    $sig->status->value,
                    $sig->certChain->trusted ? 'yes' : 'no',
                    $sig->revocation->isRevoked ? 'yes' : 'no',
                ));
            }
        }
    }
}

exit($exit);

Sortie attendue (stderr, pour un document dont la preuve de révocation était indisponible ; les autres lignes varient selon tes entrées) :

contract-0042.pdf: indeterminate (chain trusted: yes, revoked: no)

Le rapport JSON sérialise les champs d’identité du signataire via le CertPiiGuard par défaut, de sorte qu’une entrée par signature ressemble à ceci (extrait, à titre indicatif) :

{
    "status": "indeterminate",
    "signer": "[REDACTED]",
    "level": "B-B",
    "subFilter": "ETSI.CAdES.detached"
}

Cas limites et pièges

Une liste d’entrée vide lève \InvalidArgumentException ; plus de 1,000 documents en un seul appel lève \OverflowException. Découpe les exécutions plus grandes, comme dans l’exemple de production.
Mise à niveau depuis des versions antérieures : sans client OCSP ni CRL configuré, la révocation est unavailable, de sorte qu’aucune signature ne peut atteindre Valid. Les versions antérieures rapportaient Valid ici ; la 3.1.0 rapporte Indeterminate (voir Vue d’ensemble conceptuelle).
Les compteurs au niveau du document sont stricts : seul Valid incrémente validCount. Invalid, Indeterminate et Error incrémentent tous invalidCount. Un document dont l’unique signature est Indeterminate rapporte donc all_invalid. Conditionne sur le status par signature lorsque la distinction importe.
Le contrôle OCSP ne s’exécute que lorsque la chaîne récupérée comporte au moins deux certificats, car la requête a besoin de l’émetteur. Une chaîne à un seul certificat bascule vers le chemin CRL ou unavailable.
crlStatus ne rapporte jamais revoked dans les résultats de lot. Le repli CRL atteste uniquement la fraîcheur de la liste ; un résultat révoqué faisant autorité provient d’OCSP.
timestamp est toujours absent() dans les résultats de lot. Le validateur de lots n’évalue pas les jetons RFC 3161 intégrés ; utilise Vérification de signature pour l’évaluation d’horodatage.
signer est vide lorsque l’authentification a échoué. Lorsqu’il est défini, il s’agit du CN (ou O) du sujet du certificat vérifié par le CMS — jamais la chaîne /Name non authentifiée issue du dictionnaire de signature.
Les entrées trustedCerts doivent être des certificats PEM. Une liste d’ancres vide ou malformée produit un verdict de chaîne purement structurel avec trusted: false, plafonnant le verdict à Indeterminate.
Des octets qui ne commencent pas par un en-tête PDF produisent un statut error par document avec zéro signature — sans exception.
toJson() expurge les données personnelles par défaut. Ne passe new CertPiiGuard(disclosePii: true) que là où tu disposes d’une base légale documentée pour traiter l’identité du signataire.

Notes de sécurité

Producteur de verdict fail-closed. Valid requiert l’ensemble : une authentification CMS vérifiée sur le condensé du /ByteRange, une chaîne valide, une appartenance confirmée à une ancre de confiance et un statut de non-révocation concluant. Chaque contrôle non établi dégrade le verdict ; rien ne retombe sur une réussite par défaut.
Aucun blanchiment d’identité. Le signataire rapporté est le sujet du certificat lié cryptographiquement. L’entrée /Name est une métadonnée contrôlée par l’attaquant et n’est jamais présentée comme le signataire.
Les algorithmes faibles ne passent jamais. Une signature SHA-1 qui se vérifie est tout de même rapportée comme non valide ; une validité cryptographique sous un condensé faible n’est pas blanchie en une réussite complète.
La confiance est une entrée, pas une inférence. Les ancres que tu fournis sont comparées au terminus de la chaîne par empreinte DER SHA-256 (RFC 5280 §6.1.1). La cohérence interne d’une chaîne, ou une liste d’ancres non vide à elle seule, n’établit jamais la confiance.
La révocation est décisive. Une déclaration de révocation vérifiée force Invalid quels que soient tous les autres contrôles ; une preuve indisponible force Indeterminate.
Confidentialité par défaut dans la sortie sérialisée. toJson() masque le CN du signataire, le DN de l’émetteur racine, le nom de la TSA et les diagnostics de problème de chaîne à moins que tu ne le désactives, mettant en œuvre la minimisation des données de l’article 5(1)(c) du RGPD à la frontière de sérialisation.
Temps déterministe. La décision de fraîcheur CRL lit l’horloge PSR-20 injectée, et non l’horloge murale de l’hôte, de sorte que les verdicts de révocation sont reproductibles en test.

Conformité

NextPDF Enterprise met en œuvre un comportement inspiré d’ETSI EN 319 102-1 (le modèle de statut de validation à trois valeurs et la règle selon laquelle une information de révocation indisponible aboutit à INDETERMINATE), de la RFC 5652 §5.6 (recalcul du condensé côté vérificateur) et de la RFC 5280 §6.1 (les ancres de confiance en tant qu’entrées de la partie utilisatrice pour la validation de chemin). La prise en charge n’est pas la conformité, et la conformité n’est pas la certification. NextPDF ne détient aucune certification et n’en accorde aucune. Le validateur de lots n’est pas un service de validation qualifié, et ses statuts sont des verdicts d’ingénierie alignés sur la taxonomie EN 319 102-1 — et non des indications TOTAL-PASSED/TOTAL-FAILED/INDETERMINATE issues d’un processus de validation complet de la clause 5. En particulier, le mode lot n’effectue aucun traitement de preuve d’existence ni d’horodatage ; le côté vérification mono-document couvre ce terrain.

Comportement en mode FIPS

Le validateur de lots ne consulte aucune politique de mode FIPS, et activer le mode FIPS ne change pas les verdicts de lot. Sa gestion des algorithmes côté vérification est fixe et fail-closed : les signatures faibles (SHA-1) ne sont jamais rapportées Valid, avec ou sans mode FIPS. La politique de mode FIPS d’Enterprise contrôle le côté signature/génération, documenté dans FIPS 140 — Référence approfondie. La prise en charge de FIPS 140 est une déclaration de capacité, non une revendication de validation ou de certification.

Contrat de comportement

validate() lève \InvalidArgumentException pour une liste vide et \OverflowException au-delà de 1,000 documents. Les documents malformés ne lèvent jamais d’exception ; ils produisent des résultats error par document.
Valid requiert la conjonction : CMS cryptographiquement vérifié, chaîne valide, appartenance à une ancre de confiance confirmée, et RevocationStatus::hasConclusiveGood() vrai.
Un certificat confirmé révoqué est décisif : le verdict est Invalid quelles que soient toutes les autres preuves.
Les deux contrôles de révocation à Unknown/Unavailable signifient Indeterminate, jamais Valid (durcissement 3.1.0, impact sur la compatibilité ascendante).
Une signature authentifiée et à chaîne valide sans ancre de confiance confirmée est Indeterminate — authentique, confiance non établie.
signer est le sujet vérifié par le CMS ou la chaîne vide ; l’entrée /Name n’est jamais utilisée.
timestamp est toujours l’état absent dans les résultats de lot.
validCount ne compte que Valid ; tous les autres statuts comptent dans invalidCount, et le statut du document s’agrège à partir de ces compteurs.
toJson() applique le CertPiiGuard respectueux de la vie privée par défaut à moins qu’un garde ne soit passé explicitement.
Les totaux du rapport sont des sommes exactes sur les résultats par document ; durationMs est le temps réel mesuré pour le lot.

Repli Core

Le module Sécurité / Signature de NextPDF Core est le côté producteur : il crée des signatures CMS, applique des horodatages RFC 3161 et valide les chaînes et la révocation du matériel qu’il intègre au moment de la signature. Core ne fournit aucun orchestrateur de lots côté vérification : pas de rapport multi-documents, pas de taxonomie de statut agrégée, pas de verdicts de révocation OCSP/CRL pour des documents tiers, ni de sérialisation de rapport protégeant les données personnelles. Avec Core seul, tu extrairais et vérifierais chaque signature toi-même et construirais ton propre reporting. Le côté vérification mono-document d’Enterprise (Vérification de signature) et cet orchestrateur de lots fournissent cette couche.

Limite de publication

Cette page documente uniquement le comportement observable en externe et la surface d’API publique prise en charge. Les chemins de namespace internes, les classes utilitaires, les tables de mécanismes, les noms de fichiers de runbook et les préfixes de ticket sont hors périmètre.

Voir aussi

Vérification de signature — le côté vérification cryptographique AdES/PAdES mono-document, y compris la validation d’horodatage et de chaîne d’archivage
Archive — intégration de matériel DSS/VRI et d’horodatages de document pour la validité à long terme
Validation — contrôles de politique structurels en lecture seule, sans cryptographie
Signature — Référence approfondie — la référence approfondie du module Signature
Niveaux de garantie eIDAS — l’API CertPiiGuard et la correspondance des niveaux de garantie
Signer à grande échelle, sans compromis — essai Insider sur la conception de signature et de validation à haut volume
Valider correctement une signature — essai Insider sur l’importance d’une validation fail-closed