What Is a Key Goal of a Public Key Infrastructure (PKI)?

A key goal of public key infrastructure (PKI) is to establish a verifiable, trusted association between a public key and a specific user, website, device, or service identity.

In other words, PKI does more than help a system obtain a public key. More importantly, it helps the system answer the question: Who actually owns this public key?

Once this trusted binding has been established, users and systems can safely use the public key for authentication, digital signature verification, key establishment, and encrypted communication.

The UK National Cyber Security Centre describes PKI as a trust service used to confirm identity. By verifying that an entity possesses the corresponding private key, a system can determine whether the communicating party is genuinely the identity it claims to be.

Why Must a Public Key Be Bound to an Identity?

A public key can be shared openly, but “public” does not mean “trusted.”

Suppose a server claims to be a company’s payment API and sends a public key to a client. The client can use that key to encrypt information or verify signatures, but the key alone does not prove that it actually belongs to the company.

An attacker could also generate a key pair, send the attacker-controlled public key to the client, and claim that it belongs to the intended server. The attacker might then attempt to intercept communications or impersonate the legitimate service.

One of the central challenges of public key cryptography is therefore not how to generate keys, but how to confirm the real owner of a public key securely and reliably.

PKI addresses this problem through digital certificates and certificate-based trust. A digital certificate associates a verified identity with a public key, validity period, permitted key uses, and the digital signature of the issuing authority. This allows clients to determine whether a public key genuinely belongs to the entity it claims to represent.

What Does a “Trusted Binding” Mean?

A trusted association between an identity and a public key should answer four questions:

• Who is the identity? It may be a domain, employee, server, mobile device, or application.
• What is the public key? This is the cryptographic key that the certificate holder makes available to others.
• Who verified the relationship? This is usually a trusted certificate authority.
• Is the relationship still valid? The certificate’s validity period, revocation status, and permitted uses must be checked.

A trusted binding is not permanent. If a certificate expires, a device is retired, an identity changes, or a private key is compromised, the PKI must be able to update or revoke the original trust relationship.

How Does PKI Achieve This Goal?

Step 1: Generate a Key Pair

A user, server, or device generates a mathematically related public-private key pair.

The public key can be included in a certificate and distributed openly. The private key must remain secret and should generally not be sent to the certificate authority.

Step 2: Verify the Applicant’s Identity

A certificate authority or registration authority verifies the identity of the applicant. The verification method depends on the use case. For example:

• Website certificates verify control of a domain.
• Employee certificates verify identity against corporate records.
• Device certificates verify registration and provisioning information.
• Service certificates verify an application or workload identity.

If a certificate is issued to the wrong entity during this stage, the resulting trust relationship is invalid even if all the cryptographic algorithms work correctly.

Step 3: Issue a Digital Certificate

After verifying the identity, the certificate authority signs a digital certificate with its private key. The certificate normally includes:

• The certificate holder’s identity
• The holder’s public key
• The issuing authority
• Start and expiration dates
• Permitted key uses
• A certificate serial number
• The certificate authority’s digital signature

X.509 certificates and certificate validation paths commonly used on the internet are specified in RFC 5280.

Step 4: Validate the Certificate and Proof of Private-Key Possession

After receiving a certificate, a client checks its signature, identity, validity period, permitted uses, certificate chain, and revocation status.

The communicating party generally must also use the corresponding private key during a signature or handshake operation. This proves that it controls the private key associated with the public key in the certificate.

An entity that presents a valid certificate but cannot prove possession of the corresponding private key should not be treated as the legitimate certificate holder.

Step 5: Maintain or Revoke Trust

The identity relationship established by a certificate has a lifecycle.

If a device is lost, an employee leaves, a private key is compromised, or a certificate is issued incorrectly, administrators must revoke the certificate or otherwise stop trusting the identity. Certificates approaching expiration must be renewed, and a new key pair may also be required.

PKI therefore aims not only to establish trust but also to terminate that trust promptly when circumstances change.

Is the Key Goal of PKI Simply to Encrypt Data?

Treating data encryption as the only or primary goal of PKI is inaccurate.

The core function of PKI is to manage digital identities, public keys, and certificate trust. Once a trusted public key has been established, other protocols and applications can use it to provide specific security capabilities.

Security Capability	How PKI Supports It
Authentication	Associates a public key with a website, user, device, or service identity
Confidentiality	Provides trusted public keys for encryption or key establishment
Integrity	Supports verification of digital signatures created with corresponding private keys
Source verification	Helps identify the source of a message, application, or document
Access control	Provides verified machine or user identities to authorization systems
Trust revocation	Terminates trust when a certificate or private key is no longer secure

In HTTPS, for example, PKI and digital certificates are primarily used to authenticate the server. TLS then establishes session keys and uses symmetric encryption to protect the actual communication.

PKI establishes a trusted foundation for secure communication, but it does not normally perform all data encryption by itself.

Does PKI Mean Complete Trust?

