Aaron, Yes, this is intentional and it's due to a slight difference in the mechanics between the two mechanisms. While the RFC 8823 mechanism can generate a unique "from" email address for each challenge (e.g. the document example " [email protected]") that the client can use to filter-in valid challenges, the Bundle protocol has no such controllable uniqueness at the BP layer (i.e the Primary Block). In RFC 8823 the "from" address can be used by an ACME-aware mail client to ignore unauthorized requests. While in the proposed Node ID validation the ACME server's Source Node ID is the same for all challenges, and only the "token-chal" is distinct for the authorized challenge. The ACME client's BP agent can use this to filter-in (and respond to) only authorized challenges.
This does bring up the point that multi-perspective validation would have different challenge bundle Source Node ID for each perspective, so the current logic of defining a single "source" for each challenge limits the multi-perspective use to routing from multiple forwarders but all from the same source (and thus the response bundle going to the same destination). If the "token-chal" is assumed to be globally unique, then the client really doesn't need to know what ACME servers are making the challenges. On Mon, Oct 4, 2021 at 3:05 PM Aaron Gable <[email protected]> wrote: > Brian, > > Fantastic, thank you for the responses! One further comment inline. > > On Thu, Sep 30, 2021 at 3:28 PM Brian Sipos <[email protected]> > wrote: > >> BS1: This is to handle a basic property that BP bundles are necessarily >> independent units, unidirectional, and (currently) have no "conversation" >> or "flow" associations at the BP layer. Any associations between bundles >> must be made at the application layer above, so in fact tuple (token-chal, >> token-bundle) is the *only* way for an ACME Server to correlate the two >> bundles. >> This is the same way that RFC8823 uses to correlate the two emails. >> Because email and bundles both have similar logical patterns of transport, >> this Node ID validation is intended to have the same structure and security >> properties as the email validation. >> > > RFC8823 sends the two tokens via separate mechanisms: token-part1 > (corresponding to token-bundle) is sent only in the email, and token-part2 > (corresponding to token-chall) is provided only via the Challenge object > over HTTPS to the ACME client. This draft differs, in that both token-chall > *and* token-bundle are provided in the Challenge Bundle. I believe that an > ACME Server, rather than its BP Agent, should be responsible for verifying > that the Response Bundle is correct, so there is no need for the Server's > BP Agent to ever be aware of token-chall at all, just as in RFC8823 there > is no reason for the Server's email agent to ever be aware of the > token-part2 that is part of the Challenge object. > > Thanks, > Aaron >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
