1. Introduction (はじめに)

Web PKI内の証明書 [RFC5280] は、ドメイン名 (Domain Names) の認証に最も一般的に使用されます。したがって、Web PKI内の証明機関 (Certification Authorities, CAs) は、証明書申請者が証明書内のドメイン名を正当に代表していることを検証することが信頼されています。

証明書のタイプは、CAが証明書サブジェクト情報に対して実行するさまざまな検証レベルを反映しています。「ドメイン検証」(Domain Validation, DV) 証明書は、これまでで最も一般的なタイプです。DV証明書の発行プロセスでは、CAが実行する必要がある唯一の検証は、要求者がドメイン名を有効に制御していることを確認することです [CABFBR]。CAは要求者の実在する身元を検証しようとする必要はありません。(これは、「組織検証」(Organization Validation, OV) および「拡張検証」(Extended Validation, EV) 証明書とは異なり、これらのプロセスは要求者の実在する身元の検証も目的としています。)

既存のWeb PKI証明機関は、証明書発行と身元認証に一連の臨時的なプロトコル (Ad Hoc Protocols) を使用する傾向があります。DV証明書の典型的なユーザー体験は次のとおりです:

PKCS#10 [RFC2986] 証明書署名要求 (Certificate Signing Request, CSR) を生成する。
CSRをCAのWebページにコピー＆ペーストする。
次のいずれかの方法でCSR内のドメイン名の所有権を証明する:
- Webサーバーの特定の場所にCAが提供するチャレンジ (Challenge) を配置する。
- 対象ドメイン名に対応するDNSレコードにCAが提供するチャレンジを配置する。
- ドメイン名に対応する (望ましくは) 管理者が制御する電子メールアドレスでCAが提供するチャレンジを受信し、CAのWebページで応答する。
発行された証明書をダウンロードし、ユーザーのWebサーバーにインストールする。

CSR自体と発行された証明書を除いて、これらは完全に臨時的な手順であり、機械実装された公開プロトコルではなく、人間のユーザーがCAの対話的な自然言語の指示に従うことによって完了します。多くの場合、これらの指示に従うことは困難であり、深刻なフラストレーションと混乱を引き起こします。著者が実施した非公式のユーザビリティテストでは、Webサイト管理者がドメイン名の証明書を取得してインストールするのに通常1〜3時間かかることが示されています。最良の場合でも、公開された標準化されたメカニズムの欠如は、HTTPSおよび他のPKIXに依存するシステムの広範な展開を妨げます。なぜなら、証明書の発行、展開、失効に関連するタスクの機械化を抑制するためです。

本文書は、証明書発行とドメイン名検証プロセスを自動化するための拡張可能なフレームワークについて説明し、サーバーとインフラストラクチャソフトウェアがユーザーの介入なしに証明書を取得できるようにします。このプロトコルを使用すると、HTTPSの展開、およびトランスポート層セキュリティ (Transport Layer Security, TLS) [RFC8446] ベースの他のプロトコルにおけるPKIXベースの認証の実用性を大幅に簡素化できるはずです。

なお、本文書の焦点はWeb PKIで証明書を発行するためのドメイン名の検証にありますが、ACMEは他のPKIコンテキストで他の識別子を使用する拡張をサポートしています。たとえば、本稿執筆時点では、ACMEを使用してIPアドレスを証明するWeb PKI証明書 [ACME-IP] および電話番号を証明するSecure Telephone Identity Revisited (STIR) 証明書 [ACME-TELEPHONE] を発行する作業が進行中です。

ACMEは、非自動化プロセスがまだ必要な場合でも、証明書管理の特定の側面を自動化するために使用できます。たとえば、外部アカウントバインディング (External Account Binding) 機能 (セクション7.3.4を参照) により、ACMEアカウントが外部非ACMEアカウントに既に付与されている承認を使用できるようになります。これにより、ACMEは「拡張検証」証明書の発行など、まだ完全に自動化できない発行シナリオを処理できます。