CMP (Certificate Management Protocol)

CMP (Certificate Management Protocol) is specified in IETF RFC 4210, “Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP),” September 2005. It uses CRMF, which is specified in IETF RFC 4211, “Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF),” September 2005.

CMP uses messages in ASN.​1 (Abstract Syntax Notation One). This is a very complex format for objects and is used in X.509 digital certificates, PKCS #10 Certificate-Signing Requests, and other cryptographic objects. It is very difficult to implement CMP because of this, and most implementations are only partially compliant. This leads to issues of interoperability between products using CMP.

CMP messages can be embedded in HTTP, layered over TCP, sent as a file over FTP or SCP, or sent via MIME-compliant email. Implementations exist in OpenSSL, Bouncy Castle, EJBCA, and other libraries.

CMP does not support user authentication, with username/password or Strong Client Authentication. It cannot manage per user information for forming a SubjectDN in a request. It does support submission of a CSR and retrieval of the generated certificate, among other functions.

CMC (Certificate Management over CMS)

CMC – Certificate Management over CMS. It is specified in IETF RFC 5272, “Certificate Management over CMS (CMC),” June 2008. It is based on PKCS #10 and CRMF (Certificate Request Message Format), specified in RFC 4211, “Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF),” September 2005.

CMS is Cryptographic Message Syntax, which is specified in IETF RFC 5652, “Cryptographic Message Syntax (CMS),” September 2009. It is based on PCKS #7, which was based on the older Privacy-Enhanced Mail (PEM) standard. CMS is similar to S/MIME digital envelopes.

CMC messages can be sent over MIME-compliant email or as files via FTP, SCP, etc. It includes a Proof of Possession mechanism to ensure that the requester possesses the private key corresponding to the submitted public key. This is basically the crypto challenge described elsewhere in this book.

The more recent EST (Enrollment over Secure Transport) is a profile of CMC.

SCEP (Simple Certificate Enrollment Protocol)

SCEP (Simple Certificate Enrollment Protocol) was originally created and maintained by Cisco. Its original purpose was to allow a network administrator to automate enrollment of digital certificates by various Cisco network devices from a central SCEP server. No user management or authentication was required as all nodes including the server were managed by one person (or group).

There was a long attempt to standardize SCEP in an RFC which kept failing. Finally in September 2020, SCEP was finally specified in RFC 8894, “Simple Certificate Enrollment Protocol,” September 2020. More recently, SCEP has been replaced by EST.

There are many commercial and open source implementations of SCEP, some of which will not interoperate due to the long-delayed standardization effort.

SCEP is based on CMS and PKCS #10. It is a simple client/server protocol. There is no user database or per user authentication (either username/password or Strong Client Authentication). This makes it of limited use in many situations. There is a way for each SCEP client to be issued a special certificate that can be used in SCEP Secure Messages to identify the requester, but this is not done during the connection (as is the case with many network protocols). See Section 3 of RFC 8894.

There is no database of per user information which could be used to simplify the process of creating a SubjectDN. Such database could also allow the user information to be centrally managed and preapproved for a given organization.

It is possible to add an SCEP server to any Certification Authority, and many already support it. There are various SCEP clients and APIs for adding SCEP support to applications or devices that require certificates. There are both commercial and open source implementations of SCEP clients and servers.

EST (Enrollment over Secure Transport)

EST is specified in IETF RFC 7030, “Enrollment over Secure Transport,” October 2013. It was created to allow clients to request and obtain TLS Client Certificates and the associated “CA” Certificates (Root and Intermediate Certs) from a CA. It was intended to replace SCEP (see previous). It is implemented over HTTPS. It uses certain Uniform Resource Identifiers (URIs) from RFC 8615, “Well-Known Uniform Resource Identifiers (URIs),” May 2019. Well-Known URIs can be registered at www.iana.org/assignments/well-known-uris/.

It does not appear to support requesting TLS Server Certs, Document Signing Certs, or Code Signing Certs. An S/MIME Certificate is a minor variation of a TLS Client Cert, so it should be supported (depending on implementation).

Bouncy Castle cryptographic API includes open source implementations of client-side EST for both Java and C#.

ACME (Automated Certificate Management Environment)

ACME (Automated Certificate Management Environment) (v2) is specified in IETF RFC 8555, “Automated Certificate Management Environment (ACME),” March 2019. It is heavily used by Let’s Encrypt which is a non-profit Certificate Authority that issues free TLS Server Certificates for use in securing websites and email servers. Many “casual” websites use Let’s Encrypt certificates via automation plug-ins such as Really Simple SSL for the WordPress content management system. Real commercial websites still tend to use “real” certificates from commercial Certification Authorities.

ACME was designed to automate the process of requesting a TLS Server Certificate, including establishing ownership of the relevant domain name. There are various plug-ins for content management systems such as WordPress that implement ACME (e.g., Really Simple SSL). If you run a website on WordPress, this can simplify obtaining and installing a TLS Server Cert for your site, at no cost (at least when using the base-level Really Simple SSL).

