Hi Sabrina, Thanks for the quick turnaround!
We will move this document forward in the publication process at this time. RFC Editor/mf > On Jun 17, 2025, at 11:40 AM, Sabrina Tanamal via RT <iana-mat...@iana.org> > wrote: > > Hi Megan, > > These changes are complete: > > https://www.iana.org/assignments/acme > > Thanks, > Sabrina > > On Tue Jun 17 14:31:25 2025, mfergu...@staff.rfc-editor.org wrote: >> 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
