COMP 6660 · Enterprise Cybersecurity Digital Signatures and PKI

00 Introduction

Lesson 2.3 introduced public-key cryptography and the key distribution problem it solves. This lesson addresses the question that remains: how does the enterprise know that a public key really belongs to the party it claims to belong to?

The answer is digital signatures and public key infrastructure. A digital signature binds a public key to an identity, and a certificate — the artefact produced by a certificate authority — is the enterprise-scale mechanism through which that binding is established, distributed, and verified. PKI is the trust infrastructure on which almost every modern secure communication depends: TLS, code signing, email security, VPN authentication, and federated identity all rely on certificates issued and managed through PKI.

This lesson examines digital signatures first — what they provide, how they work, and the schemes in common use. It then examines the trust problem that signatures alone do not solve, and the PKI that addresses it: certificates, certificate authorities, trust models, and the certificate lifecycle. It addresses revocation — the persistent practical problem of how to invalidate a certificate that has been compromised or is no longer trustworthy. It examines documented PKI failures and the lessons they carry. And it closes with the enterprise use of PKI, including internal certificate authorities and mutual TLS.

PKI is, in many respects, the least visible and most consequential component of enterprise cryptographic infrastructure. When PKI fails — through misissuance, compromise, or poor validation — the consequences propagate across every system that depends on the trust it was designed to provide.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 2 outcome U2.1 (cryptographic principles), and to Module 1 outcome M1.11 (PKI and digital trust). See the Unit 2 learning outcomes page for the full mapping.

02 Digital signatures

A digital signature is a cryptographic value that binds a message or document to the private key that produced it. It provides three properties simultaneously: integrity (the signed content has not been altered), authenticity (the signature was produced by the holder of the private key), and — with appropriate key management — non-repudiation (the signer cannot credibly deny having signed).

How signatures work

A digital signature is generated and verified through a well-defined process. The process is asymmetric in a specific way: anyone can verify a signature, but only the holder of the private key can produce one.

1. Signing (by the holder of the private key) Compute a hash of the message; apply a signature algorithm to the hash using the private key; produce the signature. The signature accompanies the message.
2. Distribution The signed message — message plus signature — is distributed. The signer's public key is made available to verifiers.
3. Verification (by any party holding the public key) Compute a hash of the received message; apply the verification algorithm to the signature using the public key; compare the result with the computed hash. If they match, the signature is valid.

The process relies on the asymmetric property of the algorithm: producing a signature requires the private key, but verifying it requires only the public key. This is what makes signatures useful at scale — a single signer can produce a signature that thousands of parties can verify without needing access to the private key.

What signatures do not provide

Digital signatures are frequently misunderstood, particularly regarding what they do and do not guarantee. A valid signature does not provide:

• Confidentiality. A signed message is not encrypted. Anyone can read the message; the signature verifies authenticity, not confidentiality.
• Assurance that the content is true. A signature verifies that a specific party signed a specific message. It does not verify that the message is accurate, honest, or meaningful.
• Non-repudiation by itself. Non-repudiation requires that the private key be protected so that the signer cannot claim the key was compromised. Without strong key protection, non-repudiation is claimed but not assured.
• Assurance that the public key belongs to the claimed party. This is the trust problem that PKI — Sections 3–7 — addresses.

03 Signature schemes

Three signature schemes dominate enterprise practice: RSA-PSS, ECDSA, and EdDSA. Each rests on different mathematical foundations and has different performance characteristics, key sizes, and implementation considerations.

Comparing signature schemes

Selection guidance

• For new deployments where support allows: Ed25519 is often preferred for its simplicity, security properties, and performance. It is the recommended choice in modern SSH and many new protocols.
• For TLS certificates: ECDSA with P-256 or P-384 is increasingly the default, supported by modern clients and providing smaller certificates and better performance than RSA.
• For compatibility with legacy systems: RSA-PSS with 3072 bits or larger remains appropriate where the ecosystem does not yet support ECC.
• For code signing: Ecosystem support varies. Choose based on what the signing platform and the verification environments support.

