Why one should prefer EST protocol instead of SCEP?
What is SCEP?
Simple Certificate Enrollment Protocol is a certificate enrollment protocol originally defined by Cisco in the 2011 IETF Internet-Draft draft-nourse-scep, and more recently in the 2018 IETF Internet-Draft draft-gutmann-scep out of the University of Auckland.
What is EST?
Enrollment over Secure Transport (EST) is a certificate enrollment protocol defined by Cisco, Akayla, and Aruba Networks in RFC 7030. EST can be thought of as an evolution of SCEP. Cisco provides a nice guide to understanding EST, which is spun to favour EST.
SCEP vs EST
Similarities
Both protocols are very similar in that the client sends CMS (aka PKCS#7) and CSR (aka PKCS#10) messages to the Certificate Authority, signed with a pre-existing certificate in order to enroll for a new certificate with the given CA.
They both support the following methods for the client to prove its identity to the CA (though the exact details differ):
- CMS / CSR messages signed with a previously issued client certificate (e.g., an existing certificate issued by the CA). This is typical for a certificate renewal.
- CMS / CSR messages signed with a previously installed certificate that the CA has been configured to trust (e.g., manufacturer- installed certificate or a certificate issued by some other party). This is typical for IoT devices, mobile devices, etc, that have a certificate injected during manufacture, and where the CA has been configured to trust the manufacturing CA.
- A shared secret that has been distributed to the client out-of-band.
Differences
The main difference between them is that EST uses standard TLS as the transport security layer, requiring that the certificates above be provided for TLS client-authentication in addition to signing the CMS and CSR messages.
In SCEP, the shared secret auth method is done by including the secret in the challengePassword field of the CSR, and creating a disposable self-signed certificate to sign the CMS message with.
Since EST uses standard TLS, it has two methods for enrollment using a shared secret:
Server-only TLS with HTTP username/password basic auth, where the username and password are the shared secret distributed out of band.
Mutual-auth TLS using a Pre-Shared Key (PSK) cipher suite. Neat side-effect is that this allows the client to authenticate the CA without needing to know in advance which CA it will be getting a cert from (ie no need to distribute the Root CA cert in advance).
Summary
Both are acceptable protocols for automated certificate enrollment with a PKI and offer similar security characteristics.
The advantages of EST are that it outsources its transport layer security to standard TLS, and therefore will continue to pick up security and performance improvements as new versions of TLS are released. This can also be an downside for constrained devices that do not want to dedicate code-space to a TLS implementation.
There are a lot of reasons to prefer EST over SCEP,
EST promotes enrollment based on X.509 client certificate authentication, helping on removing passwords from the past. EST can enroll clients (give an operational certificate) presenting a certificate of a third-party CA (a birth certificate). One a client is enrolled, it can renew its certificate authenticating again with its operational.
EST supports Elliptic Curves and separates very well transport and authentication from enrolling:
Transport is based on TLS. EST does not need to be updated to benefit from better cryptosuites.
Authentication can be implemented in TLS (client certificate authentication), in the HTTP transport channel (Basic Authentication), and in the CSR challenge code. Or even in the three layers at the same time!!!!
Enrollment is based on PKCS#10 (a standard Certificate Signing Request), and response is a plain X.509 certificate embedded in a PKCS#7. It is so simple that I am pretty sure that the EST protocol does not need to be updated if any of these (PKCS#10, PKCS#7, X.509) are updated.
EST provides the /serverkeygen method which may be a very interesting option for very compact IoT devices (i.e. AVR devices like Arduino).
EST is a lot easier to implement than SCEP, and therefore more secure and less dangerous than an overbloated protocol. In fact it can be implemented using curl and openssl.
If things got really complicated it can act as a CMC proxy offering the optional method /fullcmc.
I have implemented recently a EST client (PEST) written with Perl with a EST test suite (TEST) for configuring and testing EST servers. It can be downloaded from Github https://github.com/killabytenow/pest. I am pretty sure that writing a similar tool for SCEP would have ben a lot of harder. Personally and IMHO EST is always better than SCEP.