rfc9799v2.txt   rfc9799.txt 
Internet Engineering Task Force (IETF) Q. Misell, Ed. Internet Engineering Task Force (IETF) Q Misell, Ed.
Request for Comments: 9799 AS207960 Request for Comments: 9799 AS207960
Category: Standards Track June 2025 Category: Standards Track June 2025
ISSN: 2070-1721 ISSN: 2070-1721
Automated Certificate Management Environment (ACME) Extensions for Automated Certificate Management Environment (ACME) Extensions for
".onion" Special-Use Domain Names ".onion" Special-Use Domain Names
Abstract Abstract
This document defines extensions to the Automated Certificate This document defines extensions to the Automated Certificate
skipping to change at line 721 skipping to change at line 721
A site MAY redirect to another site when completing validation using A site MAY redirect to another site when completing validation using
the http-01 challenge. This redirect MAY be to either another the http-01 challenge. This redirect MAY be to either another
".onion" Special-Use Domain Name or a domain in the public DNS. A ".onion" Special-Use Domain Name or a domain in the public DNS. A
site operator MUST consider the privacy implications of redirecting site operator MUST consider the privacy implications of redirecting
to a site that is not ".onion" -- namely that the ACME server to a site that is not ".onion" -- namely that the ACME server
operator will then be able to learn information about the site they operator will then be able to learn information about the site they
were redirected to that they would not have if accessed via a were redirected to that they would not have if accessed via a
".onion" Special-Use Domain Name, such as its IP address. If the ".onion" Special-Use Domain Name, such as its IP address. If the
site redirected to is on the same or an adjacent host to the ".onion" site redirected to is on the same or an adjacent host to the ".onion"
Special-Use Domain Name, this reveals information that the "Tor Special-Use Domain Name, this reveals information that the "Tor
Rendezvous Specification - Version 3" secion of [tor-spec] was Rendezvous Specification - Version 3" section of [tor-spec] was
otherwise designed to protect. otherwise designed to protect.
If an ACME server receives a redirect to a domain in the public DNS, If an ACME server receives a redirect to a domain in the public DNS,
it MUST NOT utilize Tor to make a connection to it due to the risk of it MUST NOT utilize Tor to make a connection to it due to the risk of
exit hijacking. exit hijacking.
8.6. Security of CAA Records 8.6. Security of CAA Records
The Second Layer Hidden Service Descriptor is signed, encrypted, and The Second Layer Hidden Service Descriptor is signed, encrypted, and
encoded using a Message Authentication Code (MAC) in a way that only encoded using a Message Authentication Code (MAC) in a way that only
a party with access to the secret key of the Hidden Service could a party with access to the secret key of the Hidden Service could
manipulate what is published there. For more information about this manipulate what is published there. For more information about this
process, see the "Hidden service descriptors: encryption format" process, see the "Hidden service descriptors: encryption format"
section of [tor-spec]. section of [tor-spec].
8.7. In-Band CAA 8.7. In-Band CAA
Tor directory servers are inherently untrusted entities; as such, Tor directory servers are inherently untrusted entities. As such,
there is no difference in the security model for accepting CAA there is no difference in the security model for accepting CAA
records directly from the ACME client or fetching them over Tor. records directly from the ACME client or fetching them over Tor: the
There is no difference in the security model between accepting CAA CAA records are verified using the same hidden service key in either
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. case.
8.8. Access of the Tor Network 8.8. Access of the Tor Network
The ACME server MUST make its own connection to the Hidden Service The ACME server MUST make its own connection to the Hidden Service
via the Tor network and MUST NOT outsource this to a third-party via the Tor network and MUST NOT outsource this to a third-party
service, such as Tor2Web. service, such as Tor2Web.
8.9. Anonymity of the ACME Client 8.9. Anonymity of the ACME Client
skipping to change at line 875 skipping to change at line 873
Winter, P., Köwer, R., Mulazzani, M., Huber, M., Winter, P., Köwer, R., Mulazzani, M., Huber, M.,
Schrittwieser, S., Lindskog, S., and E. Weippl, "Spoiled Schrittwieser, S., Lindskog, S., and E. Weippl, "Spoiled
Onions: Exposing Malicious Tor Exit Relays", Privacy Onions: Exposing Malicious Tor Exit Relays", Privacy
Enhancing Technologies (PETS 2014), Lecture Notes in Enhancing Technologies (PETS 2014), Lecture Notes in
Computer Science, vol. 8555, pp. 304-331, Computer Science, vol. 8555, pp. 304-331,
DOI 10.1007/978-3-319-08506-7_16, 2014, DOI 10.1007/978-3-319-08506-7_16, 2014,
<https://doi.org/10.1007/978-3-319-08506-7_16>. <https://doi.org/10.1007/978-3-319-08506-7_16>.
[tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS [tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft, Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-24, 20 March 2025, draft-ietf-tls-esni-25, 14 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-24>. esni-25>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>. December 2021, <https://www.rfc-editor.org/info/rfc9162>.
Appendix A. Discussion on the Use of the "dns" Identifier Type Appendix A. Discussion on the Use of the "dns" Identifier Type
The reasons for utilizing the "dns" identifier type in ACME and not The reasons for utilizing the "dns" identifier type in ACME and not
defining a new identifier type for ".onion" may not seem obvious at defining a new identifier type for ".onion" may not seem obvious at
first glance. After all, ".onion" Special-Use Domain Names are not first glance. After all, ".onion" Special-Use Domain Names are not
 End of changes. 6 change blocks. 
9 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.48.