Android の Certificate Transparency（証明書の透明性）ポリシー

このポリシーに関するご質問は、CT ポリシー フォーラム（ct-policy@chromium.org）にお寄せください。

証明書の透明性へのオプトインを行っているアプリで接続の Transport Layer Security（TLS）証明書が検証されると、Android 証明書の透明性（CT）ポリシーに対する準拠性が評価されます。このポリシーを満たす署名付き証明書タイムスタンプ（SCT）が付属している証明書は、CT 準拠であると言われます。

CT 準拠は、証明書と付随する SCT のセットが、このポリシーで定義され、証明書の検証時に一般的な TLS ライブラリ（組み込みの Conscrypt を含む）によって適用される一連の技術要件を満たすことで達成されます。

CT ログの状態

Android の CT 準拠は、CT ログから SCT を評価し、チェック時にこれらのログが正しい状態であることを確認することで判断されます。CT ログが取りうる状態のセットは次のとおりです。

  • Pending
  • Qualified
  • Usable
  • ReadOnly
  • Retired
  • Rejected

Android での CT 準拠の要件を理解するうえで役立つよう、これらの状態の定義、各状態でのログの要件、これらの状態が Android の動作に与える影響については、Chrome のドキュメントの CT ログのライフサイクルの説明で詳しく説明しています。

CT 準拠証明書

TLS 証明書は、SCT が Android に配信される方法に応じて、後で定義される基準の少なくとも 1 つを満たす SCT のセットが付属している場合、CT 準拠となります。Android の CT 強制アプリでは、すべての公開信頼 TLS 証明書が CT に準拠して正常に検証される必要があります。ただし、CT に記録されていない証明書や SCT が不十分な証明書は、誤発行とは見なされません。

CT 準拠の証明書を評価する際、Android は、SCT の数、SCT を発行した CT ログの運営者、SCT を発行した CT ログの状態（証明書の検証時と、CT ログによる SCT の作成時の両方）など、いくつかの要素を考慮します。

SCT が Android に提示される方法に応じて、次のいずれかの条件を満たすことで CT 準拠を達成できます。

埋め込み SCT:

  1. チェック時に Qualified、Usable、または ReadOnly であった CT ログの埋め込み SCT が少なくとも 1 つ。
  2. チェック時に Qualified、Usable、ReadOnly、または Retired であった、少なくとも N 個の異なる CT ログからの埋め込み SCT がある（N は次の表で定義されています）。
  3. 要件 2 を満たす SCT のうち、少なくとも 2 つの SCT は、Android が認識する別個の CT ログ オペレーターから発行される必要があります。
  4. 要件 2 を満たす SCT のうち、少なくとも 1 つの SCT は、Android によって RFC 6962 準拠として認識されているログから発行されなければなりません。
証明書の有効期間 異なる CT ログからの SCT の数
180 日以下 2
180 日以上 3

OCSP または TLS 経由で配信される SCT:

  1. チェック時に Qualified、Usable、または ReadOnly であった CT ログからの SCT が少なくとも 2 つ。
  2. 要件 1 を満たす SCT のうち、少なくとも 2 つの SCT は、Android が認識する別個の CT ログ オペレーターから発行される必要があります。
  3. 要件 1 を満たす SCT のうち、少なくとも 1 つの SCT は、Android によって RFC6962 準拠として認識されている CT ログから発行される必要があります。

埋め込み SCT と OCSP または TLS を使用して配信される SCT の両方で、ログ オペレーターの一意性は、ログリストのオペレーター セクション内に個別のエントリがあることとして定義されます。

CT ログの有効期間中にオペレーターが変更されることはまれですが、CT ログには、必要に応じて previous_operators のリストを含めることができます。このリストには、前のオペレーターがこのログを操作した最終タイムスタンプが伴います。ログ オペレータの変更によって既存の証明書が破損しないように、各 SCT のログ オペレータは、SCT のタイムスタンプと previous_operators のタイムスタンプ（存在する場合）を比較することで、SCT の発行時のオペレータであると判断されます。

重要な注意点

ハンドシェイクで提示された SCT の組み合わせのいずれかが、上記の CT 準拠基準を満たしている限り、SCT のステータスに関係なく、追加の SCT は証明書の CT 準拠ステータスにプラスまたはマイナスの影響を与えません。

証明書の CT 準拠に貢献するためには、ログの Retired タイムスタンプ（存在する場合）より前に SCT が発行されている必要があります。Android は、提示されたすべての SCT のうち最も古い SCT を使用して、CT ログの Retired タイムスタンプに対する CT 準拠を評価します。これは、証明書ロギング リクエストの送信プロセス中に CT ログが廃止されるエッジケースを考慮したものです。

「埋め込み SCT」とは、証明書内の SignedCertificateTimestampList X.509v3 拡張機能を使用して配信される SCT を意味します。多くの TLS サーバーは OCSP ステープリングまたは TLS 拡張機能をサポートしていないため、Android での検証または EV 処理を確実に行うために、CA は発行する証明書に SCT を埋め込む準備をする必要があります。

Android に CT ログを追加する方法

CT ログが Qualified になる条件と、Retired になる状況については、Chrome CT ログポリシーをご覧ください。

CT の適用タイムアウト

Google は毎日、新しい log_list_timestamp を含む新しい CT ログリストを公開しています。Android デバイスは、検証を目的として、このリストの最新バージョンのダウンロードを 1 日 1 回試みます。デバイスでログリストが利用できない場合、またはログリストのタイムスタンプが 70 日より古い場合、CT の適用は無効になります。このタイムアウトは、新しい CT ログが Qualified になってから一定時間内に安全に使用可能に移行できることを CT エコシステムに保証する重要なものです。

Android ログリスト

Android ログリストは log_list.json に公開され、毎日更新されます。このログリストは、安定版 API、SLA、可用性の保証なしで提供されます。

Android は、CT ログリストを、CT と WebPKI エコシステムとの互換性を維持したい、またはその内容を調査したい証明書提出者（認証局など）と CT モニターおよび監査担当者が利用できるようにしています。

Android CT ログリストへの不正な依存は、ユーザーだけでなく、Android ユーザーと CT エコシステム全体を危険にさらします。アプリに CT 強制の追加を検討している場合は、Android プラットフォームでサポートされているメカニズムを使用してください。

このポリシーに沿わない Android CT ログリストの使用は自己責任で行ってください。アプリケーションやライブラリの破損につながる可能性があります。Android は、Android ユーザーの安全性とセキュリティを維持するため、CT エコシステムのインシデントに対応して CT ログリストを変更できる必要があります。Android は、CT ログリストに対するサードパーティの依存関係が、不正使用を阻止するためのログリストの予告なしの変更など、Android のインシデント対応能力を損なわないようにするための措置を講じることがあります。