Simple Certificate Enrollment Protocol (SCEP) is described by the informational RFC 8894. Older versions of this protocol became a de facto industrial standard for pragmatic provisioning of digital certificates mostly for network equipment.

The protocol has been designed to make the request and issuing of digital certificates as simple as possible for any standard network user. These processes have usually required intensive input from network administrators, and so have not been suited to large-scale deployments.

Popularity

The Simple Certificate Enrollment Protocol still is the most popular and widely available certificate enrollment protocol, being used by numerous manufacturers of network equipment and software who are developing simplified means of handling certificates for large-scale implementation to everyday users.^{[citation needed]} It is used, for example, by the Cisco Internetworking Operating System (IOS), though Cisco promotes the Enrollment over Secure Transport (EST), with additional features, and iPhones (iOS) to enroll in enterprise public key infrastructure (PKI).^[1] Most PKI software (specifically RA implementations) supports it, including the Network Device Enrollment Service (NDES) of Active Directory Certificate Service and Intune.^[2]

Criticism

• Legacy versions of SCEP, which still are employed in the vast majority of implementations, are limited to enrolling certificates for RSA keys only.
• Due to the use of the self-signed PKCS#10 format for Certificate Signing Requests (CSR), certificates can be enrolled only for keys that support (some form of) signing. A limitation shared by other enrollment protocols based on PKCS#10 CSRs, e.g., EST and ACME, or even the web-based enrollment workflow of most PKI software where the requester starts by generating a key pair and a CSR in PKCS#10 format. For example ACME, which also uses PKCS#10, issues TLS certificates which by definition must be capable of signing for the TLS handshake. However this distinction is so far mostly theoretical since in practice all algorithms commonly used with certificates support signing. This may change with post-quantum cryptography where some keys only support KEM. The CRMF format, as used by CMP and CMS, is more flexible here, supporting also keys that are usable for encryption only.
• Although proof-of-origin of certificate enrollment requests, i.e., authentication of the certificate requester, is the most critical security requirement, for pragmatic reasons its support is not strictly required within SCEP. Signature-based client authentication using an already existing certificate would be the preferred mechanism but in many use cases is not possible or not supported by the given deployments. As an alternative, SCEP just provides the use of a shared secret, which should be client-specific and used only once.
• The confidentiality of the shared secret optionally used for source authentication is fragile because it must be included in the 'challengePassword' field of the CSR, which is then protected by an outer encryption. It would have been more secure to use a password-based MAC algorithm such as HMAC.
• Encrypting the whole PKCS#10 structure in order to protect the 'challengePassword' field (which is used for self-contained source authentication) has a further drawback: the whole CSR becomes unreadable for all parties except the intended ultimate receiver (the CA), although most of its content is not confidential. So the PKCS#10 structure cannot be checked by intermediate agents such as an RA.

History

SCEP was designed by Verisign for Cisco^[3] as a lean alternative to Certificate Management over CMS (CMC) and the very powerful but also rather bulky Certificate Management Protocol (CMP). It had support from Microsoft early with its continuous inclusion in Windows starting with Windows 2000.^[4] In around 2010, Cisco suspended work on SCEP and developed EST instead. In 2015, Peter Gutmann revived the Internet Draft due to SCEP widespread use in industry and in other standards.^[5] He updated the draft with more modern algorithms corrected numerous issues in the original specification. In September 2020, the draft was published as informational RFC 8894, more than twenty years after the beginning of the standardization effort.^[6] The new version also supports enrollment of non-RSA certificates (e.g., for ECC public keys).