├── .circleci └── config.yml ├── .editorconfig ├── .github ├── CODEOWNERS └── workflows │ ├── archive.yml │ ├── ghpages.yml │ ├── publish.yml │ └── update.yml ├── .gitignore ├── .gitmodules ├── 343-rend-caa.txt ├── CONTRIBUTING.md ├── LICENSE.md ├── Makefile ├── README.md └── draft-ietf-acme-onion.xml /.circleci/config.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | jobs: 3 | build: 4 | docker: 5 | - image: martinthomson/i-d-template:latest 6 | resource_class: small 7 | working_directory: ~/draft 8 | 9 | steps: 10 | - run: 11 | name: "Print Configuration" 12 | command: | 13 | xml2rfc --version 14 | gem list -q kramdown-rfc 15 | echo -n 'mmark '; mmark --version 16 | 17 | - restore_cache: 18 | name: "Restoring cache - Git" 19 | keys: 20 | - v2-cache-git-{{ .Branch }}-{{ .Revision }} 21 | - v2-cache-git-{{ .Branch }} 22 | - v2-cache-git- 23 | 24 | - restore_cache: 25 | name: "Restoring cache - References" 26 | keys: 27 | - v1-cache-references-{{ epoch }} 28 | - v1-cache-references- 29 | 30 | # Workaround for https://discuss.circleci.com/t/22437 31 | - run: 32 | name: Tag Checkout 33 | command: | 34 | if [ -n "$CIRCLE_TAG" ] && [ -d .git ]; then 35 | remote=$(echo "$CIRCLE_REPOSITORY_URL" | \ 36 | sed -e 's,/^git.github.com:,https://github.com/,') 37 | git fetch -f "$remote" "refs/tags/$CIRCLE_TAG:refs/tags/$CIRCLE_TAG" || \ 38 | (echo 'Removing .git cache for tag build'; rm -rf .git) 39 | fi 40 | 41 | - checkout 42 | 43 | # Build txt and html versions of drafts 44 | - run: 45 | name: "Build Drafts" 46 | command: make 47 | 48 | # Update editor's copy on gh-pages 49 | - run: 50 | name: "Update GitHub Pages" 51 | command: | 52 | if [ "${CIRCLE_TAG#draft-}" == "$CIRCLE_TAG" ]; then 53 | make gh-pages 54 | fi 55 | 56 | # For tagged builds, upload to the datatracker. 57 | - deploy: 58 | name: "Upload to Datatracker" 59 | command: | 60 | if [ "${CIRCLE_TAG#draft-}" != "$CIRCLE_TAG" ]; then 61 | make upload 62 | fi 63 | 64 | # Archive GitHub Issues 65 | - run: 66 | name: "Archive GitHub Issues" 67 | command: "make archive || make archive DISABLE_ARCHIVE_FETCH=true && make gh-archive" 68 | 69 | # Create and store artifacts 70 | - run: 71 | name: "Create Artifacts" 72 | command: "make artifacts CI_ARTIFACTS=/tmp/artifacts" 73 | 74 | - store_artifacts: 75 | path: /tmp/artifacts 76 | 77 | - run: 78 | name: "Prepare for Caching" 79 | command: "git reflog expire --expire=now --all && git gc --prune=now" 80 | 81 | - save_cache: 82 | name: "Saving Cache - Git" 83 | key: v2-cache-git-{{ .Branch }}-{{ .Revision }} 84 | paths: 85 | - ~/draft/.git 86 | 87 | - save_cache: 88 | name: "Saving Cache - Drafts" 89 | key: v1-cache-references-{{ epoch }} 90 | paths: 91 | - ~/.cache/xml2rfc 92 | 93 | 94 | workflows: 95 | version: 2 96 | build: 97 | jobs: 98 | - build: 99 | filters: 100 | tags: 101 | only: /.*?/ 102 | -------------------------------------------------------------------------------- /.editorconfig: -------------------------------------------------------------------------------- 1 | # See http://editorconfig.org 2 | 3 | root = true 4 | 5 | [*.{md,xml,org}] 6 | charset = utf-8 7 | insert_final_newline = true 8 | trim_trailing_whitespace = true 9 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Automatically generated CODEOWNERS 2 | # Regenerate with `make update-codeowners` 3 | draft-misell-acme-onion.xml q@as207970.net 4 | -------------------------------------------------------------------------------- /.github/workflows/archive.yml: -------------------------------------------------------------------------------- 1 | name: "Archive Issues and Pull Requests" 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * 0,2,4' 6 | repository_dispatch: 7 | types: [archive] 8 | workflow_dispatch: 9 | inputs: 10 | archive_full: 11 | description: 'Recreate the archive from scratch' 12 | default: false 13 | type: boolean 14 | 15 | jobs: 16 | build: 17 | name: "Archive Issues and Pull Requests" 18 | runs-on: ubuntu-latest 19 | steps: 20 | - name: "Checkout" 21 | uses: actions/checkout@v2 22 | 23 | # Note: No caching for this build! 24 | 25 | - name: "Update Archive" 26 | uses: martinthomson/i-d-template@v1 27 | env: 28 | ARCHIVE_FULL: ${{ inputs.archive_full }} 29 | with: 30 | make: archive 31 | token: ${{ github.token }} 32 | 33 | - name: "Update GitHub Pages" 34 | uses: martinthomson/i-d-template@v1 35 | with: 36 | make: gh-archive 37 | token: ${{ github.token }} 38 | 39 | - name: "Save Archive" 40 | uses: actions/upload-artifact@v3 41 | with: 42 | path: archive.json 43 | -------------------------------------------------------------------------------- /.github/workflows/ghpages.yml: -------------------------------------------------------------------------------- 1 | name: "Update Editor's Copy" 2 | 3 | on: 4 | push: 5 | paths-ignore: 6 | - README.md 7 | - CONTRIBUTING.md 8 | - LICENSE.md 9 | - .gitignore 10 | pull_request: 11 | paths-ignore: 12 | - README.md 13 | - CONTRIBUTING.md 14 | - LICENSE.md 15 | - .gitignore 16 | 17 | jobs: 18 | build: 19 | name: "Update Editor's Copy" 20 | runs-on: ubuntu-latest 21 | steps: 22 | - name: "Checkout" 23 | uses: actions/checkout@v3 24 | 25 | - name: "Setup" 26 | id: setup 27 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 28 | 29 | - name: "Caching" 30 | uses: actions/cache@v3 31 | with: 32 | path: | 33 | .refcache 34 | .venv 35 | .gems 36 | node_modules 37 | .targets.mk 38 | key: i-d-${{ steps.setup.outputs.date }} 39 | restore-keys: i-d- 40 | 41 | - name: "Build Drafts" 42 | uses: martinthomson/i-d-template@v1 43 | with: 44 | token: ${{ github.token }} 45 | 46 | - name: "Update GitHub Pages" 47 | uses: martinthomson/i-d-template@v1 48 | if: ${{ github.event_name == 'push' }} 49 | with: 50 | make: gh-pages 51 | token: ${{ github.token }} 52 | 53 | - name: "Archive Built Drafts" 54 | uses: actions/upload-artifact@v3 55 | with: 56 | path: | 57 | draft-*.html 58 | draft-*.txt 59 | -------------------------------------------------------------------------------- /.github/workflows/publish.yml: -------------------------------------------------------------------------------- 1 | name: "Publish New Draft Version" 2 | 3 | on: 4 | push: 5 | tags: 6 | - "draft-*" 7 | 8 | jobs: 9 | build: 10 | name: "Publish New Draft Version" 11 | runs-on: ubuntu-latest 12 | steps: 13 | - name: "Checkout" 14 | uses: actions/checkout@v3 15 | 16 | # See https://github.com/actions/checkout/issues/290 17 | - name: "Get Tag Annotations" 18 | run: git fetch -f origin ${{ github.ref }}:${{ github.ref }} 19 | 20 | - name: "Setup" 21 | id: setup 22 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 23 | 24 | - name: "Caching" 25 | uses: actions/cache@v3 26 | with: 27 | path: | 28 | .refcache 29 | .venv 30 | .gems 31 | node_modules 32 | .targets.mk 33 | key: i-d-${{ steps.setup.outputs.date }} 34 | restore-keys: i-d- 35 | 36 | - name: "Build Drafts" 37 | uses: martinthomson/i-d-template@v1 38 | with: 39 | token: ${{ github.token }} 40 | 41 | - name: "Upload to Datatracker" 42 | uses: martinthomson/i-d-template@v1 43 | with: 44 | make: upload 45 | 46 | - name: "Archive Submitted Drafts" 47 | uses: actions/upload-artifact@v3 48 | with: 49 | path: "versioned/draft-*-[0-9][0-9].*" 50 | -------------------------------------------------------------------------------- /.github/workflows/update.yml: -------------------------------------------------------------------------------- 1 | name: "Update Generated Files" 2 | # This rule is not run automatically. 3 | # It can be run manually to update all of the files that are part 4 | # of the template, specifically: 5 | # - README.md 6 | # - CONTRIBUTING.md 7 | # - .note.xml 8 | # - .github/CODEOWNERS 9 | # - Makefile 10 | # 11 | # 12 | # This might be useful if you have: 13 | # - added, removed, or renamed drafts (including after adoption) 14 | # - added, removed, or changed draft editors 15 | # - changed the title of drafts 16 | # 17 | # Note that this removes any customizations you have made to 18 | # the affected files. 19 | on: workflow_dispatch 20 | 21 | jobs: 22 | build: 23 | name: "Update Files" 24 | runs-on: ubuntu-latest 25 | steps: 26 | - name: "Checkout" 27 | uses: actions/checkout@v2 28 | 29 | - name: "Update Generated Files" 30 | uses: martinthomson/i-d-template@v1 31 | with: 32 | make: update-files 33 | token: ${{ github.token }} 34 | 35 | - name: "Push Update" 36 | run: git push 37 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | 2 | *.html 3 | *.pdf 4 | *.redxml 5 | *.swp 6 | *.txt 7 | *.upload 8 | *~ 9 | .idea 10 | .tags 11 | /*-[0-9][0-9].xml 12 | /.gems/ 13 | /.refcache 14 | /.targets.mk 15 | /.venv/ 16 | /.vscode/ 17 | /lib 18 | /node_modules/ 19 | /versioned/ 20 | Gemfile.lock 21 | archive.json 22 | draft-misell-acme-onion.xml 23 | package-lock.json 24 | report.xml 25 | !requirements.txt 26 | !343-rend-caa.txt -------------------------------------------------------------------------------- /.gitmodules: -------------------------------------------------------------------------------- 1 | [submodule "lib"] 2 | path = lib 3 | url = https://github.com/martinthomson/i-d-template 4 | -------------------------------------------------------------------------------- /343-rend-caa.txt: -------------------------------------------------------------------------------- 1 | Filename: 343-rend-caa.txt 2 | Title: CAA Extensions for the Tor Rendezvous Specification 3 | Author: Q Misell 4 | Created: 2023-04-25 5 | Status: Open 6 | Ticket: https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/716 7 | 8 | Overview: 9 | The document defines extensions to the Tor Rendezvous Specification Hidden 10 | Service descriptor format to allow the attachment of DNS style CAA records to 11 | Tor hidden services to allow the same security benefits as CAA provides in the 12 | DNS. 13 | 14 | Motivation: 15 | As part of the work on draft-misell-acme-onion [I-D.misell-acme-onion] at the 16 | IETF it was felt necessary to define a method to incorporate CAA records 17 | [RFC8659] into Tor hidden services. 18 | 19 | CAA records in the DNS provide an mechanism to indicate which Certificate 20 | Authorities are permitted to issue certificates for a given domain name, and 21 | restrict which validation methods are permitted for certificate validation. 22 | 23 | As Tor hidden service domains are not in the DNS another way to provide the 24 | same security benefits as CAA does in the DNS needed to be devised. 25 | 26 | It is important to note that a hidden service is not required to publish a CAA 27 | record to obtain a certificate, as is the case in the DNS. 28 | 29 | More information about this project in general can be found at 30 | https://acmeforonions.org. 31 | 32 | Specification: 33 | To enable maximal code re-use in CA codebases the same CAA record format is 34 | used in Tor hidden services as in the DNS. To this end a new field is added to 35 | the second layer hidden service descriptor [tor-rend-spec-v3] § 2.5.2.2. 36 | with the following format: 37 | 38 | "caa" SP flags SP tag SP value NL 39 | [Any number of times] 40 | 41 | The contents of "flag", "tag", and "value" are as per [RFC8659] § 4.1.1. 42 | Multiple CAA records may be present, as is the case in the DNS. 43 | 44 | A hidden service's second layer descriptor using CAA may look 45 | something like the following: 46 | 47 | create2-formats 2 48 | single-onion-service 49 | caa 0 issue "example.com" 50 | caa 0 iodef "mailto:security@example.com" 51 | caa 128 validationmethods "onion-csr-01" 52 | introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3KHCZ... 53 | 54 | As the CAA records are in the second layer descriptor and in the case of a 55 | hidden service requiring client authentication it is impossible to read them 56 | without the hidden service trusting a CA's public key, a method is required to 57 | signal that there are CAA records present (but not reveal their contents, 58 | which may disclose unwanted information about the hidden service operator to 59 | third parties). This is to allow a CA to know that it must attempt to check 60 | CAA records before issuance, and fail if it is unable to do so. 61 | 62 | To this end a new field is added to the first layer hidden service descriptor 63 | [tor-rend-spec-v3] § 2.5.1.2. with the following format: 64 | 65 | "caa-critical" NL 66 | [At most once] 67 | 68 | Security Considerations: 69 | The second layer descriptor is signed, encrypted and MACed in a way that only 70 | a party with access to the secret key of the hidden service could manipulate 71 | what is published there. Therefore, Tor CAA records have at least the same 72 | security as those in the DNS secured by DNSSEC. 73 | 74 | The "caa-critical" flag is visible to anyone with knowledge of the hidden 75 | service's public key, however it reveals no information that could be used to 76 | de-anonymize the hidden service operator. 77 | 78 | The CAA flags in the second layer descriptor may reveal information about the 79 | hidden service operator if they choose to publish an "iodef", "contactemail", 80 | or "contactphone" tag. These however are not required for primary goal of CAA, 81 | that is to restrict which CAs may issue certificates for a given domain name. 82 | 83 | No more information is revealed by the "issue" nor "issuewild" tags than would 84 | be revealed by someone making a connection to the hidden service and noting 85 | which certificate is presented. 86 | 87 | Compatibility: 88 | The hidden service spec [tor-rend-spec-v3] already requires that clients 89 | ignore unknown lines when decoding hidden service descriptors, so this change 90 | should not cause any compatibility issues. Additionally in testing no 91 | compatibility issues where found with existing Tor implementations. 92 | 93 | A hidden service with CAA records published in its descriptor is available at 94 | znkiu4wogurrktkqqid2efdg4nvztm7d2jydqenrzeclfgv3byevnbid.onion, to allow 95 | further compatibility testing. 96 | 97 | References: 98 | [I-D.misell-acme-onion] 99 | Misell, Q., "Automated Certificate Management Environment (ACME) 100 | Extensions for ".onion" Domain Names", Internet-Draft 101 | draft-misell-acme-onion-02, April 2023, 102 | . 103 | 104 | [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, 105 | "DNS Certification Authority Authorization (CAA) Resource 106 | Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, 107 | . 108 | 109 | [tor-rend-spec-v3] 110 | The Tor Project, "Tor Rendezvous Specification - Version 3", 111 | . -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | This repository relates to activities in the Internet Engineering Task Force 4 | ([IETF](https://www.ietf.org/)). All material in this repository is considered 5 | Contributions to the IETF Standards Process, as defined in the intellectual 6 | property policies of IETF currently designated as 7 | [BCP 78](https://www.rfc-editor.org/info/bcp78), 8 | [BCP 79](https://www.rfc-editor.org/info/bcp79) and the 9 | [IETF Trust Legal Provisions (TLP) Relating to IETF Documents](http://trustee.ietf.org/trust-legal-provisions.html). 10 | 11 | Any edit, commit, pull request, issue, comment or other change made to this 12 | repository constitutes Contributions to the IETF Standards Process 13 | (https://www.ietf.org/). 14 | 15 | You agree to comply with all applicable IETF policies and procedures, including, 16 | BCP 78, 79, the TLP, and the TLP rules regarding code components (e.g. being 17 | subject to a Simplified BSD License) in Contributions. 18 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # License 2 | 3 | See the 4 | [guidelines for contributions](https://github.com/AS207960/acme-onion/blob/root/CONTRIBUTING.md). 5 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | LIBDIR := lib 2 | include $(LIBDIR)/main.mk 3 | 4 | $(LIBDIR)/main.mk: 5 | ifneq (,$(shell grep "path *= *$(LIBDIR)" .gitmodules 2>/dev/null)) 6 | git submodule sync 7 | git submodule update $(CLONE_ARGS) --init 8 | else 9 | git clone -q --depth 10 $(CLONE_ARGS) \ 10 | -b main https://github.com/martinthomson/i-d-template $(LIBDIR) 11 | endif 12 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names 2 | 3 | This is the working area for the [ACME working group](https://datatracker.ietf.org/wg/acme/about/) 4 | Internet-Draft, "Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names". 5 | 6 | * [Editor's Copy](https://AS207960.github.io/acme-onion/#go.draft-ietf-acme-onion.html) 7 | * [Datatracker Page](https://datatracker.ietf.org/doc/draft-ietf-acme-onion) 8 | * [Individual Draft](https://datatracker.ietf.org/doc/html/draft-ietf-acme-onion) 9 | * [Compare Editor's Copy to Individual Draft](https://AS207960.github.io/acme-onion/#go.draft-ietf-acme-onion.diff) 10 | 11 | ## Contributing 12 | 13 | See the [guidelines for contributions](https://github.com/AS207960/acme-onion/blob/root/CONTRIBUTING.md). 14 | 15 | Contributions can be made by creating pull requests. 16 | The GitHub interface supports creating pull requests using the Edit (✏) button. 17 | 18 | ## Command Line Usage 19 | 20 | Formatted text and HTML versions of the draft can be built using `make`. 21 | 22 | ```sh 23 | $ make 24 | ``` 25 | 26 | Command line usage requires that you have the necessary software installed. 27 | See [the instructions](https://github.com/martinthomson/i-d-template/blob/main/doc/SETUP.md). 28 | 29 | -------------------------------------------------------------------------------- /draft-ietf-acme-onion.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | 7 | 8 | ]> 9 | 10 | 13 | 14 | Automated Certificate Management Environment (ACME) Extensions for ".onion" 15 | Special-Use Domain Names 16 | 17 | 18 | AS207960 Cyfyngedig 19 |
20 | 21 | 13 Pen-y-lan Terrace 22 | Caerdydd 23 | CF23 9EU 24 | United Kingdom 25 | 26 | q@as207960.net 27 | q@magicalcodewit.ch 28 | https://magicalcodewit.ch 29 |
30 | 31 | sec 32 | Automated Certificate Management Environment 33 | 34 | 35 | The document defines extensions to the Automated Certificate Management Environment (ACME) to allow for the 36 | automatic issuance of certificates to Tor hidden services (".onion" Special-Use Domain Names). 37 | 38 | 39 | 40 | Discussion 41 | Source for this draft and an issue tracker can be found at 42 | . 43 | The project website and a reference implementation can be found at 44 | . 45 | 46 | 47 | 48 | 49 |
50 | Introduction 51 | The Tor network has the ability to host "Onion Services" only accessible via the 52 | Tor network. These services use the ".onion" 53 | Special-Use Domain Name to identify these services. These can be used as any other domain 54 | name could, but do not form part of the DNS infrastructure. 55 | The Automated Certificate Management Environment (ACME) defines challenges for 56 | validating control of DNS identifiers, and whilst a ".onion" Special-Use Domain Name may appear as a DNS name, 57 | it requires special consideration to validate control of one such that ACME could be used on ".onion" 58 | Special-Use Domain Names. 59 | In order to allow ACME to be utilised to issue certificates to ".onion" Special-Use Domain Names this document 60 | specifies challenges suitable to validate control of these Special-Use Domain Names. Additionally, this document 61 | defines an alternative to the DNS Certification Authority Authorization (CAA) Resource Record 62 | that can be used with ".onion" Special-Use Domain Names. 63 | 64 |
65 | Requirements Language 66 | The key words MUST, MUST NOT, REQUIRED, SHALL, 67 | SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, 68 | NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be 69 | interpreted as described in (, ) when, 70 | and only when, they appear in all capitals, as shown here. 71 |
72 |
73 | 74 |
75 | Identifier 76 | defines the "dns" identifier type. This identifier type MUST be used 77 | when requesting a certificate for a ".onion" Special-Use Domain Name. The value of identifier 78 | MUST be the textual representation as defined in 79 | . 80 | The value MAY include subdomain labels. Version 2 addresses 81 | MUST NOT be used as these are now considered insecure. 82 | Example identifiers (linebreaks have been added for readability only): 83 | 84 | { 85 | "type": "dns", 86 | "value": "bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v 87 | q5kgwwn6aucdccrad.onion" 88 | } 89 | 90 | 91 | { 92 | "type": "dns", 93 | "value": "www.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v 94 | q5kgwwn6aucdccrad.onion" 95 | } 96 | 97 |
98 | 99 |
100 | Identifier Validation Challenges 101 | The CA/Browser Forum Baseline Requirements () 102 | define methods accepted by the CA industry for validation of ".onion" Special-Use Domain Names. 103 | This document incorporates these methods into ACME challenges. 104 |
105 | Existing challenges 106 |
107 | Existing "dns-01" Challenge 108 | The existing "dns-01" challenge MUST NOT be used to validate ".onion" Special-Use Domain 109 | Names, as these domains are not part of the DNS. 110 |
111 |
112 | Existing "http-01" Challenge 113 | The "http-01" challenge as defined in MAY be used to 114 | validate a ".onion" Special-Use Domain Names, with the modifications defined in this document, namely 115 | , and . 116 | The ACME server SHOULD follow redirects; note that these MAY be redirects to 117 | non-".onion" services, and the server SHOULD honour these. Clients might use redirects, 118 | for example, so that the response can be provided by a centralized certificate management server. See 119 | for security considerations on why a server might not want to 120 | follow redirects. 121 |
122 |
123 | Existing "tls-alpn-01" Challenge 124 | The "tls-alpn-01" challenge as defined in MAY be used to validate 125 | a ".onion" Special-Use Domain Names, with the modifications defined in this document, namely 126 | , and . 127 |
128 |
129 |
130 | New "onion-csr-01" Challenge 131 | Two methods already defined in ACME and allowed by the CA/BF ("http-01" and "tls-alpn-01") do not allow 132 | issuance of wildcard certificates. A ".onion" Special-Use Domain Name can have subdomains 133 | (just like any other domain in the DNS), and a site operator may find it useful to have one certificate for 134 | all virtual hosts on their site. This new validation method incorporates the specially signed CSR (as defined by 135 | ) into ACME to allow for the issuance of 136 | wildcard certificates. 137 | To this end a new challenge type called "onion-csr-01" is defined, with the following fields: 138 |
139 |
type (required, string)
140 |
The string "onion-csr-01"
141 |
nonce (required, string)
142 |
A Base64 encoded nonce, including padding characters. 143 | It MUST contain at least 64 bits of entropy. A response generated using this nonce 144 | MUST NOT be accepted by the ACME server if the nonce used was generated by the server more 145 | than 30 days ago (as per ).
146 |
authKey (optional, object)
147 |
The ACME server's Ed25519 public key encoded as per . This is further defined in 148 | .
149 |
150 | 151 | { 152 | "type": "onion-csr-01", 153 | "url": "https://acme-server.example.onion/acme/chall/bbc625c5", 154 | "status": "pending", 155 | "nonce": "bI6/MRqV4gw=", 156 | "authKey": { ... } 157 | } 158 | 159 | An "onion-csr-01" MUST NOT be used to issue certificates for non ".onion" 160 | Special-Use Domain Names. 161 | Clients prove control over the key associated with the ".onion" service by generating a CSR 162 | with the following additional extension attributes and signing it with the private 163 | key of the ".onion" Special-Use 164 | Domain Name: 165 |
    166 |
  • A caSigningNonce attribute containing the nonce provided in the challenge. This 167 | MUST be raw bytes, and not the base64 encoded value provided in the challenge object.
    • 168 |
  • An applicantSigningNonce containing a nonce generated by the client. This MUST 169 | have at least 64 bits of entropy. This MUST be raw bytes.
    • 170 |
