[Acme] Paul Wouters' No Objection on draft-ietf-acme-integrations-13: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-acme-integrations-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/ -- COMMENT: -- The document is a good read, and the figures in it make the process very clear. Thanks for that work. Just some minor comments: | | Publish DNS TXT | | | | "example.com"| | | | Delete DNS TXT | | | | "example.com"| | This reads a little as if a TXT record with the content "example.com" needs to be published and deleted. Maybe use 'Publish ACME DNS challange in "example.com"' ? This ownership proof could have been by fulfilling an authorization challenge against the explicit identifier "pledge.example.com", Where does "pledge" come from? Is this a normative reference to something? If it is made up here, add some "for example" text to clarify this. And use at least "_pledge" to avoid clashing with potential real hostnames called pledge ? NITS: which it will issue certificates. s/\.$/ for./ ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] John Scudder's Discuss on draft-ietf-acme-integrations-13: (with DISCUSS and COMMENT)
John Scudder has entered the following ballot position for draft-ietf-acme-integrations-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/ -- DISCUSS: -- # John Scudder, RTG AD, comments for draft-ietf-acme-integrations-13 CC @jgscudder ## DISCUSS This is an informational document but is using RFC 2119 keywords as though it were standards track. Most of these uses are in Section 8, but there are two in Sections 4 and 5. For example, If the CSR includes an identifier that the EST RA does not control, the RA MUST respond with a 4xx HTTP [RFC9110] error code. That reads as though you are imposing the requirement de novo. I assume that is not correct, and what you're actually doing is describing what the underlying standards track document mandates. If that's the case, here and in other places you use 2119-style requirement keywords, it seems to me that you should reword to make it clear you're describing the consequences of an existing requirement, not creating a new one. On the other hand, if you're creating a new requirement, then shouldn't this be a standards track document? An example of the former approach, with the quoted sentence, might be to reword it like If the CSR includes an identifier that the EST RA does not control, the RA will respond with a 4xx HTTP [RFC9110] error code. I just changed "MUST" to "will", or if you want to be more specific could interpolate something like, If the CSR includes an identifier that the EST RA does not control, an RA that follows the requirements of RFC Sec YY will respond with a 4xx HTTP [RFC9110] error code. The uses in Section 8 are more difficult for me; not being at all expert in this area I'm unable to reliably tell which if any of the MUSTs (and SHOULDs and so on) you're imposing are actually new requirements. If you think there really are new requirements being imposed here that don't exist in the base document, but that this document really is only informational, please help me understand how to resolve this seeming contradiction. Thanks in advance. (As an aside to the shepherd, I had hoped that item 11 of the shepherd writeup would help me understand how to resolve this question, but sadly the "why is this the proper type of RFC" portion was left unanswered. Maybe the shepherd was also bamboozled.) -- COMMENT: -- ## NITS "defintions" -> "definitions" "Using graph theory" -> perhaps, "in the terminology of graph theory" or "to use the terminology of graph theory"? "Roots CAs" -> "Root CAs"? "The EST Registration Authority (RA) is configured with the DNS domain which it will issue certificates." That should be "for which", right? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-subdomains-07.txt
The authors feel this update addresses all recent review comments. All comments were tracked with individual github issues, and corresponding commits, if that makes it easier to fine the respective updates: https://github.com/upros/acme-subdomains/issues?q=is%3Aissue+is%3Aclosed Owen -Original Message- From: Acme On Behalf Of internet-dra...@ietf.org Sent: Wednesday, March 1, 2023 9:38 PM To: i-d-annou...@ietf.org Cc: acme@ietf.org Subject: [Acme] I-D Action: draft-ietf-acme-subdomains-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Automated Certificate Management Environment WG of the IETF. Title : Automated Certificate Management Environment (ACME) for Subdomains Authors : Owen Friel Richard Barnes Tim Hollebeek Michael Richardson Filename: draft-ietf-acme-subdomains-07.txt Pages : 22 Date: 2023-03-01 Abstract: This document specifies how Automated Certificate Management Environment (ACME) can be used by a client to obtain a certificate for a subdomain identifier from a certification authority. This document specifies how a client can fulfill a challenge against an ancestor domain but may not need to fulfill a challenge against the explicit subdomain if certification authority policy allows issuance of the subdomain certificate without explicit subdomain ownership proof. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-subdomains/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-acme-subdomains-07 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-subdomains-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ 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] I-D Action: draft-ietf-acme-subdomains-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Automated Certificate Management Environment WG of the IETF. Title : Automated Certificate Management Environment (ACME) for Subdomains Authors : Owen Friel Richard Barnes Tim Hollebeek Michael Richardson Filename: draft-ietf-acme-subdomains-07.txt Pages : 22 Date: 2023-03-01 Abstract: This document specifies how Automated Certificate Management Environment (ACME) can be used by a client to obtain a certificate for a subdomain identifier from a certification authority. This document specifies how a client can fulfill a challenge against an ancestor domain but may not need to fulfill a challenge against the explicit subdomain if certification authority policy allows issuance of the subdomain certificate without explicit subdomain ownership proof. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-subdomains/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-acme-subdomains-07 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-subdomains-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] [dnsdir] Dnsdir telechat review of draft-ietf-acme-integrations-13
BTW, this came out sounding kind of grudging. I should say that my concerns in the previous review were my concerns, which may or may not have mattered, and I appreciate the authors addressing the concerns they addressed, and understand that they didn't see the other issues the way I did (or did, but addressed them differently than I would have). So when I refer to the "reasonable, if disappointing" reaction, it's me who's somewhat disappointed, and I am not suggesting that the IETF should be, and I really just shouldn't have said that in the review—sorry about that. On Wed, Mar 1, 2023 at 7:59 AM Ted Lemon via Datatracker via dnsdir < dns...@ietf.org> wrote: > Reviewer: Ted Lemon > Review result: Ready > > In my previous review, I mentioned that the text about graph theory seemed > to > make the document harder, not easier, to understand. This was an editorial > comment, which the authors mostly ignored, which is fine. They did add an > admonition to the reader to read RFC8499 for further clarification, for > what > that's worth. > > I also mentioned that the diagrams that show the ACME process aren't > contextualized as being part of ACME, which made it hard to figure out > where > these operations were actually described in a standard. The authors added > some > text that may have been intended to address this concern, but it's not > clear, > and I don't think this suggestion has been addressed. It was an editorial > nit, > so that seems like a reasonable, if disappointing, reaction. > > I also mentioned that the text about the use of ACME for subdomains is > somewhat > contradictory, since in one place it says they are not necessary, and in > another case it gives an example that depends on them. Some text has been > added > that may have been intended to ameliorate this concern. This was a "ready > with > issues" point, meaning that I thought it should definitely be corrected. I > think this change addresses the concern. > > I also asked for a clarification in the security considerations section > (now > section 10) that the mention of using DNS updates and TSIG or SIG(0) was > needlessly prescriptive. The update softens this text and I think > addresses my > concern. > > I also pointed out an issue with the text implying that TSIG uses "DNS key > records," which it does not, and the new text no longer confuses key > records > (SIG(0)) and TSIG keys, referring to both as "credentials." This addresses > my > concern, and also includes other means of update in the concern about > credential leakage. I think this addresses my concern. > > I further requested that references be given for RFC2136 and RFC2931 since > the > mechanisms described therein were being referenced. These references have > been > added. > > So I would say at this point that the concerns I raised have been > addressed and > the document is ready to go. > > > -- > dnsdir mailing list > dns...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsdir > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Dnsdir telechat review of draft-ietf-acme-integrations-13
Reviewer: Ted Lemon Review result: Ready In my previous review, I mentioned that the text about graph theory seemed to make the document harder, not easier, to understand. This was an editorial comment, which the authors mostly ignored, which is fine. They did add an admonition to the reader to read RFC8499 for further clarification, for what that's worth. I also mentioned that the diagrams that show the ACME process aren't contextualized as being part of ACME, which made it hard to figure out where these operations were actually described in a standard. The authors added some text that may have been intended to address this concern, but it's not clear, and I don't think this suggestion has been addressed. It was an editorial nit, so that seems like a reasonable, if disappointing, reaction. I also mentioned that the text about the use of ACME for subdomains is somewhat contradictory, since in one place it says they are not necessary, and in another case it gives an example that depends on them. Some text has been added that may have been intended to ameliorate this concern. This was a "ready with issues" point, meaning that I thought it should definitely be corrected. I think this change addresses the concern. I also asked for a clarification in the security considerations section (now section 10) that the mention of using DNS updates and TSIG or SIG(0) was needlessly prescriptive. The update softens this text and I think addresses my concern. I also pointed out an issue with the text implying that TSIG uses "DNS key records," which it does not, and the new text no longer confuses key records (SIG(0)) and TSIG keys, referring to both as "credentials." This addresses my concern, and also includes other means of update in the concern about credential leakage. I think this addresses my concern. I further requested that references be given for RFC2136 and RFC2931 since the mechanisms described therein were being referenced. These references have been added. So I would say at this point that the concerns I raised have been addressed and the document is ready to go. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
