There are several standards relevant to the digital certificates and PKI covered in this book. Some of these were from RSA, the creators of the first successful public key cryptosystem (the RSA algorithm). These are referred to as the Public Key Cryptography Standards (PKCS). Some of these are from the Internet Engineering Task Force (IETF), the technical group responsible for the standards underlying the Internet. These are called Requests for Comments (RFCs). Others are from US government agencies, such as the National Institute for Standards and Technology (NIST) and the Federal Information Processing Standards (FIPS).
PKCS – Public Key Cryptography Standards
Unlike the other standards listed here, these were created by a single company (RSA). Some had updated versions released by RSA. Some of the PKCS standards are still being used today, although they have since been adopted by the IETF, subjected to consensus review, and cleaned up or extended based on more recent technology. The IETF does not allow any standard based on patented or proprietary technology to be issued as an RFC, so PKCS #1 could not be incorporated in an RFC until after its patent expired in 2000. Most people in the field still refer to these standards by the PKCS numbers (e.g., a “PKCS #12 container”). In the following, we will reference the current RFC numbers that now specify these standards.
PKCS #1 – RSA Cryptography Standard
This specified the “RSA algorithm
.” The final version from RSA was v2.2. It is now specified in RFC 8017, “PKCS #1: RSA Cryptography Specifications Version 2.2,” November 2016. Although the Diffie-Hellman Key Agreement algorithm preceded it, the RSA cryptosystem was the first one to support general encryption and decryption using asymmetric key cryptography. It is still in widespread use although it is now reaching the end of its useful life (due to constantly increasing CPU performance and the inevitable release of viable quantum computing).
The RSA algorithm is based on one of the classic “hard problems” in mathematics, which is factoring the product of two large primes. Instead of each participant being issued a single “secret” key (symmetric key cryptography), with asymmetric key cryptography, each participant is issued a related pair of keys, one public and one private. The public key is published in some way so that anyone can use it. It is normally protected by inclusion in a public key digital certificate, along with information identifying the person or device that the key belongs to, information identifying the issuer of the certificate, validity dates, usage flags, and other information. The private key is kept secret by the key owner.
PKCS #2 – RSA Encryption of Message Digests (Withdrawn)
This standard was withdrawn by RSA and its subject incorporated into PKCS #1. It was never incorporated into an IETF RFC.
PKCS #3 – Diffie-Hellman Key Agreement
Although this was not invented by RSA personnel
, it was included in the PKCS series. It is now specified in RFC 2631, “Diffie-Hellman Key Agreement Method,” June 1999 (with no mention of PKCS #3). Nobody refers to this algorithm as “PKCS #3”.
This is actually the first widely used algorithm based on asymmetric key cryptography, invented by Whitfield Diffie and Martin Hellman and published in 1976. It was never patented.
It is based on another classic “hard problem” in mathematics, known as “discrete logarithms.” It cannot be used for general-purpose encryption and decryption (although the later ElGamal algorithm, also based on discrete logarithms, is capable of that). Recent implementations of TLS often use Diffie-Hellman Key Agreement to securely exchange a symmetric session key.
It allows two nodes to exchange numeric values over an insecure channel, resulting in a securely shared symmetric key. A hacker can intercept all of the exchanged messages and still not be able to reconstruct the shared symmetric key (at least it is very difficult and time-consuming to do so).
PKCS #4 – RSA Key Syntax (Withdrawn)
This PKCS standard specified a syntax for representing RSA keys and was incorporated into a later version of PKCS #1 in 2010. No RFC incorporated this standard.
PKCS #5 – Password-Based Encryption Standard
This is an algorithm
for creating a symmetric key from an alphanumeric passphrase in a secure, repeatable manner. It is now specified in RFC 8018, “PKCS #5: Password-Based Cryptography Specification v2.1,” January 2017.
Symmetric keys are long (128 to 256 bits) and difficult for humans to remember or specify. This algorithm allows them to use an alphanumeric passphrase (which is not the same as a password) instead of the binary key. A passphrase is far easier for a human to use or enter than a binary key. It can create a unique binary key from a given passphrase in a repeatable manner – anyone can use it to create the correct symmetric key given the correct passphrase. Like a message digest, given the symmetric key, it is very difficult to derive the passphrase from it. The most important requirement for a good passphrase is length (number of characters). Ideally, passphrases should be at least 14 characters long.
As an example, a PKCS #12 container allows you to specify a passphrase to create or open one. It uses PKCS #5 to securely create a symmetric key (typically 3DES) from the passphrase. The generated symmetric key is actually used to encrypt or decrypt the contents of the container.
A related algorithm is PBKDF2, referenced in RFC 8018. This adds the concept of “Salt,” a value used in the generation of the symmetric key from the passphrase that makes it more difficult to recover the passphrase (or password) from the hashed value using “rainbow tables” of precomputed hashes. PBKDF2 is often used to protect passwords on a server that uses username/password authentication.
PKCS #6 – Extended-Certificate Syntax Standard (Obsoleted by X.509 v3)
This specified the syntax for X.509 v1 certificates. We now use X.509 v3 certificates, so this standard is no longer in use. The current RFC that covers the syntax of X.509 v3 certificates (and X.509 v2 CRLs) is RFC 5280, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.
PKCS #7 Cryptographic Message Syntax Standard
This specifies
how to sign and/or encrypt messages using a digital certificate issued by a PKI. This was used in the creation of S/MIME which is the IETF standard for end-to-end encryption and sender authentication (originally used for Internet email). It was incorporated into an IETF standards track RFC, RFC 5652, “Cryptographic Message Syntax (CMS),” September 2009.
The standard file type for PKCS #7 objects is “.p7”.
Cryptographic Message Syntax (CMS) was originally used in
Privacy Enhanced Mail (PEM) in four standards track RFCs:
RFC 1421, “Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures,” February 1993.
RFC 1422, “Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management,” February 1993
RFC 1423, “Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes and Identifiers,” February 1993
RFC 1424, “Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services,” February 1993
We still use PEM format files for exported cryptographic keys and other objects.
PEM was not widely adopted, and replaced by S/MIME, now at version 4.0. Almost all Internet email clients support S/MIME (at least v3.1).
S/MIME is currently specified in RFC 8551, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification,” April 2019. This is an extension to Multipurpose Internet Mail Extensions (MIME) by adding MIME messages parts for digital signatures, digital envelopes, and digital certificates. It is still based on CMS and ultimately PKCS #7. S/MIME is designed for native applications, not webmail. It is transparent to intermediate servers (S/MIME-protected messages just look like normal email messages to servers). All encryption and signing is done in the sending client application, and all decryption and signature verification is done in the receiving client application. The web model is not compatible with this requirement (all processing is done on a centralized web server).
The user’s private key is used by the sending client application to create digital signatures and decrypt incoming encrypted messages. The receiving client application requires the sender’s public key (in a certificate) to verify digital signatures (usually included as part of the signed message). The sending client application requires the public keys (in certificates) for all recipients at time of message creation. This can be obtained by asking the recipient to send a signed message or from a centralized address book that supports digital certificates
.
PKCS #8 – Private-Key Information Syntax Standard
This standard
specifies a syntax for representing asymmetric private keys in a secure manner. It is now specified as part of RFC 5958, “Asymmetric Key Packages,” August 2010.
Asymmetric Key Packages use DER (Distinguished Encoding Rules), which is a binary format. It is specified in ITU-T X.690. DER syntax is a way of representing ASN.1 objects, such as asymmetric keys. These can also be encoded in PEM format, which uses alphanumeric Base64 encoding with well-known headers and trailers.
The standard file type for PKCS #8 files is “.p8”.
PKCS #9 – Selected Attribute Types
This defines selected attribute types for use in PKCS #6 extended certificates, PKCS #7 digitally signed messages, PKCS #8 private-key information, and PKCS #10 certificate-signing requests.
This was incorporated in the IETF RFCs as an informational document in RFC 2985, “PKCS #9: Selected Object Classes and Attribute Types Version 2.0,” November 2000.
Most people (unless they are creating a cryptographic API) do not need to use PKCS #9.
PKCS #10: Certification Request Standard
The syntax of a message is sent to a Certification
Authority to request the creation of a digital certificate. Now specified in RFC 2986, “PKCS #10: Certification Request Syntax Specification v1.7,” November 2000. It is commonly referred to as a PKCS #10 request or a Certificate-Signing Request (CSR)
.
A CSR contains several things needed by a Certification Authority to issue a digital certificate, including
The subject’s public key, including algorithm and key length
The Subject Distinguished Name (SubjectDN), which identifies the subject (applicant), for example, CN=Lawrence Hughes, E=[email protected], O=PKIEdu Inc., OU=IT, L=Frisco, ST=Texas, C=US
Requested Key Usage flags
Requested Enhanced Key Usage flags
Note that the CSR never includes the subject’s private key. Normally, only the generated certificate is returned to the applicant (e.g., by email or web download). The generated certificate must be reassociated with the private key created by the user to make usable key material (certificate + private key). It is possible for the CA to create the key pair, in which case the certificate and the private key are returned in a PKCS #12 container. The submitted CSR is digitally signed using the subject’s private key. This signature is validated using the subject’s submitted public key.
The Certification Authority adds several things to the preceding information to create the issued certificate, including
Issuer Distinguished Name that identifies the certificate issuer (CA)
Certificate serial number
Validity dates (ValidFrom and ValidTo)
CRL Distribution Point (where you can find the CRL for this certificate)
OCSP URL (where you can find the OCSP server for this certificate)
Approved Key Usage flags
Approved Enhanced Key Usage flags
A digital signature that covers all fields of the certificate except for the signature itself, using a private key corresponding to the issuing certificate
Note that the Registration Authority or Certification Authority can modify the SubjectDN if needed (e.g., only include items that have been authenticated) as well as the Requested Key Usage and Enhanced Key Usage flags
.
PKCS #11 – Cryptographic Token Interface (Cryptoki)
An API for communicating
with a hardware cryptographic token, such as a USB PKI token or PKI Smart card. This allows you to initialize a token, load certificates and private keys into the token, view the current contents of the token, delete certificates and private keys from the token, etc.
Windows uses PKCS 11 to integrate hardware tokens into the Certificate Store (so they appear to be in the local Certificate Store but really are in the token).
Note that each cryptographic token includes a PKCS11 .DLL to allow a generic PKCS 11 API to communicate with that type of token. When you install the token driver, it usually installs this .DLL into your Windows subdirectory. The .DLL must be installed before you can work with that kind of token.
Many cryptographic APIs include PKCS #11 interfaces for working with hardware tokens.
RSA turned control over PKCS 11 to the OASIS PKCS 11 Technical Committee.
PKCS #12 – Personal Information Exchange Syntax Standard
This standard
specifies a container that can securely hold certificates and private keys. It is currently specified in RFC 7292, “PKCS #12: Personal Information Exchange Syntax v1.1,” July 2014.
When you create the container, you provide a passphrase (an alphanumeric string) that is converted into a 3DES key by PKCS #5. The private key is encrypted using this key. To open the container, you must supply the original passphrase used to create it. Because the private key is encrypted, it is safe to store PKCS12 files in a database or file system or send via unsecured channels such as email, FTP, etc.
For example, if the CA creates the key pair, they can provide the certificate and private key to the user in a PKCS12 container, but they must securely provide the passphrase needed to open it to the customer as well (via a different channel).
One clever use of PKCS12 containers is for private key escrow (where the organization can recover the private key of any user for law enforcement reasons or if the key owner leaves the organization without surrendering their private key). You create a PKCS12 container with their certificate and private key, using a randomly generated passphrase, and then encrypt the passphrase with a special “escrow” digital certificate. The corresponding private key can be kept securely with access limited to corporate executives with secure auditing. To recover the user’s key, you decrypt the passphrase using the escrow private key and then open the container with the recovered passphrase.
The recommended file type for a PKCS12 container is “.p12”, but on Windows, “.pfx” is commonly used. Microsoft refers to PKCS12 containers as “Personal Information Exchange” files
.
Internet Request for Comments (RFCs)
There are currently over 8,000 RFCs, including the ones listed earlier that are the current specifications for the old PKCS standards from RSA.
There are quite a few standards created by the PKIX working group (for PKI using X.509 certificates). A long list of PKI-related RFCs can be found at www.oasis-pki.org/resources/techstandards/.
RFC 4211 – “Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF),” September 2005. This RFC specifies the format for messages used to request a certificate (CSR).
RFC 3647 – “Internet X.509 Public Key Infrastructure Certificate Policies and Certification Practices Framework,” November 2003. This RFC provides guidance on how to draft a Certification Practices Statement (CPS) that explains how your CA operates. Every issued certificate should include the URL of that CA’s CPS. This CPS becomes legally a part of the certificate by this inclusion.
RFC 5272 – “Certificate Management over CMS (CMC),” June 2008. This RFC specifies how to do certificate management via CMS messages, typically over email.
RFC 5280 – “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008. This is the main specification for the X.509 v3 certificate as well as the Certificate Revocation List (CRL) v2.
The X.509 certificate was originally specified in ISO X.509, which was part of the OSI X.500 Directory Services (which ran on OSI networks). It included specifications for Distinguished Names and other concepts. The current version is v3. RFC 5280 is one of several “profiles” that specify the use of X.509 certificates in particular environments (in this case, the Internet).
A Certificate Revocation List (CRL) is a sorted list of serial numbers of revoked certificates from a given certificate hierarchy (and the reason those certificates were revoked). It is a “blacklist” that identifies only revoked certificates. If the serial number of the certificate in question is not on the list, then it has not been revoked. Each CRL is digitally signed by the CA to provide authentication of the issuing CA and detect tampering with the list.
Each certificate that supports revocation checking via CRL includes the URL of the CRL server at the CA (as the CRL Distribution Point). CRLs may be published via HTTP, HTTPS, LDAP, or LDAPS. CRLs are updated periodically (e.g., once a day, once a week, etc.). Each CRL indicates when the next CRL for this certificate hierarchy will be published.
RFC 6960 – “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP,” June 2013. This is the main specification for the Online Certificate Status Protocol (OCSP) used by many CAs as an alternative to Certificate Revocation Lists (CRLs).
Each certificate that has an OCSP server includes the URL for that server in the certificate (in an AIA field). Unlike CRLs, you connect to the correct OCSP server and request the current revocation status of a single certificate by serial number. The response is digitally signed and can include one of three values for status: good, revoked, and unknown.
RFC 8446 – “The Transport Layer Security (TLS) Protocol Version 1.3,” August 2018. This specifies the Transport Layer Security (TLS) protocol that can protect any text-based protocol with a request/response design. It is used with HTTP, SMTP, IMAP, LDAP, etc. It requires a TLS Server Certificate on the server to enable TLS and provide server-to-client authentication. It optionally can use a TLS Client Certificate on the client to provide strong client-to-server authentication. It also supports secure exchange of a symmetric session key to enable encryption of the entire session after the handshake. This can be done with asymmetric key encryption and decryption or via the Diffie-Hellman Key Agreement algorithm. Some applications are still using TLS v1.2, but versions 1.1 and earlier (including SSL 2.0 and 3.0) have been deprecated.