Common signature implementation pitfalls

• Nonce reuse in ECDSA. ECDSA requires a unique random value (the nonce) for each signature. Reusing the nonce across two signatures allows an attacker to recover the private key. This has produced several high-profile compromises. EdDSA avoids the issue by deriving the nonce deterministically.
• Weak randomness in key generation. Signing keys generated with inadequate randomness can be predictable or shared. This is a recurring source of compromise, particularly in embedded and IoT devices.
• Padding misuse in RSA. RSA signatures require proper padding (PSS for modern use). Without it, signatures can be forged through a range of attacks.
• Improper verification. Applications that fail to check signatures properly, accept invalid signatures, or skip verification for "trusted" sources introduce vulnerabilities regardless of the algorithm's strength.
• Signing the wrong thing. Signing a hash of the message rather than the message itself requires careful implementation to avoid collisions and length-extension attacks.

04 The trust problem

A signature verifies that the holder of a private key signed a message. It does not verify that the public key used for verification belongs to the party the signer claims to be.

This gap is the trust problem in public-key cryptography. Consider the scenario: an attacker generates a key pair, attaches their own public key to a message claiming to be from a bank, and signs the message with their private key. Verification succeeds — the signature is cryptographically valid. But the message is from the attacker, not the bank. The signature proves only that someone with some private key produced it; it does not prove who that someone is.

Why this problem exists

Public-key cryptography is built on mathematical operations over keys. There is nothing in the mathematics that binds a public key to a name, an organisation, a domain, or any real-world identity. The binding must be established by some external mechanism — an authority that vouches for the association.

Without such an authority, public-key cryptography is limited to scenarios where the parties already share a trusted channel — for example, where they exchange public keys in person or through a previously trusted channel. This is not scalable.

Three approaches to establishing trust

• Direct trust. Parties exchange public keys through a trusted channel, or verify them against a known value. This is the model of SSH known-hosts and of manual certificate fingerprint verification. It is secure but does not scale.
• Centralised trust. A trusted third party vouches for the association between a public key and an identity by signing a certificate. This is the model of public PKI — the certificate authority system that underpins TLS on the public web. It scales well but introduces dependence on the third party.
• Distributed trust. Multiple parties vouch for each other's keys, and trust is established through a network of relationships. This is the model of the PGP web of trust. It reduces centralised dependence but imposes higher usability and governance costs.

In enterprise environments, centralised trust dominates. Internal certificate authorities, public certificate authorities, and federated identity providers all operate on the principle that a trusted authority vouches for the association between a public key and an identity. The rest of this lesson examines how that model works, how it fails, and how it is deployed in practice.

05 Certificates

A digital certificate is a signed statement that binds a public key to an identity. It is the artefact through which a trusted authority vouches for the association, and it is the mechanism that makes centralised trust practical at scale.

The X.509 standard

Almost all certificates used in enterprise environments follow the X.509 standard. X.509 defines the structure of certificates, the fields they contain, and the conventions for issuing, validating, and revoking them. It has been extended over decades, and the standard has variants (X.509 v1, v2, v3), but modern certificates use the v3 format.

Certificate structure

An X.509 certificate contains several fields. The most important are:

What certificates are used for

Certificates are used in a wide range of enterprise contexts. The type of certificate reflects the purpose it is intended to serve.

• TLS server certificates. Bind a domain name to a public key, enabling clients to verify they are connecting to the correct server. This is the most visible use of certificates.
• TLS client certificates. Bind a client identity to a public key, enabling mutual authentication — the server verifies the client, as the client verifies the server.
• Code signing certificates. Bind a publisher identity to a public key, enabling verification of the origin and integrity of software.
• Email certificates (S/MIME). Bind an email address to a public key, enabling signing and encryption of email.
• Document signing certificates. Bind a signer identity to a public key for legal or regulatory purposes, often subject to specific standards and requirements.
• Device certificates. Bind a device identity to a public key, used in mutual TLS for machine-to-machine communication and in IoT deployments.
• Certificate authority certificates. Bind the identity of a CA to a public key, and are used to sign other certificates — including intermediate CA certificates and end-entity certificates.

