Download the PHP package tecnickcom/tc-lib-pdf-sign without Composer

tc-lib-pdf-sign

Digital signature primitives for PDF documents (PKCS#7, CAdES, PAdES).

💖 Part of the tc-lib-pdf / TCPDF ecosystem (100M+ installs). Sponsor its maintenance →

Overview

tc-lib-pdf-sign provides the cryptographic building blocks and PDF signature objects used by tc-lib-pdf to produce signed PDF documents. The crypto and the PDF object generation live here, while the host library keeps the ByteRange placement, the incremental update writer, and the public facade.

The package assembles CMS/CAdES signatures natively in pure PHP (via a small DER ASN.1 codec), so it can embed the ESS signing-certificate-v2 attribute that openssl_pkcs7_sign() cannot add. This is what lifts a plain PKCS#7 signature to a PAdES baseline signature.

Features

Signature profiles (each level builds on the previous one):

• RSA and ECDSA signing keys, with SHA-256, SHA-384, or SHA-512 digests.
• Local (private key), external, and remote (HSM, smart card, CSC) signing. The CMS is assembled here in one call or in two, and the tc-lib-pdf facade drives the placeholder and the injection.
• The PAdES baseline output has been validated against the EU DSS reference validator (B-B, B-T, B-LT, B-LTA all report the expected baseline level).

Components

Design

The codecs are pure and perform no file or network access. HTTP transports (TSA, OCSP, CRL) and key loading are injected by the host as callables, so the consuming application owns networking and SSRF protection.

Nothing a TSA, an OCSP responder, or a CRL distribution point returns becomes validation material until its signature has been checked:

• A timestamp token must carry exactly one SignerInfo whose signature verifies against the TSA certificate the token embeds, whose content-type and message-digest attributes match the encapsulated TSTInfo (RFC 5652 sections 5.3 and 11.1), and whose ESS signing-certificate attribute, when present, names that same certificate. It must then answer the request that was sent (RFC 3161 section 2.4.2): the same message imprint under the same digest algorithm, the nonce echoed unchanged, the policy that was asked for when one was requested, and a genTime near the moment of the request. That certificate must be a TSA certificate: RFC 3161 section 2.3 reserves a TSA key for timestamping, so id-kp-timeStamping is required as the single extended key usage, marked critical, and the certificate must have covered the instant the token attests.
• An OCSP response is checked against the RFC 6960 section 3.2 acceptance rules: successful status, a basic response type, a signature that verifies against a responder the issuer authorised (itself, or a delegate holding id-kp-OCSPSigning that the issuer signed and that is inside its own validity period), a SingleResponse whose CertID matches the request by value, a good certificate status, and a validity interval covering the moment of use. thisUpdate is held to the age limit whether or not the response carries a nextUpdate, rule 5 being an acceptance rule of its own and no nonce being sent. Every entry matching the CertID is read rather than the first, and a revoked among them wins. A singleExtension or responseExtension marked critical that this codec does not recognise makes the response unusable (RFC 6960 section 4.4).
• A CRL must be one complete CertificateList issued by the certificate the distribution point came from and signed by it, with matching inner and outer signature algorithms, covering the moment of use, and not narrowed by a deltaCRLIndicator or an issuingDistributionPoint. The issuing certificate must be one that may sign a list at all (RFC 5280 section 6.3.3 (f)): a CA whose keyUsage admits cRLSign, the counterpart of the id-kp-OCSPSigning check on the OCSP side. A named distributionPoint is refused along with the other narrowings, being one shard of a partitioned list. onlyContainsUserCerts and onlyContainsCACerts split the issuer's certificates in two rather than narrowing the list, so which half answers is decided against the certificate the list was fetched for (RFC 5280 section 6.3.3). An extension type appearing twice is refused rather than collapsed to the last, and a critical extension this reader does not recognise makes the list unusable (RFC 5280 section 6.3.3 (a)(2)). The issuer certificate is required, so Signer::collectValidationMaterial() does not fetch a CRL for a chain entry whose issuer it does not hold and reports the URLs it therefore did not try. The certificate the list is fetched for is required too, though it may be passed as null to skip the revocation lookup; given one, its serial is looked up among the revoked entries.

Anything that fails is rejected here rather than embedded in the document. The number of URLs taken from one certificate extension is bounded at Ltv\ValidationMaterial::MAX_URLS, each one being a call to the host's transport; the excess is reported rather than dropped. Revocation collection is best-effort, so a rejection is a skip rather than an error: Signer::collectValidationMaterial() takes an $onSkip observer that receives every discarded URL with the reason and an Ltv\SkipReason, which separates a revoked verdict from a timeout:

The digest and signature algorithms accepted for validation material are SHA-256 and above. SHA-1 is refused; a host that has to accept one from a legacy responder passes allowSha1: true to Cms\SignatureVerifier or Cms\SignedDataVerifier and injects it.

RSA signatures are PKCS#1 v1.5 throughout, identified by rsaEncryption as RFC 3370 section 3.2 defines it for CMS and read back under either that identifier or the sha*WithRSAEncryption form. RSASSA-PSS is not supported, in either direction: openssl_sign() cannot produce it and openssl_verify() cannot express its parameters, so a PSS-signing key cannot sign through this library, and a PSS-signed timestamp token, OCSP response, or CRL is refused as an unsupported signature algorithm.

Some checks stay with the host. The library does not decide whether a certificate is trusted, and by default it does not refuse to sign with one that has expired or whose key usage forbids signing, since a host may deliberately re-sign historical content. Cms\Certificate::assertValidAt() and Cms\Certificate::assertUsableForSigning() run those checks on demand, and new Signer(checkSignerCertificate: true) runs both on every sign() and prepare().

Timestamp\Config carries host, timeout, verifyPeer, username, password, and cert for the host to apply to its own HTTP client. This library never reads them, opening no connection.

Requirements

• PHP 8.2 or later
• Extensions: hash, json, openssl, pcre
• Composer

Installation

This package is normally pulled in transitively by tc-lib-pdf; install it directly only when you need the low-level primitives on their own.

Usage

For signing PDF documents, use the tc-lib-pdf fluent signature() facade, which drives this package end to end:

See the full guide in tc-lib-pdf/doc/DIGITAL_SIGNATURES.md and the runnable E007/E008/E009/E081 signature examples in tc-lib-pdf.

Low-level: building a detached CMS

Cms\Builder produces a detached CAdES-BES CMS over arbitrary bytes (the host supplies the ByteRange-covered content). It is the core of PAdES B-B:

Low-level: two-phase signing

sign() needs the private key and the content in this process. When either is unavailable, the same call is available in two halves. signaturePayload() returns the DER SET OF signed attributes that the signature has to cover, and buildFromSignature() turns those plus the signature into the CMS.

This covers a key held in a hardware token, a smart card, or a remote signing service, and a document too large to hold as a string, since the request carries the message digest rather than the content:

Signer exposes the same three steps (prepare(), signaturePayload(), buildFromSignature()), so a host driving a remote signer can complete the flow through that class alone while getting the profile rules applied.

buildFromSignature() verifies the signature against the signing certificate before it emits anything, so a signature over the wrong bytes, from the wrong key, or in the wrong encoding fails at the call. Cms\SignedDataVerifier::verify() reads a finished CMS back, given the content a detached signature covers:

Omit the content and the message has to carry its own, which is the shape of an RFC 3161 timestamp token; supply it and the message must carry none, because a message with content of its own is not the message being checked. An ECDSA signature returned as the fixed-width r || s concatenation is accepted by passing SignatureEncoding::P1363 as the last argument.

The request is immutable and validated on construction. When the two phases are separate HTTP requests, carry it across with toArray() and fromArray(), which validate again on the way back in.

Validation is not authentication. Re-running the constructor rejects a payload that is not a valid request, but not one edited into a different valid request. Pass a secret to both calls and the state carries an HMAC that is checked before anything else, or carry it over a channel the host already protects.

Signer::prepare() and Signer::buildFromSignature() are the same pair one level up, applying the profile rules: the signing-time attribute is omitted for PAdES, and a B-T or higher profile requires the timestamp client and transport.

Signer::collectValidationMaterial() takes the signer chain leaf-first, one certificate per entry as PEM or DER, and verifies that ordering by signature rather than by name. Taking the signature as the link is what lets an authority that re-issued its own certificate with a Name of the same value in another string type still be recognised as the issuer of the leaves it signed. A PEM entry holding more than one certificate, such as a fullchain.pem, is refused rather than decoded as a chain of one. Each entry is parsed as a certificate, and the armour has to say CERTIFICATE, since nearly everything a PEM file holds is a DER SEQUENCE.

The certificates a timestamp token embeds are ordered into a path starting at the certificate the token was verified against, not at a leaf picked out of the bag: the certificates field sits outside signedAttrs and is covered by no signature. A bag member outside the path is still collected, since a validator may need it, but nothing can be looked up for it, so its URLs are reported through $onSkip with SkipReason::NotAttempted.

Signer::signatureTimestampTokens() reads the tokens back out of a CMS. The token is produced inside sign(), by the provider the profile requires, and the host's transport sees the TimeStampResp rather than the token inside it, so this is how the output of sign() or buildFromSignature() feeds the collector:

Pass the signature timestamp tokens as the fourth argument: the certificates they embed are ordered into a path, by signature for the same reason, and run through the same OCSP and CRL lookups as the signer's own chain, which is what ETSI EN 319 142-1 requires of a B-LT Document Security Store. Members of the token's certificate bag that do not chain are collected as certificates but not looked up, there being no issuer to build a lookup against. Ordering the bag costs a signature check per pair of members, so one larger than Signer::MAX_PATH_CERTIFICATES is refused rather than ordered.

Pass the signing time as the fifth argument so a retried or queued signature collects against the same instant it signs for. It is separate from the $timestampNow argument of sign() and buildFromSignature(), which is the moment the timestamp request is made and what the token's genTime is checked against.

Output\Dss::emit() returns a state entry alongside the objects. A DSS written by an incremental update replaces the one before it, so pass that state back on the next update (a second signature, or the B-LTA archive timestamp) and the earlier VRI entries are carried into the new dictionary instead of being dropped. Material an earlier revision already wrote is referenced again rather than written a second time.

A signed attribute a profile requires, such as the CAdES signature-policy-identifier, is passed to the request as an OID-keyed map. The attribute types the builder controls are reserved and cannot be overridden.

Standards

• ETSI EN 319 142-1 - PAdES baseline profiles (B-B, B-T, B-LT, B-LTA)
• ISO 32000-1 / ISO 32000-2 - PDF digital signatures and the Document Security Store
• RFC 5652 - Cryptographic Message Syntax (CMS)
• RFC 5035 - ESS signing-certificate-v2 attribute
• RFC 3161 - Time-Stamp Protocol (TSP)
• RFC 6960 - Online Certificate Status Protocol (OCSP)
• RFC 5280 - X.509 certificates and CRLs

Development

Packaging

For system packages, bootstrap with:

Contributing

Contributions are welcome. Please review SECURITY.md.