Hi Rich, Based on the discussions on the mailer last December and the preferences indicated, I will make these initial recommendations, and yes, a slot to discuss at IETF110 would be great. I will prepare a few slides to outline the recommendations, and summarise the reasons why as given on the mailer late last year.
The open items are quoted exactly as is from https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4 Open item 1: “Does the client need a mechanism to indicate that they want to authorize a parent domain and not the explicit subdomain identifier? Or a mechanism to indicate that they are happy to authorize against a choice of identifiers? E.g. for foo1.foo2.bar.example.com, should the client be able to specify anywhere from 1 to 4 identifiers they are willing to fulfil challenges for?” Recommendation 1: YES. Clients may advertise the parent ADNs that they are authorised to fulfil challenges against when they want a cert for an FQDN, the server picks from one of those challenges. Open item 2: “Does the server need a mechanism to provide a choice of identifiers to the client and let the client chose which challenge to fulfil? E.g. for foo1.foo2.bar.example.com, should the server be able to specify anywhere from 1 to 4 identifiers that the client can pick from to fulfil?” Recommendation 2: NO. Servers do not need a mechanism to advertise multiple potential challenges to the client and let the client pick one. Open item 3: Should acme-subdomains be restricted to dns-01 challenges and not allowed for http-01 challenges? Recommendation 3: YES. Restrict acme-subdomains to dns-01 challenges. Fulfilment of a http-01 challenge must be carried out against the explicit FQDN, and not a parent ADN. Servers must not offer a client the option of fulfilling a http-01 challenge against a parent ADN. If server policy allows, then a client may fulfil a dns-01 challenge against a parent ADN in order to complete an order against a child FQDN. Point of Confusion: acme-subdomains works for both the pre-authorization flows, and the standard flow where the client POSTs the newOrder before authorization takes place. -----Original Message----- From: Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> Sent: 03 February 2021 05:42 To: Salz, Rich <rs...@akamai.com>; Owen Friel (ofriel) <ofr...@cisco.com>; IETF ACME <acme@ietf.org> Subject: Re: [Acme] FW: New Version Notification for draft-friel-acme-subdomains-03.txt Do we have any views on these open issues? Do we want to discuss at the virtual IETF next month? On 1/12/21, 1:52 PM, "Salz, Rich" <rsalz=40akamai....@dmarc.ietf.org> wrote: Reposting this to see if we can close the two open issues. On 10/12/20, 4:25 AM, "Owen Friel (ofriel)" <ofriel=40cisco....@dmarc.ietf.org> wrote: This new draft addresses the comments that were raised back in August by Russ. It also explicitly lists in the Open Items https://tools.ietf.org/html/draft-friel-acme-subdomains-03*section-4 the two main open items that have been raised by Felipe and Ryan: 1. Does the client need a mechanism to indicate that they want to authz a parent domain and not the explicit subdomain identifier? Or a mechanism to indicate that they are happy to authz against a choice of identifiers? 2. Does the server need a mechanism to provide a choice of identifiers to the client and let the client chose which to fulfil? Both would require some JSON definition work. If we can't reach consensus on the mailer, we could discuss at IETF 109 Online. Cheers, Owen -----Original Message----- From: internet-dra...@ietf.org <internet-dra...@ietf.org> Sent: 09 October 2020 18:35 To: Richard Barnes <r...@ipv.sx>; Tim Hollebeek <tim.holleb...@digicert.com>; Owen Friel (ofriel) <ofr...@cisco.com>; Michael Richardson <mcr+i...@sandelman.ca> Subject: New Version Notification for draft-friel-acme-subdomains-03.txt A new version of I-D, draft-friel-acme-subdomains-03.txt has been successfully submitted by Owen Friel and posted to the IETF repository. Name: draft-friel-acme-subdomains Revision: 03 Title: ACME for Subdomains Document date: 2020-10-09 Group: Individual Submission Pages: 13 URL: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dfriel-2Dacme-2Dsubdomains-2D03.txt&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=TvT7TDlUQ5gKnK6wZ-OXEwDofAYq7LINGqq4Q-XaRKU&s=BU6Y6_X7HUffuxdnapklOZeMRtGd0KkNPaAvb49LYKA&e= Status: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfriel-2Dacme-2Dsubdomains_&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=TvT7TDlUQ5gKnK6wZ-OXEwDofAYq7LINGqq4Q-XaRKU&s=nVKzeNyyg4s-D5rg2gvxxaqf3bhTy0szmVOHFSVe3pQ&e= Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dfriel-2Dacme-2Dsubdomains&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=TvT7TDlUQ5gKnK6wZ-OXEwDofAYq7LINGqq4Q-XaRKU&s=8Pobbb3L_ALZLAMgcmOGrA-gFJOU9BYqtf3W8wSukRQ&e= Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfriel-2Dacme-2Dsubdomains-2D03&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=TvT7TDlUQ5gKnK6wZ-OXEwDofAYq7LINGqq4Q-XaRKU&s=c1L6LvA9uHzoce1HPiXM3fgOffVbmmoDhpzN_nu0cFE&e= Diff: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dfriel-2Dacme-2Dsubdomains-2D03&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=TvT7TDlUQ5gKnK6wZ-OXEwDofAYq7LINGqq4Q-XaRKU&s=iG7_buccTRbxl6J5pk_IvqgfgdIUPJH3J1GmYZ9bKaY&e= Abstract: This document outlines how ACME can be used by a client to obtain a certificate for a subdomain identifier from a certification authority. The client has fulfilled a challenge against a parent domain but does not need to fulfil a challenge against the explicit subdomain as certificate policy allows issuance of the subdomain certificate without explicit subdomain ownership proof. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Acme mailing list Acme@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=TvT7TDlUQ5gKnK6wZ-OXEwDofAYq7LINGqq4Q-XaRKU&s=ohK3nmt-JwvlYhgDVOMz6y80hA19HWsBGFGonK7XlHI&e= _______________________________________________ Acme mailing list Acme@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!GjvTz_vk!FkL4sCRJs_l1txVztBHqrQINVbEI5NFif9mE6ZxlLobD1uLAcDN5jzUKPDVv$ _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
