[Starting a new thread for this particular fork of the conversation] Thanks for the input, Tim! As a member of the CA/Browser Forum Validation Working Group, and a big contributor to the BR validation methods, your perspective on this is particularly helpful.
On 01/23/2018 08:37 AM, Tim Hollebeek wrote: > Your proposed method defeats one of the goals of the BR domain > control validation requirements, which is to demonstrate control > at time of validation, not just as some previous time in the past. For the moment, let's continue to assume that the CA fully resolves the TXT record during validation. I think continuing to present a delegation of the authorization label to an authorized party (in this case the CA) does constitute demonstration of continued control. > That's why the existing, approved validation methods require > random numbers to guarantee the validation is fresh and not > based on some previous validation. I'm sure the intent of "freshness tokens" in the BRs was discussed extensively in the validation WG, but I don't think it made it to the final document. If you happen to recall any thread titles, would you be willing to link to the previous discussion? I'm specifically interested in why you would consider this form of automation to have a separate risk profile from HTTP-style automation. For instance, if someone leaves software like Certbot running on a server, with instructions to continue to request and respond to validation from a given CA, why is that safer than leaving a particular CNAME record in DNS? > If control at some time in the past is sufficient, you can > just re-use the previous validation, which is allowed in some > circumstances(see the BRs). This is fundamentally different from validation reuse. With validation reuse, a CA might say "I validated that a year ago; I'll assume it's still good." The goal of automated validation methods is to allow the CA to actually re-check the validation data at intervals that would be impractical with manual intervention. So for instance, under assisted-dns-01, a CA would actually be going out to the network and fetching DNS records with each validation. >> Oh, and the method very similar to the propose one (static >> CNAME as persistent authentication) is being used in the wild. >> And due to fundamential nature of DNS, even static zone can >> result variable results for names under the zone. > By who? I don't think it's possible for such a method to be > compliant with any of the current BR methods. If it is, we'll > fix it. Are you saying that the proposed assisted-dns-01 method is also not compliant with 3.2.2.4.7 DNS Change? Why not? If you think assisted-dns-01 is compliant, but should not be, what is your proposed fix? _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
