On Thu, Sep 3, 2020 at 9:47 AM Salz, Rich <rs...@akamai.com> wrote: > > - I followed the patterns used in RFC8555 which consistently uses > example.com as the ACME server base domain and example.org as the > client certificate identifier base domain, but yes Ryan I did find this a > source of confusion too when reading ACME. > > > > Thanks for the changes. I am also confused by example.com and example.org. > Someone want to grab acmeserver.org and donate it? >
That still seems problematic; registrations are fixed lifetimes. Just use RFC 6761 https://tools.ietf.org/html/rfc6761#section-6.5 Specifically, acmeserver.example As James points out, the use isn't really consistent with RFC 8555 in the examples provided, and that's why it bears clarifying. However, my specific concern was this statement: "For flexibility, I guess if the client wants foo.bar.example.org the protocol should also allow server choice of offering challenges for (1) both foo.bar.example.org and example.com (2) only the requested identifier foo.bar.example.com or (3) only the parent domain example.com." Which is the problematic area. I believe this is "trying" to say that the options are: foo.bar.example.org bar.example.org example.org And all permutations/combinations of those. Whether those go to acmeserver.com or acmeserver.example is irrelevant; the point of clarification is what challenges can be used for the identifier.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
