From: Aaron Gable <[email protected]> Sent: 14 September 2021 00:02 To: Owen Friel (ofriel) <[email protected]> Cc: Michael Richardson <[email protected]>; Ryan Sleevi <[email protected]>; Deb Cooley <[email protected]>; [email protected] Subject: Re: [Acme] working group call for adoption
On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) <[email protected]<mailto:[email protected]>> wrote: Consider an RA that wants to get device certs for thousands of devices e.g. foo.type-a-sensors.example.org<http://foo.type-a-sensors.example.org> and bar.type-b-sensors.example.org<http://bar.type-b-sensors.example.org>, The RA would likely do a preAuthz for the domains it owns (e.g. example.org<http://example.org>) rather than wait for a device to send an enrol request for a specific identifier (e.g. foo.type-a-sensors.example.org<http://foo.type-a-sensors.example.org>) and the RA then send a newOrder containing “identifiers”: [ {“value”: “foo.type-a-sensors.example.org<http://foo.type-a-sensors.example.org>”, “domainNamespace”:“example.org<http://example.org>”} ]. The point of much of my original message is that this flow is already possible today (modulo server policy). Instead of doing a preAuthz for example.org<http://example.org>, the subscriber would do a newOrder for *.example.org<http://example.org>. The rest of the process would be identical. [ofriel] It did come up at the last face-to-face meet IETF106 that the ACME server and authorization objects should explicitly differentiation between authorization for wildcard certs vs. authorization for the full domain namespace. It was EKR that made that point and asked for this ‘special indicator’: https://datatracker.ietf.org/meeting/106/materials/minutes-106-acme-00. This was the genesis for adding the “domainNamespace” boolean to the authz object (which was called “basedomain” in draft-01). Again, I'm new here and so I'm not sure what criteria we look for when considering new standards. Maybe a standard that provides a clear, intuitive alternative to something already possible but kinda hacky is a good thing; maybe it isn't. That's where my knowledge ends. I'm just trying to make sure we understand that this behavior is technically possible today. [ofriel] In general, its better to have the standard clear and explicit and not have implementers having to scratch their heads and jump through hoops to force the behaviour they want. On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) <[email protected]<mailto:[email protected]>> wrote: CA/B guidelines states the following in “3.2.2.4 Validation of Domain Authorization or Control” for multiple methods (including DNS)... I'm not totally sure which part of my message this is responding to. Just in case this was responding to my very last bullet point: yes, the BRs allow multiple methods (including DNS validation) to be used for subdomains. But they no longer allow Agreed-Upon Change To Website to be used for subdomains, which means Appendix A needs to be updated. [ofriel] The point I was attempting to make here, along with the assumption in my email that there is “value in explicitly distinguishing between an authorization for a wildcard vs. an authorization for an entire domain namespace” is that while CA/B policy allows that proof of domain control to be used for issuance of both wildcard and certs with subordinate identifiers in the namespace, this draft defines how an ACME servers can disambiguate between the two. This was the EKR ask at IETF106. On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) <[email protected]<mailto:[email protected]>> wrote: An RFC8555 wildcard authorization for example.org<http://example.org> only allows the *.example.org<http://example.org> cert to be issued. I don't think this is true. The relevant pieces of languages are, as far as I can tell: Section 7.1.4: "This field MUST be present and true for authorizations created as a result of a newOrder request containing a DNS identifier with a value that was a wildcard domain name. For other authorizations, it MUST be absent." "Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects. If an authorization object conveys authorization for the base domain of a newOrder DNS identifier containing a wildcard domain name, then the optional authorizations "wildcard" field MUST be present with a value of true." So an Authorization object can only have the "wildcard" field set if it was created as the result of a newOrder request for a wildcard domain name, and the "wildcard" field must be set if the Authorization object conveys authorization for the base domain of a wildcard domain name. This says nothing about whether or not that Authorization object also conveys authorization for other things (such as all subdomains of that base domain), and says nothing about whether or not that Authorization object can be re-used for orders other than the one that created it. [ofriel] On rereading, I believe your interpretation is correct, and ACME handling of wildcards is not that restrictive, although the text does not make it implicit, its implicit and a bit ambiguous. This is similar to some of the reasoning behind this draft in the first, as we have clarified that ‘ACME does not mandate that the "identifier" in a newOrder request matches the "identifier" in "authorization" objects’ The summary for what this draft is trying to accomplish is: - explicitly handle and differentiate between authorizations for identifiers in subordinate domain name spaces vs. wildcard certs - clarify how subordinate domain name spaces works for pre-authorization (which is not currently allowed for wildcards) - I am good with dropping the proposed specification of the top level domain name space that a client controls when sending in a newOrder request for a subordinate identifier, as I believe that the pre-authz flow is the really useful one. Its probably also a good idea to clarify the wildcard behaviour, as its not entirely clear. Implementor have to define behaviour based on what is not stated vs. what is explicitly stated. Thanks, Aaron
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