The certificate chain

In most deployments, certificates form a chain. A root certificate — self-signed, and distributed as a trust anchor — signs an intermediate certificate, which in turn signs an end-entity certificate (the certificate presented by a server, a client, or a signer). When a verifier validates an end-entity certificate, it verifies the signatures along the chain up to a trusted root.

The use of intermediate certificate authorities provides a separation between the root (which is trusted absolutely and rarely used) and the operational signing of certificates (which happens frequently and must be managed carefully). If an intermediate CA is compromised, the root can revoke it without invalidating every certificate the root has ever issued.

06 Certificate authorities

A certificate authority (CA) is the entity that issues, signs, and manages certificates. It is the trust anchor of centralised PKI — the party whose signature on a certificate vouches for the association between a public key and an identity.

What a certificate authority does

A CA performs several functions, each with its own security and governance implications:

• Identity verification. Before issuing a certificate, the CA verifies that the applicant is entitled to the identity they claim. Different types of certificates require different levels of verification, from a simple domain-control check to extensive organisational review.
• Certificate issuance. The CA produces and signs the certificate, binding the applicant's public key to the verified identity.
• Certificate lifecycle management. The CA manages renewal, and provides mechanisms for revocation when a certificate is compromised or no longer valid.
• Trust anchor operation. The CA's own certificates are distributed as trust anchors — the starting points for verifying certificate chains. This is the most consequential aspect of the CA's role, because compromise of the CA's signing keys compromises every certificate the CA has issued or will issue.

Public versus private certificate authorities

In enterprise environments, two types of certificate authorities are relevant:

Certificate policies and the CA/Browser Forum

Public certificate authorities are subject to oversight by the CA/Browser Forum, a consortium of CAs and browser vendors that defines baseline requirements for publicly trusted certificates. The requirements cover verification practices, certificate contents, maximum validity periods, and technical standards. Browsers and other trust store operators enforce compliance through audits and, when necessary, by removing non-compliant CAs from their trust stores.

Enterprise CAs are not subject to the CA/Browser Forum's baseline requirements, because their certificates are not publicly trusted. Enterprises establish their own policies, sometimes aligned with the CA/B requirements or with internal standards. The absence of external oversight means the enterprise is solely responsible for the quality of its internal PKI practices.

Trust anchors and root certificates

The root certificate of a CA is the trust anchor of the PKI it operates. Root certificates are self-signed — they are signed by the CA's own root private key — and are distributed through operating system trust stores, browser trust stores, or enterprise configuration management. Every certificate the CA issues derives its trustworthiness, ultimately, from the trust placed in this root.

Because the root certificate is the most consequential component of the PKI, its private key is protected with the most rigorous controls. In best practice, the root private key is kept offline in a hardware security module, never used for day-to-day operations, and accessed only for the rare issuance or revocation of intermediate CA certificates.

07 Trust models

A trust model defines how trust in a public key is established, how trust propagates through a certificate chain, and what happens when the trust is broken. Three trust models are relevant to enterprise environments.

Hierarchical trust (public PKI)

The dominant trust model in public PKI is hierarchical. A root CA sits at the top of the trust hierarchy; intermediate CAs are subordinated to the root; end-entity certificates are issued by intermediate CAs. Trust propagates down the hierarchy — a certificate is trusted if it chains to a trusted root.

This model scales well because trust anchors are distributed with operating systems and browsers, and any certificate chaining to a trusted root is automatically trusted. Its weakness is centralisation: compromise of a root CA compromises every certificate the CA issues, and every system that trusts that CA is affected.

