要約

  • v3 Onion アドレスはサービスの Ed25519 身元公開鍵から作られ、DNS 委任から生まれないため、到達性だけでは名前の制御を証明できない。
  • onion-csr-01 は CA と申請者の nonce を含む専用 CSR を Onion 身元鍵で署名させ、証明書用の最終 CSR と明確に分離する。
  • CAA は暗号化記述子または期限付きの署名済み onionCAA で提示できるが、CA が実際に選んだ経路と公開性の代償は別途記録する必要がある。

時刻順に並べなければ証明にならない

RFC 9799 の中心は、新しい challenge 名そのものではなく、どの証拠がいつ有効になるかにある。.onion は RFC 7686 による特別用途名で、通常の DNS 権威には属さない。Tor v3 のアドレスは 32 バイトの Ed25519 身元公開鍵、チェックサム、バージョンを base32 化して構成する。文字列はドメイン名に見えても、支配の根は委任ではなく秘密鍵である。

互換性のため ACME では dns 識別子を使うが、dns-01 は禁止される。TXT レコードを置く権威が存在しないからだ。http-01 と tls-alpn-01 は Tor 接続などの変更を伴えば利用できる。CA は Tor2Web に委託せず自ら Onion Service に接続しなければならない。ただし、この二方式はワイルドカードを扱えず、Onion 身元鍵そのものの署名も要求しない。

onion-csr-01 では、まず CA が 64 ビット以上のエントロピーを持つ nonce を発行する。生成から 30 日を超えた nonce の応答は受理できない。クライアントはその生バイトを caSigningNonce に、自ら生成した 64 ビット以上の nonce を applicantSigningNonce に入れ、Onion 秘密鍵で専用 CSR を署名する。

CA は PKCS#10 の形式、公開鍵と Onion 名の対応、署名、CA nonce の一致、申請者 nonce の存在とエントロピーを順に確認する。subject の内容には意味を与えず、検証してはならない。さらに、検証 CSR の公開鍵は最終 CSR の公開鍵と同じであってはならない。

この順序で、三つの鍵が混ざらなくなる。ACME アカウント鍵はプロトコル要求を認証する。Onion 身元鍵は名前の制御を証明する。最終 CSR の鍵は証明書に載る。通常の key authorization が省かれるのは、専用 CSR がすでにアカウント署名済みの ACME チャネルを通るためである。

記述子の更新には観測不能な間がある

限定公開を使うサービスでは、許可されたクライアントだけが記述子の内層を復号できる。CA がサービスへ到達できても、CAA を読めるとは限らない。challenge の authKey は、CA が記述子アクセスに用いる Ed25519 公開鍵を示す。この鍵は別の Onion Service と共有してはならず、同一サービスの再検証には再利用できる。

CA は自らの CLIENT-ID を計算し、第一層の auth-client と照合する。該当行がなければ、クライアント認証は不要と仮定する。新しい CA 鍵を許可する場合、運用者は記述子を再署名して再公開し、ディレクトリへの伝播を待つ。

ここには固定時間がない。RFC は数分程度を見込む一方、将来の Tor 運用で変わり得ると明記し、challenge には少なくとも 30 分を推奨する。数分という期待値と 30 分という猶予を SLA として扱ってはならない。クライアントの authorization 応答は「鍵を追加する機会があった」という合図であり、「新しい記述子を CA が読んだ」という証拠ではない。

CAA の有効時間は、証明 challenge と別に進む

記述子 CAA は RFC 8659 の flags tag value を第二暗号化層に置く。DNS の親方向探索も .onion TLD の照会も行わない。同じ基底 Onion アドレスの下にあるサブドメインは、一つの CAA 集合を共有する。

限定公開の外側からは内容が見えないため、第一層に caa-critical を置ける。これは CAA が存在することだけを示し、CA が復号して解析するまで発行を止める。可視のフラグは不可視のポリシーの代用品ではない。

別の経路では、最終化時に onionCAA を送る。各 Onion 名について CAA 文字列または null、Unix 期限、Onion 身元鍵の Ed25519 署名を含む。期限は原則として未来 8 時間以内で、64 ビット以上として処理する。署名対象は onion-caa|、先頭ゼロのない十進期限、|、CAA 本文の厳密な連結である。

CA は署名済み集合だけを採用しても、無視して記述子を取得しても、両方を確認してもよい。記述子取得に対応せず onionCAA がなければ onionCAARequired を返し、directory の inBandOnionCAARequired で要件を予告できる。したがって監査では、署名の成否だけでなく、CA がどの時点のどの集合を選択したかが必要になる。

Tor ディレクトリは信頼主体ではない。記述子方式も in-band 方式も、最終的な権威は同じ Onion 身元鍵の検証にある。配送経路の違いを権威の違いと読み違えてはならない。

最後に残るのはプライバシーの時系列

CA は Onion Service へ自ら Tor 接続する。ACME クライアントも Tor を用い、CA が Onion endpoint を提供するなら優先することが望ましい。既知の CA アドレスへ直接接続すれば、そのホストに Onion Service があることを推測され得る。

http-01 が公開 DNS ホストへ redirect すると、その IP やホスティング関係が CA に見える。公開ドメイン側の検証を Tor exit 経由にすると exit hijack の危険があるため、それも禁止される。

公的 WebPKI 証明書はさらに後戻りできない。Onion 名が Certificate Transparency に載るからだ。公開信頼が必要なサービスもあれば、私的信頼や自己署名で足りるサービスもある。登録情報は最小化し、複数サービスを CA に関連付けられたくないなら ACME アカウント鍵も分ける。

証明書が発行された時刻だけを残しても、何も監査できない。nonce の発行、身元署名、記述子更新、最初の復号、CAA 期限、最終 CSR、redirect、CT 公開を別々の時刻として保存して初めて、RFC 9799 の証拠鎖は機能する。

出典