10年以上経ってもあまり適用されていないデジタル署名が注目を集めている。複合的アプリケーション(モバイルの世界では集中型アプリケーションと呼れる)が出現しつつあるのが理由だ。複合的アプリケーションはアーキテクチャが相当複雑だ。所有者も、開発したチームも、リリースサイクルも、利用している技術も、拡張性も、可用性も、セキュリティモデルも異なるのサービスによって作られているからだ。
複合的アプリケーションの大きな問題のひとつに信頼性がある。共通のソリューションを提供するために協調して動いているすべてのサービス(これらのサービスは様々なソリューションに幅広く利用されている)はアイデンティティとアクセス権の観点からお互いを信頼する必要がある。このことを考慮すると、HTTPには重大な問題がある。それは認証の仕組みがリクエストハンドラによって検証されるシングルアイデンティティー(ひとりのユーザか単一のサーバ)を前提にしているからだ。HTTPのリクエスト(開発者Xによって作成されたシッククライアントやシンクライアントのアプリケーションを使っているユーザのリクエスト)の中にまとまっている複数のアイデンティティを確立するのは本当に難しい。近頃、この問題は世界中の開発者に信頼されたサービスを提供している大規模"独立系サービスベンダ"に共通して起こっている。どのようにすればHTTPがユーザ、そのクライアントデバイス、アプリケーション、そしてアプリケーション開発者の認証情報を伝達することができるのか。これが問題だ。
Bill Burke氏はデジタル署名をサポートするHTTPプロトコルの拡張と対応するRESTEasyのAPIを提案した。氏によれば、
OAuthはそのプロトコルの一部に署名を含んでいます。しかし、私が欲しかったのはクライアントやサーバが認証にOAuthを使わない、OAuthとは違う仕組みです。
この提案の目的と特徴は、
- ヘッダーの単純化 署名に関するすべての情報をHTTPリクエストとレスポンスのヘッダーに含めること。こうすることでフレームワークやクライアントやサーバ側のコードが署名を検証するのが簡単になる。
- 有効期限 署名の有効期限を設定したい。
- 署名者の情報 誰がメッセージに署名したのかわかるようにしたい。そうすることで受信者が内部に保持する検証キーを探すことができる。
- 署名を気にしたくないなら無視できるようにしたい。
- 複数のエンドポイント/受信者へメッセージを転送できるようにしたい。
- 複数の異なるURLで同じ署名がされたメッセージを発行したい。
- メッセージの完全性を保証するダイジェストプロトコルや既存のOAuthを置き換えるものではない。
デジタル署名を利用したプロトコルの大きな利点のひとつは身元の主張とメッセージを勝手に開封できない封筒で包むことができることだ。このふたつは通常同時に使われる。
氏はContent-Signature HTTPヘッダーについて下記のように具体的に提案している。
Content-Signature: type=redhat;
values=signer:expiration;
headers=Content-Type:Date;
signer=bill;
expiration="Sunday, 06-Nov-11 08:49:37 GMT";
signature=0f341265ffa32211333f6ab2d1
真の問題は如何にしてHTTPに組み込んだデジタル署名を適用するかではない。これは"メッセージエンベロープ"の問題だからだ。真の問題は"デジタル署名の利用を妨げてきた問題を業界がどうやって解決するのか"だ。特に互換性の問題だ。HTTPに認証の拡張と不正開封防止の仕組みが必要だろうか。どのような解決策があるだろう。