Simple Certificate Enrollment Protocol

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

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[edit]

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 IOS operating system (even if Cisco is now pushing the slightly more featured EST) and iPhones to enroll in enterprises PKI. Most PKI software (specifically RA implementations) supports it, including the Network Device Enrollment Service (NDES) of Active Directory Certificate Service.

Criticism[edit]

  • 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 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. The CRMF format, as used by CMP and CMS, is more flexible here, supporting also keys that are usable for encryption or key agreement only.
  • Although proof-of-origin of certificate enrollment requests, i.e., authentication of the certificate requestor, 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.

History[edit]

SCEP was designed by Verisign for Cisco[1] as a lean alternative to Certificate Management over CMS (CMC) and the very powerful but also rather bulky Certificate Management Protocol (CMP). 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.[2] 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.[3] The new version also supports enrollment of non-RSA certificates (e.g., for ECC public keys).

See also[edit]

External links[edit]

References[edit]