Bridge and mesh trust

Some environments — particularly in government, defence, and federated enterprise contexts — use bridge or mesh trust models. In a bridge model, multiple hierarchies are linked through a bridge CA that cross-signs intermediate CAs from different hierarchies. In a mesh model, CAs cross-sign each other directly.

These models accommodate federated trust across organisational boundaries. They introduce additional complexity and additional trust relationships that must be governed. Cross-signing means each CA in the mesh inherits the trust of the others — and therefore the consequences of any of them being compromised.

Web of trust (decentralised)

The web of trust — most associated with PGP — is a decentralised model in which trust is established through individual relationships. Parties sign each other's public keys to vouch for the association between key and identity. Trust propagates through the network of signatures, and each party determines for themselves which signatures they accept as sufficient.

The web of trust is elegant in principle and difficult in practice. Establishing sufficient trust in a key requires navigating a complex network of relationships, and adoption has been limited outside specific communities. It is mentioned here because it illustrates an alternative model — one that does not rely on centralised trust anchors — and because federated identity systems sometimes incorporate elements of it.

Trust model selection in the enterprise

08 The certificate lifecycle

Certificates are not static. They are requested, issued, used, renewed, and eventually revoked or allowed to expire. Managing this lifecycle is one of the most operationally intensive aspects of PKI, and one where enterprise failures recur.

Certificate validity periods

The validity period of a certificate has shortened substantially over the past decade. Public TLS certificates were once issued with multi-year validity; they are now limited to a maximum of 398 days (about 13 months), and this is expected to reduce further over time. The reasons are:

• Limiting exposure from compromise. A certificate issued for a shorter period reduces the window during which a compromised key can be used.
• Improving revocation reliability. Frequent reissuance means that revocation is less critical — a compromised certificate will expire soon in any case.
• Forcing automation. Short validity periods make manual renewal impractical, encouraging adoption of automated certificate management (ACME and similar protocols).

The shortening of validity periods has significant operational implications for enterprises. Manual certificate management is no longer viable at scale; enterprises must invest in automation, inventory, and monitoring.

Certificate management at enterprise scale

Large enterprises may have thousands or tens of thousands of certificates in use across web servers, APIs, internal services, devices, and applications. Managing this portfolio involves:

• Inventory. A complete, current register of every certificate in use, its owner, its location, and its expiry date.
• Monitoring. Alerting on certificates approaching expiry, on unexpected certificates, and on validation failures.
• Automation. Automated renewal and deployment, typically using ACME or internal tooling, to avoid manual processes at scale.
• Governance. Clear ownership for each certificate, defined practices for issuance and renewal, and accountability for failures.
• Revocation management. Processes for revoking certificates promptly when a key is compromised or a system is decommissioned.

09 Revocation

Revocation is the mechanism through which a certificate is invalidated before its natural expiry. It is required when a private key is compromised, when a certificate was misissued, when a system is decommissioned, or when a relying party should no longer trust the certificate. It is also, in practice, one of the weakest parts of the PKI system.

Why revocation is hard

Revocation is difficult because it requires that every relying party know about the revocation in a timely manner. A certificate that has been revoked but is still presented to and accepted by relying parties is no more useful than a certificate that was never revoked. Ensuring that relying parties check revocation status, and that the status information is current and reliable, has proven technically and operationally challenging.

Revocation mechanisms

The soft-fail problem

Most clients and applications, when they cannot reach a revocation service, default to accepting the certificate rather than rejecting it. This behaviour — soft-fail — is a pragmatic response to the unreliability of revocation services, but it means revocation is only effective if the relying party can reach the revocation service. An attacker who can prevent the relying party from reaching the revocation service — through network manipulation, denial of service, or exploitation of connectivity failures — can effectively bypass revocation.

Soft-fail behaviour is the primary reason that revocation has proven unreliable in practice. It is also the reason that short-lived certificates are increasingly favoured: if revocation cannot be relied on, the best defence is to limit the window in which a compromised certificate is useful.