171 | These additional attributes have the following format 172 | 173 | cabf OBJECT IDENTIFIER ::= 174 | { joint-iso-itu-t(2) international-organizations(23) 175 | ca-browser-forum(140) } 176 | 177 | cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } 178 | 179 | caSigningNonce ATTRIBUTE ::= { 180 | WITH SYNTAX OCTET STRING 181 | EQUALITY MATCHING RULE octetStringMatch 182 | SINGLE VALUE TRUE 183 | ID { cabf-caSigningNonce } 184 | } 185 | 186 | cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 187 | 188 | applicantSigningNonce ATTRIBUTE ::= { 189 | WITH SYNTAX OCTET STRING 190 | EQUALITY MATCHING RULE octetStringMatch 191 | SINGLE VALUE TRUE 192 | ID { cabf-applicantSigningNonce } 193 | } 194 | 195 | The subject of the CSR need not be meaningful and CAs MUST NOT validate its contents. 196 | The public key presented in this CSR MUST be the public key corresponding to the ".onion" 197 | Special-Use Domain Name being validated. It MUST NOT be the same public key presented in the 198 | CSR to finalize the order. 199 | Clients respond with the following object to validate the challenge: 200 |
201 |
csr (required, string)
202 |
203 | The CSR in the base64url-encoded version of the DER format. 204 | (Note: Because this field uses base64url, and does not include headers, it is different from PEM.) 205 |
206 |
207 | 208 | POST /acme/chall/bbc625c5 209 | Host: acme-server.example.onion 210 | Content-Type: application/jose+json 211 | 212 | { 213 | "protected": base64url({ 214 | "alg": "ES256", 215 | "kid": "https://acme-server.example.onion/acme/acct/evOfKhNU60wg", 216 | "nonce": "UQI1PoRi5OuXzxuX7V7wL0", 217 | "url": "https://acme-server.example.onion/acme/chall/bbc625c5" 218 | }), 219 | "payload": base64url({ 220 | "csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P" 221 | }), 222 | "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4" 223 | } 224 | 225 | When presented with the CSR the server verifies it in the following manner: 226 |
    227 |
  1. The CSR is a well formatted PKCS#10 request.
    2. 228 |
  2. The public key in the CSR corresponds to the ".onion" Special-Use Domain Name being validated.
    3. 229 |
  3. The signature over the CSR validates with the ".onion" Special-Use Domain Name public key.
    4. 230 |
  4. The caSigningNonce attribute is present and its contents matches the nonce provided to the client.
    5. 231 |
  5. The applicantSigningNonce attribute is present and contains at least 64 bits of entropy.
    6. 232 |
