Public Key Infrastructure PKI: Cryptography Deep Dive

1. Introduction and Core Concepts

Public Key Infrastructure (PKI) is the foundational framework that enables secure communication, authentication, and data integrity on untrusted networks like the internet. At its core, public key infrastructure pki is not a single algorithm or product, but a comprehensive system of hardware, software, policies, and procedures required to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption. Without PKI, the modern web as we know it — from HTTPS and e-commerce to code signing and secure email — would be impossible.

The need for PKI arises from a fundamental problem in cryptography: how do you securely distribute keys? Symmetric cryptography requires both parties to share a secret key in advance, which is impractical at internet scale. Asymmetric or public-key cryptography solved this by using mathematically linked key pairs — a public key that can be freely shared and a private key that must be kept secret. However, this introduced a new problem: how do you know that a given public key actually belongs to the entity it claims to belong to? An attacker could easily publish a public key claiming to be your bank. PKI solves this identity binding problem through trusted third parties and verifiable credentials.

The core components of any public key infrastructure pki include: Key Pairs (asymmetric keys, typically RSA or Elliptic Curve Cryptography), Digital Certificates (X.509 documents that bind a public key to an identity), Certificate Authorities (CAs) that issue and vouch for certificates, Registration Authorities (RAs) that verify identities before issuance, Certificate Repositories and Distribution Points, and Revocation Mechanisms such as Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). Together, these components create a chain of trust that allows strangers to establish secure communication without prior contact.

Why PKI Matters

PKI provides four critical security services: Authentication (proving who you are), Confidentiality (encrypting data so only the intended recipient can read it), Integrity (ensuring data has not been altered in transit), and Non-repudiation (preventing an entity from denying an action it performed, via digital signatures). These services are essential for regulatory compliance, zero-trust architectures, and establishing trust in distributed systems.

In essence, PKI transforms an untrusted network into a trusted ecosystem. When your browser shows a padlock icon, when you install a signed software update, or when your company laptop authenticates to a corporate VPN, you are relying on PKI to have already validated the identity of the other party and to have provided the cryptographic material needed for a secure exchange.

2. How It Works

The operation of public key infrastructure pki can be understood as a lifecycle with several distinct phases: key generation, certificate enrollment and issuance, validation, usage, and revocation. Each phase is governed by strict policies defined in a Certificate Policy (CP) and Certification Practice Statement (CPS).

Everything begins with asymmetric key generation. An end-entity (such as a web server, a user, or an IoT device) generates a key pair. The private key never leaves the secure storage of the entity — ideally a Hardware Security Module (HSM) or Trusted Platform Module (TPM). The public key is then placed into a Certificate Signing Request (CSR), which also contains identity information like the Common Name (CN), Organization (O), and Subject Alternative Names (SANs). The CSR is signed with the entity's private key to prove possession.

The CSR is sent to a Registration Authority, which performs identity vetting. For a Domain Validated (DV) certificate, this might be an automated check of DNS records. For Extended Validation (EV), it involves rigorous legal and physical verification. Once verified, the CA takes the public key and identity information, adds validity periods, serial number, issuer name, extensions (like Key Usage and Basic Constraints), and signs the entire structure with the CA's own private key. This signature is what makes the certificate trustworthy — anyone who trusts the CA can verify its signature using the CA's public key. This issued X.509 certificate is then installed on the end-entity.

The Chain of Trust and Validation

Trust in PKI is hierarchical. At the top is a Root CA, a highly secured, offline entity whose self-signed certificate is pre-installed in trust stores (browsers, operating systems). Root CAs rarely sign end-entity certificates directly; instead, they sign Intermediate CAs, which in turn sign end-entity certificates. This creates a certificate chain: End-Entity -> Intermediate CA -> Root CA. This hierarchy limits exposure — if an intermediate is compromised, it can be revoked without distrusting the entire root.

When a client (like a browser) connects to a server, the server presents its certificate chain. The client performs path validation: it verifies the signature on each certificate in the chain, checks that each certificate is within its validity period (NotBefore and NotAfter), verifies that the issuer of each certificate matches the subject of its parent, checks revocation status via CRL or OCSP, and ensures the chain terminates at a trusted root anchor. Only if all checks pass is the connection considered trusted, after which the public key in the leaf certificate is used to establish a symmetric session key via a protocol like TLS.

Revocation: Handling Compromise