Certificate Transparency

Certificate Transparency (CT) is a response to misissuance. CAs publish every certificate they issue into public, append-only logs that are cryptographically protected against modification. Domain owners, security researchers, and monitoring services can observe the logs and detect certificates that should not exist — misissuance for a domain the CA was not authorised to certify, or certificates issued without the domain owner's knowledge.

CT has become a baseline requirement for publicly trusted certificates. Browsers now require CT for certificates issued by public CAs, and the logs provide a durable record of what was issued and when. For enterprises, CT provides a monitoring capability: unexpected certificates for the enterprise's domains can be detected and investigated.

10 PKI failures and lessons

PKI is a mature technology, but it has produced notable failures. These failures are instructive because they illustrate the ways PKI can go wrong — not in the mathematics, but in the governance, operations, and trust-management practices that surround it.

Failure 1 — CA compromise (DigiNotar, 2011)

DigiNotar, a Dutch certificate authority, was compromised by attackers who issued fraudulent certificates for high-profile domains — including major webmail providers — and used them to conduct man-in-the-middle attacks against Iranian users. The compromise was discovered through Certificate Transparency-like monitoring (before CT was formalised) and through user reports of certificate errors.

The consequences were severe: the CA was removed from browser trust stores, every certificate it had issued became untrusted, and the CA filed for bankruptcy. The case demonstrated that compromise of a CA affects not only the CA but also every certificate it has ever issued and every customer that depends on its certificates.

Lessons: CA compromise has enterprise-wide and ecosystem-wide consequences. Certificate Transparency and monitoring can detect misissuance. CAs must be subjected to rigorous oversight, and the removal of a CA from trust stores must be possible without requiring changes to every client.

Failure 2 — Weak randomness in key generation

Several incidents have involved cryptographic keys generated with inadequate randomness. An early and instructive case involved Debian's OpenSSL package, which for a period generated keys with substantially reduced entropy due to a code change intended to silence a warning. The result was that affected keys could be brute-forced, and every key generated by affected systems was compromised.

Lessons: Random number generation is critical and under-appreciated. Code changes to cryptographic libraries can have catastrophic and non-obvious consequences. Libraries used in cryptographic operations must be vetted carefully, and changes to them must be reviewed with the same rigour as changes to the algorithms themselves.

Failure 3 — Misissuance and trust store removal

Several CAs have been removed from browser trust stores — or had trust restrictions imposed — following misissuance: issuing certificates for domains the CA was not authorised to certify, issuing certificates to parties with insufficient verification, or failing to follow required practices. The consequences for the CA have been severe, and the consequences for customers have been significant.

Lessons: Verification practices matter. A CA that issues certificates without proper validation undermines the trust placed in the entire system. Certificate Transparency provides a means of detecting misissuance after the fact, but prevention requires that CAs apply rigorous practices to every certificate they issue.

Failure 4 — Improper certificate validation

Perhaps the most consequential PKI failure is not in the PKI itself but in the applications that rely on it. Applications that fail to validate certificates properly — accepting any certificate, ignoring hostname mismatches, failing to check the chain, or skipping revocation checks — undermine the security that PKI provides. These failures have been found in many applications, libraries, and mobile apps, and have enabled man-in-the-middle attacks that should have been prevented.

Lessons: PKI security depends as much on the relying party as on the certificate. Applications must validate certificates rigorously, and developers must use cryptographic libraries correctly. Disabling validation "for testing" or "for convenience" introduces vulnerabilities that persist into production.

Failure 5 — Certificate expiry and operational neglect

The most common PKI failure is not dramatic: certificates expire because renewal was not managed, and services become unavailable. This is a failure of operations rather than of cryptography, but its consequences for the enterprise can be substantial — service outages, customer impact, and reputational damage.

