There are many good reasons to sign HTTP messages, to ensure authenticity and integrity of HTTP service calls (a.k.a. REST APIs). Now that RFC 9421 is finally published, we can expect many people to migrate from provisional and proprietary solutions into the standard.

My Go (Golang) implementation covers nearly the entire RFC, and has been tested with all the test vectors that are sprinkled all across the standard. The package is also reasonably well documented, with a number of examples included. It is early days for the standard - and for the Go package - so let me know if you find the library useful. And definitely let me know if something is not working right!

There’s a large community of people working now on service-to-service authentication, which just happens to be a natural use of HTTP Message Signatures. I hope my package is put to good use in securing service infrastructure.

Yaron Sheffer, Peter Saint-Andre and Thomas Fossati

There’s a new standard out, RFC 9325, with guidelines on secure use of TLS. This short post will explain some of the history behind it and why you might want to explore this document.
​
In early 2013, we started working on a set of guidelines for Transport Layer Security (TLS) deployments. TLS is the security protocol that underlies much of today’s internet. In fact, almost all web pages today are served over HTTPS, which means the HTTP protocol is layered on top of TLS. Many years ago, the same protocol was called Secure Socket Layer or SSL, and this is the name many people still use to refer to TLS.
​
Back in 2013, TLS was in crisis. It was becoming increasingly clear that the internet needed to move into a fully encrypted model, especially after the Snowden revelations in mid-2013. TLS was the obvious technology to do the job. But...

In early March 2020, just as the world was bracing for the COVID-19 pandemic, my co-authors and I published RFC 8739. This new standard introduced the concept of short-term, automatically renewed (STAR) certificates into the X.509 certificate universe, and specifically to the large and vibrant ACME ecosystem. A year and a half later, we followed that with the publication of RFC 9115 which builds on the ACME and STAR foundations to enable automated, easy to manage certificate delegation.

ACME is an open protocol for automated management of public-key certificates. It underlies the free and hugely successful Let’s Encrypt certificate authority (CA) and is now being adopted by commercial CAs as well. ACME enables to automatically order, renew and revoke certificates using a simple REST API, and there are many open source tools based on this API that make it easily usable by administrators...

My coauthors and I just published RFC 8739 on Short-Term, Automatically Renewable (STAR) certificates in the ACME automated certificate management protocol. This post explains what STAR certificates are, why we see them as an essential next step for the global public key infrastructure (PKI) and how they are enabled by the new ACME protocol.

Some RFCs published by the IETF are fixes for well established technologies. This is true for my own TLS Best Current Practices and the more recent JWT BCP. In contrast, the STAR RFC aims to kickstart new technology that we see as essential to the new ways applications are being deployed. To see why, we need to dive into the theory – and the very different practice – of PKI.

If you’ve only learned the theory of public key infrastructure in school, you could be forgiven for having a traditional view of the certificate lifecycle:

• Certificates are...

Just Published: RFC 8672 on Server Identity Pinning – a modern, lightweight alternative to certificate pinning

The RFC Editor just published RFC 8672, a specification that can potentially make TLS deployments much more secure by virtually eliminating the risk of forged public-key certificates.

For many years we have been seeing attacks on certificate authorities (CAs). All CAs are essentially created equal, and if a rogue CA issues a certificate for example.com and hands it to a malicious server, there’s nothing to stop clients from connecting to the server and trusting its identity. The same is true for servers located behind enterprise firewalls. A rogue CA could just as well issue a fake certificate for finance-dept.example.com, regardless of whether it can access the server or not.

An often used approach within enterprise networks is certificate pinning. Normally we trust a...