前回の CA/B フォーラムのミーティングで Chrome は、「Moving Forward, Together（ともに、未来へ）」と題して今後の Web PKI ポリシーに関するビジョンの概要を説明しました。特に目立ったのは、Chrome のビジョンで証明書の有効期限が 90 日間になっていることです。これについては別の記事で詳しく解説しています。ただし、Chrome のビジョンには、関連性があってお客様が注意しておくべきポリシー案がほかにも含まれています。ルート認証局（CA）の期間制限や中間認証局（ICA）の最大有効期限の提案などです。

Chrome は、以下の点に関連する将来のポリシー要件を検討していると、その発表の中で述べています。

• 最新のインフラストラクチャと敏捷性の促進
• シンプルさの重視
• 自動化の推進
• 発行ミスの低減
• 説明責任とエコシステムの整合性を向上する
• ドメイン認証業務の合理化と改善
• 耐量子時代への備え

私たちデジサートは、「インターネットの安全性向上」という Chrome の目標を支持しています。しかし、セキュリティと管理性の間にはバランスが存在することも認識しています。90 日の証明書に関する記事でも述べたように、これまで当社は証明書ライフサイクルの短縮を支持してきましたが、90 日間というのは危殆化した証明書が存続するには長すぎる反面、業界の移行やドメイン登録を考えると短すぎます。お客様が真に短期の証明書に移行することを奨励して実現するような他の選択肢を模索したほうがいいでしょう。

同様に、Chrome はルート CA を 7 年ごとに、その他の ICA を最大 3 年間の有効期限でローテーションすることも提案しています。現在、ルート CA は 25 年ごとにローテーションされており、ICA の有効期間は無期限です。当社はこれまで ICA 有効期間の短縮を支持してきましたが、正確な期間は、セキュリティと現実のバランスをうまくとるべきです。詳しく説明していきます。

ルートおよび ICA とは何か

ルートとは、CA のアイデンティティをそのルート公開鍵に結び付ける自己署名証明書のことであり、ルート公開鍵とは CA が配布する他の ICA すべてに署名する際に使用する公開鍵です。ICA 証明書には、他の ICA またはエンドエンティティ証明書への署名に使用される公開鍵や記録されているほか、CA が準拠するポリシー、署名する証明書の種類、発行された際のルート、関連するアイデンティティなどに関する他のメタデータも含まれています。

エンドエンティティ証明書と ICA 証明書は署名者からの信頼を獲得しており、署名者はそこに記録されている情報がすべて有効であり、正しく、信頼できることを証明します。ルート証明書がそれ自体の信頼性を証明することはできないため、ブラウザのルートプログラムで信頼されたルート証明書のリストに掲載されることによって信頼を確保しています。

ルート証明書は、すべてのルートプログラムで利用可能になり、大多数のプラットフォームに配布されて初めて顧客に信頼されます。これが、一般的に普及というプロセスであり、それには簡単に数年かかることがあります。したがって、有効期間はルート証明書が最も長く、SSL 証明書が最も短いというのが普通です。

ローテーションする理由

ICA をローテーションするのは、最新の標準に間違いなく準拠するためであり、エンドエンティティ証明書をローテーションするのがよいのと同じ理由です。ポリシーにはときどき変更や改善があるので、互換性の理由から、業界はたいてい継続的にポリシーを変更します。ICA をローテーションすると、こうしたポリシーの改善が妥当な時間内にあらゆる ICA に伝わることを保証できるのです。したがって、ICA の期間が短くなることは、現在の制限が永続的であることを考えると特に、必ずしも悪いこととは限りません。

