Proposal of ACME Validation Method for use with SC-88

[Henry Birge-Lee]

Hi all,

At yesterday's call there was some discussion of how ACME should handle validation under the new proposed persistent validation method that would be added by ballot SC-88.

I understand there are some proposals to treat a persistent DNS validation like a reused validation and have the ACME server issue a certificate without sending any challenges to the ACME client (i.e., the ACME server would check for the presence of the challenge on its own and if it was valid, proceed to sign a certificate).

While this has a plus of magically working with ACME clients today, I had never really imagined performing persistent DNS validation validation in this way. There are some considerations regarding CA load. This approach requires a CA to either 1) check the _validation-persist label at every domain in a new order object and every parent of those domains and/or 2) preemptively check domains in all active certs to keep an up-to-date persistent DNS authorization ahead of any new order request from a client. Given that there could be a period where this method is still gaining popularity and is used by a minority of clients, this approach could mean a lot of extra load just to support a small number of clients.

I think there is some argument that for certain CAs looking to support persistent DNS validation, simply slotting it into the ACME protocol the exact same way all other validation methods are done leads to the cleanest implementation. With this system the client selects the validation method (as is the case with all other validation methods) and informs the CA when the validation is complete. The CA only needs to check the validation when the client selects this method, so there is no load or system change needed for clients that don't select persistent DNS validation. The generation of authorization objects and all other aspects of the ACME protocol can remain unmodified leading to minimal server changes.

To this end, I put together an Internet Draft of what a persistent dns validation compliant with SC-88 in ACME might look like. This is just a rough draft of the core sections, if this moves forward I will add more Intro/Security Considerations/Abstract etc...

https://birgelee.github.io/birgelee-acme-dns-persist-01/draft-birgelee-acme-dns-persist.html

I don't feel strongly that this is the approach that must be pursued, and as discussed in the call, I agree that this should not be a blocker on SC-88. I just felt that given the conversation of how will this work in ACME, putting forward something concrete would be helpful.

Best,

Henry

[Aaron Gable]

Hi Henry et al.,

I agree that the cleanest way to support persistent validation in line with SC-088 is to specify a new ACME validation method, similar to how TLS-ALPN-01 and DNS-ACCOUNT-01 have been specified since the creation of RFC 8555.

Having the CA perform this persistent validation before even creating the Order and Authorization objects is, in my opinion, a gross violation of the ACME protocol's data model and flow. One could imagine an in-between, in which the CA attempts validation both under the "_acme-challenge" and "_validation-persist" subdomains when the client selects the DNS-01 challenge type, but this would be a violation of RFC 8555 (which specifies how DNS-01 works in detail), and comes with the baggage of the CA having to provide a random token even when the applicant is not going to end up using it.

Therefore I believe that specifying a new validation method, and updating both ACME clients and servers to support this new validation method, is the correct approach.

Thanks,

Aaron

--
You received this message because you are subscribed to the Google Groups "Validation Subcommittee (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validation+...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/d40306b0-b84a-4e45-a7f9-a4a8989609e2n%40groups.cabforum.org.