今回の CA/B フォーラムは 10 月下旬にベルリンで開催されました。このフォーラムは、コロナ禍後最初に開かれた大規模な対面形式ミーティングのひとつで、70 名以上が出席しました。ベルリンで開かれたことのもう一つのメリットは、ドイツの主催者によるオルガン演奏の披露と、その後に振舞われたバイエルン地方の伝統的な食べ物とビールでした。これらはすべて主催者の尽力のおかげで可能になりました。

ドイツの伝統文化を披露するだけでなく、CA/B フォーラムは主要イニシアティブにおいてもいくつかの進展を見せました。まず、S/MIME ベースライン要件についての最終議論が行われ、それらを確定した後、コードサイニングのトークン変更についての話し合いと、失効時の OCSP のチェックの不要化に関する提案の検討が行われました。

約 5 年前、CA/B フォーラムは再編成を経て、サーバー証明書だけでなく、コードサイニングや S/MIME の最小要件を扱うようになりました。フォーラムのグループの活動は活性化しており、今では独自の要件を設定するようになっています。これにより、業界の俊敏性を促しています。耐量子コンピューター暗号（PQC）への移行が進んでいることを考慮すると、これは最適なタイミングです。耐量子コンピューター暗号により、セキュリティ要件は劇的に変化し、業界のデジタルトラストを維持するために、かつてないほどの暗号化の俊敏性が求められることになります。以下は、これらのグループでの最新状況の概要です。

S/MIME ベースライン要件の確定

最も顕著な進展は、S/MIME ベースライン要件（BR）が確定されたことです。つまり、メール署名と暗号化署名に関する BR の要件のいくつかが、最初に施行されることになります。これは、以前にブログで説明した 4 年プロセスの成果です。デジサートの Stephen Davidson は、過去 2 年にわたって S/MIME ワーキンググループの議長を務めています。デジサートは、業界が最初の基準（メール署名に関するもの）の導入に関して同意に至ったことを誇りに思っています。

新たな S/MIME BR では、監査可能な要件が設定されます。これにより、S/MIME 証明書が適切な最低検証基準に従いつつ、相互運用可能なプロファイルに準拠するようになります。3 つの異なるレベル（レガシー、多目的、厳格）が定義されることにより、既存の慣行の継続を許可しつつも、企業が高品質で新規の S/MIME 証明書に移行できるようにします。

これらの要件の発行日は 2023 年 9 月ですが、1 つ以上のメールクライアントがコンプライアンスの義務付けを決定するまで、実際の施行は行われません。数々のルートプログラムは、S/MIME BR へのコンプライアンスの義務付けに関して意欲を示していますが、まだ正式な発表は行われていません。

サーバー証明書の OCSP チェック不要化の流れ

さらに、失効時における OCSP チェックを不要化する流れがブラウザで起きています。これは、ここ数年で徐々に起きてきたことですが、Chrome はすでに不要化しており、Apple もその方向で進んでいます。OCSP の使用には多くのプライバシーリスクが伴っているため、近い将来 OCSP は廃止されるものと思われます。OCSP を使用してウェブサイトの失効ステータスをチェックする際には、ブラウザはアクセス中のドメイン名をインターネット経由で送信する必要があります。この情報はスヌーピングに対して脆弱になります。ここ数年の間、インターネットエンジニアは、ユーザーが訪問したウェブサイトをネットワークオペレーターが特定するのを困難にするよう尽力してきました。同時期に、いくつかのブラウザ企業では、圧縮された失効情報をブラウザに直接送信するテクノロジーを開発および導入してきました。これにより、OCSP がなくても失効情報を入手できるようになりました。

さらに、失効時における OCSP チェックを不要化する流れがブラウザで起きています。これは、ここ数年で徐々に起きてきたことですが、Chrome はすでに不要化しており、Apple もその方向で進んでいます。OCSP の使用には多くのプライバシーリスクが伴っているため、近い将来 OCSP は廃止されるものと思われます。OCSP を使用してウェブサイトの失効ステータスをチェックする際には、ブラウザはアクセス中のドメイン名をインターネット経由で送信する必要があります。この情報はスヌーピングに対して脆弱になります。ここ数年の間、インターネットエンジニアは、ユーザーが訪問したウェブサイトをネットワークオペレーターが特定するのを困難にするよう尽力してきました。同時期に、いくつかのブラウザ企業では、圧縮された失効情報をブラウザに直接送信するテクノロジーを開発および導入してきました。これにより、OCSP がなくても失効情報を入手できるようになりました。

コードサイニング

最後に、業界は、独自に保持したトークンから署名サービスへと移行する方法を模索し続けています。しかし、クラウド署名サービスの最小セキュリティ要件は何かを定義するのは困難です。コードサイニング証明書ユーザーの大半は、 コードサイニング鍵を保護するのに依然として物理トークンを使っています。これは多くの場合、鍵の不正使用や盗難につながります。また、トークンは、コードサイニングのエコシステムにおける俊敏性と鍵保護の向上に悪影響を及ぼします。Microsoft は、コードサイニングにおける鍵保護を一段と改善する方法に高い関心を示しています。

耐量子コンピューター暗号への移行を踏まえ、署名鍵セキュリティに関する俊敏性は特に重要になってきます。TLS などの有効期間の短い認証証明書については、新しいテクノロジーに移行するまでの十分な時間がありますが、現在署名されているソフトウェアライブラリは、暗号に対応する量子コンピューターが登場する時点でも使われていることになります。そのため、署名ソリューションへの改善は、今から適用されていく必要があります。

署名サービスでは、一元化された鍵管理が実現されるため、ソリューションの進化にあわせてより簡単にアップグレードできます。課題となるのは、署名サービスに関する妥当な最小基準を策定して維持しながら、強力な認証と鍵保護を保証することです。最小要件を設定しなければ、セキュリティレベルは玉石混交になります。署名サービスの中には、e-Bay が利用しているような強力なHSMで保護されているものから普通のネット接続者と変わらないようなものまであります。

2 月の開催

次回の CA/B フォーラムは、2 月にカナダのオタワで開催され、Entrust 社が主催します。いつもどおり、CA/B フォーラムのアップデートについては、デジサートのブログ（www.digicert.com/jp/blog/category/ca-browser-forum）をフォローしてください。