Seo Suchan said: > Would it be illegal to server probe both scope and pass if there is intended token?
This is a possibility, but it's inefficient and I think it's likely to lead to implementation bugs. Better to be clear and explicit on both sides. Amir Omidi said: > My intention that I should probably clarify in the draft is that the server picks based on the Authorization object Yep, I figured the intention was something like this. We could call this "Server and client follow the same algorithm to arrive at the same scope." Also a valid approach! But I think we get benefits from not having that algorithm, even as simple as it is. For instance, the BRs say of some methods: > Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. If host-scoped, wildcard-scoped, and domain-scoped challenges were separate types, it would be straightforward to adapt this language to the new challenge types. Ilaria Ilusvaara said: > The client also needs to know the acceptable domains, and needs to select the domain to use. The domain to use is part of the authorization object: the identifier value (https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4). It is chosen by the server. I think what you're getting at is that the client might feel like "I requested a new-order for www.example.com, and the server created an authorization object with an identifier value of www.example.com. But I really wish the server would have created an authorization object with an identifier value of example.com, and I would complete domain-scoped DNS challenge." This would allow the full expressiveness permitted by BRs 3.2.2.4.7 DNS Change, which has the "MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN" language. I'd actually like to go the other direction: What if we only specify host-scoped and wildcard-scoped validations? Domain-scoped validations make sense when validations are very manual and time consuming, and you are trying to strictly minimize them. But ACME tries to make validations easy and quick, so it doesn't matter if you have to do more of them. There are still important use case for wildcard certificates, but I think there is less need for domain-scoped validations in ACME.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
