[Acme] [Errata Held for Document Update] RFC8555 (6276)
The following errata report has been held for document update for RFC8555, "Automatic Certificate Management Environment (ACME)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6276 -- Status: Held for Document Update Type: Editorial Reported by: James Manger Date Reported: 2020-09-03 Held by: Benjamin Kaduk (IESG) Section: 2 Original Text - o The CA verifies that the client controls the requested domain name(s) by having the ACME client perform some action(s) that can only be done with control of the domain name(s). For example, the CA might require a client requesting example.com to provision a DNS record under example.com or an HTTP resource under http://example.com. Corrected Text -- o The CA verifies that the client controls the requested domain name(s) by having the ACME client perform some action(s) that can only be done with control of the domain name(s). For example, the CA might require a client requesting example.org to provision a DNS record under example.org or an HTTP resource under http://example.org. Notes - The spec consistently uses example.com for an ACME CA server, and example.org for a site requesting a certificate -- except in this sentence. -- RFC8555 (draft-ietf-acme-acme-18) -- Title : Automatic Certificate Management Environment (ACME) Publication Date: March 2019 Author(s) : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten Category: PROPOSED STANDARD Source : Automated Certificate Management Environment Area: Security Stream : IETF Verifying Party : IESG ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME subdomains
On Thu, Sep 3, 2020 at 9:47 AM Salz, Rich 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
Re: [Acme] Review of draft-friel-acme-subdomains-02
> What if … there’s no need for a standard for this? Or at least, the > standard would require no significant changes to the protocol? Hosting services need this, such as myshop.etsy.com? ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME subdomains
* 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? ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] [Editorial Errata Reported] RFC8555 (6276)
The following errata report has been submitted for RFC8555, "Automatic Certificate Management Environment (ACME)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6276 -- Type: Editorial Reported by: James Manger Section: 2 Original Text - For example, the CA might require a client requesting example.com to provision a DNS record under example.com or an HTTP resource under http://example.com. Corrected Text -- For example, the CA might require a client requesting example.org to provision a DNS record under example.org or an HTTP resource under http://example.org. Notes - The spec consistently uses example.com for an ACME CA server, and example.org for a site requesting a certificate -- except in this sentence. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8555 (draft-ietf-acme-acme-18) -- Title : Automatic Certificate Management Environment (ACME) Publication Date: March 2019 Author(s) : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten Category: PROPOSED STANDARD Source : Automated Certificate Management Environment Area: Security Stream : IETF Verifying Party : IESG ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Review of draft-friel-acme-subdomains-02
Hi all, What if … there’s no need for a standard for this? Or at least, the standard would require no significant changes to the protocol? The application that I help manage integrates alternately with Sectigo and with Let’s Encrypt. Sectigo, when they verify domain control, always checks parent domains along with the domain(s) given in the certificate order. If any of those checks succeeds, the authz is valid. Perhaps the standard could be defined merely in those terms, such that CAs who so choose could simply indicate in the authz objects that parent/ancestor domains suffice for the verification? This would also allow CAs to mandate that such liberty apply only to DNS-based authz, while still requiring HTTP-based authz to be against the literal identifier. A bit of context: our application runs on shared-hosting servers that we don’t administer, subject to firewall rules that neither we nor the admin may control. The admins run the gamut of competence, from highly-skilled on down. The domains are end-user-controlled, not necessarily registered with the same organization that administers the server. We’ve seen all kinds of crazy setups that complicate SSL issuance, as a result of which our certificate-provision logic attempts to accommodate potential misconfigurations. Sectigo’s acceptance of ancestor domains for authz helps toward that end since all we have to do to capitalize on it is to create the relevant HTTP docroot files or DNS records all at once, then send the order. Some oddity might frustrate direct authz against “www.whatever.bobs-store.com”, but as long as “bobs-store.com” works, we can still secure the subdomain. An alternate implementation might be for authz objects to include challenges against whatever ancestor domains and methods the server allows; thus, if I do newAuthz against “foo.bar.example.com”, I might get back: - http-01, foo.bar.example.com - tls-alpn-01, foo.bar.example.com - dns-01, foo.bar.example.com - dns-01, bar.example.com - dns-01, example.com The disadvantage to that, for us, would be that we’d have to recreate the authz for every failure. I assume that that’s also disadvantageous for the ACME server--more so than simply doing “fallback” authz checks against parent domains. That aside, as to Owen’s proposal document: - How is the client to indicate that they want to authz the parent domain (example.com) rather than the literal identifier (sub0.example.com)? And for foo.bar.example.com, how shall the client indicate which parent domain is to be used for authz? Thank you! cheers, -Felipe Gasper > On Sep 2, 2020, at 5:41 AM, Owen Friel (ofriel) > wrote: > > Thanks Russ. I've addressed all these in github at: > https://github.com/upros/acme-subdomains/blob/master/draft-friel-acme-subdomains.md. > I have not pushed out draft-03 yet, lets see what Jacob and Felipe have to > say on the related thread about challenge options, and I will incorporate > then. > > > -Original Message- > From: Acme On Behalf Of Russ Housley > Sent: 05 August 2020 06:44 > To: IETF ACME > Subject: [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 > > ___ > 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