233 | If all of the above are successful then validation succeeds, otherwise it has failed. 234 |
235 |
236 | 237 |
238 | Client authentication to hidden services 239 | Some hidden services do not wish to be accessible to the entire Tor network, and so encrypt their hidden 240 | service descriptor with the keys of clients authorized to connect. Without a way for the CA to signal what key 241 | it will use to connect these services will not be able to obtain a certificate using http-01 or tls-alpn-01, 242 | nor enforce CAA with any validation method. 243 | To this end, an additional field in the challenge object is defined to allow the ACME server to advertise the 244 | Ed25519 public key it will use (as per 245 | ) to 246 | authenticate itself when retrieving the hidden service descriptor. 247 |
248 |
authKey (optional, object)
249 |
The ACME server's Ed25519 public key encoded as per .
250 |
251 | ACME servers MUST NOT use the same public key with multiple hidden services. 252 | ACME servers MAY re-use public keys for re-validation of the same hidden service. 253 | There is no method to communicate to the CA that client authentication is necessary; instead the ACME server 254 | MUST attempt to calculate its CLIENT-ID as per 255 | . 256 | If no auth-client line in the first layer hidden service descriptor matches the computed client-id 257 | then the server MUST assume that the hidden service does not require client authentication and 258 | proceed accordingly. 259 | In the case the Ed25519 public key is novel to the client it will have to resign and republish its hidden service 260 | descriptor. It MUST wait some (indeterminate) amount of time for the new descriptor to 261 | propagate the Tor hidden service directory servers, before proceeding with responding to the challenge. 262 | This should take no more than a few minutes. This specification does not set a fixed time as changes in the 263 | operation of the Tor network can affect this propagation time in the future. ACME servers 264 | MUST NOT expire challenges before a reasonable time to allow publication of the new descriptor - 265 | it is RECOMMENDED the server allow at least 30 minutes; however it is entirely up to operator preference. 266 |
267 | 268 |
269 | ACME over hidden services 270 | A CA offering certificates to ".onion" Special-Use Domain Names SHOULD make their 271 | ACME server available as a Tor hidden services. ACME clients SHOULD also support connecting to 272 | ACME servers over Tor, regardless of their support of "onion-csr-01", as their existing "http-01" 273 | and "tls-alpn-01" implementations could be used to obtain certificates for ".onion" Special-Use Domain Names. 274 |
275 | 276 |
277 | Certification Authority Authorization (CAA) 278 | ".onion" Special-Use Domain Name are not part of the DNS, and as such a variation on CAA 279 | is necessary to allow restrictions to be placed on certificate issuance. 280 | To this end a new field is added to the second layer hidden service descriptor as defined in 281 | 282 | with the following format (defined using the notation from 283 | ): 284 | 285 | "caa" SP flags SP tag SP value NL 286 | [Any number of times] 287 | 288 | The presentation format is provided above purely for the convenience of the reader and implementors, 289 | the canonical version remains that defined in , 290 | or future updates to the same. 291 | The contents of "flag", "tag", and "value" are as per . 292 | Multiple CAA records MAY be present, as is the case in the DNS. CAA records in a hidden service 293 | descriptor are to be treated the same by CAs as if they had been in the DNS for the ".onion" Special-Use Domain Name. 294 | A hidden service's second layer descriptor using CAA could look something like the following 295 | (additional linebreaks have been added for readability): 296 | 297 | create2-formats 2 298 | single-onion-service 299 | caa 128 issue "acmeforonions.example;validationmethods=onion-csr-01" 300 | caa 0 iodef "mailto:security@example.com" 301 | introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3 302 | KHCZUZ3C6tXDeRfM9SyNY0DlgbF8q+QSaGKCs= 303 | ... 304 | 305 |
306 | Relevant Resource Record Set 307 | In the absence of the possibility for delegation of subdomains from a ".onion" Special-Use Domain Name as 308 | there is in the DNS there is no need, nor indeed any method available, to search up the DNS tree for a 309 | relevant CAA record set. Similarly, it is also impossible to check CAA records on the "onion" Special-Use TLD, 310 | as it does not exist in any form except as described in , so implementors 311 | MUST NOT look here either. 312 | Instead all subdomains under a ".onion" Special-Use Domain Name share the same CAA record set. That is, 313 | all of these share a CAA record set with "a.onion": 314 |
    315 |
  • b.a.onion
    • 316 |
  • c.a.onion
    • 317 |
  • e.d.a.onion
    • 318 |
