Proposal to Implement ACME "dns-account-01" Challenge in Boulder about boulder

[aaomidi]

I'm one of the authors of that draft, I'll also commit to helping with this implementation if need be!

Thank you so much for this, @sheurich

[aarongable]

We'd be happy to accept contributions implementing DNS-ACCOUNT-01!

A few notes:

• Please implement DNS-ACCOUNT-01 in pebble first, to help maintain parity between the two ACME implementations and to ensure that clients implementing DNS-ACCOUNT-01 have a testbed to test against.
• As always, please break large changes down into easily-reviewable sections, preferably as separate PRs, but failing that as well-structured commits within a single PR. I honestly don't have a good instinct for how large this change is going to be, so it may fit in a single PR just fine, but keep it in mind.
• Just as a heads-up: we do automatic round-robin assignment of reviewers to PRs. Your first assigned reviewer should respond to the PR in about one business day, and other reviewers should take a look shortly after that. If the change is broken into multiple PRs, they'll likely be assigned to different people for their first round of review.

[aarongable]

The Boulder VA is already configured with a set of accountURIPrefixes. The IsCaaValid gRPC method combines those prefixes with an accountURIID to check that CAA "accountURI" parameters are correct.

The AuthzMeta protobuf already contains the account's regID, which can be used in exactly the same way. Combining that regID with the accountURIPrefixes should give the full account URI, which can then be fingerprinted per the IETF draft.

edit: gah sorry, I now see that you already proposed this configuration-based approach in your comment above. Yes, I think that is the correct path forward :)

[sheurich]

Great, thanks! I created letsencrypt/pebble#425 for the Pebble work.

[sheurich]

In contrast to the Pebble implementation, the Boulder work has the additional complication of component separation. The method used in Pebble's wfe.updateChallenge:

        // Reconstruct account URL for use in scoped validation methods
        acctURL := wfe.relativeEndpoint(request, fmt.Sprintf("%s%s", acctPath, existingAcct.ID))

        // Submit a validation job to the VA, this will be processed asynchronously
        wfe.va.ValidateChallenge(ident, existingChal, existingAcct, acctURL, wildcard)

could be implemented in Boulder but this requires a change in the RA/VA gRPC definition for PerformValidationRequest (e.g. an additional member of AuthzMeta).

One alternative could be statically defining account URL prefixes in configuration cf. https://github.com/orangepizza/boulder/blob/703182fae06ccf8e876a9c6bdc71b5e4186d630d/va/dns.go#L132-L133.

The protobuf change would be small and additive, while the configuration approach is a more localized change. How does this comparison align with the overall strategy in Boulder development?