IANA, This document has completed AUTH48 and needs a few updates to the following to match. You may view the related diff (Section 7) for your convenience at: https://www.rfc-editor.org/authors/rfc9773-diff.html
1) At https://www.iana.org/assignments/acme/acme.xhtml#acme-resource-types, please remove the space between Renewal and Info: Original: renewalInfo Renewal Info object [RFC-ietf-acme-ari-08] Current: renewalInfo RenewalInfo object [RFC-ietf-acme-ari-08] 2) The new sub registry at https://www.iana.org/assignments/acme/acme.xhtml#acme-renewal-info-object-fields needs a similar title update: Original: ACME Renewal Info Object Fields Current: ACME RenewalInfo Object Fields 3) At https://www.iana.org/assignments/acme/acme.xhtml#acme-error-types, in the Description, please change “which” to “that”: Original: …predecessor certificate which has… Current: …predecessor certificate that has… Once these updates have been completed, this document will be ready to move forward in the publication process. Thank you. RFC Editor/mf > On Jun 6, 2025, at 5:55 PM, Aaron Gable <aa...@letsencrypt.org> wrote: > > Hi Megan, > > Apologies for the delay. After extensive review with all of my coworkers, we > have found one last typo: > > Section 6 > > OLD: > (or do no implement ARI at all) > > NEW: > (or do not implement ARI at all) > > Thanks, > Aaron > > On Thu, Jun 5, 2025 at 10:47 AM Megan Ferguson > <mfergu...@staff.rfc-editor.org> wrote: > Hi Aaron, > > Just a friendly reminder that we await your confirmation of our changes and > approval prior to moving this document forward in the publication process. > > Thank you. > > RFC Editor/mf > > > > > > Begin forwarded message: > > > > From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > > Subject: Re: AUTH48: RFC-to-be 9773 <draft-ietf-acme-ari-08> for your review > > Date: May 13, 2025 at 9:31:58 PM MDT > > To: Aaron Gable <aa...@letsencrypt.org> > > Cc: RFC Editor <rfc-edi...@rfc-editor.org>, acme-...@ietf.org, > > acme-cha...@ietf.org, ynir.i...@gmail.com, Deb Cooley > > <debcool...@gmail.com>, auth48archive@rfc-editor.org > > > > Hi Aaron, > > > > Thank you for sending along these changes in the XML file. We have adopted > > the changes and reposted. > > > > Please review the files carefully as we do not make changes after > > publication. > > > > The files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9773.txt > > https://www.rfc-editor.org/authors/rfc9773.pdf > > https://www.rfc-editor.org/authors/rfc9773.html > > https://www.rfc-editor.org/authors/rfc9773.xml > > > > The relevant diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9773-diff.html (comprehensive diff) > > https://www.rfc-editor.org/authors/rfc9773-auth48diff.html (AUTH48 > > changes only) > > https://www.rfc-editor.org/authors/rfc9773-lastdiff.html (last to current > > version only) > > https://www.rfc-editor.org/authors/rfc9773-lastrfcdiff.html (last to > > current version side by side) > > > > Please contact us with any further updates/questions/comments you may have > > or with your approval of the document in its current form. Once we have > > your approval, we will send along any necessary updates to IANA prior to > > publication. > > > > The AUTH48 status page for this document is available here: > > > > https://www.rfc-editor.org/auth48/rfc9773 > > > > Thank you. > > > > RFC Editor/mf > > > On May 13, 2025, at 5:29 PM, Aaron Gable <aa...@letsencrypt.org> wrote: > > > > I have two final minor edits that I would like to incorporate: > > > > - In Section 4.2, replace "set of names on the order" with "set of > > identifiers on the order". > > - In Section 5, replace "GET requests described above" with "GET requests > > described in Section 4.1", with an internal cross-link to that section. > > > > I have attached an XML file that I believe implements these two edits and > > no other changes; please make sure I haven't accidentally broken anything! > > > > Thanks again, > > Aaron > > > > On Wed, May 7, 2025 at 6:18 PM Megan Ferguson > > <mfergu...@staff.rfc-editor.org> wrote: > > Hi Aaron, > > > > Just a friendly reminder that the updates to this document await your > > review. > > > > Please contact us at your earliest convenience with any further changes you > > may have or your approval of the document in its current form. > > > > Thank you. > > > > RFC Editor/mf > > > > > > > On Apr 29, 2025, at 1:53 PM, Megan Ferguson > > > <mfergu...@staff.rfc-editor.org> wrote: > > > > > > Hi Aaron, > > > > > > Thank you for your reply and the updated XML file. > > > We have adopted your version (see below) and added the keywords suggested > > > to our database. > > > > > > Please review the files carefully as we do not make changes after > > > publication. > > > > > > The files have been posted here (please refresh): > > > https://www.rfc-editor.org/authors/rfc9773.txt > > > https://www.rfc-editor.org/authors/rfc9773.pdf > > > https://www.rfc-editor.org/authors/rfc9773.html > > > https://www.rfc-editor.org/authors/rfc9773.xml > > > > > > The relevant diff files have been posted here (please refresh): > > > https://www.rfc-editor.org/authors/rfc9773-diff.html (comprehensive > > > diff) > > > https://www.rfc-editor.org/authors/rfc9773-auth48diff.html (AUTH48 > > > changes only) > > > https://www.rfc-editor.org/authors/rfc9773-lastdiff.html (last to > > > current version only) > > > > > > Please contact us with any further updates/questions/comments you may > > > have. > > > > > > We will await approvals from each of the parties listed on the AUTH48 > > > status page prior to moving forward to publication. > > > > > > The AUTH48 status page for this document is available here: > > > > > > https://www.rfc-editor.org/auth48/rfc9773 > > > > > > Thank you. > > > > > > RFC Editor/mf > > > > > >> On Apr 25, 2025, at 4:17 PM, Aaron Gable > > >> <aaron=40letsencrypt....@dmarc.ietf.org> wrote: > > >> > > >> Hello editors, > > >> > > >> Thank you for the edits and improvements to this document! My responses > > >> to your specific questions are inline below, and the updated XML file is > > >> attached. > > >> > > >> Thanks again, > > >> Aaron > > >> > > >> On Wed, Apr 23, 2025 at 1:51 PM <rfc-edi...@rfc-editor.org> wrote: > > >> 1) <!-- [rfced] Please note that the title of the document has been > > >> updated as follows: > > >> > > >> We have moved the expansion of ACME from the document title to its first > > >> use in the Abstract as generally we do not expand abbreviations within > > >> abbreviations. > > >> > > >> Original: > > >> Automated Certificate Management Environment (ACME) Renewal > > >> Information (ARI) Extension > > >> > > >> Current: > > >> ACME Renewal Information (ARI) Extension > > >> > > >> --> > > >> > > >> Thank you, the improved title is great. > > >> > > >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > >> the title) for use on > > >> https://www.rfc-editancestorDomainancestorDomainor.org/search. --> > > >> > > >> I have added the following keywords: > > >> - certificate > > >> - CA > > >> - x509 > > >> - pki > > >> - webpki > > >> - renew > > >> - replace > > >> > > >> I'm not sure how best to see the keywords attached to other ACME > > >> documents all in one place; please feel free to add or remove keywords > > >> to bring this list in line with best practices. > > >> > > >> 3) <!--[rfced] Please review our update to "a literal period" to make it > > >> match similar handling of the "=" character later in the paragraph and > > >> uses in the RFC Series and let us know any objections. > > >> > > >> Original: > > >> > > >> The unique identifier is constructed by concatenating the > > >> base64url-encoding [RFC4648] of the keyIdentifier field of the > > >> certificate's Authority Key Identifier (AKI) [RFC5280] extension, a > > >> literal period, and the base64url-encoding of the DER-encoded Serial > > >> Number field (without the tag and length bytes). > > >> > > >> Current: > > >> > > >> The unique identifier is constructed by concatenating the > > >> base64url-encoding [RFC4648] of the keyIdentifier field of the > > >> certificate's Authority Key Identifier (AKI) [RFC5280] extension, the > > >> period character ".", and the base64url-encoding of the DER-encoded > > >> Serial > > >> Number field (without the tag and length bytes). > > >> > > >> --> > > >> > > >> This update looks great to me. > > >> > > >> 4) <!--[rfced] We had the following questions related to the IANA > > >> Considerations section: > > >> > > >> a) Section 7.1: In the Resource Type column of Table 2, please review if > > >> "Renewal info", "Renewal Information", or "renewalInfo" or something > > >> else should be used instead of "Renewal Info" as this is the only > > >> occurrence in the document of this form (other than Table 1, which also > > >> uses "Renewal info"). > > >> > > >> Original: > > >> Renewal Info object > > >> > > >> Thank you for catching this. I have settled on the following convention: > > >> - `renewalInfo` (always in <tt>, always starting lowercase) refers to > > >> the new entry added to the Directory object. > > >> - RenewalInfo (always in plaintext, always starting uppercase) refers to > > >> the newly-introduced resource/object. > > >> > > >> I've also eliminated all use of the shortened form "info", except as > > >> part of those two compound words. I have attempted to update the whole > > >> document to abide by this convention, but may have missed a spot. Please > > >> let me know if I have! > > >> > > >> b) Section 7.2: FYI - we have added a citation to RFC 8126 in the > > >> description of the Registration Procedure and a corresponding entry in > > >> the Informative References section. Please let us know any concerns. > > >> > > >> c) FYI- we will communicate any nits/edits to IANA upon the completion > > >> of AUTH48. > > >> > > >> > > >> --> > > >> > > >> Thanks for the heads-up! > > >> > > >> 5) <!--[rfced] Please review the following questions related to > > >> terminology use throughout the document. > > >> > > >> a) We see mixed marking of the following terms throughout the document. > > >> Please let us know if/how these may be made uniform: > > >> > > >> "renewalInfo" resource vs. renewalInfo resource > > >> > > >> See above, I believe I have standardized this now. > > >> > > >> New Order request vs. new-order request > > >> > > >> Interestingly, neither of these is correct! I have updated all instances > > >> to "newOrder request", to match RFC 8555 and other ACME documents. > > >> > > >> Server vs. server > > >> > > >> Standardized on the lowercase form, to match RFC 8555 > > >> > > >> base64url-encoding vs. base64url encoding > > >> > > >> Standardized on the form without a hyphen, to match RFC 8555. > > >> > > >> b) There are instances of simply RenewalInfo. Should a label follow > > >> (e.g., object, resource, etc.) for the ease of the reader? > > >> > > >> I have added either "object" or "resource" after all instances of > > >> RenewalInfo except those of the form "the certificate's RenewalInfo", > > >> which I think are already sufficiently clear. > > >> > > >> > > >> --> > > >> > > >> > > >> 6) <!--[rfced] We note the use of the <tt> element to mark text in this > > >> document. See the list of marked terms below. > > >> > > >> a) We recommend authors review the output of this element in all > > >> output formats (text, pdf, html, etc.) to ensure it appears as > > >> expected across formats. > > >> > > >> b) Please review for consistent use throughout the document (as we see > > >> some occurrences that are not marked with <tt>) and either update the > > >> edited XML file directly or let the RPC know if/how we may update > > >> . > > >> > > >> 00:87:65:43:21 > > >> 0x87 > > >> 69:88:5B:6B:87:46:40:41:E1:B3:7B:84:7B:A0:AE:2C:DE:01:C8:D4 > > >> AIdlQyE= > > >> aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE > > >> aYhba4dGQEHhs3uEe6CuLN4ByNQ= > > >> cron > > >> end > > >> explanationURL > > >> keyIdentifier > > >> renewalInfo > > >> replaces > > >> Retry-After > > >> start > > >> suggestedWindow > > >> = > > >> || > > >> > > >> I believe I have standardized the use of <tt> so that now it is used in > > >> only the following circumstances: > > >> - around JSON object field names, such as renewalInfo, suggestedWindow, > > >> explanationURL, start, end, and replaces > > >> - around literal byte sequences, such as the period, equals, pipes, and > > >> various hex and base64 values > > >> > > >> I have removed it from Retry-After, keyIdentifier, and cron. > > >> > > >> --> > > >> > > >> > > >> 7) <!-- [rfced] Please review the "Inclusive Language" portion of the > > >> online Style Guide > > >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and > > >> let us know if any changes are needed. Updates of this nature typically > > >> result in more precise language, which is helpful for readers. > > >> > > >> Note that our script did not flag any words in particular, but this > > >> should > > >> still be reviewed as a best practice. > > >> > > >> --> > > >> > > >> Thank you for this reference; I believe this document abides by all of > > >> its suggestions. All people mentioned in the acknowledgements have given > > >> their permission and preferred name. > > >> > > >> > > >> > > >> Thank you. > > >> > > >> RFC Editor/mf > > >> > > >> *****IMPORTANT***** > > >> > > >> Updated 2025/04/23 > > >> > > >> RFC Author(s): > > >> -------------- > > >> > > >> Instructions for Completing AUTH48 > > >> > > >> Your document has now entered AUTH48. Once it has been reviewed and > > >> approved by you and all coauthors, it will be published as an RFC. > > >> If an author is no longer available, there are several remedies > > >> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > >> > > >> You and you coauthors are responsible for engaging other parties > > >> (e.g., Contributors or Working Group) as necessary before providing > > >> your approval. > > >> > > >> Planning your review > > >> --------------------- > > >> > > >> Please review the following aspects of your document: > > >> > > >> * RFC Editor questions > > >> > > >> Please review and resolve any questions raised by the RFC Editor > > >> that have been included in the XML file as comments marked as > > >> follows: > > >> > > >> <!-- [rfced] ... --> > > >> > > >> These questions will also be sent in a subsequent email. > > >> > > >> I believe all questions have been addressed above. > > >> > > >> > > >> * Changes submitted by coauthors > > >> > > >> Please ensure that you review any changes submitted by your > > >> coauthors. We assume that if you do not speak up that you > > >> agree to changes submitted by your coauthors. > > >> > > >> No coauthors have submitted any parallel changes. > > >> > > >> > > >> * Content > > >> > > >> Please review the full content of the document, as this cannot > > >> change once the RFC is published. Please pay particular attention to: > > >> - IANA considerations updates (if applicable) > > >> - contact information > > >> - references > > >> > > >> All the content appears correct to my eye, though I've now stared at it > > >> for so long that I'm sure I'm blind to any remaining typos. > > >> > > >> > > >> * Copyright notices and legends > > >> > > >> Please review the copyright notice and legends as defined in > > >> RFC 5378 and the Trust Legal Provisions > > >> (TLP – https://trustee.ietf.org/license-info). > > >> > > >> Reviewed. > > >> > > >> > > >> * Semantic markup > > >> > > >> Please review the markup in the XML file to ensure that elements of > > >> content are correctly tagged. For example, ensure that <sourcecode> > > >> and <artwork> are set correctly. See details at > > >> <https://authors.ietf.org/rfcxml-vocabulary>. > > >> > > >> All semantic markup (largely just sourcecode and tt in this document) > > >> looks good to me. > > >> > > >> > > >> * Formatted output > > >> > > >> Please review the PDF, HTML, and TXT files to ensure that the > > >> formatted output, as generated from the markup in the XML file, is > > >> reasonable. Please note that the TXT will have formatting > > >> limitations compared to the PDF and HTML. > > >> > > >> Formatting looks good. Thank you so much for getting the text version to > > >> have nice indentation when defining new object fields (e.g. Section 5); > > >> I couldn't figure out how to get my markdown-to-rfc tooling to do that > > >> at all. > > >> > > >> Submitting changes > > >> ------------------ > > >> > > >> To submit changes, please reply to this email using ‘REPLY ALL’ as all > > >> the parties CCed on this message need to see your changes. The parties > > >> include: > > >> > > >> * your coauthors > > >> > > >> * rfc-edi...@rfc-editor.org (the RPC team) > > >> > > >> * other document participants, depending on the stream (e.g., > > >> IETF Stream participants are your working group chairs, the > > >> responsible ADs, and the document shepherd). > > >> > > >> * auth48archive@rfc-editor.org, which is a new archival mailing list > > >> to preserve AUTH48 conversations; it is not an active discussion > > >> list: > > >> > > >> * More info: > > >> > > >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > >> > > >> * The archive itself: > > >> https://mailarchive.ietf.org/arch/browse/auth48archive/ > > >> > > >> * Note: If only absolutely necessary, you may temporarily opt out > > >> of the archiving of messages (e.g., to discuss a sensitive > > >> matter). > > >> If needed, please add a note at the top of the message that you > > >> have dropped the address. When the discussion is concluded, > > >> auth48archive@rfc-editor.org will be re-added to the CC list and > > >> its addition will be noted at the top of the message. > > >> > > >> You may submit your changes in one of two ways: > > >> > > >> An update to the provided XML file > > >> — OR — > > >> An explicit list of changes in this format > > >> > > >> Section # (or indicate Global) > > >> > > >> OLD: > > >> old text > > >> > > >> NEW: > > >> new text > > >> > > >> You do not need to reply with both an updated XML file and an explicit > > >> list of changes, as either form is sufficient. > > >> > > >> We will ask a stream manager to review and approve any changes that seem > > >> beyond editorial in nature, e.g., addition of new text, deletion of > > >> text, > > >> and technical changes. Information about stream managers can be found > > >> in > > >> the FAQ. Editorial changes do not require approval from a stream > > >> manager. > > >> > > >> > > >> Approving for publication > > >> -------------------------- > > >> > > >> To approve your RFC for publication, please reply to this email stating > > >> that you approve this RFC for publication. Please use ‘REPLY ALL’, > > >> as all the parties CCed on this message need to see your approval. > > >> > > >> > > >> Files > > >> ----- > > >> > > >> The files are available here: > > >> https://www.rfc-editor.org/authors/rfc9773.xml > > >> https://www.rfc-editor.org/authors/rfc9773.html > > >> https://www.rfc-editor.org/authors/rfc9773.pdf > > >> https://www.rfc-editor.org/authors/rfc9773.txt > > >> > > >> Diff file of the text: > > >> https://www.rfc-editor.org/authors/rfc9773-diff.html > > >> https://www.rfc-editor.org/authors/rfc9773-rfcdiff.html (side by side) > > >> > > >> Diff of the XML: > > >> https://www.rfc-editor.org/authors/rfc9773-xmldiff1.html > > >> > > >> > > >> Tracking progress > > >> ----------------- > > >> > > >> The details of the AUTH48 status of your document are here: > > >> https://www.rfc-editor.org/auth48/rfc9773 > > >> > > >> Please let us know if you have any questions. > > >> > > >> Thank you for your cooperation, > > >> > > >> RFC Editor > > >> > > >> -------------------------------------- > > >> RFC9773 (draft-ietf-acme-ari-08) > > >> > > >> Title : Automated Certificate Management Environment (ACME) > > >> Renewal Information (ARI) Extension > > >> Author(s) : A. Gable > > >> WG Chair(s) : Yoav Nir, Tomofumi Okubo > > >> > > >> Area Director(s) : Deb Cooley, Paul Wouters > > >> > > >> > > >> <rfc9773.xml> > > > > > > > > > > > > > <rfc9773.xml> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
