Bouncy Castle adds support for EST

Note: We would especially like to thank the Crypto Workshop team for their contributions to this post and the fruitful collaboration.

Recently Crypto Workshop has been working on adding support for the EST protocol in Bouncy Castle (BC) Cryptography APIs. Bouncy Castle (BC) is a prominent library that provides cryptography for Java applications.

Enrollment over Secure Transport (EST) is a standard (RFC7030) designed to improve the provisioning of digital certificates. At Cisco, we believe in a more secure and flexible certificate enrollment protocol like EST. We have blogged about it before and have written about how EST compares with SCEP and other certificate management protocols, and why the industry has started to shift to it. EST is adopted in standards like IEC 62351-9 and IETF BRSKI. Some of our products already support EST for digital certificates (e.g., Cisco IOS and IOS-XE), but EST endpoints don’t just operate by themselves. EST involves a certificate consumer and a certificate provider, usually called a Certificate Authority (CA). We need to ensure that our EST solutions are compatible with third parties such as CAs, authentication servers, and endpoints.

For that reason, we worked with the Bouncy Castle team to ensure interoperability of BC’s implementation with EST implementations (libEST and more) used in Cisco products. The EST operations we tested initially were /cacerts, /csrattrs, /simpleenroll and /simplereenroll. After concluding our testing, we have confirmed that:

• Cisco products that offer Registration Authority (RA) functionality can successfully allow Cisco IOS an IOS-XE products to communicate with BC’s implementation.
• libEST fully interoperates with BC’s implementation. The same holds for Cisco EST libraries.

The following are some things we learned in our collaboration:

• Language used in standards is sometimes open to interpretation. Implementers should try to stay close to the standard definition and standards’ authors should be as explicit and clear as possible when defining the protocol and provide examples that provide good coverage of the protocol.
• Implementer’s choices about details not defined in the standard should be well-thought and communicated in order to avoid incompatibilities.
• It is important to properly log protocol failures in order to trace back interoperability issues.
• Using a well-defined testing strategy can help in identifying implementation holes.

BC announced EST support in Release 1.57 on May 11, 2017. As recently various CAs have been working on supporting EST we are expecting Bouncy Castle’s EST support to further enable and promote the adoption of a more secure and flexible PKI for the future. Due to its high adoption rate, we expect the support of EST to benefit CAs and endpoint vendors that take advantage of BC APIs for their crypto.

Share