CA Browser ForumのBaseline Requirementの施行が迫る

すみません、最近はMTB関連のブログばかりを書いていました。今日はPKIネタを書きたいと思います。

昨年は偽SSL証明書の発行が多発してPKI業界にとっては災難な1年でした。結構な枚数の偽証明書を発行したDiginotar社は、各社のブラウザにインストールされるルート証明書の一覧から除外され、最終的には倒産してしまったそうです。

こういった問題を放置すると、信頼性を売りにしているPKI業界としては困ったことになってしまいます。SSL証明書なんて誰も信じなくなったら、我々業界人は飯の食い上げになっちゃいます。

そこで、認証局の信頼を取り戻すべく、昨年11月にEV SSL証明書の規格を制定した団体であるCA Browser Forumが、SSL証明書を発行する認証局の標準規格を発表しました。英語版はこちらから、日本語版はこちらからダウンロードできます。

この文書が正式に施行されるのは2011年7月1日からですが、SSL証明書の販売を行う各社は先行して対応状況をアナウンスしています。例えば、GlobalSignではこんなプレスリリースを出しています。着々と準備は進んでいるようですね。

そこで、この文書の内容をちょっとだけ見てみましょう。

Windows Server 8のAD CS新機能

先日からWindows Server 8を試していますが、いろいろと変更があって戸惑います。もちろん、AD CSもいくつか新機能が追加されていますが、あまり大きな変更はないため、淋しかったり逆に嬉しかったりします。

新機能の詳細についてはこちらに出ています。Server 8では以下の機能が追加になったそうです。

• Integration with Server Manager
• Deployment and management capabilities from Windows PowerShell
• All AD CS role services run on any Windows Server “8” Beta version
• All AD CS role services can be run on Server Core
• Support for automatic renewal of certificates for non-domain joined computers
• Enforcement of certificate renewal with same key
• Support for international domain names
• Increased security enabled by default on the CA role service

ちょいと個人的に気になったポイントだけ見ていきたいと思います。

エディションごとの役割サービスの差がなくなった
2008の頃はAD CSはWindowsのエディションによっては、使えない役割サービスがありました。8では、エディションごとの区別が無くなって、どのエディションでも全ての役割サービスが使用できます。

具体的には、以下のEnterprise以上のエディションでのみ使えていたNDESとOCSPの役割サービスが、Standard Editionでも使えるようになります。

AD CSのPowerShellの対応
AD CSのインストールがPower Shellのコマンドレットから行うことができるようになったそうです。追加になったインストール関連のコマンドレットはこちらから見れます。

同時に管理用のコマンドレットも追加になりました。こちらに詳細が出ています。Certutil.exeでできなかった機能が追加になっているので、ちょっとありがたいです。

毎回、案件の度に思うのですが、Windowsの構築手順書は図ばかりで書くのも読むのも面倒なんですよね。「上記の図のように設定する」とか書かれていると、図と画面をにらめっこしたりして疲れるのです。コマンドが一発で済むようになると、かなり楽になります。

また、コマンドが充実したことによって、AD CSの全ての役割サービスがServer Coreモードでも動くようになったそうです。


証明書テンプレートがVersion 4になった
しばらく変更の無かった証明書テンプレートのバージョンが上がり、バージョン4になります。バージョン4の変更点は以下のようになります。

• テンプレートの暗号プロバイダにCNGが指定できるようになった
• 同じ鍵での更新（rekeyではなく）を指定できるようになった
• 互換性タブが増えて、テンプレートが適用されるクライアントとCAのバージョンが指定できるようになった

ちなみに新しく追加になった互換性タブはこんな感じです。

なお、8のデフォルトでインストールされるテンプレート構成はバージョン4を使ったものはありませんでした。

MTB関連のブログを作りました

MTB関連のブログエントリーが増えてきたので、MTB関連は新しいブログに分離したいと思います。

クラウド鍵管理型暗号方式って何だ？