ルートに関しては、ローテーションの利点はさらに曖昧です。前述したとおり、ルートには意図的に情報がほとんど含まれていません。これは、特定の ICA が本当にルートプログラムで信頼された特定の CA のものかどうかを長期的に検証する手段を提供することが目的だからです。過去のルートは、もっと緩やかなコンプライアンス環境で作成されたものであり、なかには監査の対象範囲にギャップがあるものもあります。そのため、それがなくなるのはエコシステムにとって望ましいのですが、ルートの移行は複雑なので、そのメリットとリスクを比較検討してみる必要があります。特に、ルートプログラムに新しいルートを含めることには歴史的に時間がかかっており、ルート作成から普及までたった 2 年という Google のビジョンを達成するには、大幅な改善が必要です。今でも、ルートの埋め込みには 3 年、ルートの普及にさらに 3 年かかっているため、ルートの有効期間が最大 7 年というのは現実的ではありません。Google はルートの埋め込みを急ぐことができるかもしれませんが、Web PKI には、エコシステム全体にルートを分散させるという価値もあります。Chrome、Apple、Mozilla のそれぞれでサイトにアクセスするユーザーに対して別々のルートを用意する必要はありません。つまり、ルートローテーションは、ユーザーエージェントのルートストアの中で最も遅いメンバーと同じ速さでしか起こらないのです。これらのユーザーエージェントのなかには、CA/B フォーラムに参加せず、迅速なルートローテーションの必要性を表明していないものもあります。

ルート組み込みに要する長いプロセスを回避する方法はあります。パッケージでチェーンを増やすことです。その方策を実現するには、事実上 4 チェーン以上のルートが必要です。まず、すべてにチェーンして普及を目指すマスタールートがあります。2 つ目は、Chrome をはじめとする更新頻度の高いブラウザに組み込まれたルート、3 つ目は、エンドエンティティ証明書を発行する発行 CA です。この設計の問題点は、Chrome に対して他のユーザーエージェントがすべて不利になるということです。使用するチェーンが長くなると、迅速なルート置換を行う場合より速度が低下します。このとき、TLS 接続が実際に速くなるわけではなく、プログラムに参加していないすべてのエージェントで速度が低下するだけです。

ルートと ICA をローテーションすると、ピン留めを使用している場合は特に、混乱が生じます。&

影響を受けるサーバーで手動の更新が必要になることが多いため、ルートと ICA のローテーションが顧客に与える影響は大きく、業界にとっても非常に大きな混乱を招きかねません。また、デジサートがピン留めに強く反対しているにもかかわらず、多くの顧客がルートと ICA をピン留めしています。証明書のピン留めは非常にリスクが高く、鍵が危殆化したときには証明書の交換が不可能になります。ハッカーがウェブサイトに長期的なダメージを与えられるようになり、証明書の問題に対応しにくくなります。Google も、2011 年に証明書のピン留めを初めて使ったうちの 1 社でしたが、証明書をピン留めすることのリスクはすぐに明らかになりました。証明書のピン留めを利用しているお客様は、できるだけ速やかにピン留めをやめるべきですが、ルートと ICA のローテーション頻度を引き上げるという議論も、現在ピン留めを利用しているお客様にとっては、重ねての注意喚起になります。

絶えざる要件の変化に遅れないよう、デジサートがサポートすることが可能です。

一方、デジサートのルートが広く普及しており、デジサートが ICA のローテーションに関して豊富な経験を有していることを、お客様には知っていただきたいと考えています。また、DigiCert^® Trust Lifecycle Manager など当社のソリューションによって、お客様は変化の絶えないコンプライアンス要件や脅威を先取りしやすくなります。DigiCert Trust Lifecycle Manager は、パブリックとプライベートのトラストを越えて、CA に依存しない証明書管理と PKI サービスを統合するものであり、一元的な可視化と管理を実現し、ビジネスの中断を防いで、ID とアクセスを保護します。DigiCert Trust Lifecycle Manager は、進化し続ける業界標準に対する企業のコンプライアンス遵守を支援するフルスタックソリューションです。

まとめ

最後に、これらのポリシーは保証されたものではなく、CA/B フォーラムで投票が行われているわけではないことに注意してください。また、企業が適応するまでの時間を確保するために、業界に関わる変更は事前に通知されます。それでも、Chrome のビジョンは、業界で今こうした問題をめぐる議論が進んでいるということの証です。Chrome はその提案に関して、chrome-root-program [at] google [dot] com で、また CCADB の調査を通じて、CA オーナーからのフィードバックも受け付けています。私たちは、CA/B フォーラムをはじめとする場で議論を続けていくなかで、お客様の最大の利益を支持し続け、Chrome や CA/B フォーラムの他のメンバーとともに、インターネットの安全性向上に向けて取り組んでいきます。

この件に関連する最新情報は、デジサートブログまたは SNS をご覧ください。