Hi Aaron,
Right, so until today, I thought that the ACME Challenges were about
proving ownership of an identifier. If the ACME WG is ok with broadening
Challenges to other things, then our usecase fits right in and Challenges
would be the right place.
> I *believe* that the reason the design team has gone in this direction is
because the rats identifier does not appear in the final issued
certificate. Is that correct?
So let's run this use-case: You want to enroll your phone for a corporate
S/MIME cert over ACME. You do the usual "email-reply-00" Challenge as
specified in RFC 8823, but ALSO the ACME server wants you to prove that you
are running the latest Windows patch and the corp anti-virus, for which it
wants a RATS attestation. The point of the attestation is about proving the
state of the device, and has nothing at all to do with device identifiers.
The other technical challenge we ran into is that 8555 only requires the
client to respond to ONE challenge. This is fundamental to ACME and as far
as we can tell, there is no way to say "Please do one of {http-01, dns-01}
AND {device-attest-02}. This is why we moved this to the /new-order, /order.
TL;DR: ACME is fundamentally about identifiers that go into certs. We (much
like Kathleen's draft) are trying to do something in ACME that has
absolutely nothing to do with identifiers that go into the cert; but rather
about authorizing the whole cert issuance in the first place.
On Tue, 22 Jul 2025 at 07:43, Aaron Gable <aaron=
[email protected]> wrote:
> In the wake of the rushed IETF 123 meeting, I wanted to start a
> conversation here about the ACME RATS draft. I have a few thoughts, some
> large, some small, presented below in no particular order.
>
> ---
>
> The presentation said that the design team had come to the conclusion that
> the attestation evidence should be presented in the newOrder request,
> rather than as a traditional challenge. This design decision does not seem
> to be reflected in the current draft
> <https://www.ietf.org/archive/id/draft-liu-acme-rats-01.html>. nor in the
> main branch of the github repo
> <https://github.com/liuchunchi/draft-liu-acme-rats/blob/main/draft-liu-acme-rats.md>.
> Therefore I feel somewhat underprepared to discuss this design proposal in
> detail.
>
> That said, my gut reaction is that it is a bad idea. The beauty of ACME,
> in my opinion, is that it has an infinitely extensible collection of
> identifier types, and an infinitely extensible collection of challenges to
> validate those identifiers. If the thing that is semantically happening is
> that the server is validating a claim that the client is making, that
> should almost certainly take place as part of the existing extensible
> identifier/authorization/challenge mechanism, not get bolted on elsewhere
> in the protocol.
>
> I *believe* that the reason the design team has gone in this direction is
> because the rats identifier does not appear in the final issued
> certificate. Is that correct?
>
> If yes, *why* does no corresponding identifier appear in the cert? If the
> CA is enforcing that certain policies be met, then can't that be
> represented by a Certificate Policies extension? And then you're in an even
> better place, since enterprise clients can enforce that the specific
> Certificate Policy OID be present before they trust a cert.
>
> I'm imagining a world where the flow looks like this:
> 1. Enterprise client requests a new order for internal.tld
> 2. Enterprise CA says "sure, but only if you're up-to-date", and creates
> an order with two identifiers:
> a. {"type": "dns", "value": "internal.tld"}
> b. {"type": "policy", "value": "1.2.3.4.5"} (created by server policy,
> not because client requested it)
> 3. Enterprise CA creates a corresponding authorization object, too, with
> the same "policy"-type identifier, and two "rats-01" and "rats-02"
> challenges, representing different ways the client can prove that it
> complies with the policy.
> 4. The client fulfills one of the challenges, and the authorization gets
> marked as valid.
> 5. The CA issues the cert, and includes OID 1.2.3.4.5 in the Certificate
> Policies extension
>
> ---
>
> Regarding Q Misell's statement that RFC 8555 technically allows a server
> to require multiple challenges for a single authorization: the exact quote
> from Section 7.1.4
> <https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4>, in the
> description of the `challenges` field, is:
> Each array entry is an
> object with parameters required to validate the challenge. A
> client should attempt to fulfill one of these challenges, and a
> server should consider any one of the challenges sufficient to
> make the authorization valid.
> There's a similar statement later in Section 7.5.1
> <https://datatracker.ietf.org/doc/html/rfc8555#autoid-39>, which says
> The server is said to "finalize" the authorization when it has
> completed one of the validations.
>
> So I at least partially agree that it's acceptable for a server to require
> two different challenges to be fulfilled on a single authorization before
> it considers that authorization valid. However, I think doing this in
> practice would break virtually every ACME client in existence. In
> particular, most clients have very simple heuristics for selecting which
> challenge to fulfill on an authorization. I expect that, if a server
> accepted a challenge validation attempt but *didn't* mark the
> corresponding authorization as valid, most clients would get stuck in an
> infinite loop either polling the authorization until it becomes valid, or
> retrying the same challenge type over and over again.
>
> ---
>
> In Section 3, I think that bullet points 2 and 3 are unnecessary. This
> draft is defining a new identifier type and a new challenge type. The rest
> of the process -- i.e. how the server reflects that identifier within the
> Order and Authorization objects -- is identical to vanilla RFC 8555, and
> does not need to be repeated here.
>
> ---
>
> In Section 3, the last code block shows a challenge of type "rats", but
> then Section 4 defines two different "device-attest-02" and
> "device-attest-03" challenges. Those are the strings which should appear in
> the challenge objects in Section 3. Also, the URLs for each challenge need
> to be different:
>
> {
> "status": "pending",
>
> "identifier": {
> "type": "policy",
> "value": "1.2.3.4.5"
> },
>
> "challenges": [
> {
> "type": "rats-01",
> "url": "https://example.com/acme/chall/asdf";,
> "status": "pending",
> "token": "DGyRejmCefe7v4NfDGDKfA",
> },
> {
> "type": "rats-02",
> "url": "https://example.com/acme/chall/zxcv";,
> "status": "pending",
> "token": "DGyRejmCefe7v4NfDGDKfA",
> },
> ],
> }
>
>
> ---
>
> In Section 4.1, the "response sent to the url" is defined, but appears to
> be just a plain string (`token || '.' || cmw`). The object posted to a
> challenge URL is always a signed JSON blob; just a pair of empty curly
> braces for the original challenge types, but subsequent challenge types
> (such as onion-csr-01
> <https://www.rfc-editor.org/rfc/rfc9799.html#name-new-onion-csr-01-challenge>)
> have added custom fields to that object. This draft needs to describe the
> whole payload which should be POSTed to the challenge URL, not just a
> single string.
>
> ---
>
> In Section 4.2, it's unclear what part of Section 4.1 is being replaced by
> the "Background Check Model". Is that just a different way of computing
> `cmw`? A little more verbiage here would be useful.
>
> ---
>
> In both Sections 4.1 and 4.2, it's unclear what steps the ACME server is
> supposed to take to verify that the challenge has been completed
> successfully / that the client has POSTed the correct content.
>
> ---
>
> I don't understand the purpose of Section 5. How are these hints presented
> to the client? I don't see any evidence of them in the authorization or
> challenge objects created by the server in Section 3.
>
> ---
>
> Overall, I like this draft. It's another simple example of adding a new
> identifier type, and a couple new challenges that can be used to validate
> that identifier type. This is exactly the kind of extension that ACME is
> built for. I think it just needs a bit of work to clarify how rats
> identifiers are represented in certificates, how rats challenges are
> fulfilled, and how ACME servers validate the challenges.
>
> Thanks,
> Aaron
> _______________________________________________
> Acme mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