キーマンズネットにNTT情報流通プラットフォーム研究所が開発したクラウド暗号の特集が出ていました。記事はこちら（要ユーザー登録）。本家のプレスリリースはこちら。キーマンズネットの方が詳細に書かれています。

クラウド暗号というのは、公開鍵暗号方式の私有鍵をクラウド側に保管・管理・利用するための仕組みだそうです。PKIでは私有鍵はエンドエンティティが保管・管理・利用することになっていますが、これをクラウド側でやってしまおうという事。

いわゆるキーエスクロー（鍵預託）に近いものと思われますが、単純にキーエスクローをクラウド化すると、暗号文の復号時に復号された平分がネットワークを通してユーザーに送られてしまうのに対し、クラウド暗号ではそれが発生しないのが特徴です。

また、ユーザー側で鍵を持たないという特性から、鍵の使用に関するコントロールは完全にクラウド側が握ることになります。このため、鍵の使用前にユーザー認証（と承認）を行うことによって、特定のグループに所属するユーザーに対してのみ鍵の使用を許可したりできるのも面白いですね。

（以下、参考までに、記事を読んだ時のメモです。）

復号するユーザーは、暗号文を「乱数化標本器」を使って「撹乱」処理を行ってからクラウドに送る。この撹乱済み暗号文を「身代り」と言う。このデータは漏えいしてもOK。

クラウド側では「身代り」に対し復号化（この時点で撹乱を解除しているか、身代わりをそのまま復号化しているかは不明）して、「復号された身代り」をユーザーに返す。その後、ユーザーは、復号済みデータを「乱数化標本器」を使って復元し平分を得る。あと、このほかにも改ざん検知用のしくみもある。

つまり、クラウド<->ユーザー間ネットワークには「身代り」と「復号化した身代り」しか流れずに済むのがポイント。気になるのは「乱数化標本器」と復号処理。クラウド側で撹乱の解除を行ってから復号する場合は、クラウド側とユーザー側で何らかの共通知識が必要になりそうだし、そうでない場合は撹乱がある場合でも復号できるアルゴリズムが必要になる。面白いですねぇ。

もしかしてPMBOKって役に立つのでは？

ここ最近は、PMBOKを読んでいます。いわゆる、「プロジェクトマネジメント知識体系ガイド」と言うやつです。ちょっと前に認定試験のPMPが流行りましたね。

まぁ、そういう仕事もやらざるを得なくなってきたという感じで、必要に迫られて渋々と言った方が適切なのかもしれませんが、実際に読んでみると意外と関心させられることも多く、いつもの「もっと早くやっておけばよかった」のパターンになりつつあります。

（まだ、途中ですが）読んだ後に私が関わった案件思い返してみると、納期、機能、品質、コスト等の細い成功条件を全て満たしているのは1つくらいしかなさそうです。そして、失敗の原因はプロジェクトマネジメントの不備に起因するものが大部分を占めているような気がします。

極端な例かもしれませんが、私が下っ端として参加したあるプロジェクトでは、WBSなし、スコープ定義なし、スケジュールは随時可変、権限と責任も曖昧な状況で、もはやプロジェクトと言うよりは、それに類似した何か（お手伝いとか？）のようなものもありました。

もちろんこの案件は、最終的に顧客側が「いつまでに、何ができるのかが分からん！お前のところには頼まん！！」ってブチ切れて訴訟沙汰になったりして、それはそれは悲惨な結末を迎えました。当然ですね。

まぁ、とりあえずIT技術者でPMっぽい事をしている人には、PMBOKは必読だと感じました。PMには経験や人格も求められますが、知識もそれらと同じぐらい重要だなと思います。

ちなみに、PMBOKですが日本語版はオンラインでしか買えなかったりするのですが、ひそかに八重洲ブックセンターに大量に在庫されていたりします。ちなみに、相当デカイので注意してください。私は即効で自炊しました。