Certificates have long lifetimes (typically 90 days to 1 year), but private keys can be compromised, or an employee may leave a company. PKI must handle revocation. The two primary mechanisms are CRLs — periodically published, signed lists of all revoked serial numbers — and OCSP, a real-time protocol where a client queries an OCSP responder for the status of a single certificate. Modern enhancements like OCSP Stapling allow the server to provide a time-stamped OCSP response during the TLS handshake, improving privacy and performance.

3. Implementation

While production PKI relies on robust libraries like OpenSSL, BoringSSL, or cloud KMS services, understanding the underlying cryptographic primitives is essential. The following Python examples use the cryptography library to demonstrate core PKI operations. These are simplified for educational purposes and abstract away the complexity of ASN.1 parsing and X.509 encoding.

The first example demonstrates RSA key pair generation and the creation of a self-signed certificate, which mimics what a Root CA does when it initializes its trust anchor. Note the importance of secure key sizes and proper extensions.

from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import hashes, serialization
from cryptography import x509
from cryptography.x509.oid import NameOID
import datetime

# 1. Generate RSA Key Pair for a Root CA (2048-bit minimum, 4096 recommended)
# Private key must be kept secure, ideally in an HSM
private_key = rsa.generate_private_key(
    public_exponent=65537,
    key_size=2048  # For production, use 4096 for Root CAs
)
public_key = private_key.public_key()

# 2. Create a self-signed X.509 certificate
subject = issuer = x509.Name([
    x509.NameAttribute(NameOID.COMMON_NAME, u"Example Root CA"),
    x509.NameAttribute(NameOID.ORGANIZATION_NAME, u"FlyFishNWA Corp"),
    x509.NameAttribute(NameOID.COUNTRY_NAME, u"US"),
])

cert = x509.CertificateBuilder().subject_name(
    subject
).issuer_name(
    issuer
).public_key(
    public_key
).serial_number(
    x509.random_serial_number()
).not_valid_before(
    datetime.datetime.utcnow()
).not_valid_after(
    # Valid for 10 years for a Root CA
    datetime.datetime.utcnow() + datetime.timedelta(days=3650)
).add_extension(
    x509.BasicConstraints(ca=True, path_length=None), critical=True,
).add_extension(
    x509.KeyUsage(
        digital_signature=True, key_cert_sign=True, crl_sign=True,
        content_commitment=False, key_encipherment=False,
        data_encipherment=False, key_agreement=False, encipher_only=False, decipher_only=False
    ), critical=True
).sign(private_key, hashes.SHA256())

# Serialize for distribution
pem_cert = cert.public_bytes(serialization.Encoding.PEM)
pem_key = private_key.private_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PrivateFormat.TraditionalOpenSSL,
    encryption_algorithm=serialization.BestAvailableEncryption(b"strong-password")
)
print(pem_cert.decode())

The next example shows how an Intermediate CA is signed by the Root CA, and how an end-entity certificate is issued. This demonstrates the chaining that is central to public key infrastructure pki.

from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes

# Assume root_private_key and root_cert are loaded from previous example
# Generate Intermediate CA key pair
intermediate_private = rsa.generate_private_key(public_exponent=65537, key_size=2048)
intermediate_public = intermediate_private.public_key()

# Build Intermediate CSR / Certificate signed by Root
intermediate_cert = x509.CertificateBuilder().subject_name(
    x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, u"Example Intermediate CA")])
).issuer_name(
    root_cert.subject  # Issuer is the Root CA
).public_key(
    intermediate_public
).serial_number(
    x509.random_serial_number()
).not_valid_before(
    datetime.datetime.utcnow()
).not_valid_after(
    datetime.datetime.utcnow() + datetime.timedelta(days=1825)
).add_extension(
    x509.BasicConstraints(ca=True, path_length=0), critical=True
).sign(root_private_key, hashes.SHA256())

# Now issue an end-entity certificate (e.g., for www.example.com)
leaf_private = rsa.generate_private_key(public_exponent=65537, key_size=2048)
leaf_cert = x509.CertificateBuilder().subject_name(
    x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, u"www.example.com")])
).issuer_name(
    intermediate_cert.subject
).public_key(
    leaf_private.public_key()
).serial_number(
    x509.random_serial_number()
).not_valid_before(
    datetime.datetime.utcnow()
).not_valid_after(
    datetime.datetime.utcnow() + datetime.timedelta(days=90)
).add_extension(
    x509.SubjectAlternativeName([x509.DNSName(u"www.example.com")]), critical=False
).add_extension(
    x509.BasicConstraints(ca=False, path_length=None), critical=True
).sign(intermediate_private, hashes.SHA256())

