LaMarr Labs Field Guide

PKCS

14 min read

up:: Classical Cryptography MOC

PKCS

PKCS, the Public-Key Cryptography Standards, is a family of specifications from RSA Laboratories that standardize how cryptographic keys, signatures, certificates, and hardware tokens are encoded and accessed. Most members define a data format (how an RSA key or a signed message is packed into bytes), while PKCS#11 defines a programming interface (how software talks to a smart card or a hardware security module). Together they are the plumbing that lets a key made by one product be read by another and a hardware token from any vendor be driven by any compliant application. That interoperability is why PKCS sits on the post-quantum critical path: each format and the interface names its algorithm by a fixed identifier, so carrying ML-DSA or ML-KEM means teaching every parser and token to recognize and hold the new, much larger keys.

The short version:

  1. PKCS is a numbered set of standards (PKCS#1 through PKCS#15) from RSA Laboratories that fixes how keys, signatures, and cryptographic tokens are represented and used, so different products interoperate.
  2. Most PKCS members are data formats: PKCS#1 is RSA encoding, PKCS#7 is signed and enveloped messages (now CMS), PKCS#8 is a private-key container, PKCS#10 is a certificate request, and PKCS#12 is the .p12/.pfx bundle that ships a key with its certificate.
  3. One member is different in kind. PKCS#11 is an API, the standard way an application calls into a smart card or a hardware security module without knowing the vendor.
  4. Change control for most of the format standards moved to the IETF years ago, so today you cite the equivalent RFC (RFC 8017 for PKCS#1, RFC 5652 for CMS) rather than the old RSA document, while PKCS#11 lives at OASIS.
  5. The migration relevance is direct. These formats and this interface all name algorithms by identifier and assume classical key sizes, so post-quantum algorithms need new identifiers, new PKCS#11 mechanisms, and enough room for keys and signatures that are many times larger. Flexing all of that is part of what crypto-agility has to deliver.

Think of PKCS as the combination of standardized shipping boxes and standardized wall sockets for cryptography. PKCS#1 is the packing rule for what goes inside an RSA box. PKCS#8 and PKCS#12 are the standard boxes a private key travels in, so a key exported from one system unpacks cleanly on another. PKCS#11 is the wall socket: a hardware security module exposes the same plug shape to every application, so software can draw on it without custom wiring for each brand.

When a new kind of key arrives that is physically bigger and shaped differently, like a post-quantum one, you have to widen the boxes and add a socket type, and every warehouse and appliance that handled the old ones has to learn the new dimensions.

What is PKCS?

PKCS is a set of cryptographic standards, numbered PKCS#1 through PKCS#15, that specify concrete formats and interfaces for public-key cryptography so that independently built products can exchange keys, signatures, and certificates. RSA Laboratories developed the series to fill a gap the underlying math left open: the algorithms told you how to compute an RSA signature, but not the exact byte layout to store the key in, or how a program should ask a smart card to perform the operation. Without an agreed encoding, a key made by one vendor’s tool would be unreadable by another’s. PKCS is the agreement.

The series splits into two kinds of member:

  1. Data-format standards. These define an exact on-the-wire or on-disk encoding, almost always expressed in ASN.1 (a formal notation for describing data structures) and serialized with DER. PKCS#1, #7, #8, #10, and #12 are all of this kind. A file in one of these formats is self-describing enough that any compliant parser can read it.
  2. An interface standard. PKCS#11 is not a file format at all. It is a C-language API, a fixed list of function calls and constants, that an application uses to drive a cryptographic token such as a smart card or a hardware security module.

RFC 8017, the current specification of PKCS#1, states the lineage plainly: it “represents a republication of PKCS #1 v2.2 from RSA Laboratories’ Public-Key Cryptography Standards (PKCS) series.”

Source: K. Moriarty, Ed., B. Kaliski, J. Jonsson, A. Rusch, “PKCS #1: RSA Cryptography Specifications Version 2.2,” RFC 8017, November 2016, RFC 8017.

Who created PKCS, and why does it still matter?

PKCS was created by RSA Laboratories, the research arm of RSA Security, and published as the Public-Key Cryptography Standards series to make early public-key cryptography usable across products rather than locked inside one vendor’s software. Over time, change control for most of the format standards was transferred to standards bodies so the wider internet could maintain them. The republished RFCs say so directly: RFC 7292 notes that “by publishing this RFC, change control is transferred to the IETF,” and RFC 5652 records that the Cryptographic Message Syntax “is derived from PKCS #7 version 1.5.”

It still matters for a practical reason: the formats never went away. When you export a private key and certificate from a browser or a server, you get a PKCS#12 .p12 or .pfx file. When an application talks to a hardware security module, it very often does so through PKCS#11. When a server requests a certificate from a Certificate Authority, it sends a PKCS#10 certification request. These are the default containers and interfaces of everyday public-key infrastructure and key management, which is exactly why they sit on the critical path of a post-quantum migration.

Source: K. Moriarty, Ed., M. Nystrom, S. Parkinson, A. Rusch, M. Scott, “PKCS #12: Personal Information Exchange Syntax v1.1,” RFC 7292, July 2014, RFC 7292.

What are the main PKCS standards?

The members you meet in practice are a handful of the numbered series, each doing one specific job in the lifecycle of a key or a signed object. The table below lists the load-bearing ones, what each does, and where its authoritative specification lives today. Read it top to bottom and it traces a key’s whole life: how it’s encoded (PKCS#1), how it’s stored privately (PKCS#8), how it’s requested into a certificate (PKCS#10), how it’s bundled with that certificate for transport (PKCS#12), how signed messages are packaged (PKCS#7 / CMS), and how a hardware token is driven (PKCS#11).

StandardWhat it doesAuthoritative spec today
PKCS#1Defines RSA key encoding and the RSA signature and encryption padding schemes (RSASSA-PSS, RSAES-OAEP)RFC 8017, “PKCS #1: RSA Cryptography Specifications Version 2.2,” Nov 2016
PKCS#7Packages signed and/or encrypted (“enveloped”) messages; the basis of S/MIME and code signingRFC 5652, “Cryptographic Message Syntax (CMS),” Sep 2009 (derived from PKCS#7 v1.5)
PKCS#8A container for a private key of any algorithm, optionally password-encrypted; the .p8 / PRIVATE KEY formatRFC 5958, “Asymmetric Key Packages,” Aug 2010 (obsoletes PKCS#8 v1.2)
PKCS#10The certification request (CSR) a subject sends to a CA to get a certificate issuedRFC 2986, “PKCS #10: Certification Request Syntax Specification Version 1.7,” Nov 2000
PKCS#11A programming interface (the “Cryptoki” API) for driving smart cards and hardware security modulesOASIS, “PKCS #11 Cryptographic Token Interface Base Specification Version 3.0,” OASIS Standard, 15 Jun 2020
PKCS#12Bundles a private key together with its certificate chain into one portable, password-protected file (.p12 / .pfx)RFC 7292, “PKCS #12: Personal Information Exchange Syntax v1.1,” Jul 2014

Sources: RFC 8017, PKCS #1; R. Housley, “Cryptographic Message Syntax (CMS),” RFC 5652, September 2009, RFC 5652.

S. Turner, “Asymmetric Key Packages,” RFC 5958, August 2010, RFC 5958.

M. Nystrom, B. Kaliski, “PKCS #10: Certification Request Syntax Specification Version 1.7,” RFC 2986, November 2000, RFC 2986.

OASIS, “PKCS #11 Cryptographic Token Interface Base Specification Version 3.0,” OASIS Standard, 15 June 2020, OASIS PKCS #11 v3.0.

What’s the difference between a PKCS format and the PKCS#11 interface?

The format standards describe data at rest, and PKCS#11 describes a conversation with a device, which is why PKCS#11 behaves so differently from the rest of the family. A PKCS#8 or PKCS#12 file is a passive object: it sits on disk, fully described by its own bytes, and any compliant tool can parse it without asking anyone’s permission. PKCS#11, by contrast, is a live API. An application loads a vendor’s PKCS#11 library, calls functions like C_GenerateKeyPair, C_Sign, and C_Decrypt, and the actual key material can stay locked inside the hardware security module the whole time, never leaving the device.

That distinction has a real security consequence:

  1. A format exposes the key. A PKCS#12 bundle contains the private key itself (encrypted under a password). Whoever holds the file and the password holds the key.
  2. The interface can hide the key. PKCS#11’s whole point is that an application can use a key it can never extract. The token performs the signing or decryption internally and hands back only the result, which is how hardware security modules keep root and code-signing keys out of software memory entirely.

So when people say “PKCS,” they might mean a file you can email or a socket a device exposes, and the two raise different questions in a migration: the formats have to be widened to hold larger keys, while the interface has to gain new operations for the new algorithms.

Where do you actually encounter PKCS?

PKCS shows up wherever a key has to be stored, moved, requested, or used by hardware, which is to say almost everywhere in real PKI. The common encounters:

  1. Exporting or importing a key and certificate. Browsers, web servers, and OS keystores hand you a PKCS#12 .p12 or .pfx file, the standard way to carry a private key and its certificate chain together.
  2. Server and application private keys. A raw private key on disk is usually a PKCS#8 structure, the -----BEGIN PRIVATE KEY----- block that tools like OpenSSL read and write.
  3. Getting a certificate issued. A server or device builds a PKCS#10 certification request, signs it to prove control of the key, and sends it to a CA.
  4. Signed messages and code signing. S/MIME email, signed documents, and many code-signing formats are PKCS#7 / CMS structures wrapping a digital signature around content.
  5. Hardware-backed keys. When a key lives in a smart card, a YubiKey, or a hardware security module, the application almost always reaches it through the PKCS#11 interface.
  6. RSA operations themselves. Any time RSA is used for a signature or key transport, PKCS#1 defines the padding (RSASSA-PSS, RSAES-OAEP) that makes the raw operation safe.

Because these formats also carry key pairs and CA certificates that anchor trust, a weakness or a gap in how they represent an algorithm propagates straight into the trust layer.

How does the post-quantum transition affect PKCS?

The post-quantum transition affects PKCS because every one of these formats and the PKCS#11 interface identifies its algorithms by a fixed identifier and was sized around classical keys, so each has to be extended before it can carry ML-DSA, SLH-DSA, or ML-KEM. Two separate problems land here at once:

  1. New algorithm identifiers. PKCS structures label the algorithm inside them with an ASN.1 object identifier (OID), and PKCS#11 labels operations with numeric mechanism constants. A parser or a token that has never heard of an ML-DSA OID or an ML-KEM mechanism simply cannot read or perform the operation. Adding post-quantum support means registering those identifiers and updating every library, CA, and hardware token that implements the standard, which is slow, distributed work.
  2. Much larger objects. Post-quantum keys and signatures are far bigger than elliptic-curve ones, where the smallest ML-DSA signature runs over 2,400 bytes against roughly 64 bytes for ECDSA (see Digital Signature). That size jump stresses PKCS#8 key containers, PKCS#12 bundles, PKCS#10 requests, and PKCS#11 buffers that were tuned for small classical keys, and it can collide with fixed length limits baked into older implementations.

Standards work to close these gaps is underway across the same bodies that maintain the formats: NIST finalized the post-quantum algorithms in FIPS 203, 204, and 205 in 2024, the IETF is defining how those keys and signatures are encoded inside the ASN.1 structures the PKCS formats use, and OASIS continues to extend the PKCS#11 mechanism list. This is precisely the surface crypto-agility has to flex: an estate whose PKCS handling assumes RSA and elliptic-curve sizes, and only those OIDs, is an estate that cannot adopt a new algorithm by configuration and instead has to be found and updated component by component.

Source: NIST, “NIST Releases First 3 Finalized Post-Quantum Encryption Standards,” August 13, 2024, nist.gov.

Common misconceptions

  1. “PKCS is one standard.” It’s a numbered family, PKCS#1 through PKCS#15, each covering a different job. Saying “it’s a PKCS file” is ambiguous until you name the number.
  2. “PKCS is an RSA-only, obsolete thing.” The name reflects the origin at RSA Laboratories, but the modern formats are algorithm-agnostic containers. PKCS#8 holds a private key of any algorithm, and PKCS#12 bundles any key with any certificate, which is exactly why they’re on the post-quantum migration path.
  3. “PKCS#11 is a file format like the others.” PKCS#11 is a programming interface (an API) for talking to hardware tokens, not a data format. It’s the one structurally different member of the family.
  4. “You still cite the old RSA PKCS documents.” For most of the format standards, change control moved to the IETF, so the authoritative reference today is the RFC (RFC 8017, RFC 5652, RFC 5958, RFC 2986, RFC 7292), while PKCS#11 lives at OASIS.
  5. “A PKCS#12 file is safe because it needs a password.” The password only encrypts the bundle, often with weak legacy settings in older files. The private key is still inside it, so a PKCS#12 file is a sensitive secret that has to be handled like the key it carries.
  6. “Post-quantum is just a library swap, so the formats don’t change.” The containers and the token interface both carry algorithm identifiers and size assumptions, so they need new OIDs, new mechanisms, and room for larger objects before any library swap can take effect.

Questions people ask

Is PKCS#7 the same as CMS? Effectively yes, with one lineage note. The Cryptographic Message Syntax defined in RFC 5652 is derived from PKCS#7 version 1.5 and is its maintained IETF successor, so modern signed-message and enveloped-data work references CMS while the format remains PKCS#7-compatible in spirit.

What is the difference between PKCS#8 and PKCS#12? PKCS#8 is a container for a single private key, optionally password-encrypted. PKCS#12 is a richer bundle that carries a private key together with its certificate and the rest of its certificate chain, which is what makes .p12 and .pfx files convenient for moving a whole identity between systems.

Why does a .pfx or .p12 file matter for a migration? Because it holds the private key and certificate together, a PKCS#12 file is exactly the object that has to be reissued when you move a certificate from a classical algorithm to a post-quantum one, and every place that stores or imports these files has to accept the new, larger keys inside them.

Do post-quantum algorithms have PKCS identifiers yet? The algorithms are finalized in NIST FIPS 203, 204, and 205, and the standards bodies are defining the object identifiers and PKCS#11 mechanisms that let the formats and the token interface carry them. Support propagates unevenly across libraries and hardware, so an estate has to verify each component rather than assume coverage.

Is PKCS#11 required to use a hardware security module? Not strictly, since some vendors offer proprietary APIs, but PKCS#11 is the dominant vendor-neutral interface for smart cards and hardware security modules, which is why it’s the one an application most often targets to stay portable across devices.

What replaces PKCS in the post-quantum world? Nothing replaces it. The same formats and interface continue, extended with new algorithm identifiers and sizing so they can carry ML-DSA, SLH-DSA, and ML-KEM alongside the classical algorithms.

Where does the PKCS#1 padding fit in? PKCS#1 defines the safe padding schemes for RSA (RSASSA-PSS for signatures, RSAES-OAEP for encryption). It matters because raw RSA without correct padding is insecure, and it’s part of why RSA is a whole specification rather than a one-line formula.

Everything here is the map, given freely. When your team needs its own keystores, certificates, and hardware-token interfaces found and sequenced onto a post-quantum path, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.

Graph View

Backlinks