このポリシーについてご不明な点がございましたら、CT ポリシー フォーラム（ct-policy@chromium.org）までお問い合わせください。
証明書の透明性を有効にしているアプリで接続の Transport Layer Security（TLS）証明書が検証されると、Android 証明書の透明性（CT）ポリシーへの準拠が評価されます。このポリシーを満たす署名付き証明書タイムスタンプ（SCT）が付属している証明書は、CT に準拠していると言われます。
CT コンプライアンスは、証明書と付属の SCT セットが、証明書の検証時に一般的な TLS ライブラリ（Android の組み込み Conscrypt を含む）によって適用される一連の技術要件を満たすことで達成されます。これらの要件は、このポリシーで定義されています。
CT ログの状態
Android の CT コンプライアンスは、CT ログの SCT を評価し、チェック時にこれらのログが正しい状態であることを確認することで判断されます。CT ログが存在できる状態のセットは次のとおりです。
PendingQualifiedUsableReadOnlyRetiredRejected
Android での CT コンプライアンスの要件を理解できるように、これらの状態の定義、各状態のログの要件、これらの状態が Android の動作に与える影響について、Chrome のドキュメントの CT ログのライフサイクルの説明で詳しく説明しています。
CT 準拠証明書
TLS 証明書が CT に準拠しているかどうかは、SCT が Android に配信される方法に応じて、後述の条件の 1 つ以上を満たす SCT のセットが付属しているかどうかで判断されます。Android の CT 適用アプリでは、すべての一般公開 TLS 証明書が CT に準拠している必要があります。ただし、CT にログインされていない証明書や、SCT が不十分な証明書は、不正発行と見なされません。
CT コンプライアンスに関する証明書を評価する際、Android は、証明書が検証されているときと CT ログによって SCT が作成されたときの両方で、存在する SCT の数、SCT を発行した CT ログを運用しているユーザー、SCT を発行した CT ログの状態など、いくつかの要素を考慮します。
SCT が Android に提示される方法に応じて、CT コンプライアンスは次のいずれかの条件を満たすことで達成できます。
埋め込み SCT:
- チェック時に
Qualified、Usable、またはReadOnlyだった CT ログの埋め込み SCT が 1 つ以上ある。 - チェック時に
Qualified、Usable、ReadOnly、またはRetiredだった、少なくとも N 個の異なる CT ログから埋め込まれた SCT がある（N は次の表で定義）。 - 要件 2 を満たす SCT のうち、少なくとも 2 つの SCT が、Android によって認識される異なる CT ログ オペレーターから発行されていること。
- 要件 2 を満たす SCT のうち、少なくとも 1 つの SCT は、Android によって RFC 6962 に準拠していると認識されているログから発行されている必要があります。
| 証明書の有効期間 | 個別の CT ログからの SCT の数 |
|---|---|
| 180 日以下 | 2 |
| 180 日以上 | 3 |
OCSP または TLS を介して配信される SCT:
- チェック時に
Qualified、Usable、またはReadOnlyだった CT ログの SCT が 2 つ以上ある。 - 要件 1 を満たす SCT のうち、Android が認識する異なる CT ログ事業者から発行された SCT が 2 つ以上あること。
- 要件 1 を満たす SCT のうち、少なくとも 1 つの SCT は、Android によって RFC6962 に準拠していると認識されている CT ログから発行されている必要があります。
埋め込み SCT と OCSP または TLS を使用して配信される SCT の両方で、ログ演算子の一意性は、log_list.json の演算子セクション内に個別のエントリがあることと定義されます。
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 になる条件と、CT ログが Retired になる状況については、Chrome CT ログポリシーをご覧ください。
CT 適用のタイムアウト
Google は、新しい log_list_timestamp を含む新しい CT ログリストを毎日公開しています。Android デバイスは、検証目的で 1 日に 1 回、このリストの最新バージョンのダウンロードを試みます。デバイスでログリストが使用できない場合や、ログリストのタイムスタンプが 70 日以上前の場合、CT の適用は無効になります。このタイムアウトにより、新しい CT ログが Qualified になった後、一定の時間が経過すると、使用可能に安全に移行できることが CT エコシステムに保証されます。