A Modest Proposal A New Challenge Type for ACME

Let's Encrypt! and The ACME Protocol

UPDATE: this feature was added to the official ACME spec although in a slightly different format - more info

I was excited when I first learned of the Let's Encrypt project over a year ago, simply because of the prospect of free certs for my own personal use and in some of my work scenarios, just as I have heard from others. But when I first dug into the underpinnings that would eventually make the project possible, namely the ACME protocol, I started to imagine the possibilities...

In today's technological world there are many applications of PKI and indeed it is a necessary part of just about anything has to do with anything about computers and the Internet. From Web sites that support authentication, commerce and access to sensitive data, to messaging systems -- everything from email to IM, to bulk messaging. From directory services to file sharing, wherever there is a need to guarantee privacy, authenticity and identity, the public-key infrastructure model is the de facto approach, and certificates are the central component, and certificate authorities, server and their clients are the principal actors.

So it is so amazing to me that after all this time, the way in which we manage our interaction between CAs and their consumers and the exchange of certificates between these parties is so non-standard and varied and for the most part, still very manual.

The ACME protocol can change all that.

In its wisdom, the LE organization conceived of a standard mechanism to facilitate automation of the request, authorization and exchange of PKI certificates. Indeed, the ACME protocol is a necessity to make the idea of the LE project viable. The need to support a secure mechanism to prove ownership of a domain name and to request and exchange an issued certificate for that domain, without any human intervention on the part of the CA, and quite possibly on the part of the client, is what makes the economics of a free CA service work.

But the ACME protocol is also designed for extensibility, and we can use that to

The Out-Of-Band Challenge Type

I propose introducing a new challenge type to support out-of-band validation of a requested Identifier. The out-of-band challenge type, or OOB, is a type of catch-all challenge type that is not actually meant to support the type of automation described above, but instead allows a CA to have a client satisfy whatever requirements are necessary but cannot yet be described by the other challenge types already included in the ACME specifcation.

The OOB would have associated with it some attributes that are intentionally oriented for human consumption and prosecution. The challenge type would be defined as follows:

type (required, string)

The string "oob-01".

authenticationToken (required, string)

A seemingly random, yet human-friendly value that uniquely identifies the challenge.

authenticationProof (required, string)

A seemingly random, yet human-friendly value that can be used as an authentication factor when this challenge is being satisfied.

instructions (required, string)

A B64U-encoded¹ message, intended for human inspection, that describes the next set of steps that should be completed by the client human actor to satisfy the challenge. The decoded form of this message may contain plain text or may make use of the markdown (MD) markup language to structure and stylize the content.

¹The B64U encoding mentioned above refers to the URL-safe, Base64 encoding used throughout the ACME protocol specification.

The authenticationToken and authenticationProof are meant to be used as proof of identity and control of the associated ACME registration used to initiate the Identifier validation. These could be used, for example, to identify a client to an operator or representative of a target ACME CA over a phone call or chat window. For this reason, it is important that the Token and Proof be relatively human-friendly and easy to read and repeat.

One suggested approach is to generate the Token and Proof as follows. For the Token, generate a random and relatively short six to eight character, case-insensitive, alphanumeric code. This code has be unique for some period of time to specifically identify this challenge under the target CA. For security purposes the Token should expire with some time, for example 24 hours. To make this code easy to use, convert the code using the NATO Phonetic Alphabet.

For the Proof, a slightly more complex value should be generated, such a string of random dictionary words combined together, say 5 to 8 words.

Here is a sample:

• We start with a randomly-generated alphanumeric code:
  • R8J79
• Then convert this using the NATO Phonetic Alphabet:
  • ROMEO - eight - JULIET - seven - nine
• Finally, string together 6 randomly selected dictionary words:
  • COLLECTION - FURNITURE - FISHING - STUDY - NEARBY - MODERN