PAdES-Signaturrichtlinien-Validierung

HotPDF erzeugt und validiert das explizite signierte CMS-Attribut signature-policy-identifier, das von PAdES-E-EPES-Signaturen verwendet wird

Eine explizite Richtlinie erzeugen

Setzen Sie SignaturePolicyOID und den Digest des Richtliniendokuments auf THPDFCMSSignOptions und wählen Sie dann optionale strukturierte Qualifier

Options := HPDFCMSDefaultOptions(palExtended_E_EPES);
Options.SignaturePolicyOID := '1.2.3.4.5.1';
Options.SignaturePolicyHash := HPDFCMSDigestBytes(PolicyDocument, cmsdaSHA256);
Options.SignaturePolicyURI := 'https://policies.example/approval-v1';

SetLength(Options.SignaturePolicyQualifiers, 1);
Options.SignaturePolicyQualifiers[0].Kind := cmsqUserNotice;
Options.SignaturePolicyQualifiers[0].ExplicitText := 'Approval policy applies';

CMS := HPDFCMSBuildSignedDataEx(KeyMaterial, DocumentDigest, Options);

SignaturePolicyHashAlgOID verwendet bei Leerwert standardmäßig SHA-256, während SignaturePolicyURI eine Kompatibilitäts-Abkürzung für einen einzelnen SPuri-Qualifier bleibt und mit SignaturePolicyQualifiers kombiniert werden kann

Das strukturierte Qualifier-Modell unterstützt SPuri, SPUserNotice mit einer optionalen Hinweisreferenz und explizitem Text sowie SPDocSpecification, identifiziert durch eine OID oder URI

Setzen Sie SignaturePolicyHashIsUnknown nur, wenn der Unterzeichner den Richtlinien-Hash nicht kennt; HotPDF emittiert dann die ETSI-Alles-Null-Darstellung in der gewählten Digestslänge

Parsen und berichten

HPDFParseCMSSignature macht das Attribut über THPDFSignatureInfo.SignaturePolicy zugänglich, einschließlich seiner Kennung, des Hash-Algorithmus, der Hash-Bytes, des Unbekannt-Hash-Flags, der Qualifier und des Validierungsstatus

Bekannte Qualifier-Werte werden in typisierte Felder dekodiert, während ein nicht erkanntes Qualifier seine OID und den rohen Wert als DER für die Anwendungsebene behält

HPDFSignatureValidationReportToJSON serialisiert dieselben Richtlinien- und Qualifier-Daten mit einem maschinenlesbaren Validierungsstatus

Eine erforderliche Richtlinie festlegen

VerifyOptions := THPDFCMSVerifyOptions.Default;
VerifyOptions.RequireSignaturePolicy := True;
VerifyOptions.ExpectedSignaturePolicyOID := '1.2.3.4.5.1';
VerifyOptions.ExpectedSignaturePolicyHash := ExpectedPolicyHash;
VerifyOptions.SignaturePolicyDocument := PolicyDocument;
VerifyOptions.VerifySignaturePolicyDocumentHash := True;
VerifyOptions.RejectUnknownSignaturePolicyHash := True;

Status := HPDFVerifyCMSSignatureEx(Source, ByteRange, CMS,
  VerifyOptions, SignatureInfo);

Erwartete OID- und Hash-Felder schränken nur den jeweils passenden Wert ein, und die Prüfung des Richtliniendokuments hasht sogar ein absichtlich leeres Dokument, wenn VerifySignaturePolicyDocumentHash wahr ist

Fehlende, abweichende, nicht unterstützte oder abgelehnte unbekannte Richtlinien liefern svSignaturePolicyMismatch und vfcSignaturePolicyMismatch mit einem präzisen THPDFSignaturePolicyValidationStatus

Richtlinienprüfungen laufen vor der Arbeit von Signaturprovider, Zertifikatspfad oder Nachweiserhebung und gelten nur für primäre SignerInfo-Datensätze, sodass eine Richtlinie des übergeordneten Dokuments Gegen-Signaturen nicht einschränkt

Strenge und Grenzen

Der Parser lehnt doppelte Richtlinienattribute, mehrere Werte, implizierte NULL-Richtlinie, fehlerhaft geformte bekannte Qualifier, nicht-ASCII-IA5String-Werte, ungültiges Unicode, falsche bekannte Digestlängen und Sammlungsgrößen über den konfigurierten Implementierungsgrenzen ab

PAdES E-EPES verlangt das explizite Richtlinienattribut genau einmal und verbietet den Eintrag /Reason im PDF-Signaturwörterbuch, wenn dieses Attribut vorhanden ist; die CMS-Ebene kann das PDF-Wörterbuch nicht prüfen, daher muss der PDF-erzeugende Workflow diese letzte Einschränkung durchsetzen

Siehe CMS mit mehreren primären Unterzeichnern, Konsistenz der CMS-Digest-Algorithmen und CMS-Validierungsberichte