For many years SCEP was a simple and widely used protocol for obtaining X.509 certificates. However, not too so long ago another protocol called EST (RFC 7030) was developed.
What are the main reasons to move out from SCEP in favor of EST?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
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.
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.
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):
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).
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.
An advantage of EST is that it supports Elliptic Curve Cryptography (ECC) encryption compared to SCEP's RSA encryption. The major advantage of ECC over RSA is that it can provide the same amount of security but with much smaller (50% smaller) key sizes. Therefore if you have two identical limited memory devices, the one that integrates the EST protocol would have much securer certificates than the one that only integrates SCEP. A 15,360 bit RSA key has the same cryptographic strength as a 521 bit ECC key - 15,360 bits may seem like overkill but a discussion here shows sides saying quantum computers could be able to break RSA in a decade or so (though some answers say both are as easily breakable so read all the answers and make your own decision on it ^-^).
Another factor is that in EST the certificate can only be given to the client, from the certificate authority, who holds the unique private key or username/password. Hence the client can only get the certificate for themselves and not anyone else (EDIT: unless they share their username/password, thus using a private key is better).
SCEP - on the other hand - is given to a client from the certificate authority using a shared key which is meant to be secret, however, the problem arises that anyone who knows the key can get a certificate, thus the client could generate copies of the certificate to pass on to someone else and so on...
These are only the security advantages that EST holds over SCEP - Cisco have an interesting document about other advantages and differences here.
EDIT: As discussed in comments.