print("Chain created: Leaf -> Intermediate -> Root")

Once certificates are issued, they are used for two primary operations: encryption/key exchange and digital signatures. The following example shows both.

from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.hazmat.primitives import hashes

# --- Operation 1: Encryption (Confidentiality) ---
# Anyone can encrypt with the public key, only private key holder can decrypt
message = b"Secret session key for TLS: 0x4A5F..."
ciphertext = leaf_cert.public_key().encrypt(
    message,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)
# Decryption requires the corresponding private key
plaintext = leaf_private.decrypt(
    ciphertext,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)
assert plaintext == message
print(f"Encryption successful: {plaintext.decode()}")

# --- Operation 2: Digital Signature (Authentication & Non-repudiation) ---
data_to_sign = b"Document: Transfer $100 to Bob"
signature = leaf_private.sign(
    data_to_sign,
    padding.PSS(
        mgf=padding.MGF1(hashes.SHA256()),
        salt_length=padding.PSS.MAX_LENGTH
    ),
    hashes.SHA256()
)
# Anyone with the certificate can verify the signature
try:
    leaf_cert.public_key().verify(
        signature,
        data_to_sign,
        padding.PSS(
            mgf=padding.MGF1(hashes.SHA256()),
            salt_length=padding.PSS.MAX_LENGTH
        ),
        hashes.SHA256()
    )
    print("Signature verified: Authentic and untampered")
except Exception as e:
    print(f"Signature verification failed: {e}")

Finally, certificate path validation is the most critical client-side operation. This simplified validator checks signatures, expiry, and basic constraints, mirroring what a browser does during a TLS handshake.

import datetime

def validate_certificate_chain(leaf_cert, intermediate_cert, root_cert):
    """Simplified PKI chain validation"""
    current_time = datetime.datetime.utcnow()
    
    # 1. Check validity periods for all certs
    for cert, name in [(leaf_cert, "Leaf"), (intermediate_cert, "Intermediate"), (root_cert, "Root")]:
        if current_time < cert.not_valid_before or current_time > cert.not_valid_after:
            return False, f"{name} certificate expired or not yet valid"
    
    # 2. Verify issuer/subject chaining
    if leaf_cert.issuer != intermediate_cert.subject:
        return False, "Leaf issuer does not match Intermediate subject"
    if intermediate_cert.issuer != root_cert.subject:
        return False, "Intermediate issuer does not match Root subject"
    
    # 3. Verify cryptographic signatures (most expensive step)
    try:
        # Verify intermediate was signed by root
        root_cert.public_key().verify(
            intermediate_cert.signature,
            intermediate_cert.tbs_certificate_bytes,
            padding.PKCS1v15(),
            intermediate_cert.signature_hash_algorithm,
        )
        # Verify leaf was signed by intermediate
        intermediate_cert.public_key().verify(
            leaf_cert.signature,
            leaf_cert.tbs_certificate_bytes,
            padding.PKCS1v15(),
            leaf_cert.signature_hash_algorithm,
        )
    except Exception as e:
        return False, f"Signature verification failed: {e}"
    
    # 4. Check BasicConstraints (CA flag)
    try:
        leaf_bc = leaf_cert.extensions.get_extension_for_class(x509.BasicConstraints).value
        if leaf_bc.ca is True:
            return False, "Leaf certificate must not be a CA"
    except x509.ExtensionNotFound:
        pass
    
    # 5. (In production) Check revocation via CRL/OCSP
    # if is_revoked(leaf_cert.serial_number): return False
    
    return True, "Chain is valid and trusted"

is_valid, msg = validate_certificate_chain(leaf_cert, intermediate_cert, root_cert)
print(f"Validation result: {msg}")

4. Step-by-Step Example

Let us walk through a concrete, end-to-end example of public key infrastructure pki in action: securing a connection to shop.flyfishnwa.com. This scenario involves four actors: the Shop Server (end-entity), an Intermediate CA operated by Let's Encrypt, a Root CA (ISRG Root X1), and a Customer's Browser.

Step 1: Key Generation. The administrator for shop.flyfishnwa.com generates a 2048-bit RSA key pair on the web server. The private key is stored with file permissions 600 and never leaves the server. The public key is extracted and ready for certification.

