Options de signature Linux natives

L'ABI de callbacks native lie les contraintes de signature de documents à la sortie CMS réelle et à l'apparence générée

Digest et métadonnées Unicode

L'opération sign accepte digestMethod comme SHA256, SHA384 ou SHA512 ; la valeur par défaut est SHA256 et la valeur sélectionnée détermine le digest réel du signataire CMS

reason, location, contactInfo, signerName et legalAttestation acceptent des chaînes Unicode sans caractères NUL embarqués

Les métadonnées suivent la politique de chiffrement de chaînes du document source, y compris les entrées AES-256 authentifiées

legalAttestation s'applique aux signatures de certification et devient la valeur Legal.Attestation du catalog

Les valeurs de seed requises gouvernent le digest réel, la raison, les propriétés de certificats, la permission de certification, l'attestation légale, le profil d'apparence, les informations de révocation et le comportement d'horodatage

Octets de trust explicites

trustedCAPEM, timestampTrustedCAPEM et timestampTrustedCRLPEM acceptent des octets PEM dans des chaînes JSON

Les entrées de chemins legacy correspondantes sont trustedCAFile, timestampTrustedCAFile et timestampTrustedCRLFile ; fournissez des octets ou un chemin pour chaque source de trust

Les entrées PEM sont conservées dans des fichiers privés exclusifs avec le mode 0600 pendant l'opération puis supprimées ; les réponses n'exposent pas ces chemins générés

Le trust du certificat signataire n'est évalué que lorsqu'il est explicitement configuré, tandis que la vérification d'intégrité CMS vérifie toujours la signature réelle et la liaison du certificat de signature

Informations de révocation signées et validées

Fournissez un objet revocationInfo avec enabled, certificatesBase64, ocspResponsesBase64, crlsBase64, et trustedCAPEM ou trustedCAFile

enabled vaut true par défaut ; des informations désactivées ne peuvent pas inclure de tableaux de preuves

Les tableaux contiennent des chaînes Base64 canoniques pour des certificats DER complets, des objets OCSPResponse réussis et des objets CertificateList

clockSkewSeconds vaut 300 par défaut et doit être entre 0 et 86400 ; maxOCSPAgeSeconds vaut 86400 par défaut et doit être positif ; requireTimestamp vaut false par défaut

La validation vérifie les chaînes de certificats du signataire et de l'horodatage inclus par rapport au trust explicite, la couverture complète non racine, la correspondance d'émetteur et de numéro de série, les signatures CRL et OCSP, l'autorisation du responder, les intervalles de validité et le statut révoqué

Des preuves malformées, périmées, incomplètes, non fiables ou révoquées font échouer l'opération avant la publication du PDF

Les preuves validées deviennent l'attribut CMS signé 1.2.840.113583.1.1.8, et le résultat rapporte revocationInfoEvaluated et revocationInfoValid

signatures.verify accepte le même objet revocationInfo pour valider l'attribut signé réellement embarqué ; les CRL et réponses OCSP de l'appelant ne remplacent pas cet attribut pendant la vérification

Les objets de preuves et les octets totaux partagent les limites de l'opération, et les vérifications cryptographiques utilisent le token d'annulation de l'opération

Préréglages d'apparence nommés réels

Fournissez un objet appearance avec caption, fontFamily optionnel et profileName optionnel

Le préréglage détermine son style et sa taille de police ; un profil inconnu échoue au lieu d'étiqueter une apparence arbitraire

Un AppearanceFilter requis correspond au profil réellement généré pendant l'opération courante ; une apparence précédemment chargée doit être régénérée

Sans profileName, fontSize vaut 12 par défaut ; les caption, fontFamily et fontSize de premier niveau legacy restent pris en charge

Ne combinez pas une caption de premier niveau avec un objet appearance

Provenance du transport applicatif

credentialSourceURL énonce la provenance des credentials affirmée par l'application fournissant l'identité, et timestampServerURL énonce la provenance du endpoint affirmée par son callback d'horodatage

Ces valeurs sont comparées aux contraintes de seed requises correspondantes ; elles ne récupèrent pas de credentials, n'accèdent pas à un serveur distant et n'authentifient pas indépendamment l'identité du endpoint HTTPS

L'application contrôle la récupération d'identité et l'authentification du transport

timestampServerURL exige un véritable callback dans hpdf_signing_operation_v1, et la réponse RFC 3161 retournée doit passer les vérifications d'empreinte de signature, de nonce, de but du certificat TSA, de trust explicite et de révocation demandée

Workflows de signature · Transport d'horodatage · Contraintes de seed · Profils d'apparence