Lessons: Certificate lifecycle management is an operational discipline. Inventory, monitoring, and automation are essential. Manual processes do not scale and do not survive staff turnover.

11 Enterprise PKI

Beyond the public PKI that secures web traffic, enterprises operate their own certificate authorities for internal purposes. Enterprise PKI serves several functions that public PKI cannot, and presents its own governance and operational challenges.

Uses of enterprise PKI

Designing an enterprise CA

Enterprise PKI deployments follow the same principles as public PKI but with the enterprise as the trust anchor. Common design choices include:

• Offline root, online intermediate. The root CA is kept offline, accessed only to sign intermediate CA certificates. Intermediates operate online and issue end-entity certificates. This pattern reduces exposure of the highest-trust component.
• Hardware security modules. CA private keys are stored in HSMs to protect against extraction and misuse.
• Separate CAs for separate purposes. Some enterprises operate separate CAs for user certificates, device certificates, code signing, and server certificates — limiting the consequences of any single CA being compromised.
• Documented certificate policies. Certificate policies define what the CA will certify, how it validates requests, and what relying parties can assume. These policies are the enterprise's contract with itself about the meaning of its certificates.
• Integration with lifecycle management. Enterprise PKI is integrated with identity management, device management, and configuration management, so that certificate issuance and revocation happen automatically as identities and devices change.

Enterprise PKI governance

The security of an enterprise PKI depends as much on governance as on cryptography. Key governance questions include:

• Who decides what the enterprise CA will certify? A CA that will issue certificates for anything is a CA whose trust has no boundaries.
• Who approves the issuance of new CA certificates? The creation of a new intermediate CA is a significant trust decision and should have appropriate approval.
• How are CA keys protected? Physical security, HSMs, separation of duties, and audit logging.
• How are CA operations monitored? Issuance logs, anomaly detection, and periodic review of what has been issued.
• How would the enterprise respond to a CA compromise? Revocation of the compromised CA, reissuance of certificates, and communication with relying parties.
• How are relying parties managed? Distribution of CA certificates, configuration of trust stores, and monitoring of validation failures.

12 Key concepts

The terms below are used throughout the course. Capture them in your own words as you work through the lesson.

Digital signature

A cryptographic value produced with a private key and verified with the corresponding public key. Provides integrity, authenticity, and — with appropriate key management — non-repudiation.

Signature scheme

A specific algorithm for producing and verifying digital signatures. Common schemes include RSA-PSS, ECDSA, and EdDSA.

RSA-PSS

RSA signatures using the Probabilistic Signature Scheme padding. Replaces the older PKCS#1 v1.5 padding for new deployments.

ECDSA

Elliptic-Curve Digital Signature Algorithm. The dominant ECC-based signature scheme; used in TLS, SSH, and code signing. Vulnerable to private key recovery if the random nonce is reused.

EdDSA / Ed25519

Edwards-curve Digital Signature Algorithm, typically with Curve25519. Designed for security, simplicity, and performance; avoids several common pitfalls present in ECDSA implementations.

Certificate

A digitally signed statement that binds a public key to an identity. Typically follows the X.509 standard. The artefact through which a certificate authority vouches for the association between a key and an identity.

X.509

The standard that defines the structure of digital certificates, including fields such as issuer, subject, validity period, public key, extensions, and signature.

Certificate authority (CA)

The entity that issues, signs, and manages certificates. The trust anchor of centralised PKI. May be public (trusted by general-purpose trust stores) or private (trusted only within the enterprise).

Root certificate

A self-signed certificate representing the CA's identity. Distributed as a trust anchor. Its private key is protected with the most rigorous controls because compromise affects every certificate the CA has issued or will issue.

Intermediate certificate

A certificate issued by a root CA to another CA, which in turn issues end-entity certificates. Enables the root to remain offline while certificate issuance happens through intermediates.

Certificate chain

The sequence of certificates from an end-entity certificate up to a trusted root, used to verify that a certificate was issued by a trusted authority.

