筆者：GMOグローバルサイン株式会社
事業企画部 ビジネスプロデューサー 稲葉 厚志
（JIPDEC客員研究員）

前回、2017年9月25日に「電子証明書ガイドライン策定のためのCA/Browser Forum」について紹介しました。今回は、そこで記載しきれなかったことをご紹介していきます。

CA/Browser Forumでの議論に用いられる手段

CA/Browser Forumで、どのように議論が行われているのかについて、興味をお持ちの方もおられると思います。実はオープンな情報として、Forumでの議論の大半は公開されており、メールやウェブサイトを通じて把握することが可能です。

CA/Browser Forumが議論に使用しているメーリングリストには、マネージメントメーリングリスト(以下、Management ML)とパブリックメーリングリスト(以下、Public ML)の2種類があり、後者のPublic MLについては、登録(英語のメールかつ受信のみですが、https://cabforum.org/mailman/listinfo/public から登録可能 )さえすれば、基本的には誰でもForumメンバーによるメールでの議論をリアルタイムに共有できます。

前者のManagement MLはForumメンバー限定のメーリングリストで、議事録ドラフトの確認やミーティングアジェンダ案の検討などに用いられ、メンバー間の議論は、後者のPublic MLを用いて行うことを基本としています。メーリングリストのほかに、隔週で実施される電話会議(最近はWebEX(注１)を使い始めている)及び年3回開催されるFace to Faceミーティングで議論が行われています。また、議論の後には、Baseline Requirementsの改訂等、フォーラムの決定を行う際のプロセスとしてBallotと呼ばれる投票が行われ、ブラウザ、認証局の各々で一定割合の賛成票が得られたことをもって可決となります。

• ウェブサイト別ウインドウで開く

近年のCA/Browser Forumの議論の中で大きく扱われたものの1つに、サーバ証明書のSHA-1(注2)からSHA-2(注3)への暗号アルゴリズムの移行があります。SHA-1の暗号アルゴリズムの脆弱性が報告されたことを受け、2013年に、より安全で強いSHA-2の暗号アルゴリズムへの移行についての議論が行われ、この過程で課題として提起されたのが、非パーソナルコンピュータ環境でのSHA-2アルゴリズム対応でした。パーソナルコンピュータと異なり、一旦、市場に出て稼働して以降の新機能対応アップデートを容易に行うことができない業務専用システムや組込ブラウザ搭載端末がSHA-2対応できるまでのリードタイムを考慮し、SHA-1の利用を2016年末まで可とするという決定がなされました。

2013年当時、日本の携帯電話利用は、フィーチャーフォン6割強、スマートフォン4割弱で、しかもSHA-2に対応したフィーチャーフォンがかなり少ない状況でした。そこで、そのようなスマートフォンやSHA-2対応フィーチャーフォン普及が進まない中でSHA-1が使えなくなると、日本における携帯電話からのhttpsサイトアクセスに大きな影響が出るかもしれないという内容のプレゼンテーションをFace to Face ミーティングの場で行ったことを思い出します。

認証局は、パブリック証明書の発行を開始するのに先駆けて、ブラウザ等インターネットへアクセスする製品への「認証局ルート証明書」搭載を進めることが必須です。

Microsoft、Mozilla、Google、Apple等の主要ブラウザベンダーは、CA/Browser Forumに参画しForumの動向を把握しながらも、「ルート証明書搭載要件」を各々独自に策定しています。主要ブラウザベンダー間で共通している要件も多く、これらはCA/Browser Forumから発信されるBaseline Requirementsに盛り込まれてきますが、主要ブラウザベンダー間で全く同じというわけではないので、認証局としては、ルート証明書搭載推進とその普及(=自社発行証明書の適用可能範囲拡張)に向け、各々のブラウザベンダーの要件すべてに対応していかざるを得ないのが現状です。こうした背景から、フォーラムにおけるブラウザベンダーと認証局の関係においては、ブラウザベンダーの影響力・発言力が認証局のそれを凌駕している感があります。

認証局側は、電子証明書サービスを顧客に提供している立場上、ルート証明書搭載要件やBaseline Requirementsへの様々な改訂への対応に際し、ブラウザベンダー以上に顧客への影響を考慮せざるを得ないのが実情です。認証局の運用方針を示したCPS(注4)の改訂やシステムリリースなどは3か月から半年を要するのが一般的であり、顧客への案内や契約文書の変更が必要な場合もあります。
要件を盛り込んだサービス提供まで、十分な時間を確保したい認証局側と、決まった要件はすぐにも対応すべきというブラウザベンダー側とで、しばしば議論となることがあります。

過去の議論の中には、サーバ証明書の有効期間短縮も議題にあがりました。
当時、認証局の中には、10年という長期の有効期間でサーバ証明書(DV、OV)を発行しているサービスがあり、グローバルサインもサービス開始当初は、有効期間が5年や6年の証明書を発行していました。ただし、全体的な市場の風潮として、なりすましサイトの発生やSHA-1における脆弱性への懸念から、鍵の安全性を問う声が多く挙がり、１つの鍵を長期にわたって使用していることが問題視されるようになりました。
Forum内でもサーバ証明書有効期間短期化が検討され、まずは最長有効期限を5年とし、その後、39か月(2015年4月～)に改訂され、現時点では、2018年3月以降に発行されるサーバ証明書(DV、OV)は、EV SSLと同様に27か月(825日)を最長とすることがBaseline Requirementsに既に規定されています。

主要ブラウザベンダーの中には、12か月や6か月を最長とすべきとの意見をもつベンダーもいます。また、証明書の有効期間をもっと短くしてはという意見もあります。
short lived certificateとして、数日間だけ利用できる証明書を発行し、失効情報参照先の証明書への記載を行わないという案ですが、このような失効の手立てのない証明書を発行してしまうことに感覚的に馴染めない認証局も少なくありません。
サーバ証明書を利用する顧客視点からしても、例えば、ホスティング事業者などは証明書の有効期間が短くなることで、頻繁に多くの証明書更新作業を行うという負荷がかかるため、過度に短期間化が進むことに懸念を示すことが予想されます。
今後、更なる証明書有効期間短期間化を巡る議論が必至の状況にあるといえます。

• （参考）Baseline Requirements for the Issuance and Management of Publicly-Trusted Certicates（パブリック証明書の発行及びマネジメントの基本要件）別ウインドウで開く

最後になりますが、CA/Browser Forumで、現在どのような議論がなされているかは、一般公開用のページを閲覧することで、情報を得ることができます。

• 一般公開用のページ別ウインドウで開く

このページ内で公開されているドキュメントは、Baseline RequirementsやEV SSLガイドラインといった要件に関するドキュメントのほか、Ballot(投票)案件とその結果、電話会議及びFace to Face ミーティングの議事録も参加者の氏名入りで公開されています。
これらを参照して頂くことで、認証局が行うCertificate Transparency(注5)対応、CAA(注6)チェック、ドメイン認証に使用できる方法の明確化など、様々なトピックをそこから把握することが可能です。各認証局などからも適宜、情報発信があるとは思いますが、事前に、電子証明書に関わる動向を押さえたいという方には、上記CA/Browser Forumのウェブサイト掲載情報のチェックをお勧めいたします。

• (注1)：オンライン会議、ビデオ会議を行うための仕組み
• (注2)：暗号処理の際に使用されるハッシュ関数の1つ。SHA-1の生成するハッシュ値は160bit。SHAは「Secure Hash Algorithm」の頭文字をとったもの
• (注3)：暗号処理の際に使用されるハッシュ関数の1つ。SHA-2の生成するハッシュ値は224～512bit。SHA-2はSHA-224、SHA-256、SHA-384、SHA-512の４種類。
• (注4)：認証局の信頼性、安全性を対外的に示すために、認証局の運用、鍵の生成・管理、責任等に関して、運用方針をどのように適用させるのかを定めた文書。Certification Practices Statementの頭文字をとったもの。
• (注5)：発行されたSSLサーバ証明書が正しいものであるかの正当性を検証する仕組み。外部の公開ログサーバに監査ログとして登録。
• (注6)：SSLサーバ証明書の誤発行防止のため、ドメイン管理者がDNSに追加するレコードのこと。Certification Authority Authorizationの頭文字をとったもの

（2017年9月掲載）