PKI Protocols and Standards

TL;DR

PKI relies on specific protocols and standards to manage digital certificates and ensure secure communication. These define how certificates are requested, issued, revoked, and used. Understanding them helps you grasp the operational backbone of secure online interactions.

1. The Mental Model

Think of PKI protocols as the traffic rules and road signs for digital identities. They dictate how different systems (like your browser and a website server) talk to each other to establish trust and maintain security online.

2. The Core Material

When we talk about PKI protocols and standards, we're discussing the agreed-upon methods that make PKI work across different vendors and systems. These aren't just for issuing certificates, but for their entire lifecycle: requesting, delivering, checking status, and revoking.

Certificate Request and Management Protocols

You can't just wish a certificate into existence; there's a standardized process to get one.

• PKCS#10 (Certificate Request Syntax Standard): This is a widely used format for sending a certificate signing request (CSR) to a Certificate Authority (CA). It contains your public key and information about you or your organization, all signed with your private key. It's essentially your application form for a certificate.
• CMC (Certificate Management over CMS): A more advanced and flexible protocol for certificate management operations. It handles not just initial requests but also renewals, key archival, and key recovery. CMC uses Cryptographic Message Syntax (CMS) to secure the management messages.
• EST (Enrollment over Secure Transport): Designed for situations where a device might not have a lot of manual human interaction, like IoT devices. EST uses simpler messages and relies on TLS for transport security, making it easier to automate certificate enrollment.
• ACME (Automated Certificate Management Environment): This protocol (famously used by Let's Encrypt) automates the process of domain validation and certificate issuance. It's designed to make getting and renewing certificates free and easy, especially for web servers.

Certificate Revocation and Validation Protocols

Certificates aren't forever, and sometimes they need to be invalidated quickly. How do others know if a certificate is still good?

• CRL (Certificate Revocation List): A list maintained by a CA containing serial numbers of certificates that have been revoked before their expiry date. When you check a certificate, your system might download a CRL and see if the certificate's serial number is on it. This can be slow if the CRL is large or infrequently updated.
• OCSP (Online Certificate Status Protocol): A more efficient alternative to CRLs. Instead of downloading a whole list, your system sends a real-time query to an OCSP responder asking about the status of a specific certificate. The responder replies "good," "revoked," or "unknown." This is much faster.
• OCSP Stapling (TLS Certificate Status Request Extension): To speed up OCSP even more, the web server itself can query the OCSP responder and "staple" (attach) the signed OCSP response to its TLS handshake. This means your browser gets the revocation status directly from the server, saving it an extra step.
• SCVP (Server-based Certificate Validation Protocol): This protocol offloads the complex path validation process (checking the entire chain of trust) to a dedicated server. This is useful for devices with limited processing power.

Certificate Formats and Data Structures

These define how certificates and related data are structured.

• X.509: This is the foundational standard for public key certificates. It defines the structure and content of a digital certificate, including fields for the public key, issuer, subject, validity period, and digital signature. Most certificates you encounter are X.509 certificates.
• PKCS#12 (Personal Information Exchange Syntax Standard): Defines a portable format for storing a private key, its associated public key certificate, and potentially other certificates in the chain. These are often used to export/import keys and certificates, usually protected by a password. File extensions like .p12 or .pfex are common.

Here’s a simplified flow illustrating how a certificate is requested and then its status checked:

graph TD
    A["User/Server (Identity Owner)"] --> B{"Generate Key Pair & CSR (PKCS#10)"};
    B --> CReq["Send CSR to CA (e.g., via CMC, EST, ACME)"];
    CReq --> CA["Certificate Authority"];
    CA --"Verifies & Signs"--> CResp["Issue Certificate (X.509)"];
    CResp --> A;

    subgraph Certificate Validation
        Client["Client (e.g., Web Browser)"] --> D{"Receives Certificate from Server"};
        D --> E{"Check Certificate Validity Period"};
        E --> F{"Validate Signature (Trust Chain)"};
        F --"If Revocation Check Needed"--> G{"Query OCSP Responder"};
        G --> H["OCSP Responder"];
        H --"Status: Good/Revoked/Unknown"--> Client;
    end

3. Worked Example

Let's imagine you're setting up a new web server and need an SSL/TLS certificate for yourdomain.com.

1. Generate Private Key and CSR: You'd typically use a tool like OpenSSL on your server.
   bash openssl genrsa -out yourdomain.key 2048 openssl req -new -key yourdomain.key -out yourdomain.csr -sha256 \ -subj "/C=US/ST=State/L=City/O=YourCo/CN=www.yourdomain.com"
   This command generates a 2048-bit RSA private key (yourdomain.key) and then uses it to create a CSR (PKCS#10 format) (yourdomain.csr). The -subj part fills in the basic X.509 fields.

2. Submit CSR to CA: You'd copy the content of yourdomain.csr (it begins with -----BEGIN CERTIFICATE REQUEST-----) and paste it into a web form of a CA (like DigiCert, Sectigo, or Let's Encrypt). If using Let's Encrypt, an ACME client like Certbot would automate this process for you, including domain validation.

3. CA Issues Certificate: After validation, the CA issues an X.509 certificate for www.yourdomain.com. You'd download this certificate (e.g., as yourdomain.crt) and any intermediate certificates.

4. Install on Server: You install yourdomain.key and yourdomain.crt on your web server (e.g., Nginx or Apache).

5. Client Validation (Real-time): When someone visits https://www.yourdomain.com/:

   • Their browser receives the X.509 certificate from your server.
   • The browser checks the certificate's validity period and ensures it's signed by a trusted CA.
   • It then, potentially, sends an OCSP query to an OCSP responder (or receives an OCSP stapled response from your server) to ensure the certificate hasn't been revoked.
   • If all checks pass, a secure TLS connection is established.

4. Key Takeaways

• PKCS#10 is the standard format for sending certificate signing requests to a CA.
• X.509 defines the universally accepted structure and content of digital certificates.
• CRLs provide lists of revoked certificates, while OCSP offers real-time certificate status checks.
• OCSP stapling improves efficiency by having the server provide revocation status directly.
• ACME and EST are protocols designed to automate and simplify certificate enrollment, especially for devices.
• PKCS#12 is used for securely bundling private keys with their corresponding certificates.
• These protocols ensure certificates can be requested, issued, validated, and revoked across diverse systems.

Common Mistakes to Avoid:
- Misunderstanding the difference between a CSR (request) and a certificate (issued credential).
- Neglecting revocation checks, which can leave systems vulnerable to compromised certificates.
- Using outdated or insecure key sizes and algorithms for certificate generation.
- Storing private keys insecurely, which completely undermines PKI's security.

5. Now Try It

Using OpenSSL, generate a 4096-bit RSA private key and then create a PKCS#10 CSR with it for a fictional domain like test.local. Specify common name www.test.local, organization name My Test Org, and a country code. What to do: produce both the .key and .csr files. What success looks like: you can view the contents of the .csr file using openssl req -in test.csr -text -noout and confirm it contains the information you provided and corresponds to a 4096-bit key.