10

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?

7
+100

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.

1

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.

  • A 1024 bit RSA key is certainly not overkill given that 768 bit keys were vulnerable more than 5 years ago, 1024 is the bare minimum now. Also, quantum computing will break ECC just as much as RSA. – AndrolGenhald Nov 28 '17 at 20:21
  • 1
    It was more as an example to show that ECC and RSA keys can have the same strength even though ECC can be 10-50% smaller bit-wise. And as to whether quantum computers will be able to break either or both encryptions, you should look at this question which has very interesting answers supporting both sides - discussing how the architecture of the chips and whatnot affect it. – adam Nov 28 '17 at 20:37
  • Interesting, I just found out that RSA actually could be quantum safe. Either way though, both RSA and ECC as used today are vulnerable to Shor's algorithm. – AndrolGenhald Nov 28 '17 at 20:59
  • @AndrolGenhald LOL Bernstein's joke paper strikes again! RSA is quantum safe if you use 1TB keys, and are willing to wait 2 months for your laptop's full disk encryption after each reboot. The point of that paper is to settle the debate among academic about whether "Post Quantum RSA" could ever be practical. The answer is a fat No. – Mike Ounsworth Nov 29 '17 at 3:42
  • @AdamBromiley Minor quibble, technically username/password is a form of shared secret, so if you argue that "anyone who knows the key can get a certificate", then you need to make the same statement about the username / password method. – Mike Ounsworth Nov 29 '17 at 3:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.