From: Acme <acme-boun...@ietf.org> On Behalf Of Aaron Gable Sent: 02 September 2021 08:31 To: Michael Richardson <mcr+i...@sandelman.ca> Cc: Ryan Sleevi <ryan-i...@sleevi.com>; Deb Cooley <deco...@nsa.gov>; acme@ietf.org Subject: Re: [Acme] working group call for adoption
On Wed, Sep 1, 2021 at 5:28 PM Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr%2bi...@sandelman.ca>> wrote: Yes, but not necessarily across TLS connections. One connects, gets a challenge, sets it up (DNS or HTTP/S), waits for the authorization check to complete, and sends an order. I don't know what letsencrypt does, but my understanding is that I could do all of this on the same connection, and afterward, aside from the certificate that I append to a database, there is no other moving parts. I do not believe this is an accurate description of the ACME protocol, and certainly not of any implementation of it that I'm aware of (but I may be wrong!). It is true that one could imagine an ACME server which never performs authorization re-use. It would not support pre-authorization, as it always creates new authorizations for every name in each new order. Such a server would be able to support the extensions to the newOrder endpoint proposed by this draft, but would not be able to support the extensions to newAuthz proposed by this draft or proposed by my message above. That said, even such a server is required to keep state about its authorizations for arbitrarily long periods of time: the authorizations are created (including the `wildcard` boolean) when the client requests a newOrder; they are served when the client requests details about the authorizations for the order; they are updated when the client fulfills challenges; and they must be examined by the server when the client requests to finalize the order. Each of these requests is a separate HTTP/TLS connection from the client to the server, and they may be seconds, hours, or even days apart, depending on the `expires` timestamp that the server populates in the order object. Aaron [ofriel] Thanks for the all the comments Aaron. In my mind, the newAuthz proposal in this draft is the more useful and most likely to be implemented approach vs. the extension to newOrder. Consider an RA that wants to get device certs for thousands of devices e.g. foo.type-a-sensors.example.org and bar.type-b-sensors.example.org, The RA would likely do a preAuthz for the domains it owns (e.g. 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) and the RA then send a newOrder containing “identifiers”: [ {“value”: “foo.type-a-sensors.example.org”, “domainNamespace”:“example.org”} ]. I think this would also make the RA code simpler. So on balance, I do not think having the “domainNamespace”: “<FQDN>” extension to the newOrder would likely be used much, and am fine with dropping that. This use case did come up in discussions no the mailer over the past year, but simplifying this and removing that newOrder extension is OK. It would also avoid adding this complexity to both RA and ACME server code. CA/B guidelines states the following in “3.2.2.4 Validation of Domain Authorization or Control” for multiple methods (including DNS): “Note: 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.” meaning that this covers both the wildcard cert and any subdomain certs in the full domain namespace under that FQDN. Is there any value in explicitly distinguishing between an authorization for a wildcard vs. an authorization for an entire domain namespace? An RFC8555 wildcard authorization for example.org only allows the *.example.org cert to be issued. Whereas, what we have proposed is that a domainNamespace authorization for example.org enables a cert with any identifier in the entire subordinate domain namespace to be issued. e.g. foo.type-a-sensors.example.org and bar.type-b-sensors.example.org. For sure, for the device cert enrolment and RA use cases we have in mind, the device and RA most definitely do not want a wildcard cert, they want a unique cert per device. Assuming there is value in this, then the proposed changes to the APIs and objects are actually pretty minimal: domainNamespace bool in authz object domainNamespace bool in newAuthz request domainNamespace bool in directory metadata to advertise the server supports this domainNamespace string (an FQDN) in newOrder request (which I think we don’t really need, the pre-authorization workflow seems the really useful one here) Cheers, Owen
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
