Re: [Acme] ACME subdomains
I haven't followed the "ACME for subdomains" conversation closely, but the base semantics of ACME are designed such that they can express "all of" semantics AND "one of" semantics. For a given Order, a client has to fulfil *all* the Authorizations; for a given Authorization, a client has to fulfil *one of* the Challenges. To take advantage of this, you would need to define a new challenge type that expresses validating a parent domain. For instance "dns-parent-01." It would contain the name of the parent domain as a field. If a server has the policy that validating control of either foo.bar.example.com or example.com is sufficient to issue for foo.bar.example.com, it would respond to newOrder requests for foo.bar.example.com by creating an Order with one Authorization (for foo.bar.example.com), and that Order would have two Challenges: "dns-01" and "dns-parent-01" (with a parent domain of "example.com"). The client could then choose which challenge to attempt. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] ACME subdomains
As regards https://tools.ietf.org/html/draft-friel-acme-subdomains-02 ... Is the idea that the client will, if requesting authz on sub.example.com, *only* be able to do authz against the parent domain (example.com)? It would seem advantageous—from the client’s perspective, anyway—to allow a workflow where the client can do authz against one or the other. For longer subdomains, e.g., foo.bar.example.com, likewise, ideally the domain itself or either parent domain would work. Was this considered and deemed infeasible? Thank you! -Felipe Gasper___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Review of draft-friel-acme-subdomains-02
Document: draft-friel-acme-subdomains-02 Reviewer: Russ Housley Date: 2020-08-04 Major Concern: The TODO markers regarding wildcard domain names, the 200 response code, and the security considerations should be filled in with strawman text before this I-D is adopted by the ACME WG. Minor Concerns: General: s/certificate authority/certification authority/ (many) Abstract: s/certificate authority policy/certificate policy/ Introduction: s/X.509 (PKIX)/X.509v3 (PKIX) [RFC5280]/ Terminology: Correct CA, please. See above. Terminology: Please add a definition of subdomain. Nits: Section 3: says: 3. client sends POST-as-GET requests to retrieve the "authorizations", with the downloaded "authorization" object(s) containing the "identifier" that the client must prove control of s/client must prove control of/client must prove that they control/ There is something wrong with the table formatting in Section 6.2. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
