Internet Engineering Task Force (IETF) Q. Misell, Ed.
Request for Comments: 9799 AS207960
Category: Standards Track June 2025
ISSN: 2070-1721
This document defines extensions to the Automated Certificate Management Environment (ACME) to allow for the automatic issuance of certificates to Tor Hidden Services (".onion" Special-Use Domain Names).
このドキュメントでは、自動化された証明書管理環境（ACME）への拡張機能を定義して、隠されたサービス（「.Onion "Special-Use Domain名）に証明書を自動発行できます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9799.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9799で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. Identifier
3. Identifier Validation Challenges
3.1. Existing Challenges
3.1.1. Existing: "dns-01" Challenge
3.1.2. Existing: http-01 Challenge
3.1.3. Existing tls-alpn-01 Challenge
3.2. New onion-csr-01 Challenge
4. Client Authentication to Hidden Services
5. ACME over Hidden Services
6. Certification Authority Authorization (CAA)
6.1. Relevant Resource Record Set
6.2. When to Check CAA
6.3. Preventing Mis-Issuance by Unknown CAs
6.4. Alternative In-Band Presentation of CAA
6.4.1. ACME Servers Requiring In-Band CAA
6.4.2. Example In-Band CAA
7. IANA Considerations
7.1. Validation Methods
7.2. Error Types
7.3. Directory Metadata Fields
8. Security Considerations
8.1. Security of the onion-csr-01 Challenge
8.2. Use of the "dns" Identifier Type
8.2.1. http-01 Challenge
8.2.2. tls-alpn-01 Challenge
8.2.3. dns-01 Challenge
8.3. Key Authorization with onion-csr-01
8.4. Use of Tor for Domains That Are Not ".onion"
8.5. Redirects with http-01
8.6. Security of CAA Records
8.7. In-Band CAA
8.8. Access of the Tor Network
8.9. Anonymity of the ACME Client
8.9.1. Avoid Unnecessary Certificates
8.9.2. Obfuscate Subscriber Information
8.9.3. Separate ACME Account Keys
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Discussion on the Use of the "dns" Identifier Type
Acknowledgements
Author's Address
The Tor network has the ability to host "Onion Services" [tor-spec] only accessible via the Tor network. These services use the ".onion" Special-Use Domain Name [RFC7686] to identify these services. These can be used as any other domain name could, but they do not form part of the DNS infrastructure.
TORネットワークには、TORネットワークを介してのみアクセスできる「オニオンサービス」[TOR-SPEC]をホストする機能があります。これらのサービスは、「.Onion」特別使用ドメイン名[RFC7686]を使用して、これらのサービスを特定します。これらは他のドメイン名と同じように使用できますが、DNSインフラストラクチャの一部を形成しません。
The Automated Certificate Management Environment (ACME) [RFC8555] defines challenges for validating control of DNS identifiers, and whilst a ".onion" Special-Use Domain Name may appear as a DNS name, it requires special consideration to validate control of one such that ACME could be used on ".onion" Special-Use Domain Names.
自動化された証明書管理環境（ACME）[RFC8555]は、DNS識別子の制御を検証するための課題を定義します。
In order to allow ACME to be utilized to issue certificates to ".onion" Special-Use Domain Names, this document specifies challenges suitable to validate control of these Special-Use Domain Names. Additionally, this document defines an alternative to the DNS Certification Authority Authorization (CAA) Resource Record [RFC8659] that can be used with ".onion" Special-Use Domain Names.
ACMEを使用して証明書を「.Onion」特別使用ドメイン名に発行できるようにするために、このドキュメントは、これらの特別使用ドメイン名の制御を検証するのに適した課題を指定します。さらに、このドキュメントは、「.Onion」特別使用ドメイン名で使用できるDNS認定局の認可（CAA）リソースレコード[RFC8659]の代替案を定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
[RFC8555] defines the "dns" identifier type. This identifier type MUST be used when requesting a certificate for a ".onion" Special-Use Domain Name. The value of the identifier MUST be the textual representation as defined in the "Special Hostnames in Tor - .onion" section of [tor-spec]. The value MAY include subdomain labels. Version 2 addresses [tor-rend-spec-v2] MUST NOT be used as these are now considered insecure.
[RFC8555]は「DNS」識別子タイプを定義します。この識別子タイプは、「.Onion」特別使用ドメイン名の証明書を要求するときに使用する必要があります。識別子の値は、[TOR -SPEC]の「TOR- .Onionの特別なホスト名」セクションで定義されているテキスト表現でなければなりません。値にはサブドメインラベルが含まれる場合があります。バージョン2アドレス[TORREND-SPEC-V2]は、これらが安全でないと見なされるため、使用してはなりません。
Example identifiers (line breaks have been added for readability only):
識別子の例（読みやすさのためにラインブレークが追加されました）：
{
"type": "dns",
"value": "bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v
q5kgwwn6aucdccrad.onion"
}
{
"type": "dns",
"value": "www.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v
q5kgwwn6aucdccrad.onion"
}
The CA/Browser Forum Baseline Requirements define methods accepted by the CA industry for validation of ".onion" Special-Use Domain Names (see Appendix B.2 of [cabf-br]). This document incorporates these methods into ACME challenges.
CA/ブラウザフォーラムのベースライン要件は、「.Onion」特別使用ドメイン名の検証のためにCA業界が受け入れた方法を定義します（[CABF-BR]の付録B.2を参照）。このドキュメントは、これらの方法をACMEの課題に組み込みます。
The existing "dns-01" challenge MUST NOT be used to validate ".onion" Special-Use Domain Names as these domains are not part of the DNS.
既存の「DNS-01」チャレンジを使用して、「特別使用ドメイン名」を検証するために使用してはなりません。これらのドメインはDNSの一部ではないためです。
The http-01 challenge, as defined in Section 8.3 of [RFC8555], MAY be used to validate a ".onion" Special-Use Domain Name with the modifications defined in this document, namely those described in Sections 4 and 6.
[RFC8555]のセクション8.3で定義されているHTTP-01チャレンジは、このドキュメントで定義されている修正、つまりセクション4および6で説明されている変更を使用して、「.Onion」特別使用ドメイン名を検証するために使用できます。
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. For example, clients might use redirects so that the response can be provided by a centralized certificate management server. See Section 10.2 of [RFC8555] for security considerations on why a server might not want to follow redirects.
ACMEサーバーはリダイレクトに従う必要があります。これらは「.Onion」ではないサービスにリダイレクトされ、サーバーがこれらを尊重する必要があることに注意してください。たとえば、クライアントはリダイレクトを使用して、集中型証明書管理サーバーによって応答を提供できるようにすることができます。サーバーがリダイレクトに従いたくない理由についてのセキュリティに関する考慮事項については、[RFC8555]のセクション10.2を参照してください。
The tls-alpn-01 challenge, as defined in [RFC8737], MAY be used to validate a ".onion" Special-Use Domain Name with the modifications defined in this document, namely those described in Sections 4 and 6.
[RFC8737]で定義されているTLS-ALPN-01チャレンジは、このドキュメントで定義されている修正、つまりセクション4および6で説明されている修正を使用して、「.Onion」特別使用ドメイン名を検証するために使用できます。
The two ACME-defined methods allowed by CA/BF described in Sections 3.1.2 and 3.1.3 (http-01 and tls-alpn-01) do not allow issuance of wildcard certificates. A ".onion" Special-Use Domain Name can have subdomains (just like any other domain in the DNS), and a site operator may find it useful to have one certificate for all virtual hosts on their site. This new validation method incorporates the specially signed Certificate Signing Request (CSR) (as defined by Appendix B.2.b of [cabf-br]) into ACME to allow for the issuance of wildcard certificates.
セクション3.1.2および3.1.3（HTTP-01およびTLS-ALPN-01）で説明されているCA/BFで許可されている2つのACME定義方法は、ワイルドカード証明書の発行を許可していません。「.Onion」特別使用ドメイン名にはサブドメイン（DNSの他のドメインと同様）があり、サイトオペレーターは、サイトにすべての仮想ホストの証明書を1つ持つことが有用であると感じる場合があります。この新しい検証方法には、特別に署名された証明書署名要求（CSR）（[CABF-BR]の付録B.2.bで定義されている）をACMEに組み込み、ワイルドカード証明書の発行を可能にします。
To this end, a new challenge called onion-csr-01 is defined, with the following fields:
この目的のために、Onion-CSR-01と呼ばれる新しい課題が定義されており、次のフィールドがあります。
type (required, string):
タイプ（必須、文字列）：
The string onion-csr-01.
ストリングオニオン-CSR-01。
nonce (required, string):
nonce（必須、文字列）：
A Base64-encoded nonce [RFC4648] including padding characters. It MUST contain at least 64 bits of entropy. A response generated using this nonce MUST NOT be accepted by the ACME server if the nonce used was generated by the server more than 30 days prior (as per Appendix B.2.b of [cabf-br]).
パディング文字を含むBase64エンコードのノンセ[RFC4648]。少なくとも64ビットのエントロピーを含める必要があります。このNonCEを使用して生成された応答は、使用されているNonCEが30日前にサーバーによって生成された場合、ACMEサーバーで受け入れてはなりません（[CABF-BR]の付録B.2.bに従って）。
authKey (optional, object):
authkey（オプション、オブジェクト）：
The ACME server's Ed25519 public key encoded as per [RFC8037]. This is further defined in Section 4.
ACMEサーバーのED25519公開キーは、[RFC8037]に従ってエンコードされています。これは、セクション4でさらに定義されています。
{
"type": "onion-csr-01",
"url": "https://acme-server.example.onion/acme/chall/bbc625c5",
"status": "pending",
"nonce": "bI6/MRqV4gw=",
"authKey": { ... }
}
An onion-csr-01 challenge MUST NOT be used to issue certificates for Special-Use Domain Names that are not ".onion".
Onion-CSR-01チャレンジは、「.Onion」ではない特別使用ドメイン名の証明書を発行するために使用してはなりません。
Clients prove control over the key associated with the ".onion" service by generating a Certificate Request (CSR) [RFC2986] with the following additional extension attributes and signing it with the private key of the ".onion" Special-Use Domain Name:
クライアントは、次の追加の拡張属性を使用して証明書要求（CSR）[RFC2986]を生成し、「.Onion」特別使用ドメイン名の秘密鍵に署名することにより、「.Onion」サービスに関連付けられたキーの制御を証明します。
* A caSigningNonce attribute containing the nonce provided in the challenge. This MUST be raw bytes and not the base64 encoded value provided in the challenge object.
* チャレンジで提供されているノンセを含むカシングノンセ属性。これは、チャレンジオブジェクトで提供されるbase64エンコード値ではなく、生のバイトでなければなりません。
* An applicantSigningNonce attribute containing a nonce generated by the client. This MUST have at least 64 bits of entropy. This MUST be raw bytes.
* クライアントによって生成されたNONCEを含むApplicantsIngingNonce属性。これには、少なくとも64ビットのエントロピーが必要です。これは生のバイトでなければなりません。
These additional attributes have the following format
これらの追加属性には、次の形式があります
cabf OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) international-organizations(23)
ca-browser-forum(140) }
cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }
caSigningNonce ATTRIBUTE ::= {
WITH SYNTAX OCTET STRING
EQUALITY MATCHING RULE octetStringMatch
SINGLE VALUE TRUE
ID { cabf-caSigningNonce }
}
cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }
applicantSigningNonce ATTRIBUTE ::= {
WITH SYNTAX OCTET STRING
EQUALITY MATCHING RULE octetStringMatch
SINGLE VALUE TRUE
ID { cabf-applicantSigningNonce }
}
The subject of the CSR need not be meaningful and CAs MUST NOT validate its contents. The public key presented in this CSR MUST be the public key corresponding to the ".onion" Special-Use Domain Name being validated. It MUST NOT be the same public key presented in the CSR to finalize the order.
CSRの主題は意味のあるものである必要はなく、CASはその内容を検証してはなりません。このCSRに提示された公開鍵は、検証されている「.Onion」特別使用ドメイン名に対応する公開鍵でなければなりません。注文を確定するためにCSRに提示されたのと同じ公開鍵であってはなりません。
Clients respond with the following object to validate the challenge:
クライアントは次のオブジェクトで応答して、課題を検証します。
csr (required, string):
CSR（必須、文字列）：
The CSR in the base64url-encoded version of the DER format. (Note: Because this field uses base64url, and does not include headers, it is different from Privacy Enhanced Mail (PEM).)
base64urlエンコードバージョンのder形式のCSR。（注：このフィールドはbase64urlを使用しており、ヘッダーが含まれていないため、プライバシー拡張メール（PEM）とは異なります。）
POST /acme/chall/bbc625c5
Host: acme-server.example.onion
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid":
"https://acme-server.example.onion/acme/acct/evOfKhNU60wg",
"nonce": "UQI1PoRi5OuXzxuX7V7wL0",
"url": "https://acme-server.example.onion/acme/chall/bbc625c5"
}),
"payload": base64url({
"csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P"
}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
When presented with the CSR, the server verifies it in the following manner:
CSRに提示されると、サーバーは次の方法でそれを検証します。
1. The CSR is a well formatted PKCS#10 request.
1. CSRは、適切にフォーマットされたPKCS＃10リクエストです。
2. The public key in the CSR corresponds to the ".onion" Special-Use Domain Name being validated.
2. CSRの公開鍵は、検証されている「.Onion」特別使用ドメイン名に対応しています。
3. The signature over the CSR validates with the ".onion" Special-Use Domain Name public key.
3. CSRの署名は、「.Onion」特別使用ドメイン名の公開キーで検証されます。
4. The caSigningNonce attribute is present and its contents match the nonce provided to the client.
4. CasivingNonce属性が存在し、その内容はクライアントに提供されるNonCEと一致します。
5. The applicantSigningNonce attribute is present and contains at least 64 bits of entropy.
5. ApplicantsIngingNonce属性が存在し、少なくとも64ビットのエントロピーが含まれています。
If all of the above are successful then validation succeeds, otherwise it has failed.
上記のすべてが成功した場合、検証は成功します。そうしないと、失敗しました。
Some Hidden Services do not wish to be accessible to the entire Tor network, and so they encrypt their Hidden Service Descriptor with the keys of clients authorized to connect. Without a way for the CA to signal what key it will use to connect, these services will not be able to obtain a certificate using http-01 or tls-alpn-01, nor enforce CAA with any validation method.
一部の隠されたサービスは、TORネットワーク全体にアクセスできないため、接続が許可されたクライアントのキーを使用して隠されたサービス記述子を暗号化します。CAが接続するために使用するキーを通知する方法がなければ、これらのサービスはHTTP-01またはTLS-ALPN-01を使用して証明書を取得することも、検証方法でCAAを施行することもできません。
To this end, an additional field in the challenge object is defined to allow the ACME server to advertise the 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.
この目的のために、ACMEサーバーが使用するED255519公開キーを宣伝できるようにするために、チャレンジオブジェクトの追加フィールドが定義されています（[TOR-SPEC]の導入フェーズ中の認証」に従って）非表示のサービス記述子を取得するときに認証します。
authKey (optional, object):
authkey（オプション、オブジェクト）：
The ACME server's Ed25519 public key encoded as per [RFC8037].
ACMEサーバーのED25519公開キーは、[RFC8037]に従ってエンコードされています。
ACME servers MUST NOT use the same public key with multiple Hidden Services. ACME servers MAY reuse public keys for re-validation of the same Hidden Service.
ACMEサーバーは、複数の非表示サービスを備えた同じ公開キーを使用してはなりません。ACMEサーバーは、同じ隠されたサービスの再検証のためにパブリックキーを再利用する場合があります。
There is no method to communicate to the CA that client authentication is necessary; instead, the ACME server MUST attempt to calculate its CLIENT-ID as per the "Client behavior" section of [tor-spec]. If no auth-client line in the First Layer Hidden Service Descriptor matches the computed client-id, then the server MUST assume that the Hidden Service does not require client authentication and proceed accordingly.
クライアント認証が必要であるというCAに通信する方法はありません。代わりに、ACMEサーバーは、[TOR-SPEC]の「クライアントの動作」セクションに従って、クライアントIDを計算しようとする必要があります。最初のレイヤーHidden Service Decruptorが計算されたクライアントIDと一致するAuth-Clientラインがない場合、サーバーは非表示のサービスがクライアント認証を必要とせず、それに応じて進行する必要があります。
In the case in which the Ed25519 public key is novel to the client, it will have to resign and republish its Hidden Service Descriptor. It MUST wait some (indeterminate) amount of time for the new descriptor to propagate the Tor Hidden Service directory servers before proceeding with responding to the challenge. This should take no more than a few minutes. This specification does not set a fixed time as changes in the operation of the Tor network can affect this propagation time in the future. ACME servers MUST NOT expire challenges before a reasonable time to allow publication of the new descriptor. It is RECOMMENDED the server allow at least 30 minutes; however, it is entirely up to operator preference.
ED25519公開キーがクライアントにとって斬新である場合、その隠れたサービス記述子を辞任し、再公開する必要があります。新しい記述子が、チャレンジへの対応に進む前に、TOR Hidden Service Directoryサーバーを伝播するために、ある程度の（不確定な）時間を待つ必要があります。これには数分しかかからないはずです。この仕様では、TORネットワークの動作の変更が将来この伝播時間に影響を与える可能性があるため、固定時間を設定しません。ACMEサーバーは、新しい記述子の公開を許可する合理的な時間の前に課題を期限切れにしてはなりません。サーバーが少なくとも30分以上許可されることをお勧めします。ただし、完全にオペレーターの好み次第です。
A CA offering certificates to ".onion" Special-Use Domain Names SHOULD make their ACME server available as a Tor Hidden Service. ACME clients SHOULD also support connecting to ACME servers over Tor, regardless of their support of onion-csr-01, as their existing http-01 and tls-alpn-01 implementations could be used to obtain certificates for ".onion" Special-Use Domain Names.
「.Onion」特別使用ドメイン名に証明書を提供するCAは、ACMEサーバーをTOR Hiddenサービスとして利用できるようにする必要があります。ACMEクライアントは、既存のHTTP-01およびTLS-ALPN-01の実装を使用して、「特別使用ドメイン名」の証明書を取得するために、Onion-CSR-01のサポートに関係なく、TORを介したACMEサーバーへの接続をサポートする必要があります。
".onion" Special-Use Domain Names are not part of the DNS; as such, a variation on CAA [RFC8659] is necessary to allow restrictions to be placed on certificate issuance.
「.Onion」特別使用ドメイン名はDNSの一部ではありません。そのため、CAA [RFC8659]のバリエーションは、証明書発行に制限を設定できるようにするために必要です。
To this end, a new field is added to the Second Layer Hidden Service Descriptor, as defined in the "Second layer plaintext format" section of [tor-spec] with the following format (defined using the notation from the "netdoc document meta-format" section of [tor-spec]):
この目的のために、次の形式を使用して[TOR-SPEC]の[TOR-SPEC]の[TOR-SPEC]のセクションで定義されているように、新しいフィールドが2番目のレイヤー非表示サービス記述子に追加されます（[Tor-Spec]の「NetDocドキュメントメタフォーマット」セクションの表記を使用して定義）：：：
"caa" SP flags SP tag SP value NL
[Any number of times]
The presentation format is provided above purely for the convenience of the reader and implementors: the canonical version remains that defined in Section 4.1.1 of [RFC8659], or future updates to the same.
プレゼンテーション形式は、読者と実装者の利便性のために純粋に上記で提供されます。[RFC8659]のセクション4.1.1で定義されている標準バージョン、または同じものへの将来の更新が残ります。
The contents of "flags", "tag", and "value" are as per Section 4.1.1 of [RFC8659]. Multiple CAA records MAY be present, as is the case in the DNS. CAA records in a Hidden Service Descriptor are to be treated the same by CAs as if they had been in the DNS for the ".onion" Special-Use Domain Name.
[フラグ]、「タグ」、および「値」の内容は、[RFC8659]のセクション4.1.1に従っています。DNSの場合のように、複数のCAAレコードが存在する場合があります。隠されたサービス記述子のCAAレコードは、「.Onion」特別使用ドメイン名のDNSにいたかのように、CAによって同じように扱われます。
A Hidden Service's Second Layer Descriptor using CAA could look something like the following (additional line breaks have been added for readability):
CAAを使用したHidden Serviceの2番目のレイヤー記述子は、次のようなものに見える可能性があります（読みやすさのために追加のラインブレークが追加されました）：
create2-formats 2
single-onion-service
caa 128 issue "acmeforonions.example;validationmethods=onion-csr-01"
caa 0 iodef "mailto:security@example.com"
introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3
KHCZUZ3C6tXDeRfM9SyNY0DlgbF8q+QSaGKCs=
...
In the absence of the possibility for delegation of subdomains from a ".onion" Special-Use Domain Name, as there is in the DNS, there is no need, nor indeed any method available, to search up the DNS tree for a relevant CAA record set. Similarly, it is also impossible to check CAA records on the "onion" Special-Use Top-Level Domain (TLD), as it does not exist in any form except as described in [RFC7686]; therefore, implementors MUST NOT look there either.
DNSにあるように、「.Onion」特別使用ドメイン名からサブドメインを委任する可能性がない場合、DNSツリーを関連するCAAレコードセットを検索する必要も、実際に利用可能な方法もありません。同様に、[RFC7686]に記載されている場合を除き、いかなる形式でも存在しないため、「タマネギ」特別使用トップレベルドメイン（TLD）のCAAレコードを確認することも不可能です。したがって、実装者もそこを見てはなりません。
Instead, all subdomains under a ".onion" Special-Use Domain Name share the same CAA record set. That is, all of these share a CAA record set with "a.onion":
代わりに、「.Onion」特別使用ドメイン名の下のすべてのサブドメインは、同じCAAレコードセットを共有します。つまり、これらはすべて「A.Onion」とCAAレコードセットを共有しています。
* b.a.onion
* b.a.onion
* c.a.onion
* c.a.onion
* e.d.a.onion
* E.D.A.Onion
but these do not:
しかし、これらは次のとおりです。
* b.c.onion
* b.c.onion
* c.d.onion
* C.D.Onion
* e.c.d.onion
* E.C.D.Onion
* a.b.onion
* A.B.Onion
If the Hidden Service has client authentication enabled, then it will be impossible for the ACME server to decrypt the Second Layer Hidden Service Descriptor to read the CAA records until the ACME server's public key has been added to the First Layer Hidden Service Descriptor. To this end, an ACME server MUST wait until the client responds to an authorization before checking the CAA and treat this response as an indication that their public key has been added and that the ACME server will be able to decrypt the Second Layer Hidden Service Descriptor.
Hidden Serviceにクライアント認証が有効になっている場合、ACMEサーバーがACMEサーバーの公開キーが最初のレイヤーHidden Service Decruptorに追加されるまで、ACMEサーバーが2番目のレイヤーHidden Service Decruptorを復号化してCAAレコードを読み取ることは不可能です。この目的のために、ACMEサーバーは、CAAをチェックする前にクライアントが承認に応答するまで待機し、この応答を公開キーが追加されたこと、およびACMEサーバーが2番目のレイヤーHidden Service Decruptorを復号化できることを示すものとして扱う必要があります。
In the case of a Hidden Service requiring client authentication, the CA will be unable to read the hidden service's CAA records without the Hidden Service trusting an ACME server's public key -- as the CAA records are in the Second Layer Hidden Service Descriptor. A method is necessary to signal that there are CAA records present (but not reveal their contents, which, in certain circumstances, would unwantedly disclose information about the Hidden Service operator).
クライアント認証を必要とする隠されたサービスの場合、CAはACMEサーバーの公開キーを信頼する隠されたサービスなしで非表示サービスのCAAレコードを読み取ることができません。CAAレコードは2番目のレイヤーHidden Service Decruptorにあるためです。CAAレコードが存在することを示す方法が必要です（ただし、特定の状況では、隠されたサービスオペレーターに関する情報を望ましく開示する内容を明らかにしません）。
To this end, a new field is added to the First Layer Hidden Service Descriptor in the "First layer plaintext format" section of [tor-spec] with the following format (defined using the notation from the "netdoc document meta-format" section of [tor-spec]):
この目的のために、[TOR-SPEC]の[Tor-Spec]の「Tor-Spec]の「最初のレイヤープレーンテキスト形式」セクションの最初のレイヤー非表示サービス記述子に新しいフィールドが追加されます（[Tor-Spec]の「NetDocドキュメントメタ形式」セクションの表記を使用して定義）：：
"caa-critical" NL
[At most once]
If an ACME server encounters this flag, it MUST NOT proceed with issuance until it can decrypt and parse the CAA records from the Second Layer Hidden Service Descriptor.
ACMEサーバーがこのフラグに遭遇した場合、2番目のレイヤーHidden Service DecruptorからCAAレコードを解読して解析できるまで発行を続行しないでください。
An ACME server might be unwilling to operate the infrastructure required to fetch, decode, and verify Tor Hidden Service Descriptors in order to check CAA records. To this end a method to signal CAA policies in-band of ACME is defined.
ACMEサーバーは、CAAレコードを確認するために、Hidden Service Decriptorsを取得、デコード、検証するために必要なインフラストラクチャを操作することを嫌がっている可能性があります。このため、ACMEの帯域内のCAAポリシーを信号する方法が定義されています。
If a Hidden Service does use this method to provide CAA records to an ACME server, it SHOULD still publish CAA records if its CAA record set includes "iodef", "contactemail", or "contactphone" so that this information is still publicly accessible. Additionally, a Hidden Service operator MAY not wish to publish a CAA record set in its Hidden Service Descriptor to avoid revealing information about the service operator.
Hidden Serviceがこの方法を使用してACMEサーバーにCAAレコードを提供する場合、CAAレコードセットに「IODEF」、「コンタクトマイル」、または「連絡先」が含まれている場合、CAAレコードを公開する必要があります。さらに、Hidden Serviceオペレーターは、サービスオペレーターに関する情報が表示されないように、Hidden Service DecruptorにCAAレコードセットを公開することを望まない場合があります。
If an ACME server receives a validly signed CAA record set in the finalize request, it MAY proceed with issuance on the basis of the client-provided CAA record set only, without checking the CAA set in the Hidden Service. Alternatively, an ACME server MAY ignore the client provided record set and fetch the record set from the Hidden Service Descriptor. In any case, the server MAY fetch the record set from the Hidden Service Descriptor. If an ACME server receives a validly signed CAA record set in the finalize request, it need not check the CAA set in the Hidden Service Descriptor and can proceed with issuance on the basis of the client-provided CAA record set only. An ACME server MAY ignore the client-provided record set and is free to always fetch the record set from the Hidden Service Descriptor.
ACMEサーバーがファイナライズリクエストで有効に署名されたCAAレコードセットを受信した場合、非表示サービスでCAAセットをチェックすることなく、クライアントが提供するCAAレコードセットのみに基づいて発行を進めることができます。または、ACMEサーバーは、クライアントが提供されたレコードセットを無視し、Hidden Service Decruptorからレコードセットを取得する場合があります。いずれにせよ、サーバーは非表示のサービス記述子からレコードセットを取得できます。ACMEサーバーがFinalize Requestで有効に署名されたCAAレコードを受信した場合、Hidden Service DescriptorでCAAセットを確認する必要はなく、クライアントが提供するCAAレコードセットのみに基づいて発行を進めることができます。ACMEサーバーは、クライアントが提供するレコードセットを無視する場合があり、Hidden Service Decruptorから常にレコードセットを無料で取得できます。
A new field is defined in the ACME finalize endpoint to contain the Hidden Service's CAA record set for each ".onion" Special-Use Domain Name in the order.
新しいフィールドは、ACMEファイナライズエンドポイントで定義されており、「.Onion」特別使用ドメイン名のHidden ServiceのCAAレコードセットを順序に含めます。
onionCAA (optional, dictionary of objects):
onioncaa（オプション、オブジェクトの辞書）：
The CAA record set for each ".onion" Special-Use Domain Name in the order. The key is the ".onion" Special-Use Domain Name, and the value is an object with the fields described below.
順序で「.Onion」特別使用ドメイン名ごとにCAAレコードが設定されています。キーは「.Onion」特別使用ドメイン名で、値は以下に説明するフィールドを持つオブジェクトです。
The contents of the values of the "onionCAA" object are as follows:
「onioncaa」オブジェクトの値の内容は次のとおりです。
caa (required, string or null):
CAA（必須、文字列またはヌル）：
The CAA record set as a string, encoded in the same way as if was included in the Hidden Service Descriptor. If the Hidden Service does not have a CAA record set, then this MUST be null.
CAAレコードは、Hidden Service Decruptorに含まれている場合と同じ方法でエンコードされた文字列として設定されました。非表示のサービスにCAAレコードセットがない場合、これはnullでなければなりません。
expiry (required, integer):
有効期限（必須、整数）：
The Unix timestamp at which this CAA record set will expire. This SHOULD NOT be more than 8 hours in the future. ACME servers MUST process this as at least a 64-bit integer to ensure functionality beyond 2038.
このCAAレコードセットが期限切れになるUNIXタイムスタンプ。これは、将来8時間以内ではないはずです。ACMEサーバーは、これを少なくとも64ビット整数として処理して、2038を超えて機能を確保する必要があります。
signature (required, string):
署名（必須、文字列）：
The Ed25519 signature of the CAA record set using the private key corresponding to the ".onion" Special-Use Domain Name, encoded using base64url. The signature is defined below.
base64urlを使用してエンコードされた「.Onion」特別使用ドメイン名に対応する秘密鍵を使用して、CAAレコードセットのED25519署名。署名は以下に定義されています。
The data that the signature is calculated over is the concatenation of the following, encoded in UTF-8 [RFC3629]:
署名が計算されるデータは、UTF-8 [RFC3629]にエンコードされた以下の連結です。
"onion-caa|" || expiry || "|" || caa
Where "|" is the ASCII character 0x7C, and expiry is the expiry field as a decimal string with no leading zeros. If the caa field is null, it is represented as an empty string in the signature calculation.
ここで「|」ASCII文字0x7Cであり、有効期限は、主要なゼロがない小数文字列として有効期限フィールドです。CAAフィールドがnullの場合、署名計算の空の文字列として表されます。
If an ACME server does not support fetching a service's CAA record set from its Hidden 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.
ACMEサーバーがHidden Service記述子からサービスのCAAレコードセットの取得をサポートしておらず、ACMEクライアントがファイナライズリクエストで「onionCaa」オブジェクトを提供しない場合、ACMEサーバーはこれを示すために「TonionCaarequired」エラーで応答する必要があります。
To support signaling the server's support for fetching CAA record sets over Tor, a new field is defined in the directory "meta" object to signal this.
CAAレコードセットを取得するためのサーバーのサポートをTORにサポートするために、新しいフィールドがディレクトリ「メタ」オブジェクトで定義され、これを通知します。
inBandOnionCAARequired (optional, boolean):
Inbandonioncaarequired（オプション、ブール値）：
If true, the ACME server requires the client to provide the CAA record set in the finalize request. If false or absent, the ACME server does not require the client to provide the CAA record set is this manner.
Trueの場合、ACMEサーバーは、クライアントにファイナライズリクエストでCAAレコードを提供するよう要求します。falseまたは存在しない場合、ACMEサーバーは、クライアントにCAAレコードセットを提供するように要求しません。
A directory of such a CA could look like the following:
このようなCAのディレクトリは、次のように見えることがあります。
HTTP/1.1 200 OK
Content-Type: application/json
{
"newNonce": "https://acme-server.example.onion/acme/new-nonce",
"newAccount": "https://acme-server.example.onion/acme/new-account",
"newOrder": "https://acme-server.example.onion/acme/new-order",
"revokeCert": "https://acme-server.example.onion/acme/revoke-cert",
"keyChange": "https://acme-server.example.onion/acme/key-change",
"meta": {
"termsOfService":
"https://acme-server.example.onion/acme/terms/2023-10-13",
"website": "https://acmeforonions.example/",
"caaIdentities": ["acmeforonions.example"],
"inBandOnionCAARequired": true
}
}
Given the following example CAA record set for 5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpigyb7x2i2m2qd.onion (additional line breaks have been added for readability):
次の例を考慮して、5anebu2glyc235wbbop3m2ukzlaptpkq33333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333のレコード（読みやすくするために追加のラインブレークが追加されています）：
caa 128 issue "acmeforonions.example;
validationmethods=onion-csr-01"
caa 0 iodef "mailto:example@example.com"
The following would be submitted to the ACME server's finalize endpoint (additional line breaks have been added for readability):
以下は、ACMEサーバーのファイナライズエンドポイントに提出されます（読みやすさのために追加のラインブレークが追加されました）：
POST /acme/order/TOlocE8rfgo/finalize
Host: acme-server.example.onion
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid":
"https://acme-server.example.onion/acme/acct/evOfKhNU60wg",
"nonce": "MSF2j2nawWHPxxkE3ZJtKQ",
"url": "https://acme-server.example.onion/acme/order/
TOlocE8rfgo/finalize"
}),
"payload": base64url({
"csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P",
"onionCAA": {
"5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpi
gyb7x2i2m2qd.onion": {
"caa": "caa 128 issue \"acmeforonions.example;
validationmethods=onion-csr-01\"\n
caa 0 iodef \"mailto:example@example.com\"",
"expiry": 1697210719,
"signature": "u_iP6JZ4JZBrzQUKH6lSrWejjRfeQmkTuehc0_FaaTNP
AV0RVxpUz9r44DRdy6kgy0ofnx18KIhMrP7N1wpxAA=="
}
}
}),
"signature": "uOrUfIIk5RyQ...nw62Ay1cl6AB"
}
One new entry has been added to the "ACME Validation Methods" registry that was defined in Section 9.7.8 of [RFC8555] (<https://www.iana.org/assignments/acme>).
[RFC8555]のセクション9.7.8（<https://www.iana.org/assignments/acme>）で定義された「ACME検証方法」レジストリに1つの新しいエントリが追加されました。
+==============+=================+======+===========+
| Label | Identifier Type | ACME | Reference |
+==============+=================+======+===========+
| onion-csr-01 | dns | Y | RFC 9799 |
+--------------+-----------------+------+-----------+
Table 1: onion-csr-01 Validation Method
表1：Onion-CSR-01検証方法
One new entry has been added to the "ACME Error Types" registry that was defined in Section 9.7.4 of [RFC8555] (<https://www.iana.org/assignments/acme>).
[RFC8555]のセクション9.7.4（<https://www.iana.org/assignments/acme>）で定義された「ACMEエラータイプ」レジストリに1つの新しいエントリが追加されました。
+==================+===============================+===========+
| Type | Description | Reference |
+==================+===============================+===========+
| onionCAARequired | The CA only supports checking | RFC 9799 |
| | the CAA for Hidden Services | |
| | in-band, but the client has | |
| | not provided an in-band CAA | |
+------------------+-------------------------------+-----------+
Table 2: onionCAARequired Error Type
表2：オニオンカレク化されたエラータイプ
One new entry has been added to the "ACME Directory Metadata Fields" registry that was defined in Section 9.7.6 of [RFC8555] (<https://www.iana.org/assignments/acme>).
[RFC8555]のセクション9.7.6（<https://www.iana.org/assignments/acme>）で定義された「ACMEディレクトリメタデータフィールド」レジストリに1つの新しいエントリが追加されました。
+==================+============+===========+
| Field name | Field type | Reference |
+==================+============+===========+
| onionCAARequired | boolean | RFC 9799 |
+------------------+------------+-----------+
Table 3: onionCAARequired Metadata Field
表3：オニオンカレク化されたメタデータフィールド
The security considerations of [cabf-br] apply to issuance using the Certificate Request method.
[CABF-BR]のセキュリティ上の考慮事項は、証明書要求方法を使用して発行に適用されます。
The reuse of the "dns" identifier type for a Special-Use Domain Name not actually in the DNS infrastructure raises questions regarding its suitability. The reasons to pursue this path in the first place are detailed in Appendix A. It is felt that there is little security concern in reuse of the "dns" identifier type with regard to the mis-issuance by CAs that are not aware of ".onion" Special-Use Domain Names as CAs would not be able to resolve the identifier in the DNS.
実際にはDNSインフラストラクチャにない特別使用ドメイン名の「DNS」識別子タイプの再利用は、その適合性に関する疑問を提起します。そもそもこのパスを追求する理由は、付録Aに詳述されています。「DNS」識別子タイプの再利用には、「。」という特別使用ドメイン名がDNSの識別子を解決できないように、CASの誤発行に関して、「DNS」識別型の再利用にはほとんどセキュリティの懸念がないと感じられています。
In the absence of knowledge of this document, a CA would follow the procedure set out in Section 8.3 of [RFC8555], which specifies that the CA should "Dereference the URL using an HTTP GET request". Given that ".onion" Special-Use Domain Names require special handling to dereference, this dereferencing will fail, disallowing issuance.
このドキュメントの知識がない場合、CAは[RFC8555]のセクション8.3に記載されている手順に従います。これは、CAが「HTTP GETリクエストを使用してURLを再参照する」必要があることを指定します。「.Onion」特別使用ドメイン名には、特別な取り扱いが必要であることを考えると、この控訴は失敗し、発行が許可されません。
In the absence of knowledge of this document, a CA would follow the procedure set out in Section 3 of [RFC8737], which specifies that the CA "resolves the domain name being validated and chooses one of the IP addresses returned for validation". Given that ".onion" Special-Use Domain Names are not resolvable to IP addresses, this dereferencing will fail, disallowing issuance.
このドキュメントの知識がない場合、CAは[RFC8737]のセクション3に記載されている手順に従います。これは、CAが「検証されているドメイン名を解決し、検証のために返されるIPアドレスの1つを選択する」ことを指定します。「.Onion」特別使用ドメイン名がIPアドレスに対して解決できないことを考えると、この命令は失敗し、発行が許可されません。
In the absence of knowledge of this document, a CA would follow the procedure set out in Section 8.4 of [RFC8555], which specifies that the CA should "query for TXT records for the validation domain name". Given that ".onion" Special-Use Domain Names are not present in the DNS infrastructure, this query will fail, disallowing issuance.
このドキュメントの知識がない場合、CAは[RFC8555]のセクション8.4に記載されている手順に従います。これは、CAが「検証ドメイン名のTXTレコードをクエリする」必要があることを指定します。DNSインフラストラクチャに「.Onion」特別使用ドメイン名が存在しないことを考えると、このクエリは失敗し、発行が許可されません。
The onion-csr-01 challenge does not make use of the key authorization string defined in Section 8.1 of [RFC8555]. This does not weaken the integrity of authorizations.
Onion-CSR-01 Challengeは、[RFC8555]のセクション8.1で定義されている主要な認証文字列を使用していません。これは、承認の完全性を弱めることはありません。
The key authorization exists to ensure that, whilst an attacker observing the validation channel can observe the correct validation response, they cannot compromise the integrity of authorizations as the response can only be used with the account key for which it was generated. As the validation channel for this challenge is ACME itself, and ACME already requires that the request be signed by the account, the key authorization is not necessary.
重要な承認は、検証チャネルを観察する攻撃者が正しい検証応答を観察できることを保証するために存在します。それらは、それが生成されたアカウントキーでのみ応答が使用されるため、許可の整合性を妥協することはできません。この課題の検証チャネルはACME自体であり、ACMEはすでに要求をアカウントによって署名する必要があるため、主要な承認は必要ありません。
An ACME server MUST NOT utilize Tor for the validation of domains that are not ".onion", due to the risk of exit hijacking [spoiled-onions].
ACMEサーバーは、「.Onion」ではないドメインの検証にTORを利用してはなりません。
A site MAY redirect to another site when completing validation using the http-01 challenge. This redirect MAY be to either another ".onion" Special-Use Domain Name or a domain in the public DNS. A site operator MUST consider the privacy implications of redirecting to a site that is not ".onion" -- namely that the ACME server operator will then be able to learn information about the site they were redirected to that they would not have if accessed via a ".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" Special-Use Domain Name, this reveals information that the "Tor Rendezvous Specification - Version 3" section of [tor-spec] was otherwise designed to protect.
HTTP-01チャレンジを使用して検証を完了すると、サイトは別のサイトにリダイレクトできます。このリダイレクトは、別の「特別使用ドメイン名または公開DNSのドメイン」のいずれかにある場合があります。サイトオペレーターは、「.Onion」ではないサイトへのリダイレクトのプライバシーへの影響を考慮する必要があります。つまり、ACMEサーバーオペレーターは、IPアドレスなどの「.Onion」特別使用ドメイン名など、アクセスしない場合にリダイレクトされたサイトに関する情報を学ぶことができます。リダイレクトされたサイトが「.Onion」特別使用ドメイン名の隣接ホストである場合、これは「Tor Rendezvous仕様 - バージョン3」セクション[TOR-SPEC]のセクションが保護するように設計されているという情報を明らかにします。
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 exit hijacking.
ACMEサーバーがパブリックDNSのドメインへのリダイレクトを受信した場合、出口ハイジャックのリスクがあるため、TORを利用して接続してはなりません。
The Second Layer Hidden Service Descriptor is signed, encrypted, and 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 manipulate what is published there. For more information about this process, see the "Hidden service descriptors: encryption format" section of [tor-spec].
2番目のレイヤーHidden Service Decruptorは、Hidden Serviceの秘密キーにアクセスできるパーティーのみがそこに公開されているものを操作できるように、メッセージ認証コード（MAC）を使用して署名、暗号化、およびエンコードされます。このプロセスの詳細については、[TOR-SPEC]の「Hidden Service Decruptors：暗号化形式」セクションを参照してください。
Tor directory servers are inherently untrusted entities. 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.
TORディレクトリサーバーは、本質的に信頼されていないエンティティです。そのため、ACMEクライアントからCAAレコードを直接受け入れるか、TORを介してそれらを取得するためのセキュリティモデルに違いはありません。CAAレコードは、どちらの場合でも同じ隠しサービスキーを使用して検証されます。
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 service, such as Tor2Web.
ACMEサーバーは、TORネットワークを介して非表示サービスに独自の接続を行う必要があり、TOR2WEBなどのサードパーティサービスにこれを外注してはなりません。
ACME clients requesting certificates for ".onion" Special-Use Domain Names not over the Tor network can inadvertently expose the existence of a Hidden Service on the host requesting certificates to unintended parties; this is true even when features such as Encrypted ClientHello (ECH) [tls-esni] are utilized, as the IP addresses of ACME servers are generally well-known, static, and not used for any other purpose.
ACMEクライアントは、TORネットワーク上にない「.Onion」特別使用ドメイン名の証明書を要求しています。ACMEサーバーのIPアドレスは一般によく知られており、他の目的には使用されていないため、暗号化されたClientHello（ECH）[TLS-ESNI]などの機能が利用されている場合でもこれは当てはまります。
ACME clients SHOULD connect to ACME servers over the Tor network to alleviate this, preferring a Hidden Service endpoint if the CA provides such a service.
ACMEクライアントは、TORネットワークを介してACMEサーバーに接続してこれを軽減する必要があります。CAがそのようなサービスを提供する場合は、非表示のサービスエンドポイントを好みます。
If an ACME client requests a publicly trusted WebPKI certificate, it will expose the existence of the Hidden Service publicly due to its inclusion in Certificate Transparency logs [RFC9162]. Hidden Service operators MUST consider the privacy implications of this before requesting WebPKI certificates. ACME client developers SHOULD warn users about the risks of CT-logged certificates for Hidden Services.
ACMEクライアントが公開されているWebPKI証明書を要求する場合、証明書の透明性ログ[RFC9162]に含まれるため、非表示サービスの存在が公開されます。Hidden Serviceオペレーターは、WebPKI証明書を要求する前に、これのプライバシーへの影響を考慮する必要があります。ACMEクライアント開発者は、非表示サービスのCTログ付き証明書のリスクについてユーザーに警告する必要があります。
Not all services will need a publicly trusted WebPKI certificate; for internal or non-public services, operators SHOULD consider using self-signed or privately trusted certificates that aren't logged to certificate transparency.
すべてのサービスが公的に信頼されているWebPKI証明書を必要とするわけではありません。内部または非公開のサービスの場合、オペレーターは、証明書の透明性に記録されていない自己署名または個人的に信頼できる証明書の使用を検討する必要があります。
When an ACME client is registering with an ACME server, it SHOULD provide minimal or obfuscated subscriber details to the CA, such as a pseudonymous email address, if at all possible.
ACMEクライアントがACMEサーバーに登録している場合、可能であれば、仮名の電子メールアドレスなど、最小限または難解なサブスクライバーの詳細をCAに提供する必要があります。
If a Hidden Service operator does not want their different Hidden Services to be correlated by a CA, they MUST use separate ACME account keys for each Hidden Service.
隠されたサービスオペレーターが別の隠されたサービスをCAによって相関させることを望まない場合、各隠されたサービスに個別のACMEアカウントキーを使用する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
2015, <https://www.rfc-editor.org/info/rfc7686>.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/info/rfc8037>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
"DNS Certification Authority Authorization (CAA) Resource
Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
<https://www.rfc-editor.org/info/rfc8659>.
[RFC8737] Shoemaker, R.B., "Automated Certificate Management
Environment (ACME) TLS Application-Layer Protocol
Negotiation (ALPN) Challenge Extension", RFC 8737,
DOI 10.17487/RFC8737, February 2020,
<https://www.rfc-editor.org/info/rfc8737>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[tor-spec] The Tor Project, "Tor Specifications",
<https://spec.torproject.org>.
[tor-rend-spec-v2]
The Tor Project, "Tor Rendezvous Specification - Version
2", commit 2437d19c,
<https://spec.torproject.org/rend-spec-v2>.
[cabf-br] CA/Browser Forum, "Baseline Requirements for the Issuance
and Management of Publicly-Trusted TLS Server
Certificates", Version 2.0.6, 5 August 2024,
<https://cabforum.org/working-groups/server/baseline-
requirements/documents/CA-Browser-Forum-TLS-BR-2.0.6.pdf>.
[onion-services-setup]
The Tor Project, "Set Up Your Onion Service",
<https://community.torproject.org/onion-services/setup/>.
[spoiled-onions]
Winter, P., Köwer, R., Mulazzani, M., Huber, M.,
Schrittwieser, S., Lindskog, S., and E. Weippl, "Spoiled
Onions: Exposing Malicious Tor Exit Relays", Privacy
Enhancing Technologies (PETS 2014), Lecture Notes in
Computer Science, vol. 8555, pp. 304-331,
DOI 10.1007/978-3-319-08506-7_16, 2014,
<https://doi.org/10.1007/978-3-319-08506-7_16>.
[tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-25, 14 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-25>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
The reasons for utilizing the "dns" identifier type in ACME and not defining a new identifier type for ".onion" may not seem obvious at first glance. After all, ".onion" Special-Use Domain Names are not part of the DNS infrastructure and, as such, why should they use the "dns" identifier type?
ACMEで「DNS」識別子タイプを使用し、「ONION」の新しい識別子タイプを定義しない理由は、一見明白ではないように思えるかもしれません。結局のところ、「.Onion」特別使用ドメイン名はDNSインフラストラクチャの一部ではなく、なぜ「DNS」識別子タイプを使用する必要があるのですか？
Appendix B.2.a.ii of [cabf-br] defines, and this document allows, using the http-01 or tls-alpn-01 validation methods already present in ACME (with some considerations). Given the situation of a web server placed behind a Tor-terminating proxy (as per the setup suggested by the Tor project [onion-services-setup]), existing ACME tooling can be blind to the fact that a ".onion" Special-Use Domain Name is being utilized, as they simply receive an incoming TCP connection as they would regardless (albeit from the Tor-terminating proxy).
付録B.2.A.II [CABF-BR]が定義しており、このドキュメントでは、HTTP-01またはTLS-ALPN-01検証方法を使用してACMEに既に存在します（いくつかの考慮事項があります）。トル終了プロキシの後ろに配置されたWebサーバーの状況を考えると（TORプロジェクト[Onion-Services-Setup]、Setupに従って）、既存のACMEツーリングは、「.Onion」特殊使用ドメイン名が利用されているという事実を盲目にすることができます。
An example of this would be Certbot placing the ACME challenge response file in the webroot of an NGINX web server. Neither Certbot nor NGINX would require any modification to be aware of any special handling for ".onion" Special-Use Domain Names.
この例は、Nginx WebサーバーのWebrootにACMEチャレンジ応答ファイルを配置することです。CertbotもNginxのどちらも、「.Onion」特別使用ドメイン名の特別な処理を認識するために変更を必要としません。
This does raise some questions regarding security within existing implementations; however, the authors believe this is of little concern, as per Section 8.2.
これにより、既存の実装内のセキュリティに関するいくつかの疑問が生じます。ただし、著者らは、セクション8.2に従って、これはほとんど懸念がないと考えています。
With thanks to the Open Technology Fund for funding the work that went into this document.
この文書に入った作業に資金を提供してくれたOpen Technology Fundに感謝します。
The authors also wish to thank the following for their input on this document:
著者はまた、このドキュメントに関する入力について以下に感謝したいと思います。
* Iain Learmonth
* iain learmonth
* Jan-Frederik Rieckers
* Jan-Frederik Rieckers
Q Misell (editor)
AS207960 Cyfyngedig
13 Pen-y-lan Terrace
Caerdydd
CF23 9EU
United Kingdom
Email: q@as207960.net, q@magicalcodewit.ch
URI: https://magicalcodewit.ch