Trust anchor

A root certificate that the relying party trusts unconditionally. The starting point for verifying a certificate chain. Trust in the anchor is the foundation on which all other trust in the PKI rests.

Trust model

The structure through which trust in a public key is established and propagated. Common models include hierarchical (public PKI), bridge or mesh (federated), and web of trust (decentralised).

Certificate lifecycle

The stages through which a certificate passes: request and validation, issuance, deployment, use and verification, renewal, and revocation or expiry.

Revocation

The process of invalidating a certificate before its natural expiry, when the private key is compromised, when the certificate was misissued, or when it is no longer needed.

CRL (Certificate Revocation List)

A signed list of revoked certificates published by a CA. Relying parties download the list and check whether a certificate appears on it.

OCSP (Online Certificate Status Protocol)

A protocol for querying the revocation status of a specific certificate in real time. OCSP stapling embeds the response in the server's handshake to reduce latency and privacy concerns.

Soft-fail

The behaviour of accepting a certificate when the revocation status cannot be determined — because the revocation service is unreachable or slow. The primary reason revocation has proven unreliable in practice.

Certificate Transparency (CT)

A system in which certificates are published in public, append-only logs, allowing misissuance to be detected after the fact. Now a baseline requirement for publicly trusted certificates.

Mutual TLS (mTLS)

A TLS configuration in which both client and server present certificates and authenticate each other. Used for machine-to-machine communication and in zero-trust architectures.

Certificate policy

A document defining what a CA will certify, how it validates requests, and what relying parties can assume. The enterprise's statement of what its certificates mean.

13 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 1. They are not graded, but completing them will improve the quality of your forum contribution.

14 Self-check

Answer the questions below before moving to Lesson 2.5. If you cannot answer a question confidently, revisit the corresponding section.

15 Summary

This lesson has examined digital signatures and the public key infrastructure that makes them useful at scale. The essential points are:

• Digital signatures provide integrity, authenticity, and — with appropriate key management — non-repudiation. They do not provide confidentiality. Signatures verify that a specific party signed a specific message; they do not verify that the message is true or that the public key belongs to the claimed party.
• Three signature schemes dominate enterprise practice. RSA-PSS for compatibility, ECDSA for modern TLS and code signing, and EdDSA (Ed25519) for new deployments where support allows. Each has distinctive strengths and pitfalls; ECDSA nonce reuse is the most dangerous.
• The trust problem is that public-key cryptography does not bind keys to identities. A signature verifies that someone with some private key signed a message, but not who that someone is. Certificates solve this by binding keys to identities through a trusted third party.
• Certificates and certificate authorities are the mechanism of centralised trust. X.509 certificates contain a subject, a public key, a validity period, extensions, and a signature from the issuing CA. The CA is the trust anchor of the PKI.
• Trust models determine where failures propagate. The hierarchical model dominates public and enterprise PKI; bridge and mesh models accommodate federated trust; the web of trust offers decentralised alternatives.
• The certificate lifecycle is operationally intensive. Request, issuance, deployment, use, renewal, and revocation. Validity periods have shortened substantially, making automation and inventory essential.
• Revocation has proven unreliable in practice. Soft-fail behaviour, distribution challenges, and privacy concerns limit its effectiveness. Short-lived certificates are increasingly preferred as a practical alternative.
• Documented PKI failures carry important lessons. CA compromise, weak randomness, misissuance, improper certificate validation, and certificate expiry. Most PKI failures are governance and operational, not cryptographic.
• Enterprise PKI serves internal purposes that public PKI cannot. Internal TLS, mutual TLS, device identity, user authentication, code signing, and document signing. Enterprise PKI is a governance exercise as much as a technical one.

These ideas prepare for Lesson 2.5, which examines identity and access management — the enterprise discipline through which the cryptographic infrastructure studied so far becomes the foundation for how enterprises manage identity and control access to their systems.