IANA, Please make the following updates to https://www.iana.org/assignments/acme/acme.xhtml#acme-error-types to match the document.
Original: The CA only supports checking CAA for hidden services in-band, but the client has not provided an in-band CAA New (add “the” and cap Hidden Services): The CA only supports checking the CAA for Hidden Services in-band, but the client has not provided an in-band CAA Once these updates have been confirmed, this document will be ready to move forward to publication. Thank you. RFC Editor/mf > On Jun 6, 2025, at 4:51 PM, Q Misell <q...@as207960.net> wrote: > > That looks good to me. Happy for this to move to TI. > Any statements contained in this email are personal to the author and are not > necessarily the statements of the company unless specifically stated. > AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, > Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered > in Wales under № 12417574, LEI 875500FXNCJPAPF3PD10. ICO register №: > ZA782876. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: > 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a > registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, > 46001, trading as Glauca Digital, is a company registered in Estonia under № > 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are > registered trademarks in the UK, under № UK00003718474 and № UK00003718468, > respectively. > > > > Ar Gwen, 6 Meh 2025 am 18:26 Megan Ferguson <mfergu...@staff.rfc-editor.org> > ysgrifennodd: > Hi Q, > > Thank you for the prompt reply. We have updated the redundant text (with a > few punctuation tweaks pulled back in from our previous edits). Please > review and approve. > > We have also noted your request to wait for tooling to handle the name issue > at the AUTH48 status page for this document. Once we receive your approval > of the last update, we will move this document to TI state (Tooling Issue) to > await resolution. > > 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/rfc9799.txt > https://www.rfc-editor.org/authors/rfc9799.pdf > https://www.rfc-editor.org/authors/rfc9799.html > https://www.rfc-editor.org/authors/rfc9799.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9799-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9799-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9799-lastdiff.html (last version to > this) > > Please contact us with any further updates/questions/comments you may have. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9799 > > Thank you. > > RFC Editor/mf > > > On Jun 6, 2025, at 4:54 AM, Q Misell <q...@as207960.net> wrote: > > > > Hi Megan, > > > > I'd rather wait a bit longer for the discussion on pull #1246 to conclude. > > I don't mind if this RFC takes a little longer to publish, but with my name > > shown correctly. > > > > In re the redundant text, indeed I did get confused with other questions. > > You are right, it is redundant. I propose the following text instead: > > > > Tor directory servers are inherently untrusted entities, and as such there > > is no difference in the security model for accepting CAA records directly > > from the ACME client or fetching them over Tor; the CAA records are > > verified using the same hidden service key in either case. > > > > Q > > Any statements contained in this email are personal to the author and are > > not necessarily the statements of the company unless specifically stated. > > AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, > > Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company > > registered in Wales under № 12417574, LEI 875500FXNCJPAPF3PD10. ICO > > register №: ZA782876. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish > > VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, > > having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, > > Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in > > Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and > > the Glauca logo are registered trademarks in the UK, under № UK00003718474 > > and № UK00003718468, respectively. > > > > > > > > Ar Iau, 5 Meh 2025 am 21:39 Megan Ferguson <mfergu...@staff.rfc-editor.org> > > ysgrifennodd: > > Hi Q, > > > > Thanks for the prompt reply and the updated XML file. > > We have adopted this version and posted to the links below. > > > > A few follow-up comments/questions: > > > > 1) Looks like the issue about your initial is still being discussed (see > > https://github.com/ietf-tools/xml2rfc/pull/1246). > > > > 2) We may have confused you with Question 14 with side edits (sorry!). > > Please review the following for redundancy and let us know if you’d like to > > make any changes: > > > > Original: > > > > Tor directory servers are inherently untrusted entities, and as such > > there is no difference in the security model for accepting CAA > > records directly from the ACME client or fetching them over Tor. > > There is no difference in the security model between accepting CAA > > records directly from the ACME client and fetching them over Tor; the > > CAA records are verified using the same hidden service key in either > > case. > > > > 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/rfc9799.txt > > https://www.rfc-editor.org/authors/rfc9799.pdf > > https://www.rfc-editor.org/authors/rfc9799.html > > https://www.rfc-editor.org/authors/rfc9799.xml > > > > The relevant diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9799-diff.html (comprehensive diff) > > https://www.rfc-editor.org/authors/rfc9799-auth48diff.html (AUTH48 > > changes 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/rfc9799 > > > > Thank you. > > > > RFC Editor/mf > > > > > On Jun 4, 2025, at 7:26 AM, Q Misell <q=40as207960....@dmarc.ietf.org> > > > wrote: > > > > > > > > > Thank you for your copy editing; as always, much appreciated! > > > > > > Attached is my edited XML source, incorporating changes relating to your > > > comments. Below are my responses to all comments. > > > > > > > The short title that appears in the running header of the pdf output > > > > has been updated to use double quotes around ".onion" to match the use > > > > in the full title. > > > > > > LGTM. > > > > > > > Q - currently our tooling does not support the request to remove the > > > > period from following your first name. > > > > > > I have made a PR to xml2rfc > > > (https://github.com/ietf-tools/xml2rfc/pull/1246) to fix this to my > > > liking. > > > I would appreciate that merged before publication. > > > > > > > Please insert any keywords > > > > > > Done. > > > > > > > Please review our edits to the following text to ensure we have > > > > maintained your intent. > > > > The ACME server SHOULD follow redirects. Note that these MAY be > > > > redirects to services that are not ".onion" and that the server SHOULD > > > > honor these. > > > > > > LGTM. > > > > > > > Please review our updates to this text carefully and let us know any > > > > objections. > > > > An "onion-csr-01" challenge MUST NOT be used to issue certificates for > > > > Special-Use Domain Names that are not ".onion". > > > > > > LGTM. > > > > > > > Please note that sourcecode elements in this document exceed our > > > > character limit > > > > > > XML edited accordingly. > > > > > > > Please note that we have updated to use "flags" (plural) to match the > > > > use in Section 4.1.1 of RFC 8659. > > > > > > No objection. > > > > > > > In the following instances, please review the use of the BCP 14 keyword > > > > with the surrounding text > > > > > > Fixed in HTML. > > > > > > > We have deleted the "it" before the comma in this sentence. > > > > > > LGTM. > > > > > > > Please note that we believe Section 9.7.8 should actually read 9.7.4 in > > > > the following. > > > > > > That is correct. > > > > > > > We believe "ACME Directory Metadata Fields" registry is defined in > > > > Section 9.7.6 of [RFC8555], not Section 9.7.8. > > > > > > That is correct. > > > > > > > Please review our update to this text to expand MAC and avoid using an > > > > abbreviation as a verb. > > > > > > LGTM > > > > > > > These sentences seem redundant. Please review. > > > > > > Edits LGTM > > > > > > > Please note that we have changed the URL of the [spoiled-onions] > > > > reference to point use the DOI rather than the original URL, which took > > > > the reader to a preview page that they couldn't back out of. > > > > > > LGTM > > > > > > > Please review. We found an open-access version of [spoiled-onions] on > > > > arXiv. The information appears to match the current reference; however, > > > > some author names are missing. Would you prefer to use this open-access > > > > version of this reference? > > > > > > The version I worked from whilst writing this RFC was the one published > > > by Springer. The version on the arXiv appears to be a draft before the > > > paper underwent peer-review, and as such I would rather not use it. > > > > > > > We assume ".onion" is pronounced as "dot onion" and have thus left > > > > instances of "a ".onion" as they were. > > > > > > That is correct. > > > > > > > We see the following similar terms used. Please let us know if these > > > > should be made uniform or if they should remain distinct terms. > > > > > > They are all equivalent, I have edited the XML accordingly. > > > > > > > We note that <tt> tags were used to enclose the following terms in this > > > > document. > > > > > > XML edited accordingly. > > > > > > > Please note we have expanded these abbreviations as follows > > > > > > LGTM > > > > > > > We note that the original xml file submitted used <eref> to point to > > > > specific sections in the [tor-spec]. Please review if these links > > > > should remain with the following in mind. Please let us know how you > > > > would like to proceed. > > > > > > As, even during the course of drafting this RFC, the links became > > > outdated, I have opted to remove any <eref>s to Tor spec documents. > > > > > > > Please consider whether the “type" attribute of any sourcecode element > > > > should be set and/or has been set correctly. > > > > > > I'm happy with the type attributes as they are. > > > > > > > Please note that CSR (the abbreviation at least) is not used in either > > > > Appendix B.2.b of [cabf-br] or [RFC2986]. Please review the citations > > > > in this document and let us know if any updates are necessary/desirable. > > > > > > I've expanded the abbreviation to Certificate Request where appropriate > > > in the XML. > > > Any statements contained in this email are personal to the author and are > > > not necessarily the statements of the company unless specifically stated. > > > AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, > > > Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company > > > registered in Wales under № 12417574, LEI 875500FXNCJPAPF3PD10. ICO > > > register №: ZA782876. UK VAT №: GB378323867. EU VAT №: EU372013983. > > > Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 > > > Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, > > > Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company > > > registered in Estonia under № 16755226. Estonian VAT №: EE102625532. > > > Glauca Digital and the Glauca logo are registered trademarks in the UK, > > > under № UK00003718474 and № UK00003718468, respectively. > > > > > > > > > > > > Ar Llun, 2 Meh 2025 am 22:53 <rfc-edi...@rfc-editor.org> ysgrifennodd: > > > Q, > > > > > > While reviewing this document during AUTH48, please resolve (as > > > necessary) the following questions, which are also in the XML file. > > > > > > 1) <!-- [rfced] Please note that the title of the document has been > > > updated as follows: > > > > > > The short title that appears in the running header of the pdf output has > > > been updated to use double quotes around ".onion" to match the use in the > > > full title. > > > > > > Original: > > > > > > ACME for .onion > > > Current: > > > ACME for ".onion" > > > --> > > > > > > > > > 2) <!--[rfced] Q - currently our tooling does not support the request to > > > remove the period from following your first name. Please see > > > https://github.com/ietf-tools/xml2rfc/issues/1204. We have > > > commented on this issue to raise awareness that you document is > > > now in AUTH48 and publication is nearing. > > > > > > > > > --> > > > > > > > > > 3) <!-- [rfced] Please insert any keywords (beyond those that appear in > > > the title) for use on https://www.rfc-editor.org/search. --> > > > > > > > > > 4) <!--[rfced] Please review our edits to the following text to ensure we > > > have maintained your intent. > > > > > > Original: > > > The ACME server SHOULD follow redirects; note that these MAY be > > > redirects to non-".onion" services, and the server SHOULD honour > > > these. > > > > > > Current: > > > The ACME server SHOULD follow redirects. Note that these MAY be > > > redirects to services that are not ".onion" and that the server > > > SHOULD honor these. > > > > > > --> > > > > > > > > > 5) <!--[rfced] Please review our updates to this text carefully and let > > > us know any objections. > > > > > > Original: > > > > > > An "onion-csr-01" MUST NOT be used to issue certificates for non > > > ".onion" Special-Use Domain Names. > > > > > > Current: > > > An "onion-csr-01" challenge MUST NOT be used to issue certificates for > > > Special-Use Domain Names that are not ".onion". > > > --> > > > > > > > > > 6) <!--[rfced] Please note that sourcecode elements in this document > > > exceed our character limit (see > > > https://authors.ietf.org/en/drafting-in-plaintext for the 69 > > > character limit on sourcecode elements). Please review > > > throughout the document and let us know how these may be changed > > > (or feel free to update/replace in the edited XML file yourself > > > if this is more convenient).--> > > > > > > > > > 7) <!--[rfced] Please note that we have updated to use "flags" (plural) > > > to match the use in Section 4.1.1 of RFC 8659. Please let us > > > know any objections. > > > > > > > > > Original: > > > The contents of "flag", "tag", and "value" are as per Section 4.1.1 > > > of [RFC8659]. > > > > > > Current: > > > The contents of "flags", "tag", and "value" are as per Section 4.1.1 > > > of [RFC8659]. > > > > > > --> > > > > > > > > > 8) <!--[rfced] In the following instances, please review the use of the > > > BCP 14 keyword with the surrounding text (i.e., also and always > > > specifically). > > > > > > > > > Original: > > > > > > A hidden service operator MAY also not wish to publish a CAA record > > > set in its service descriptor to avoid revealing information about the > > > service operator. > > > > > > Perhaps: > > > Also, a hidden service operator MAY not wish to publish a CAA record > > > set in its service descriptor to avoid revealing information about the > > > service operator. > > > > > > > > > > > > Original: > > > In any case, the server always MAY fetch the record set from the > > > service descriptor. > > > > > > Perhaps: > > > In any case, the server MAY fetch the record set from the > > > service descriptor. > > > > > > --> > > > > > > > > > 9) <!--[rfced] We have deleted the "it" before the comma in this > > > sentence. Please let us know if some other rephrase was > > > intended. > > > > > > Original: > > > If an ACME server does not support fetching a service's CAA record > > > set from its service descriptor it, and the ACME client does not > > > provide an "onionCAA" object in its finalize request the ACME server > > > MUST respond with an "onionCAARequired" error to indicate this. > > > > > > Current: > > > If an ACME server does not support fetching a service's CAA record > > > set from its service descriptor, and the ACME client does not > > > provide an "onionCAA" object in its finalize request, the ACME server > > > MUST respond with an "onionCAARequired" error to indicate this. > > > > > > --> > > > > > > > > > 10) <!--[rfced] Please note that any changes affecting IANA registries > > > will be communicated to IANA by the RPC once AUTH48 completes.--> > > > > > > > > > 11) <!-- [rfced] Please note that we believe Section 9.7.8 should actually > > > read 9.8.4 in the following. Please review and confirm our > > > update. > > > > > > Original: > > > Per this document, one new entry has been added to the "ACME > > > Validation Methods" registry defined in Section 9.7.8 of [RFC8555]... > > > > > > Current: > > > Per this document, one new entry has been added to the "ACME > > > Validation Methods" registry defined in Section 9.7.4 of [RFC8555]... > > > > > > --> > > > > > > > > > 12) <!-- [rfced] We believe "ACME Directory Metadata Fields" registry is > > > defined in Section 9.7.6 of [RFC8555], not Section 9.7.8. Please > > > confirm our update. > > > --> > > > > > > > > > 13) <!--[rfced] Please review our update to this text to expand MAC and > > > avoid using an abbreviation as a verb (see > > > https://www.rfc-editor.org/styleguide/part2/#abbrev_as_verb). If > > > this does not correctly capture your intent, please let us know > > > how we may rephrase. > > > > > > Original: > > > The second layer descriptor is signed, encrypted and MACed in a way > > > that only a party with access to the secret key of the hidden service > > > could manipulate what is published there. > > > > > > Current: > > > The second layer descriptor is signed, encrypted, and encoded using > > > Message Authentication Code (MAC) in a way that only a party with > > > access to the secret key of the hidden service could manipulate > > > what is published there. > > > > > > > > > --> > > > > > > > > > 14) <!--[rfced] These sentences seem redundant. Please review. > > > > > > Original: > > > > > > Tor directory servers are inherently untrusted entities, and as such > > > there is no difference in the security model for accepting CAA > > > records directly from the ACME client or fetching them over Tor. > > > There is no difference in the security model between accepting CAA > > > records directly from the ACME client and fetching them over Tor; the > > > CAA records are verified using the same hidden service key in either > > > case. > > > --> > > > > > > > > > 15) <!-- [rfced] Please note that we have changed the URL of the > > > [spoiled-onions] reference to point use the DOI rather than the > > > original URL, which took the reader to a preview page that they > > > couldn't back out of. Please review. > > > > > > Original: > > > https://rdcu.be/d1ZRp > > > > > > Current: > > > https://doi.org/10.1007/978-3-319-08506-7_16 > > > > > > --> > > > > > > > > > 16) <!-- [rfced] Please review. We found an open-access version of > > > [spoiled-onions] on arXiv. The information appears to match the > > > current reference; however, some author names are missing. Would you > > > prefer to use this open-access version of this reference? --> > > > > > > > > > 17) <!--[rfced] We have the following questions related to terminology > > > used throughout the document: > > > > > > a) We assume ".onion" is pronounced as "dot onion" and have thus left > > > instances of "a ".onion" as they were. If this is incorrect, please > > > let us know and we can update to "an ".onion"" as necessary. > > > > > > b) We see the following similar terms used. Please let us know if these > > > should be made uniform or if they s > > > hould remain distinct terms: > > > > > > first layer hidden service descriptor vs. first layer descriptor > > > second layer hidden service descriptor vs. second layer descriptor > > > Hidden Service vs. hidden service > > > ".onion" service vs. "Onion Services" > > > http-01 vs. "http-01" > > > tls-alpn-01 vs. "tls-alpn-01" > > > > > > c) We note that <tt> tags were used to enclose the following terms in > > > this document. Please review use for consistency as we note they were > > > not used on every occurrence. Please also review the output of the > > > <tt> tags in all formats (html, pdf, text) to ensure satisfaction. > > > > > > <tt>applicantSigningNonce</tt> > > > <tt>auth-client</tt> > > > <tt>caSigningNonce</tt> > > > <tt>"onion-csr-01".</tt> > > > --> > > > > > > > > > 18) <!--[rfced] Please review the following questions/comments regarding > > > abbreviation use in this document: > > > > > > a) Please note we have expanded these abbreviations as follows (per > > > the reference in parentheses when applicable). Please review and let > > > us know any objections/corrections: > > > > > > > > > CSR - Certificate Signing Request (RFC 8555) > > > PEM - Privacy Enhanced Mail (RFC 4648) > > > TLD - Top-Level Domain > > > ECH - Encrypted ClientHello (draft-ietf-tls-esni-24) > > > > > > b) Please note that CSR (the abbreviation at least) is not used in > > > either Appendix B.2.b of [cabf-br] or [RFC2986]. Please review the > > > citations in this document and let us know if any updates are > > > necessary/desirable. > > > > > > --> > > > > > > > > > 19) <!--[rfced] We note that the original xml file submitted used <eref> > > > to point to specific sections in the [tor-spec]. Please review > > > if these links should remain with the following in mind: > > > > > > a) These links make a difference in the output formats as follows: > > > > > > html (where the section names are linked): > > > To this end, an additional field in the challenge object is defined to > > > allow the ACME server to advertise th > > > e Ed25519 public key it will use (as per the "Authentication during the > > > introduction phase" section of [tor- > > > spec]) to authenticate itself when retrieving the hidden service > > > descriptor. > > > > > > txt (where the link appears in-line): > > > To this end, a new field is added to the second layer hidden service > > > descriptor, as defined in the "Second layer plaintext format" > > > (https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#second- > > > layer-plaintext) section of [tor-spec] with the following format > > > (defined using the notation from the "netdoc document meta-format" > > > (https://spec.torproject.org/dir-spec/netdoc.html) section of > > > [tor-spec]): > > > > > > b) These links may become stale quickly as [tor-spec] mentions an > > > upcoming reorganization and that it is a living document. > > > > > > An alternative would be to remove the links but include the section > > > names in the text itself (i.e., not use <eref>) and allow the reader > > > to simply navigate to the section from the main [tor-spec] link. This > > > would allow the html and text versions to be the same. > > > > > > Please let us know how you would like to proceed. > > > --> > > > > > > > > > 20) <!-- [rfced] Please consider whether the “type" attribute of any > > > sourcecode element should be set and/or has been set correctly. > > > > > > The current list of preferred values for "type" is available at > > > <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. > > > If the current list does not contain an applicable type, feel free to > > > suggest additions for consideration. Note that it is also acceptable > > > to leave the "type" attribute not set. > > > --> > > > > > > > > > 21) <!-- [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. > > > > > > RFC Editor/mf > > > > > > *****IMPORTANT***** > > > > > > Updated 2025/06/02 > > > > > > 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. > > > > > > * 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. > > > > > > * 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 > > > > > > * 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). > > > > > > * 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>. > > > > > > * 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. > > > > > > > > > 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/rfc9799.xml > > > https://www.rfc-editor.org/authors/rfc9799.html > > > https://www.rfc-editor.org/authors/rfc9799.pdf > > > https://www.rfc-editor.org/authors/rfc9799.txt > > > > > > Diff file of the text: > > > https://www.rfc-editor.org/authors/rfc9799-diff.html > > > https://www.rfc-editor.org/authors/rfc9799-rfcdiff.html (side by side) > > > > > > Diff of the XML: > > > https://www.rfc-editor.org/authors/rfc9799-xmldiff1.html > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > https://www.rfc-editor.org/auth48/rfc9799 > > > > > > Please let us know if you have any questions. > > > > > > Thank you for your cooperation, > > > > > > RFC Editor > > > > > > -------------------------------------- > > > RFC9799 (draft-ietf-acme-onion-07) > > > > > > Title : Automated Certificate Management Environment (ACME) > > > Extensions for ".onion" Special-Use Domain Names > > > Author(s) : Q. Misell > > > WG Chair(s) : Yoav Nir, Tomofumi Okubo > > > > > > Area Director(s) : Deb Cooley, Paul Wouters > > > > > > > > > <rfc9799.xml> > > > > > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
