Public key infrastructure (PKI) is a system of cryptographic keys, digital certificates, trusted authorities, validation processes, and policies used to connect a public key with an identified person, organization, or device.
In document signing, PKI provides the trust framework behind many digital signatures. It helps a recipient determine whether a signature was created with a particular private key, whether the associated certificate came from a trusted source, and whether the document changed after signing.
PKI is more than encryption software or a pair of keys. It includes the organizations, technical services, operating rules, and lifecycle controls needed to issue, manage, validate, renew, and revoke certificates.
The components that make PKI work
A document signing PKI normally includes several connected components:
- Public and private keys: The private key is kept under the control of its holder or a managed signing service. The corresponding public key can be shared so others can verify signatures created with the private key.
- Digital certificates: A digital certificate contains a public key and information about its subject, issuer, permitted uses, validity period, and other attributes.
- Certificate authority: A certificate authority, commonly called a CA, issues and digitally signs certificates. Its signature allows validation software to check that a certificate came from that authority and has not been altered.
- Registration and validation functions: A registration authority, CA, or approved service verifies information before a certificate is issued. The process may confirm control of an account, organizational authority, or an individual’s identity, depending on the certificate type and applicable policy.
- Certificate repositories and status services: These systems distribute certificates and provide information about certificates that have been revoked.
- Policies and operating procedures: Certificate policies define the rules for identity checks, key protection, certificate use, renewal, revocation, auditing, and other controls.
Some providers combine these functions, while others separate them among multiple organizations.
How a certificate creates a trust chain
A certificate does not become trustworthy merely because a CA signed it. Validation software must be able to connect it to a recognized trust anchor.
A typical chain contains:
- The signer’s certificate, sometimes called the end entity certificate.
- One or more intermediate CA certificates.
- A root CA certificate that the validating system explicitly trusts.
Each CA signs the certificate below it in the chain. Validation software checks those signatures until it reaches a trusted root. The root certificate is usually stored in an operating system, application, enterprise trust store, or another approved trust source.
A valid chain means the certificates connect correctly to a trusted root under the selected validation policy. It does not, by itself, guarantee that every statement in a certificate is accurate or that the signer used the key personally. Confidence still depends on the issuing authority’s verification procedures, key controls, and certificate policy.
What PKI does during document signing
Consider a company representative receiving a certificate for signing contracts. Before issuing it, the relevant authority performs the identity and authorization checks required by its policy. The certificate then binds the representative’s public key to the approved identity information.
When the representative signs a document, signing software calculates a hash, which acts as a compact fingerprint of the document. The private key is used to create a digital signature based on that hash. The certificate is included with, or made available for, the signed document.
When another person opens the document, compatible validation software can:
- Use the certificate’s public key to verify the digital signature.
- Recalculate the document hash to detect changes made after signing.
- Build and validate the certificate chain.
- Check whether the certificate was within its validity period.
- Confirm that the certificate permits the intended signing use.
- Consult available revocation information.
- Apply relevant certificate and validation policies.
If the document changes after signing, the calculated hash will no longer match the signed value. This supports document integrity by making later changes detectable.
Revocation, expiration, and signature timing
Certificates have limited validity periods, but they may also need to be invalidated early. A CA might revoke a certificate if its private key is compromised, its identifying information is no longer accurate, or the holder is no longer authorized to use it.
Revocation information is commonly distributed through certificate revocation lists or an online certificate status service. Validation results depend on whether current or historical status information is available and on the rules applied by the validating system.
Expiration and revocation do not always answer whether a signature was valid when it was created. A trusted timestamp and preserved validation data can help establish that a signature existed while the relevant certificate was valid. Long-term verification still depends on the signature format, retained evidence, available trust information, and applicable validation policy.
PKI compared with related signing concepts
| Concept | What it describes | Role in document signing |
|---|---|---|
| Public key infrastructure | The complete trust system, including keys, certificates, authorities, validation, revocation, and policies | Establishes and manages the framework used to verify certificate-based signatures |
| Digital certificate | A signed electronic credential that associates a public key with a subject | Supplies the public key and identity claims used during validation |
| Digital signature | A cryptographic result created using a private key | Helps verify document integrity and connection to the corresponding key |
| Electronic signature | A broad method of showing intent to sign electronically | May use a digital signature and PKI, but does not have to |
An electronic signature might be as simple as entering a name, selecting an acceptance box, or drawing a signature. PKI is relevant when a workflow uses certificate-based digital signatures and needs cryptographic verification.
What PKI does not prove on its own
PKI provides technical evidence, not absolute certainty. A successful validation can show that a signature corresponds to a private key associated with a certificate and that the signed data has not changed. It cannot automatically prove who physically operated the signing device, whether consent was freely given, or whether an agreement is enforceable.
Those questions may also depend on signer authentication, private key protection, intent, attribution evidence, record retention, contract requirements, and the law of the relevant jurisdiction.
Different PKI systems also provide different levels of assurance. A certificate issued after a basic account check should not be treated as equivalent to one issued following stronger identity verification and tightly controlled key management. Legal significance can vary by certificate type, signature category, transaction, and jurisdiction. This information is educational and is not legal advice.
FAQ
Is PKI required for every electronic signature?
No. Many electronic signatures do not use PKI. PKI is primarily associated with certificate-based digital signatures that support cryptographic verification.
Does PKI encrypt the signed document?
Not necessarily. Digital signing and encryption are separate functions. A document can be digitally signed without being encrypted, meaning its contents remain readable while changes can still be detected.
What is the difference between a CA and a registration authority?
A CA issues and signs certificates. A registration authority typically checks identity or authorization information before issuance. One organization may perform both roles.
Can a revoked certificate still verify an older signature?
Possibly, if reliable evidence shows that the signature existed before revocation and the applicable validation policy accepts that evidence. The result depends on timestamps, retained status information, certificate rules, and jurisdictional requirements.