Step 2: CSR Creation. The server creates a Certificate Signing Request containing: Subject: CN=shop.flyfishnwa.com, O=FlyFishNWA LLC, SANs: shop.flyfishnwa.com, www.shop.flyfishnwa.com, Public Key: (the generated RSA public key), and Extensions: KeyUsage=digitalSignature, keyEncipherment. The entire CSR is signed with the server's private key, proving it possesses the private key corresponding to the public key being certified.

Step 3: Enrollment and Validation. The CSR is submitted to Let's Encrypt via the ACME protocol. The RA performs Domain Validation by requiring the server to place a specific token at http://shop.flyfishnwa.com/.well-known/acme-challenge/... or create a DNS TXT record. An automated validator checks this token. This proves control of the domain without manual paperwork.

Step 4: Issuance. Once validation succeeds, the Intermediate CA (Let's Encrypt R3) constructs an X.509 certificate: it copies the public key and identity from the CSR, assigns a serial number (e.g., 0x03A...), sets NotBefore to now and NotAfter to now + 90 days, and signs the certificate's TBSCertificate (To-Be-Signed) bytes with its own private key using SHA-256 with RSA. The signed certificate is returned to the server along with the intermediate chain.

Step 5: TLS Handshake and Validation. A customer visits https://shop.flyfishnwa.com. The server presents its leaf certificate plus the intermediate certificate. The browser, which has ISRG Root X1 in its trust store, performs path validation: it checks the leaf's signature using the intermediate's public key, checks the intermediate's signature using the root's public key, verifies expiry, checks that shop.flyfishnwa.com matches the SAN, and queries OCSP to ensure neither certificate is revoked. If all checks pass, the browser uses the leaf's public key to negotiate a symmetric session key (via ECDHE) and establishes an encrypted channel. The customer sees a padlock, and data is now confidential and authenticated.

Step 6: Revocation Scenario. Six weeks later, the server is compromised and the private key is suspected to be leaked. The administrator immediately contacts the CA and requests revocation. The CA adds the leaf's serial number to its next CRL and updates its OCSP responder to return "revoked". Within hours, all browsers that check OCSP will refuse to connect to the compromised certificate, even though it has not yet expired. The administrator then generates a new key pair and repeats the enrollment process to obtain a replacement certificate.

5. Complexity Analysis

The performance of public key infrastructure pki is dominated by asymmetric cryptographic operations, which are orders of magnitude slower than symmetric ones. Therefore, PKI is used to bootstrap trust and exchange symmetric keys, not to encrypt bulk data directly. Understanding the computational complexity is crucial for capacity planning for CAs and for optimizing TLS handshakes.

Key generation is the most expensive operation, involving the search for large prime numbers and primality testing (Miller-Rabin). RSA operations scale cubically with key size, while Elliptic Curve Cryptography (ECC) offers equivalent security with much smaller keys and faster operations. Certificate validation time grows linearly with chain length, but each step involves a costly signature verification.

Space complexity is generally modest for individual certificates (1-2 KB), but becomes significant for CAs that must store millions of certificates and for clients that must download large CRLs. OCSP was introduced specifically to reduce this space and bandwidth cost from O(N) where N is number of revoked certs, to O(1) per query.

* With optimized sorted CRL and binary search or hash set. Naive linear scan is O(N). Hash-based OCSP and CRLite approaches achieve O(1).

In practice, an RSA-2048 private key operation takes ~1-2 milliseconds on modern CPUs, while ECDSA P-256 is ~0.3ms. A full TLS 1.3 handshake with chain validation of length 3 typically takes 5-15ms of CPU time. For a busy CA issuing 1 million certificates per day, key generation and signing become the bottleneck, necessitating HSM clusters and hardware acceleration.

6. Variations and Optimizations

While the hierarchical X.509 PKI is the dominant model on the web, several variations and optimizations have emerged to address its limitations in scalability, privacy, and trust centralization.

Elliptic Curve Cryptography (ECC): The most significant optimization is the shift from RSA to ECC. An ECC P-256 key provides equivalent security to RSA-3072 but with a 256-bit key versus 3072-bit, resulting in smaller certificates, faster handshakes, and lower power consumption — critical for mobile and IoT devices. ECDSA and EdDSA signatures are now widely supported and preferred for new deployments.

Certificate Transparency (CT): To detect mis-issued or rogue certificates from a compromised CA, CT creates an append-only, publicly auditable log of all issued certificates. CAs must submit certificates to multiple CT logs and provide Signed Certificate Timestamps (SCTs) that browsers require. This does not prevent mis-issuance but makes it detectable within hours.

Short-Lived Certificates and Automation: Traditional CRLs struggle with revocation at scale. An alternative is to issue very short-lived certificates (e.g., 24 hours or even 3 days) and automate renewal via ACME. If a key is compromised, the attacker only has a short window before the certificate naturally expires, reducing reliance on revocation checks. Let's Encrypt's 90-day certificates are a step in this direction.

Alternative Trust Models

Web of Trust (PGP): Instead of hierarchical CAs, users directly sign each other's keys. Trust is decentralized and subjective. While resilient to single CA failure, it is complex for average users and lacks clear revocation semantics, which is why it remains niche.

Private PKI and Internal CAs: Large enterprises often run their own internal PKI using tools like Active Directory Certificate Services, HashiCorp Vault, or EJBCA. This allows issuance of certificates for internal services, mutual TLS (mTLS) between microservices, and device authentication without relying on public CAs or exposing internal hostnames.

Post-Quantum PKI: Current PKI relies on RSA and ECC, which will be broken by sufficiently large quantum computers using Shor's algorithm. The NIST Post-Quantum Cryptography standardization process has selected new algorithms like Dilithium (signatures) and Kyber (key encapsulation) that are being integrated into hybrid certificates that contain both classical and post-quantum signatures to ensure a smooth transition.

7. Real-World Applications

Public key infrastructure pki is invisible to most end users, yet it underpins nearly every secure digital interaction. Its applications extend far beyond the browser padlock.

Web Security (TLS/HTTPS): This is the most visible application. Every HTTPS website, API, and CDN uses PKI to authenticate the server to the client and to negotiate encrypted sessions. Without PKI, e-commerce, online banking, and SaaS platforms could not securely transmit credentials or payment data. Modern requirements like HSTS and certificate pinning further build on PKI.

Code Signing and Software Updates: Operating systems and application platforms use PKI to verify that software comes from a legitimate publisher and has not been tampered with. Microsoft Authenticode, Apple Developer ID, and Linux package repositories all require developers to sign binaries with a code-signing certificate issued by a trusted CA. The OS verifies the signature before installation, preventing malware distribution.

Email Security (S/MIME) and Document Signing: S/MIME allows users to encrypt and digitally sign emails using certificates, ensuring only the intended recipient can read the message and proving the sender's identity. Similarly, PDF and Office documents can be signed to guarantee integrity and non-repudiation for legal contracts.

Enterprise and Network Security: PKI enables 802.1X authentication for Wi-Fi and wired networks, VPN authentication, and mutual TLS (mTLS) where both client and server present certificates — essential for zero-trust architectures. Smart cards and badge-based physical access also rely on certificates stored on the card.

Emerging applications include 5G network authentication, where every base station and device uses certificates, and blockchain-based decentralized PKI (DPKI) that attempts to reduce reliance on centralized CAs by anchoring certificate hashes on a distributed ledger.

8. Comparison with Alternatives

PKI is powerful but not the only way to establish trust. Choosing the right model depends on scale, trust requirements, and operational overhead. The table below compares public key infrastructure pki with its main alternatives.

In practice, many systems hybridize these approaches. For example, TLS can use PKI for authentication and then derive symmetric session keys for bulk encryption, combining the scalability of PKI with the performance of symmetric cryptography. Similarly, some IoT deployments use PKI for initial provisioning and then switch to symmetric keys for constrained communication.

9. Common Mistakes and Best Practices

Deploying public key infrastructure pki incorrectly can be worse than not deploying it at all, creating a false sense of security. The following pitfalls are frequently seen in audits and security incidents.

Mistake 1: Insecure Private Key Storage. Storing private keys as unencrypted PEM files on disk, committing them to Git, or sharing them via email is a critical failure. If a CA's private key is exposed, every certificate it ever signed must be distrusted. Best Practice: Always generate keys inside an HSM or use a managed service like AWS ACM Private CA or Azure Key Vault. Use strong passphrases and enforce least-privilege access. For end-entities, use OS keychains or TPMs.

Mistake 2: Ignoring Revocation and Expiry Monitoring. Many outages are caused by expired certificates that were not renewed, and many breaches persist because compromised certificates were not revoked or OCSP was not checked. Clients that soft-fail on OCSP (accepting the certificate if the OCSP responder is unreachable) are vulnerable. Best Practice: Automate renewal with ACME and monitor expiry with tools like Prometheus blackbox exporter or Certbot. Implement OCSP stapling and hard-fail policies where possible. Prefer short-lived certificates to reduce revocation window.

Mistake 3: Weak Cryptography and Poor Configuration. Using RSA-1024, SHA-1, or allowing TLS 1.0/1.1 exposes the system to collision and downgrade attacks. Self-signed certificates in production without proper trust distribution train users to click through warnings. Best Practice: Enforce a minimum of RSA-2048 or ECC P-256, use SHA-256 or stronger, disable legacy protocols, and follow Mozilla's Intermediate TLS configuration. Never use self-signed certificates for public-facing services; use a proper CA.

Operational Best Practices

• Principle of Least Privilege for CAs: Use separate intermediate CAs for different purposes (TLS, code signing, client auth) with constrained path lengths and Name Constraints to limit blast radius.
• Automate Everything: Manual certificate issuance is error-prone and slow. Use EST, SCEP, or ACME for automated enrollment and renewal.
• Audit and Transparency: Log all issuance to Certificate Transparency logs, regularly audit CA logs, and maintain an accurate inventory of all certificates in your organization.
• Plan for Rotation and Disaster Recovery: Have a documented procedure for rapid root rotation and intermediate replacement. Test revocation and re-issuance under pressure before an incident occurs.
• Validate Thoroughly: Clients must validate the entire chain, including hostname matching (SAN), key usage extensions, and revocation status. Do not disable certificate verification in code (e.g., verify=False in Python requests) even for testing.

10. Interview Questions

PKI is a favorite topic in security, backend, and systems design interviews because it tests both cryptographic understanding and practical systems thinking. Here are common questions with guidance on strong answers.

Q1: What is the difference between a digital certificate and a public key? Why can't we just distribute public keys directly?

Answer: A public key is just a cryptographic number, while a digital certificate is a public key bundled with identity information (subject, issuer, validity, extensions) and signed by a trusted CA. Distributing raw public keys is vulnerable to Man-in-the-Middle attacks — an attacker could substitute their own key and impersonate the server. The certificate's CA signature binds the key to an identity and provides authentication; without it, you have encryption without trust. Mention X.509 structure and how the signature provides integrity.

Q2: Explain the TLS handshake and where PKI is used.

Answer: Outline TLS 1.2 vs 1.3. In TLS 1.2: ClientHello, ServerHello + Certificate Chain, Client validates chain to trusted root, Client encrypts pre-master secret with server's public key (or uses ECDHE for forward secrecy), both derive session keys, Finished messages. In TLS 1.3, the handshake is 1-RTT and always uses (EC)DHE for forward secrecy; PKI is used only for authentication via signatures, not for key transport. Strong answers mention cipher suites, forward secrecy, and that bulk data uses symmetric encryption (AES-GCM/ChaCha20) after PKI bootstraps trust.

Q3: How does revocation work? What are the trade-offs between CRL and OCSP?

Answer: Explain that revocation is needed before expiry due to compromise. CRL is a periodically published signed list of revoked serial numbers — simple but large (O(N)), stale, and requires clients to download the whole list. OCSP is a real-time request-response protocol (O(1) per cert) but introduces privacy leaks (CA learns browsing history), availability dependency, and latency. Discuss OCSP Stapling (server provides OCSP response) and newer solutions like CRLite (compressed filter) and short-lived certs that minimize revocation need. Mention soft-fail vs hard-fail behavior.

Q4: What happens if a Root CA is compromised?

Answer: This is catastrophic. A compromised Root CA can issue fraudulent certificates for any domain, enabling undetectable MITM attacks. Recovery requires removing the root from all trust stores (browser/OS updates), revoking all intermediates and leafs it signed, and re-issuing everything from a new root — a massive, months-long operation. This is why Roots are kept offline, in HSMs, with multi-person control, audited ceremonies, and why intermediates are used to limit exposure. Reference real incidents like DigiNotar (2011) where a breach led to the CA's complete removal.

Q5: RSA vs ECC for PKI — when would you choose one over the other?

Answer: Compare key size, performance, and compatibility. ECC (P-256, P-384, Ed25519) offers equivalent security with much smaller keys (256-bit ECC ≈ 3072-bit RSA), faster signing/verification, lower bandwidth and CPU, ideal for mobile, IoT, and high-performance servers. RSA is older, more universally compatible with legacy systems, and simpler to implement correctly. For new systems, ECC is preferred; for maximum compatibility or where FIPS requirements mandate RSA, use RSA-2048 minimum (RSA-4096 for roots). Mention the upcoming post-quantum transition where both will be replaced.