iText 8 now supports the latest ISO PDF extensions for digital signing

Over two decades have passed since digital signatures were integrated with PDF in PDF 1.3. As cryptographic best practices evolved beyond the first mass-marketed applications of public-key cryptography from the 90s, PDF also had to keep up. In subsequent versions of the file format, the digital signature feature set was revised several times.

Some of these changes were made to incorporate new cryptographic technology (adding new algorithms), others sought to refine the semantics of PDF signatures in various ways (certification signatures, interactions with form fields, ...). PDF 2.0 also made some significant changes, including integrating the European PAdES standard and deprecating a decent chunk of the more dated and rarely used DigSig features.

In late 2022, ISO published two extension standards to PDF, with the goal of extending the file format’s digital signing capabilities yet again.

The standards in question are ISO/TS 32001 and ISO/TS 32002.

• The purpose of ISO/TS 32001 is to add SHA-3 digests to the list of supported hash functions in PDF.
• ISO/TS 32002 is all about improving PDF’s support for digital signatures based on elliptic curve cryptography. It clarifies how to use the Elliptic Curve Digital Signature Algorithm (ECDSA) with PDF, and adds support for the Edwards-curve Digital Signature Algorithm (EdDSA) as well—concretely, its two most popular parameterizations commonly referred to as Ed25519 and Ed448.

Why does this matter?

These extension standards represent an important step forward for PDF to support modern cryptographic primitives. In particular, the addition of EdDSA is a major advancement.

Ed25519 and Ed448 key pairs are much smaller than their RSA counterparts (for a comparable level of security), and the signing algorithm is easier to implement securely than RSA and (generic) ECDSA. Out in the field, EdDSA signatures are already widely used in various protocols and other applications, and it has garnered significant attention in recent years. Notably, Ed25519 and Ed448 were recently formally adopted by NIST in FIPS 186-5.

ECDSA signatures, on the other hand, have been officially supported in PDF since PDF 2.0, but the specification left some important aspects up in the air. More concretely, it did not mention anything about curve parameters. Mathematically, the ECDSA algorithm works for a very general class of elliptic curves, and in order to do anything useful with it, the signer and verifier have to agree on a choice of curve. Not all elliptic curves are created equal, though, and the right choice depends on many factors.

Since the verifier needs to know which curve parameters the signer used, you’d think that they could simply include the parameters with the key, but it turns out that this is insecure. In practice, the curve is typically only specified “by name”, and the verifier is supposed to look up the actual parameters by itself.

This means that in a file format like PDF, it’s important to agree on a set of curves that one can expect to have support for in a “general-purpose” PDF processor. This gap is also bridged by ISO/TS 32002: it contains a list of supported ECDSA curves paired with digest algorithms that can be used in PDF.

If you want to know more about the relationship between these extension standards and the “core” PDF 2.0 specification, have a look at my earlier post on the subject, or give Peter Wyatt’s article on PDF 2.0 cryptography upgrades a read.

Path to adoption and the role of FOSS

A standard like this, even though it’s not very complicated in a technical sense, takes a long time to adopt. Sure, some PDF software already supports the new extensions, but not everyone. Moreover, when introducing new signature algorithms we also need certificate authorities to issue certificates for such keys. This creates an interesting chicken-or-egg problem:

• Public certificate authorities have no incentive to start issuing document signing certificates for “new” key types if they can’t count on PDF software to support them as well.
• Conversely, if certificates for those new key types aren’t being issued at scale, PDF software vendors are not incentivized to adopt new technology either.

There’s no easy or quick way to resolve this issue, but I believe open-source implementations have a role to play here.

• A FOSS PDF implementation with a broad reach—such as iText—adopting modern standards makes it easy for its many users to follow suit.
• Additionally, having several open-source implementations freely available allows both FOSS and non-FOSS developers to use those FOSS tools as a reference for interoperability purposes. This lowers the barrier to entry considerably and allows other players to have greater confidence in the interoperability of the tooling available on the market.

These were the main reasons why I contributed the changes required to implement both of these extensions in iText 8: if major FOSS projects like iText adopt this kind of standard early, it’ll hopefully allow them to reach critical mass quicker.