I do think that this draft can do a better job describing the scope. I
think we should make it more explicit for the client to understand which
one will be used. I feel like splitting this challenge into three (and
potentially more, as extra scopes may or may not be added into the future)
might be a little too noisy.
What do you think about a `scope` field in the authorization resource the
server sends creates/communicates with the client? Clients opting into
dns02, or dns-account-01 will use this to know exactly what scope the
server is expecting from them for their ACME order.
{
"status": "valid",
"expires": "2015-03-01T14:09:07.99Z",
"identifier": {
"type": "dns",
"value": "www.example.org"
},
"challenges": [
{
"url": "https://example.com/acme/chall/prV_B7yEyA4";,
"type": "http-01",
"status": "valid",
"token": "DGyRejmCefe7v4NfDGDKfA",
"validated": "2014-12-01T12:05:58.16Z"
}
],
"scope": "host" // Or "wildcard", or "host"
}
This wouldn't remove the existing wildcard or subdomainAuthAllowed fields.
On Tue, Mar 19, 2024 at 7:36 PM Jacob Hoffman-Andrews <jsha=
40letsencrypt....@dmarc.ietf.org> wrote:
> 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
>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
