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

Wed - 06/21/2023

The ability to apply and validate secure PDF digital signatures has long been a particular strength of the open-source iText Core library. We’ve kept pace with advances such as support for PAdES and PDF 2.0, and so we’re proud to present a guest blog detailing iText 8’s support for the latest ISO extension standards for digital signing.

Share this article

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.

Matthias Valvekens

Author information

Matthias Valvekens is a FOSS developer, former iText engineer and digital signing nerd. Still an active contributor to PDF-related standardization efforts at ISO and the PDF Association, he is the current chair of the PDF Association’s Digital Signatures Technical Working Group.
Photo credit: © Archives of the Mathematisches Forschungsinstitut Oberwolfach


Many thanks to Matthias for his contributions to support these extensions in iText 8, and for writing this blog for us. In addition, we will soon be publishing a follow-up article from Matthias talking about the newly-added support for RSASSA-PSS in digital signatures. Support for RSASSA-PSS has been requested by a number of customers, since this signature scheme is more secure and robust than the "traditional" PKCS#1 v1.5 padding. There is growing adoption of PSS when signing with RSA, with recent German government guidelines requiring its use for many applications.

You can find out more about what else is new in iText 8 by checking the blog, which also links to the release notes. Alternatively, you can watch our webinar linked below!

Better than ever at digital signing & document creation!

Our first release as part of the Apryse family is also our biggest and most significant release since iText 7 in 2016. Version 8 of the iText Suite PDF SDK packs a ton of new features and API improvements across the board. Join us for an exclusive webinar where we'll explore what makes iText 8 the new go-to solution for digital signing, document creation, and much more!

Watch the webinar on YouTube


Still have questions? 

We're happy to answer your questions. Reach out to us and we'll get back to you shortly.

Contact us
Stay updated

Join 11,000+ subscribers and become an iText PDF expert by staying up to date with our new products, updates, tips, technical solutions and happenings.

Subscribe Now