要約

  • 任意の token-authority はクライアント向けの発見ヒントにすぎない。サーバーの信頼は、x5u または x5c で示された証明書と、エコシステムごとの設定済み発行者関係から生まれる。
  • ACME サーバーは JWTClaimConstraints を不透明な文字列として扱い、元の注文値とトークンの tkvalue を変換せずオクテット単位で比較する。
  • 有効化には、発行者、署名、型、厳密な値、exp、jti、ACME アカウント鍵、CSR の CA 役割という独立した証跡が必要である。発行成功は後の JWS 検証や通話結果の証明ではない。

行き先を教える値と、信頼を決める値

tkauth-01 チャレンジには、任意で token-authority URL を含められる。クライアントはその URL を使って JWTClaimConstraints Authority Token の発行先を見つける。URL がなければ、帯域外設定で取得先を知っていることが想定される。

第 05 版が明記したのは、その URL を ACME サーバーがチャレンジ応答の検証に使わないという点である。クライアントをある場所へ案内する情報は、その場所の署名者にサーバー側の権限を与えない。

発行者への信頼は別経路で成立する。Authority Token は、対象エコシステムの発行者としてサーバーに設定された証明書で署名されなければならない。証明書は HTTPS の x5u で参照するか、x5c で提示できる。どちらもない場合や、その証明書が設定済みの発行者でない場合は失敗する。任意の iss が発行者を名乗っても、トークン自身の主張で信頼を獲得することはできない。

この分離により、サービス配置と権限を別々に変更できる。可用性のために取得先を移しても、信頼集合を広げる必要はない。逆に、発行者を失効させてもクライアント経路の説明まで書き換える必要はない。両者を一つの設定にすると、単なる URL 更新が監査されない信頼変更になり得る。

意味を判断する主体と、同一性を守る主体

新規注文の JWTClaimConstraints 識別子には、JWTClaimConstraints または EnhancedJWTClaimConstraints ASN.1 オブジェクトを DER で符号化し、さらにパディングなし base64url にした値が入る。Authority Token は同じ値を atc.tkvalue に収める。

内部の制約は STIR の意味を持つ。Token Authority は RFC 8226 と RFC 9118 に従い、申請者が代表できる資源と claim に照らして、その内容を許可できるか判断する。ACME サーバーはその ASN.1 を再解釈しない。第 05 版では、クライアントとサーバーから見た値は不透明である。

サーバーが証明するのは、Token Authority が署名したものと、元の注文で要求されたものが同じだという事実である。意味の権限を持つ主体に意味を残し、共有層には正確な運搬と結合だけを求める。この薄い境界は検証の放棄ではなく、責任の局所化である。

同じ意味らしさを比較に持ち込まない

DER とパディングなし base64url が一つの正規表現を決める。サーバーは二つの文字列を直接、オクテット単位で比較しなければならない。デコード、再エンコード、再正規化、その他の変換をしてから同一と判断してはならない。

= のパディング、base64url 外の文字、空白、別アルファベット、DER ではない BER、または一オクテットの差でも失敗となる。値自体は秘密ではないが、第 05 版は保守的な実装慣行として定時間比較も勧める。

変換を許すたびに、「どの差は無視できるか」を決める別の権力が生まれる。言語やライブラリの版が違えば、その答えも変わり得る。直接比較なら、元の二文字列の安全なハッシュ、長さ、字種判定、比較結果を残し、どの事実が成立したか再現できる。

一つの成否に八つの根拠

最初に atc が整形式で、tktype、tkvalue、fingerprint を持つことを確認する。次に署名証明書が設定済み発行者であること、署名が正しいこと、型が JWTClaimConstraints であること、値が元の注文と完全一致することを確認する。

続いて exp が存在し、サーバー時計と小さなローカル許容差の下で未失効であること、jti が存在することを確かめる。fingerprint は応答したクライアントの ACME アカウント鍵と一致しなければならない。最後に、トークンの ca と CSR の Basic Constraints にある CA 真偽値を照合する。

Token Authority は、この指紋でアカウント制御を検証するのではない。指紋を署名済みトークンに入れ、ACME サーバーが実際のアカウント鍵へ結合できるようにする。意味の許可とアカウント制御は、別の主体が提供する別の証拠である。

どれか一つでも失敗すれば、チャレンジは無効となり、ACME 認可エラーになり得る。すべてを「トークン不正」に集約すると、不信頼発行者、証明書取得、署名、バイト差、時計、取引 ID、アカウント、CA 役割のどこが壊れたのか分からない。

発行後に残るリンク

認可が成功しても、証明書発行は別の処理である。草案は、成功した注文応答に CA が任意の x5u を加えることも認める。証明書所有者は、後の JWS でこの URL を参照できる。CA は依存者が署名検証に必要とする間、通常は少なくとも証明書失効時まで取得可能に保つべきだとされる。

この発行後の x5u は、Authority Token 発行者証明書を検証した x5u とは別物である。段階も鍵も保存義務も異なる。発行記録は、後日証明書が取得され、依存者に受理され、電話に関する assertion が受理されたことを証明しない。

現時点で言えないこと

第 05 版は 2026 年 9 月 5 日公開の IETF ワーキンググループ Internet-Draft で、2027 年 3 月 9 日に失効予定である。今後変更され得るし、RFC ではない。本稿はクライアント、サーバー、CA、Token Authority、実行環境、証明書置き場、通信事業者、通話経路をテストしていない。

採用、適合性、相互運用、証明書発行、電話番号の権限、通話認証、不正削減を示す資料もない。仕様案は契約を記述できるが、その契約を実行した証拠は稼働系から得る必要がある。

情報源