Automated Certificate Management Environment (ACME) Challenges Using an Authority Token
draft-ietf-acme-authority-token-09

(1) Let's talk briefly about how JWT issuers are identified.  Section 4
has some text:

   For this ACME Authority Token usage of JWT, the payload of the JWT
   OPTIONALLY contain an "iss" indicating the Token Authority that
   generated the token, if the "x5u" element in the header does not
   already convey that information; typically, this will be the same
   location that appeared in the "token-authority" field of the ACME
   challenge.  [...]

While "iss" is the default way to identify a JWT issuer, the JWT BCP
(RFC 8725, BCP 225) does not make a strong recommendation that it is the
preferred way to do so, with the implication that other ways to identify
the issuer are reasonable.  However, the text here only mentions the
"x5u" element as an alternative to "iss" for identifying the issuer,
which does not seem to be a comprehensive depiction of the JWT
ecosystem.  Issuers could be identified by other X.509 related protected
headers such as "x5c", or in some situations just by the key used for
signing (when that key is accompanied by other configured metadata),
among other things.  So, I don't understand why we call out "x5u"
specifically here and apparently don't allow other ways of identifying
the issuer.

(2) We seem to describe the contents of the "atc" JWT claim as an array
in §4, but the examples show its payload as a JSON map.  Which is
correct?

(3) I'd also like to have a (hopefully brief) discussion about the
properties that we do and do not provide as relates to binding an
authority token to an ACME client.

In particular, in the REST API to the Token Authority, we have the
client provide the fingerprint of its ACME key/identity, but the Token
Authority does not do any validation on that value and is expected to
just include it directly in the issued token.  This means that some
other entity X who is not the legitimate client but knows their key
(fingerprint), and is also authorized to use a given identifier by the
Token Authority, could cause a token to be issued that references the
legitimate client's key.  (Note that X could learn the fingerprint of
the client by, e.g., being a semi-trusted CDN in front of the ACME
server as considered by RFC 8555§10.1.)  That token would then only be
useful by the legitimate client, and so there would need to be some
other vulnerability that lets X trick the client into using that token,
but it still seems that we have broken the chain of custody that would
let us claim that the authority token was generated "based on a request
from the client" (§3.3).  In particular, it seems that (with these
preconditions) we might have a scenario where a client gets issued a
certificate for numbers that it is not actually authorized for!
This weakness does not immediately lead to an obvious vulnerability, as
it requires two additional factors to be exploited -- the attacker must
themselves be authorized at the Token Authority, and there needs to be
some as-yet-unknown mechanism for the attacker to cause the client to
use this new/different token -- but I think we at a minimum need to
document the properties that we don't provide.

We could choose to make the mechanism more complicated and close off
this loophole by requiring proof of possession in the request to the
token authority.  The obvious way to do this robustly would require
another round trip, though, to let the token authority provide a nonce
that the proof of possession is provided over.  Sometimes we can use a
TLS Exporter value to save on that round-trip, but I haven't thought
through very carefully what that would look like here.  The request to
the token authority would probably need to convey the entire public key,
not just the fingerprint, so that the signature could be verified.

There's another risk relating to thumbprints that is probably worth
documenting -- we in effect are hardcoding a dependence on SHA256 for
the fingerprints.  (I'm happy to see that the wire-format of the
thumbprint does identify the hash function used, so a transition
mechansims should be pretty straightforward.)  In light of the BCP 201
guidance for building in algorithm agility, I think we should say that
we are hardcoding SHA256 and SHA256 is believed to still be quite strong
(the SHA-3 contest helped solidify that position), but if a second
preimage attack for SHA256 is found, an issued authority token could be
used with a different ACME account key.  We can also go on to say that
in that event, implementations can migrate to using a different hash
function for the fingerprints due to the in-band hash function
identification in the fingerprint field.  Such a transition would
require a new RFC to actually specify the details of the new behavior,
but would not be very invasive to implementations.

(4) We mention almost in passing that the tkauth-01 challenge type has a
new "token-authority" field that designates a location where a token can
be acquired.  I think we need to have some more explicit discussion of
the semantics of this field and how it's populated, especially in light
of how this document implies that typical usage will include
"token-authority" but the companion document implies that
"token-authority" will not be in common usage.  We definitely need some
discussion of the security considerations of having party X tell the
client to go authenticate to party Y and do some thing; this type of
flow is very prone to enabling phishing attacks where the client gives
party Y credentials that party Y is not supposed to have.  In many cases
it ends up being a de facto requirement that the client is configured
with a specific list of allowed values for "party Y" and must reject
anything not known to be trusted.  (So, in this case, that would have
the client reject any token authority URLs that are not in this
preconfigured allow-list.)