Hi David, Looking at https://www.iana.org/assignments/acme/acme.xhtml#acme-renewalinfo-object-fields, I believe there should be initial contents:
From Section 7.2 of the document (see https://www.rfc-editor.org/authors/rfc9773.txt): Initial contents: +=================+============+===============+ | Field Name | Field Type | Reference | +=================+============+===============+ | suggestedWindow | object | This document | +-----------------+------------+---------------+ | explanationURL | string | This document | +-----------------+------------+---------------+ Table 3 Thank you. RFC Editor/mf > On Jun 11, 2025, at 4:54 PM, David Dong via RT <iana-mat...@iana.org> wrote: > > 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
