このポリシーに関するご質問は、CT ポリシー フォーラム（ ct-policy@chromium.org）までお寄せください。
接続の Transport Layer Security（TLS）証明書が検証されると、Android Certificate Transparency（CT）ポリシーに準拠しているかどうかが評価されます。このポリシーを満たす署名付き証明書タイムスタンプ（SCT）が添付された証明書は、CT 準拠と見なされます。
CT 準拠は、証明書と添付された SCT のセットが、証明書の検証時に一般的な TLS ライブラリ（組み込みの Conscrypt を含む）によって適用される一連の技術要件を満たすことで実現されます。これらの要件は、このポリシーで定義されています。
CT ログの状態
Android での CT 準拠は、CT ログの SCT を評価し、チェック時にこれらのログが正しい状態であることを確認することで判断されます。 CT ログが取り得る状態のセットは次のとおりです。
PendingQualifiedUsableReadOnlyRetiredRejected
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 ログで作成した時点の 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 ログ オペレーターから発行されていること。
| 証明書の有効期間 | 異なる CT ログからの SCT の数 |
|---|---|
| 180 日以下 | 2 |
| 180 日超 | 3 |
OCSP または TLS 経由で配信される SCT:
- チェック時に
Qualified、Usable、またはReadOnlyであった CT ログからの SCT が少なくとも 2 つあること。 - 要件 1 を満たす SCT のうち、少なくとも 2 つの SCT が、Android によって認識される異なる CT ログ オペレーターから発行されていること。
埋め込み SCT と OCSP または TLS を使用して配信される SCT の両方で、ログ オペレーター の一意性は、オペレーター セクション の ログリストに個別のエントリがあることとして定義されます。
CT ログの有効期間中にオペレーターが変更されるまれなケースでは、CT ログに、このログが以前のオペレーターによって運用された最終タイムスタンプとともに、previous_operators
のリストを含めることができます。
ログ オペレーターの変更によって既存の証明書が破損しないように、各 SCT のログ オペレーターは、SCT
の発行時のオペレーターであると判断されます。これは、SCT タイムスタンプと previous_operators
タイムスタンプ（存在する場合）を比較することで行われます。
重要な注意点
ハンドシェイクで提示される SCT の組み合わせが上記の CT 準拠基準のいずれかを満たしている限り、SCT のステータスに関係なく、追加の SCT は証明書の CT 準拠ステータスにプラスまたはマイナスの影響を与えません。
証明書の CT 準拠に貢献するには、ログの Retired タイムスタンプ（存在する場合）より前に SCT が発行されている必要があります。
Android
は、提示されたすべての SCT のうち最も古い SCT を使用して、CT ログの Retired タイムスタンプに対する CT
準拠を評価します。
これは、証明書ロギング リクエストの送信プロセス中に CT ログが Retired になるエッジケースに対応するためです。
「埋め込み SCT」とは、証明書内の SignedCertificateTimestampList X.509v3
拡張機能を使用して配信される SCT を意味します。多くの TLS サーバーは OCSP ステープリングまたは TLS
拡張機能をサポートしていないため、CA は発行された証明書に SCT を埋め込んで、Android での検証または EV
処理を確実に行えるようにする必要があります。
CT ログを Android に追加する方法
CT ログが Qualified になるための基準と、何が
原因で Retired になるかについては、Chrome CT
ログ ポリシーをご覧ください。
CT 強制タイムアウト
Google は毎日、新しい log_list_timestamp を含む新しい CT ログリストを公開しています。Android
デバイスは、検証のためにこのリストの最新バージョンを 1 日に 1 回ダウンロードしようとします。デバイスでログリストが利用できない場合、またはログリストのタイムスタンプが
70 日より古い場合、CT 強制は無効になります。
このタイムアウトにより、新しい CT ログが Qualified
になった後、一定の時間内に安全に Usable に移行できることが 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 の能力を危険にさらさないようにするための措置を講じることがあります。