WS-Securityが安全に見えない
http://slashdot.jp/security/06/09/27/1056238.shtml
SHA-1は例によってコリジョンが発見されているので、（直ちにヤバいというほどではないけれども）もはや安全とは言えないわけで、とりあえずSHA-2などを使っておけ、と言われているわけです。もっとも、うちのSebastienはSHA-2がSHA-1の問題を引きずっていないかどうかは分からない、と懸念を表明していましたが…。その後どう収束したかは、僕の知識の及ぶところではありません。
ところでWS-Security関連仕様に目を向けてみると、けっこう安全性に問題があります。
XML EncryptionではSHA-1がREQUIREDである一方、SHA-256 (SHA-2)はRECOMMENDEDであり、.NETのEncryptedXmlを含む多くの実装において、デフォルトがSHA1であろうことは想像に難くありません。
XML Signatureは基本的にSHA-1を使っています*1。もちろん、XML EncryptionでもXML Signatureでも、標準でないURIをハッシュアルゴリズムとして指定することは可能ですが、互換性は損なわれます（標準技術を使う意味なし）。
WS-SecureConversationで使われているDerivedKeyTokenなんか、RFC 2246 (SSL)の仕様では選択的になっているP_hash関数のうちの「P_SHA1を使う」と決め打ちになっていて、他の選択肢はありません。
将来のバージョンではSHA-2などを扱うことになるのかもしれませんが、これらが標準化に値するマジョリティを獲得して、標準化に組み込まれ、実装されるまでは、長い道のりかもしれません。
ちなみに、XML Encryptionで使用されるISO-10126パディングは、最終バイトはブロック長のキーサイズでの剰余バイト数（ (BlockLength + 1) % (KeySize / 8))とかなっているので、キーサイズの理論最大値は2047ビット*2だったりします。BlockLength % n が256以上になったら、1バイトに収まらないのです。全く同じ問題がPKCS7、ANSI X 923についても言えます。まあこれを心配するのはもう少し先でも良いかもしれませんが。
こういうのを見ていると、標準化技術というものは、時代の流れに影響されてしまうような部分については、独自のプロセスをもって設計された方が良いのだろうなあと思わざるを得ません。法律と政令のように、時代の流れにほとんど影響を受けないような部分については厳密な制定過程を経て、そうでないものについては比較的迅速に、それぞれ標準化できる必要があるのではないかなと思います。
最後にひとつ悲観的な予言をしましょう。今後、XML SignatureやXML Encryptionの安全性が議論されるようになってきたら、これらの標準化仕様の改訂版が出されることになるでしょう。その際、本来であれば安全性にかかる部分のみを改訂すれば良いはずなのに、余計な邪心をもって仕様の拡張や変更を主張しようとする集団が出てくるだろうと思います。
