Hi Megan, This has been completed:
1) renewalInfo RenewalInfo object [RFC-ietf-acme-ari-08] 2) ACME RenewalInfo Object Fields 3) alreadyReplaced The request specified a predecessor certificate that has already been marked as replaced [RFC-ietf-acme-ari-08] Registry: https://www.iana.org/assignments/acme/ Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Jun 09 17:07:33 2025, mfergu...@staff.rfc-editor.org wrote: > 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