PKI verifies whether a public key belongs to the user, website, device, or service named in a certificate. It can confirm a digital identity, but it cannot guarantee that the identity is trustworthy in every respect or that its behavior is safe.

PKI cannot automatically determine:

• Whether a website operator is committing fraud
• Whether an application contains security vulnerabilities
• Whether an employee is authorized to perform a particular business action
• Whether a device has been infected with malware
• Whether a server is processing the correct transaction
• Whether a user with a valid certificate will abuse their privileges

For this reason, authentication and authorization are separate security processes.

PKI helps answer “Who are you?” and “Do you possess the corresponding private key?” An authorization system answers “What are you allowed to do?”

Even when a server passes certificate validation, the business system must still determine whether it may access specific data, call administrative APIs, or initiate high-risk transactions.

Do Public and Private PKI Have the Same Goal?

Both public and private PKI establish trusted associations between identities and public keys, but they operate in different environments.

Public PKI primarily serves the internet. Website certificates issued by public certificate authorities can be validated by mainstream browsers and operating systems.

Private PKI serves an organization or a defined partner network and is commonly used for:

• Employee and enterprise device authentication
• Internal websites and applications
• Virtual private networks
• Corporate wireless networks
• Microservices and workloads
• Databases and messaging systems
• Internet of Things devices
• Internal APIs and mutual TLS

Public PKI trust roots are typically included in browser and operating system trust stores. Private PKI root certificates must be securely distributed and managed by the organization.

Why Is Certificate Lifecycle Management Part of the PKI Goal?

A certificate that was correct when issued may not remain trustworthy throughout its validity period.

A certificate may lose its trustworthiness because:

• Its private key is stolen or accidentally exposed.
• The associated device is lost or retired.
• An employee leaves the organization.
• Ownership of a domain or server changes.
• The certificate contains incorrect information.
• A CA private key is compromised.
• The algorithm or key length no longer meets security requirements.

Organizations need a certificate inventory and processes for application, approval, issuance, installation, renewal, rotation, revocation, and removal.

If an organization does not know where a certificate is installed, it may be unable to replace it quickly after a private-key compromise. An unexpected expiration could also interrupt a website, API, or internal service.

What Are the Practical Uses of PKI in Network Security?

HTTPS

A browser uses a certificate to confirm that the public key it receives belongs to the intended domain rather than an impersonating server.

Mutual TLS

The client and server present certificates and authenticate each other. Mutual TLS is commonly used for internal APIs, microservices, and machine-to-machine communication.

Enterprise Device Authentication

An organization can issue certificates to laptops, mobile phones, networking equipment, and other endpoints, allowing only registered devices to connect to internal networks.

Virtual Private Networks

VPN gateways and clients can authenticate with certificates, reducing risks associated with exposed or copied shared passwords.

Code and Document Signing

A publisher creates a digital signature with a private key. Recipients use the public key in the certificate to verify the source and integrity of the software or document.

How Is PKI Used in Institutional Wallet Infrastructure?

Servers, message relays, signing terminals, and MPC nodes in institutional wallet infrastructure must verify the identities of the systems with which they communicate.

A private PKI can issue separate certificates to these components and use mutual TLS to restrict connections to authorized nodes. In this environment, the goal of PKI remains the same: establishing a trusted association between each node’s identity and communication public key.

However, PKI keys and blockchain wallet keys have different responsibilities:

• PKI certificates and private keys authenticate servers or nodes.
• Wallet private keys or MPC key shares authorize blockchain transactions.

Possessing a node certificate should not automatically grant asset-signing authority. Likewise, controlling a wallet key share should not grant certificate-issuing privileges. The two key systems, their permissions, and their recovery procedures should be managed separately.

Frequently Asked Questions

What is a key goal of a public key infrastructure (PKI)?

A key goal of PKI is to establish a verifiable association between a public key and a specific identity, such as a user, website, device, or service.

Is the primary goal of PKI to distribute public keys?

Secure and scalable public-key distribution is an important goal of PKI, but each distributed key must also be associated with a verified identity. Otherwise, a client cannot determine whether the public key came from the correct entity.

Can PKI prevent man-in-the-middle attacks?

PKI can reduce the risk of an attacker replacing a public key or impersonating a server, provided that certificate validation, trust-store management, private-key protection, and domain verification are implemented correctly.

Does a valid digital certificate mean an identity remains trustworthy forever?

No. Clients must still check the certificate’s validity period, permitted uses, and revocation status. A certificate may no longer be trustworthy after a private-key compromise or a change in identity conditions.

Is PKI the same as access control?

No. PKI primarily helps systems authenticate identities and public keys. Access control determines what an authenticated identity is permitted to do.

Conclusion

A key goal of PKI is to bind a public key reliably to the identity of a user, website, device, or service. Through digital certificates, PKI supports identity verification for HTTPS, VPNs, device authentication, and digital signatures.

In institutional wallet infrastructure, PKI can authenticate servers and MPC nodes, but wallet signing keys and transaction permissions must still be managed separately.