Hi Jacob, What use case did you have in mind for including the expiration date in the RDATA? We didn't choose to initially include it as we believed the instructions for when a validation record could be removed were clear with ACME. ACME challenge tokens are only used once and have the expiry of the associated authorization object as you mentioned. The dnsop draft goes on to state "The 'expiry' key MAY be omitted in cases where the provider has clarified the record expiry policy out-of-band (Appendix A.1.1.3 <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-03#appendix-A.1.1.3>)" [Section 5.2.1 <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-03#name-metadata-for-expiry> ].
In regards to allowing clients to preemptively shorten lifetimes of authorizations, it would be nice to attempt to quantify the expected savings from the server standpoint and to talk to clients to see how they would use the feature. I suspect that some clients currently using authorization deactivation would continue to do so even if they could specify shorter lifetimes. They require authorization deactivation immediately upon issuance. I don't currently have any hard data though. I agree that adding the feature would best be achieved with a separate draft. James On Tue, Mar 19, 2024 at 5:23 PM Jacob Hoffman-Andrews <jsha= 40letsencrypt....@dmarc.ietf.org> wrote: > The latest dns-account-01 draft ( > https://datatracker.ietf.org/doc/html/draft-ietf-acme-scoped-dns-challenges-00) > incorporates recommendations from the dnsop domain control verification > draft ( > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-03 > ). > > The dnsop draft says: > > > Providers MUST provide clear instructions on when a validation record > can be removed. These instructions SHOULD be encoded in the RDATA via > comma-separated ASCII key-value pairs [RFC1464], using the key "expiry" to > hold a time after which it is safe to remove the validation record. > > But the ACME draft doesn't specify that. I think it should! The specified > expiry should be the expiry of the pending authorization object. After that > point, the challenge will never be validated and the record can be removed. > > This brings up a separate question: Should subscribers be able to specify > what maximum lifetime they want for the validated authorization? For > instance some subscribers might want to never reuse authorizations. > Currently they can achieve that by deactivating authorizations after > issuance, but it could be more convenient to do it preemptively. One option > would be to encode it in the TXT record. But if we specify such a thing I > think we'd want it to work for any challenge type, probably by making it > part of the challenge POST. So, out of scope for this draft, I think. > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
