Workflows de signature Linux natifs

L'ABI de callbacks versionnée exécute des jobs sign schemaVersion 1 contre des documents chargés ou des callbacks d'entrée explicites ; les révisions sources d'origine, les IDs de documents et les politiques AES-256 R5/R6 authentifiées sont conservés

Identité de signature

Fournissez certificatePEM et privateKeyPEM, ou fournissez pfxBase64 canonique paddé et pfxPassword ; mélanger ces formes d'identité est invalide

password authentique une entrée PDF explicite ; un contexte chargé conserve son mot de passe PDF, et le mot de passe PFX séparé authentique le conteneur de signature

Le décodage PFX vérifie l'alphabet, le padding et les bits inutilisés avant que OpenSSL n'analyse le conteneur borné ; les tampons d'identité privés sont effacés après l'opération

Champs de signature et apparence

field sélectionne un champ de signature non signé existant ; réglez createField: true pour créer un nouveau nom de champ entièrement qualifié sur la page à base zéro

Les coordonnées des nouveaux champs utilisent l'espace utilisateur PDF : left, bottom, right et top valent par défaut 36, 36, 240 et 108 ; un nom existant ne peut pas être recréé

Une caption optionnelle génère une apparence Unicode explicite avec une police TrueType embarquée, un mapping ToUnicode et du shaping natif de scripts complexes ; fontFamily vaut par défaut DejaVu Sans et fontSize 12

Profil et certification

cades sélectionne ETSI.CAdES.detached ; trustedCAFile fournit une politique CA explicite pour la vérification de trust à la signature, et reservedCMSBytes vaut par défaut 16384

certificationPermission vaut 0 pour une signature d'approbation ou 1, 2 ou 3 pour une signature de certification de premier document ; le writer crée le transform DocMDP correspondant et la liaison de permissions de catalog

Les restrictions de permissions par mot de passe utilisateur, les champs read-only, les signatures existantes et les contraintes de certification restent appliqués par la politique native de signature de documents

Publication transactionnelle

L'API Pascal portable TimestampToFile crée un DocTimeStamp indépendant avec ETSI.RFC3161 sur le ByteRange PDF, y compris sa déclaration ESIC, la politique explicite de trust et de CRL TSA, et l'exception authentifiée d'horodatage DocMDP/FieldMDP

Ce point d'entrée d'horodatage de document est une API Pascal ; le callback d'horodatage ABI ci-dessous fournit les horodatages de signature pour les jobs sign existants

Le transport d'horodatage ABI étendu fournit de véritables réponses RFC 3161 via un callback synchrone possédé par l'appelant avec des octets de réponses bornés, une annulation partagée et une politique explicite de trust/révocation TSA

Les callbacks de sortie et de résultats reçoivent une signature entièrement préparée ; avant la publication par callbacks, l'ABI recharge le candidat pour valider le contexte du document signé

Seule une publication réussie remplace le contexte chargé ; des identités invalides, la création de champs, les budgets, l'annulation ou un échec de callback préservent le document précédent et son arbre de champs

Les callbacks de sortie sont possédés par l'appelant et peuvent avoir déjà consommé des octets quand un callback ultérieur échoue ; les appelants exigeant un rollback externe doivent préparer ces octets eux-mêmes

Acceptation

FPC Linux 3.2.2 et 3.3.1 passent chacun 270 assertions ctypes réelles, 228 vérifications indépendantes PDF/image/sécurité/CMS, 33 assertions C ABI et 80 opérations concurrentes de handles partagés

Les vérifications indépendantes authentifient les IDs et politiques de sécurité AES, valident CMS et CAdES avec OpenSSL, rejettent le contenu falsifié, inspectent les transforms de certification et les polices d'apparences embarquées, et vérifient les pixels réels des signatures visibles

ABI C native · Signature PFX Pascal · Transport d'horodatage Pascal