Digital signatures, introduced by Whitfield Diffie and Martin E. Hellman in 1976’s “New Directions in Cryptography,” have provided the cornerstone of the internet’s cybersecurity apparatus for decades. Every moment of every day, behind the scenes of nearly every secure online interaction, these signatures enable critical trust decisions made across the globe. As the threat landscape accelerates—with AI and quantum threats challenging the status quo—there is a growing need to focus on current security status when signatures are used, making the transition from verification to trust.

Current security status is what Verisign Informed™ is designed to provide. By delivering real-time checks on the current status of any participating digital certificate, Verisign Informed aims to close the gap between cached validation data that can grow dangerously stale in the hours and days after it was provided versus the current security status of the certificate. For more details about Verisign Informed, check out our blog.

Half a century ago, Diffie and Hellman revolutionized cryptography when they proposed “new types of cryptographic systems, which minimize the need for secure key distribution channels and supply the equivalent of a written signature.”

Prior cryptographic systems had assumed that communicating parties shared a common, secret key. Public-key cryptography, introduced by Diffie and Hellman, suggested instead that complementary cryptographic operations could be “governed by distinct keys” where one could be made public while the other remained private.

In addition to providing a new framework for encryption, this breakthrough “asymmetric” approach also offered a new form of data authentication. One user—and only that one user—could process a message mathematically with a private key, in effect “signing” the message. And another user—any other user—could check that the processing was performed correctly using the public key, thus “verifying” the signature (see Figure 1).

This “sign and verify” process would provide the “equivalent of a written signature” for the digital era—a digital signature.

The revolutionary value of the digital signature led to tremendous innovation, including in the underlying cryptography which supported it. Diffie and Hellman’s “New Directions in Cryptography” was followed soon after by the RSA algorithm, invented by Ronald L. Rivest, Adi Shamir, and Leonard Adleman. That was further followed by cryptographic techniques based on different mathematical problems including NIST’s Digital Signature Algorithm (DSA), Elliptic Curve DSA (ECDSA), and more recently, two post-quantum algorithms, SLH-DSA and ML-DSA.

Five decades later, digital signatures have become a ubiquitous foundation for verifying the authenticity of data, information, and essentially every World Wide Web transaction.

Though it is hard to overstate the importance of digital signatures as a concept, it is also easy to overestimate the import of a particular digital signature. A digital signature provides evidence that at some time in the past, someone who controlled a specific private key mathematically processed a message with the private key. But who this party may have been—and whether the messages they digitally sign can be trusted—and whether a particular message, even if “true” when it was digitally signed, is still correct—are all questions requiring yet more evidence—and perhaps more digital signatures.

Digital Certificates

Introduced by Loren M. Kohnfelder in his 1978 bachelor’s thesis, a digital certificate is a digitally signed statement by a certification authority (CA) that a named party controls the private key corresponding to a specified public key. (In Kohnfelder’s terminology, the CA is a “public file” and the private key is a “decryption function.”)

As Kohnfelder observed, because the decryption function might be “lost,” i.e., the private key might be compromised, relying parties would benefit from additional evidence about whether a party continued to maintain control of its key—in today’s terms, whether a certificate is still valid.

Kohnfelder suggested three types of additional evidence, each motivated by analogy with “lost credit cards”:

• a list of “lost decryption functions” or “names of certificates to be ignored,” distributed by the public file;
• certificate expiration dates which bound the time period to which the certificate applies, after which a new certificate is needed; and
• an update directly from the public file indicating whether the certificate is still valid, or if not, as Kohnfelder put it, “the associated certificate has been cancelled due to a certificate leak.”

Digital certificates and the first two types of evidence would be standardized a decade later in ITU-T (formerly CCITT) Recommendation X.509. The third type of evidence would later be provided via the Online Certificate Status Protocol (OCSP), published in 1999.

The evidence available to relying parties has varied over the years and by use case. For example, the CA/Browser Forum has adopted a schedule of progressively shorter certificate lifespans and made OCSP optional for web server certificates. And some certificates may not offer security status at all.

Meanwhile, applications involving object security, where the object being protected has a separate lifetime from the public / private key pair protecting it, introduce foundational factors that dictate a different approach.

Consider code signing—an object security application where a device assesses whether to install a software resource based on evidence such as the following:

1. Code signer’s signature on software resource. A statement by the author of the code attesting that the software resource—typically identified by its cryptographic hash—was originated by the author. The implication is the software is safe to install and use. This statement is digitally signed with the code signer’s private key.
2. Code signer’s certificate. A statement by a CA attesting that the code signer—identified by its name and public key—adequately protects its private key and that they are who they say they are. This statement is digitally signed with the CA’s private key.
3. Timestamp. A statement by a timestamping authority (TA) attesting that statements (1) and (2) existed at a given point in time.

Is this enough evidence for the device to trust that the software resource is safe to install and use? As Verisign’s Distinguished Scientist Eric Osterweil explains in a new Verisign Labs Technical Report, “Origin Verification Is Not Enough,” more evidence might be needed.

The Importance of Current Security Status

The TA’s timestamp protects a relying party against a compromise of the code signer’s private key or operational practices that occurs after the timestamp was produced, because it provides evidence that the signature and certificate existed before the compromise.

But what if the compromise occurred before the timestamp was produced—yet this “contrary evidence” did not become known until later? Or if there were later evidence that the CA has issued the certificate to the incorrect party? Are there other relevant pieces of evidence that may have developed or come to light after signing?

Even if the TA checked a Certificate Revocation List (CRL) or OCSP response at the time of its signing to confirm that the certificate was still valid—and even if the TA included this information in the timestamp—the result would be the same, because the evidence of compromise wasn’t yet available.

A device that makes its trust decision based on only the three pieces of evidence from moment of timestamp is relying on old security status—on stale trust.

Current evidence is the driver for high-assurance security decisions. Tenet 7 in NIST’s Zero Trust Architecture includes this principle:

“The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.”

Accordingly, insights into the “current state” should be used to “improve security posture.”

One of those insights is the current security status of the certificate. In contrast to the security status that might have been available to the TA at the time of its signing, the current security status is the information available to relying parties now. That information includes whether the signer’s private key or operational practices were learned to have been compromised at any time, including before the timestamp, even if the certificate has since expired.

As the technical report explains, the security status can also include other information that may affect a relying party’s decision, such as whether the signer’s public key has been included in another certificate, and whether the certificate’s serial number is indeed unique.

A system aware of all this additional evidence would be better informed to make its trust decision on installing the software—changing the security “status quo.”

Conclusion

Digital signatures have borne the weight of the internet’s cybersecurity apparatus for decades. As the threat landscape accelerates to new levels, the concept of current security status becomes critical in the path from verification to trust.

The technical report “Origin Verification Is Not Enough” provides a more formal treatment of security status and evidence-based trust, starting with the code signing use case.