319 | but these do not: 320 |
    321 |
  • b.c.onion
    • 322 |
  • c.d.onion
    • 323 |
  • e.c.d.onion
    • 324 |
  • a.b.onion
    • 325 |
326 |
327 |
328 | When to check CAA 329 | If the hidden service has client authentication enabled then it will be impossible for the ACME server to 330 | decrypt the second layer descriptor to read the CAA records until the ACME server's public key has been added 331 | to the first layer descriptor. To this end an ACME server MUST wait until the client responds 332 | to an authorization before checking CAA, and treat this response as indication that their public key has been 333 | added and that the ACME server will be able to decrypt the second layer descriptor. 334 |
335 |
336 | Preventing mis-issuance by unknown CAs 337 | In the case of a hidden service requiring client authentication the CA will be unable to read the hidden 338 | service's CAA records without the hidden service trusting an ACME server's public key - as the CAA records are 339 | in the second layer descriptor. A method is necessary to signal that there are CAA records present 340 | (but not reveal their contents which - in certain circumstances - would unwantedly disclose information 341 | about the hidden service operator). 342 | To this end a new field is added to the first layer hidden service descriptor 343 | 344 | with the following format (defined using the notation from 345 | ): 346 | 347 | "caa-critical" NL 348 | [At most once] 349 | 350 | If an ACME server encounters this flag it MUST NOT proceed with issuance until it can decrypt 351 | and parse the CAA records from the second layer descriptor. 352 |
353 |
354 | Alternative in-band presentation of CAA 355 | An ACME server might be unwilling to operate the infrastructure required to fetch, decode, and verify Tor 356 | hidden service descriptors in order to check CAA records. To this end a method to signal CAA policies in-band 357 | of ACME is defined. 358 | If a hidden service does use this method to provide CAA records to an ACME server it SHOULD 359 | still publish CAA records if its CAA record set includes "iodef", "contactemail", or "contactphone" so that 360 | this information is still publicly accessible. A hidden service operator MAY also not wish to 361 | publish a CAA record set in its service descriptor to avoid revealing information about the service operator. 362 | If an ACME server receives a validly signed CAA record set in the finalize request it MAY 363 | proceed with issuance on the basis of the client provided CAA record set only without checking the CAA set in 364 | the hidden service. Alternatively, an ACME server MAY ignore the client provided record set and fetch the record set from 365 | the service descriptor. In any case, the server always MAY fetch 366 | the record set from the service descriptor. 367 | If an ACME server receives a validly signed CAA record set in the finalize request it need not check the CAA 368 | set in the hidden service descriptor and can proceed with issuance on the basis of the client provided CAA 369 | record set only. An ACME server MAY ignore the client provided record set, and is free to 370 | always fetch the record set from the service descriptor. 371 | A new field is defined in the ACME finalize endpoint to contain the hidden service's CAA record set for each 372 | ".onion" Special-Use Domain Name in the order. 373 |
374 |
onionCAA (optional, dictionary of objects)
375 |
376 | The CAA record set for each ".onion" Special-Use Domain Name in the order. The key is the ".onion" 377 | Special-Use Domain Name, and the value is an object with the following fields. 378 |
379 |
380 | The contents of the values of the "onionCAA" object are: 381 |
382 |
caa (required, string or null)
383 |
384 | The CAA record set as a string, encoded in the same way as if was included in the hidden service descriptor. 385 | If the hidden service does not have a CAA record set then this MUST be null. 386 |
387 |
expiry (required, integer)
388 |
389 | The Unix timestamp at which this CAA record set will expire. This SHOULD NOT be more than 390 | 8 hours in the future. ACME servers MUST process this as at least a 64-bit integer to ensure 391 | functionality beyond 2038. 392 |
393 |
signature (required, string)
394 |
395 | The Ed25519 signature of the CAA record set using the private key corresponding to the ".onion" 396 | Special-Use Domain Name, encoded using base64url. The signature is defined below. 397 |
398 |
399 | The data that the signature is calculated over is the concatenation of the following, 400 | encoded in UTF-8 : 401 | "onion-caa|" || expiry || "|" || caa 402 | Where "|" is the ASCII character 0x7C, and expiry is the expiry field as a decimal string with no 403 | leading zeros. If the caa field is null it is represented as an empty string in the signature calculation. 404 |
405 | ACME servers requiring in-band CAA 406 | If an ACME server does not support fetching a service's CAA record set from its service descriptor it, 407 | and the ACME client does not provide an "onionCAA" object in its finalize request the ACME server 408 | MUST respond with an "onionCAARequired" error to indicate this. 409 | To support signalling the server's support for fetching CAA record sets over Tor, 410 | a new field is defined in the directory "meta" object to signal this. 411 |
412 |
inBandOnionCAARequired (optional, boolean)
413 |
414 | If true, the ACME server requires the client to provide the CAA record set in the finalize request. 415 | If false or absent the ACME server does not require the client to provide the CAA record set is this 416 | manner.
417 |
418 | A directory of such a CA could look like 419 | 420 | HTTP/1.1 200 OK 421 | Content-Type: application/json 422 | 423 | { 424 | "newNonce": "https://acme-server.example.onion/acme/new-nonce", 425 | "newAccount": "https://acme-server.example.onion/acme/new-account", 426 | "newOrder": "https://acme-server.example.onion/acme/new-order", 427 | "revokeCert": "https://acme-server.example.onion/acme/revoke-cert", 428 | "keyChange": "https://acme-server.example.onion/acme/key-change", 429 | "meta": { 430 | "termsOfService": "https://acme-server.example.onion/acme/terms/2023-10-13", 431 | "website": "https://acmeforonions.example/", 432 | "caaIdentities": ["acmeforonions.example"], 433 | "inBandOnionCAARequired": true 434 | } 435 | } 436 | 437 |
438 |
439 | Example in-band CAA 440 | Given the following example CAA record set for 5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpigyb7x2i2m2qd.onion 441 | (additional linebreaks have been added for readability): 442 | 443 | caa 128 issue "acmeforonions.example; 444 | validationmethods=onion-csr-01" 445 | caa 0 iodef "mailto:example@example.com" 446 | 447 | The following would be submitted to the ACME server's finalize endpoint 448 | (additional linebreaks have been added for readability): 449 | 450 | POST /acme/order/TOlocE8rfgo/finalize 451 | Host: acme-server.example.onion 452 | Content-Type: application/jose+json 453 | 454 | { 455 | "protected": base64url({ 456 | "alg": "ES256", 457 | "kid": "https://acme-server.example.onion/acme/acct/evOfKhNU60wg", 458 | "nonce": "MSF2j2nawWHPxxkE3ZJtKQ", 459 | "url": "https://acme-server.example.onion/acme/order/TOlocE8rfgo/finalize" 460 | }), 461 | "payload": base64url({ 462 | "csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P", 463 | "onionCAA": { 464 | "5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpi 465 | gyb7x2i2m2qd.onion": { 466 | "caa": "caa 128 issue \"acmeforonions.example; 467 | validationmethods=onion-csr-01\"\n 468 | caa 0 iodef \"mailto:example@example.com\"", 469 | "expiry": 1697210719, 470 | "signature": "u_iP6JZ4JZBrzQUKH6lSrWejjRfeQmkTuehc0_FaaTNP 471 | AV0RVxpUz9r44DRdy6kgy0ofnx18KIhMrP7N1wpxAA==" 472 | } 473 | } 474 | }), 475 | "signature": "uOrUfIIk5RyQ...nw62Ay1cl6AB" 476 | } 477 | 478 |
479 |
480 |
481 | 482 |
483 | IANA Considerations 484 |
485 | Validation Methods 486 | Per this document, one new entry has been added to the "ACME Validation Methods" registry defined in 487 | 488 | (). 489 | This entry is defined below: 490 | 491 | New entry 492 | 493 | 494 | 495 | 496 | 497 | 498 | 499 | 500 | 501 | 502 | 503 | 504 | 505 | 506 | 507 | 508 |
LabelIdentifier TypeACMEReference
onion-csr-01dnsYThis document
509 |
510 |
511 | Error Types 512 | Per this document, one new entry has been added to the "ACME Error Types" registry defined in 513 | 514 | (). 515 | This entry is defined below: 516 | 517 | New entry 518 | 519 | 520 | 521 | 522 | 523 | 524 | 525 | 526 | 527 | 528 | 530 | 531 | 532 | 533 |
TypeDescriptionReference
onionCAARequiredThe CA only supports checking CAA for hidden services in-band, but the client has not provided an 529 | in-band CAAThis document
534 |
535 |
536 | Directory Metadata Fields 537 | Per this document, one new entry has been added to the "ACME Directory Metadata Fields" registry defined in 538 | 539 | (). 540 | This entry is defined below: 541 | 542 | New entry 543 | 544 | 545 | 546 | 547 | 548 | 549 | 550 | 551 | 552 | 553 | 554 | 555 | 556 | 557 |
Field nameField typeReference
onionCAARequiredbooleanThis document
558 |
559 |
560 | 561 |
562 | Security Considerations 563 |
564 | Security of the "onion-csr-01" challenge 565 | The security considerations of apply to issuance using the CSR method. 566 |
567 |
568 | Use of "dns" identifier type 569 | The re-use of the "dns" identifier type for a Special-Use Domain Name not actually in the DNS infrastructure 570 | raises questions regarding its suitability. The reasons to pursue this path in the first place are detailed in 571 | . It is felt that there is little security concern in reuse of the "dns" 572 | identifier type with regards the mis-issuance by CAs that are not aware of ".onion" 573 | Special-Use Domain Names, as CAs would not be able to resolve the identifier in the DNS. 574 |
575 | "http-01" Challenge 576 | In the absence of knowledge of this document a CA would follow the procedure set out in 577 | which specifies that the CA should "Dereference the URL using an 578 | HTTP GET request". Given that ".onion" Special-Use Domain Names require special handling to dereference, 579 | this de-referencing will fail, disallowing issuance. 580 |
581 |
582 | "tls-alpn-01" Challenge 583 | In the absence of knowledge of this document a CA would follow the procedure set out in 584 | which specifies that the CA "resolves the domain name being validated 585 | and chooses one of the IP addresses returned for validation". Given that ".onion" Special-Use Domain Names 586 | are not resolvable to IP addresses, this de-referencing will fail, disallowing issuance. 587 |
588 |
589 | "dns-01" Challenge 590 | In the absence of knowledge of this document a CA would follow the procedure set out in 591 | which specifies that the CA should "query for TXT records for the 592 | validation domain name". Given that ".onion" Special-Use Domain Names are not present in the DNS 593 | infrastructure, this query will fail, disallowing issuance. 594 |
595 |
596 |
597 | Key Authorization with "onion-csr-01" 598 | The "onion-csr-01" challenge does not make use of the key authorization string defined in 599 | . This does not weaken the integrity of authorizations. 600 | The key authorization exists to ensure that whilst an attacker observing the validation channel can observe 601 | the correct validation response, they cannot compromise the integrity of authorizations as the response 602 | can only be used with the account key for which it was generated. As the validation channel for this challenge 603 | is ACME itself, and ACME already requires that the request be signed by the account, the key authorization is 604 | not necessary. 605 |
606 |
607 | Use of Tor for non-".onion" domains 608 | An ACME server MUST NOT utilise Tor for the validation of non-".onion" domains, due to the 609 | risk of exit hijacking . 610 |
611 |
612 | Redirects with "http-01" 613 | A site MAY redirect to another site when completing validation using the "http-01" challenge. 614 | This redirect MAY be to either another ".onion" Special-Use Domain Name, or to a domain in the public DNS. 615 | A site operator MUST consider the privacy implications of redirecting to a non-".onion" 616 | site - namely that the ACME server operator will then be able to learn information about the site redirected to 617 | that they would not if accessed via a ".onion" Special-Use Domain Name, such as its IP address. If the site 618 | redirected to is on the same or an adjacent host to the ".onion" Special-Use Domain Name this reveals 619 | information was otherwise designed to protect. 620 | If an ACME server receives a redirect to a domain in the public DNS it MUST NOT utilise Tor 621 | to make a connection to it, due to the risk of exit hijacking. 622 |
623 |
624 | Security of CAA records 625 | The second layer descriptor is signed, encrypted and MACed in a way that only a party with access to the 626 | secret key of the hidden service could manipulate what is published there. For more information about this 627 | process see . 628 |
629 |
630 | In-band CAA 631 | Tor directory servers are inherently untrusted entities, and as such there is no difference in the security 632 | model for accepting CAA records directly from the ACME client or fetching them over Tor. There is no 633 | difference in the security model between accepting CAA records directly from the ACME client and fetching them 634 | over Tor; the CAA records are verified using the same hidden service key in either case. 635 |
636 |
637 | Access of the Tor network 638 | The ACME server MUST make its own connection to the hidden service via the Tor network, 639 | and MUST NOT outsource this to a third-party service, such as by using Tor2Web. 640 |
641 |
642 | Anonymity of the ACME client 643 | ACME clients requesting certificates for ".onion" Special-Use Domain Names not over the Tor network can 644 | inadvertently expose to unintended parties the existence of a hidden service on the host requesting 645 | certificates to unintended parties - even when features such as ECH are 646 | utilised, as the IP addresses of ACME servers are generally well-known, static, and not used for any other 647 | purpose. 648 | ACME clients SHOULD connect to ACME servers over the Tor network to alleviate this, preferring 649 | a hidden service endpoint if the CA provides such a service. 650 | If an ACME client requests a publicly trusted WebPKI certificate it will expose the existence of the Hidden 651 | Service publicly due to its inclusion in Certificate Transparency logs . Hidden Service 652 | operators MUST consider the privacy implications of this before requesting WebPKI 653 | certificates. ACME client developers SHOULD warn users about the risks of CT logged 654 | certificates for hidden services. 655 |
656 | Avoid unnecessary certificates 657 | Not all services will need a publicly trusted WebPKI certificate; for internal or non-public services, 658 | operators SHOULD consider using self-signed or privately-trusted certificates that aren't 659 | logged to certificate transparency. 660 |
661 |
662 | Obfuscate subscriber information 663 | When an ACME client is registering to an ACME server it SHOULD provide minimal or obfuscated 664 | subscriber details to the CA such as a pseudonymous email address, if at all possible. 665 |
666 |
667 | Separate ACME account keys 668 | If a hidden service operator does not want their different hidden services to be correlated by a CA they 669 | MUST use separate ACME account keys for each hidden service. 670 |
671 |
672 |
673 | 674 | 675 | 676 | 677 | References 678 | 679 | Normative References 680 | 681 | 682 | 683 | 684 | 685 | 686 | 687 | 688 | 689 | 690 | 691 | 692 | 693 | 694 | 695 | 696 | Tor Specifications 697 | 698 | The Tor Project 699 | 700 | 701 | 702 | 703 | 704 | 705 | Tor Rendezvous Specification - Version 2 706 | 707 | The Tor Project 708 | 709 | 710 | 711 | 712 | 713 | 714 | Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates 715 | 716 | CA/Browser Forum 717 | 718 | 719 | 720 | 721 | 722 | 723 | Informative References 724 | 725 | 726 | 727 | Set Up Your Onion Service 728 | 729 | The Tor Project 730 | 731 | 732 | 733 | 734 | 735 | 736 | Spoiled Onions: Exposing Malicious Tor Exit Relays 737 | 738 | 739 | 740 | 741 | 742 | 743 | 744 | 745 | 2014 746 | 747 | 748 | 749 | 750 | 751 | 752 | 753 | 754 |
755 | Discussion on the use of the "dns" identifier type 756 | The reasons for utilising the "dns" identifier type in ACME and not defining a new identifier type for 757 | ".onion"s may not seem obvious at first glance. After all, ".onion" Special-Use Domain 758 | Names are not part of the DNS infrastructure and as such why should they use the "dns" identifier type? 759 | defines, and this document allows, 760 | using the "http-01" or "tls-alpn-01" validation methods already present in ACME (with some considerations). 761 | Given the situation of a web server placed behind a Tor terminating proxy (as per the setup suggested by the 762 | Tor project ), existing ACME tooling can be blind to the fact that a 763 | ".onion" Special-Use Domain Name is being utilised, as they simply receive an incoming TCP connection as they 764 | would regardless (albeit from the Tor terminating proxy). 765 | An example of this would be Certbot placing the ACME challenge response file in the webroot of an NGINX web 766 | server. Neither Certbot nor NGINX would require any modification to be aware of any special handling for 767 | ".onion" Special-Use Domain Names. 768 | This does raise some questions regarding security within existing implementations, however the authors believe 769 | this is of little concern, as per . 770 |
771 | 772 |
773 | Acknowledgements 774 | With thanks to the Open Technology Fund for funding the work that went into this document. 775 | The authors also wish to thank the following for their input on this document: 776 |
    777 |
  • Iain Learmonth
    • 778 |
  • Jan-Frederik Rieckers
    • 779 |
780 |
781 | 782 | 783 | --------------------------------------------------------------------------------