ACME is not capable of requesting TLS Client Certificates, S/MIME Certificates, Document Signing Certificates, or Code Signing Certificates. It only supports requesting TLS Server Certificates and only from Let’s Encrypt. I don’t believe any commercial CAs support it (there would be no financial incentive to do so).

IRP (Identity Registration Protocol)

IRP can be implemented as part of a CA (as we did in our IDCentral CA), or it can be grafted onto any existing CA (and we have grafted it only several existing CAs, including GlobalSign, Entrust, EJBCA, and MS Certificate Services. In this usage, IRP is similar to ODBC for databases. Every Database Manager has a unique API and implementation of SQL. ODBC allows you to write clients to a single “standardized” API, and an ODBC connector maps the ODBC API calls to any supported Database Manager. This makes it easy to use any Database Manager from a given client rather than having to modify it heavily to change to another Database Manager. Many CAs have unique RESTFUL APIs. If you graft an IRP “Front End” onto a CA, any IRP-enabled client can now do full certificate management with that CA with no rewriting required.

Our IRP implementation has a unique feature with Strong Client Authentication (SCA). Most servers secured with TLS only allow turning SCA on for all users or off for all users. It can allow SCA to be “allowed” vs. “required,” but until it is “required,” a hacker could attack username/password authentication (UPA) for any user. We allow you to enable SCA on a per user basis (some users can require SCA while others still use UPA). This allows a gradual phase in of SCA. You can start with all users using UPA, and as each user obtains their TLS Client Certificate, our IRP server can automatically disable UPA for them. You can even provide a timeout after which only SCA is allowed for all users (e.g., give users two weeks to enable SCA). If a given user loses their client cert, the administrator can re-enable UPA (or even automatically re-enable it if the user can answer security questions), either for some period of time or until they obtain a client cert. This eliminates the possibility of hackers attacking the UPA scheme except for users who have had UPA temporarily enabled, while still allowing a gradual deployment of SCA.

Example of Certificate Request and Retrieval Using IRP

This demo is done using SixWallet, a native Windows application that implements IRP. The IRP server, in this case the Sixscape IDCentral CA, deployed in AWS.

The main window of SixWallet looks like the “Certificate Manager” in Internet Explorer, with some additions (Figure 9-1):

If you double-click (or right-click View Certificate) a certificate in the Person, Other People, Intermediate Certificate Authorities, or Trusted Root Certification Authority tabs, it will display the cert, as shown in Figure 9-2.

The other tabs allow viewing details of the certificate and the Certification Path (trust chain).

The CSRs tab (not found in the Internet Explorer Certificate Manager) allows you to create a CSR, optionally with the help of IRP (e.g., to get the IRP user’s Subject Distinguished Name fields), as shown in Figure 9-3.

The Token column indicates whether this is for a soft token (private key kept in MS Certificate Store) or a hard token (hardware crypto token, e.g., smart card). SixWallet allows you to create key material directly in a hardware token, even remote from the CA. This is the highest level of security, but if you do this, there is no backup of your private key possible. This is fine for Strong Client Authentication or digital signatures but is risky for encryption. If you lose the private key needed to open encrypted files, there is no way to decrypt those files.

The Algorithm column specifies the cryptographic algorithms used to create the key pair and cert. The first part, before the slash (e.g., RSA), indicates the public key algorithm of the generated key pair and of the public key part of the signing algorithm. The second part, after the slash (e.g., SHA256), indicates the HASH part of the signing algorithm. After 2016, nobody should be using SHA1 (it has been deprecated).

If the algorithm uses ECC (Elliptic Curve Cryptography), for example, ECDSA, then the Elliptic Curve column contains the name of the specific Elliptic Curve used in this CSR (there are many possible).

The Key Size column contains the length in bits of the key. For RSA, this is usually some multiple of 1024. For ECC, this may be various lengths, for example, 112, 160, 224, 256, etc. The curve selected determines the key length in this case. Note that 256-bit ECC is about as strong as 2048-bit RSA.

The Created column contains the date and time this CSR was created. It helps in reassociating the retrieved certificate with the correct private key and makes each CSR unique in the local DB and on the CA. The syntax for this timestamp is ISO 8601 (yyyy-mm-ddThh:mm:ss:fff).

The Private Key column indicates whether there is a private key corresponding to this CSR in the local DB. Normally, if you create a CSR, a private key is created at the same time. If you import a CSR without importing a private key, you could have a CSR with no private key. Private keys in the local DB are always kept encrypted. When you export a CSR, if there is a private key associated with it, it will also be exported.

If you right-click the CSR page, the context menu has the following options. For some menu items, you right-click a listed CSR to view/delete/whatever and then select the option. For others, you just right-click anywhere the CSR page.

CSRs (Create/Manage CSR)

With CSRs, the viewer is a bit different from the certificate viewer (note that the public key and private key are not shown). You can also modify the fields in the Subject DN to create a new CSR. You cannot change anything in a certificate once it is signed, but you can create a new CSR (and private key) based on an existing CSR. This viewer allows you to see the contents of an existing CSR (right-click a CSR and select View/Manage CSR, or double-click a CSR). You can also modify the fields and create a new CSR based on an existing one. See Figure 9-4.

When you are viewing an existing CSR, you can save it as a new CSR in the local database or submit it to a CA via IRP.

If you select Certificate Type as Node (Server), the form changes as in Figure 9-5.

Note that the Email Address and User Principal Name fields are cleared and disabled. These fields are not normally included in a node (server) cert. Also, the label for the first field (CommonName) changes from User’s Name to Node FQDN (for Fully Qualified Domain Name).

Assuming you have created an IRP account and that account has user info (the information used to create a Subject Distinguished Name in the CSR) defined for it, you can load that information into the CSR form by clicking Load User Info (see Figure 9-6).

The IRP account for this user is [email protected]. When you click Load User Info, it connects via IRP and downloads Alice’s user info and loads it into the fields of the CSR form.

This helps you create a CSR quickly and accurately. You can create or update an IRP account via Main Menu/Accounts/IRP/(right-click) Create New Account and view or manage the user info via Main Menu/Accounts/IRP/(right-click an IRP account) Connect To Server. You can allow users to create and manage their own IRP accounts, or they can be controlled centrally by a Security Admin.

You will be asked to enter a passphrase that is used to protect the private key in the local database until needed. See Figure 9-7.

Assuming everything works, you will see the following (Figure 9-8).

You can view the CSR details at any time, but not the private key or the public key. You can view the CSR in PEM format in order to cut and paste it into a web form at a CA. You can also submit the CSR to a CA that supports IRP via that protocol (this requires access to a CA that supports IRP and an IRP account on that CA). This is done with the Submit CSR via IRP button.

If you submit a CSR to a CA that supports IRP, the RA (Registration Authority) will review the request and approve or deny it. This involves verifying that all the information in the Subject Distinguished Name is accurate and current and that you have the right to request a certificate using the fields in the submitted Subject DN. They can also remove any item from the submitted Subject DN that they can’t verify, before approving the CSR for signing.

If the RA approves the request, then the CA (Certification Authority) will create a signed digital certificate from the CSR, using the specified algorithm. You can then use SixWallet to retrieve that certificate, reassociate it with the private key (from when the CSR was created), and store the resulting key material in your local MS Certificate Store (in the My Certs folder). This is done with the Reassociate Cert option on the CSR page (right-click the CSR used to request the cert and select Reassociate Cert) and then clicking the Get Cert via IRP button in the Reassociate Cert dialog.

CSRs (Reassociate Cert)

This is the most complex function. It assumes you have somehow received notification that the new cert is ready from the CA. You can download the new cert via IRP from a CA that supports IRP during this function. This cert should be a file in PEM or DER format (e.g., .crt or .cer file type). This cert is created by the CA and does not currently have an associated private key. That is the point of this function – to reassociate the new cert with the private key generated when you created the CSR.

When you right-click a CSR and select Reassociate Cert, you should see the information from the CSR as follows (Figure 9-9).

If you are using IRP, you can select the account to use with the IRP Account ComboBox at the bottom of this form. This should be the same IRP account you used to submit the CSR (and will be loaded for you). Just to remind you, IRP accounts are created with IRP: Create New IRP Account.

You can’t change any fields in the cert at this point. Whichever scheme you use, you will need to provide the passphrase that was used to protect the private key in the local database (Figure 9-10).

Enter the passphrase, confirm it, and click OK.

You can now choose whether the private key will be exportable and the protection level (Figure 9-11).

If you chose Protected, then you can choose medium- or high-level protection. If you chose high level, then you will need to enter a passphrase that you will need to enter every time you access that private key.

Select preferred private key options, and click OK.

If you are using IRP, shortly, the following box will display (Figure 9-12).

Dismiss this by clicking OK.

You will then get to enter a passphrase to protect a new PKCS #12 (Figure 9-13).

Enter passphrase to protect the automatically generated PKCS #12, and click OK. You will then see the following (Figure 9-14).

Dismiss this with OK. You will then see the following (Figure 9-15).

If you look in the Personal page, you will see the new certificate (Figure 9-16).

Now select the PKCS12s tab to see the new PKCS #12 in the local DB. See Figure 9-17.

SixWallet is basically a manual client for IRP. It is also possible to implement the IRP protocol in any client application or device that has network connectivity and automate the earlier steps to hide all the complexity from the user.

Sixscape has a plug-in for Microsoft Outlook that fully automates the management of S/MIME Certificates using IRP. The first time you use an account that does not currently have an S/MIME Certificate, it will obtain one for you and install it in Outlook, ready to use (in about ten seconds). This can be done from any CA that supports IRP.