2011年9月、IETFのSecurity Areaに新しいワーキンググループ（以下WG）が設置された。JOSE（Javascript Object Signing and Encryption）というWGであり、JSON（Javascriptオブジェクト記法）[1]で運ばれる構造化データ（例：JWT（JSON Webトークン））にディジタル署名を添えたり、その構造化データを暗号化したりする規格を策定する。このJOSEについて報告する前にWebオブジェクトツリーへのディジタル署名と暗号化に関するもうひとつの代表的な仕様であるXML署名と暗号化の仕様についてもふり返る。

　今日、インターネット上でツリー構造を備えるデータを交換する仕様には、下図のように複数のものがある。

図1：各種データ構造表記仕様の成立

　最初に定められたASN.1（Abstract Syntax Notation One）[2]の用例として、PKI（Public Key Infrastructure）の分野で用いられるX.509ディジタル証明書が挙げられる。X.509ディジタル証明書はツリー構造をもつデータであり、ASN.1によって表記されたデータに対してディジタル署名が付される。
　今日、ASN.1 [2]によって表記される他の代表的なディジタル署名に関する規格としてCMS（Cryptographic Message Syntax）[3]が挙げられる。これはIETFのS/MIME WGにおいて策定され、S/MIMEメールの仕様等に使われている。S/MIME WGは2010年10月に解散したが、CMSに関するRFCは、その成果物として今年まで発行され続けた。
　XML（eXensible Markup Language）は、周知のように汎用的なマークアップ言語であり、関連規格はW3C（World Wide Web Consortium）¹において策定されている。
　JSON（Javascriptオブジェクト記法）は、IETFにおいてRFC 4627 [1]として規定されている。IETFにおいて策定されるプロトコルでJSONを利用するものが台頭してきており、前期（2011年上期）にはWebsec WGについて報告した[4]。
　これらの規格はすべて現在も利用されているものであり、時代の変遷によって置き換えられてきたというわけではない。それぞれが適する用途に使われている。

(1) ASN.1との違い

　ASN.1 [2]による表記を扱うことは、今日の読者にとって、敷居が高いように思われるかもしれない。各種の記法（例：選択型（CHOICE）、順序列型（SEQUENCE）等）を駆使することによって柔軟なデータ構造を表現することができる一方、実際にはASN.1コンパイラが許容してくれる記法は限られる。また、外部データを参照する際には、あらかじめ登録しておくOID（オブジェクトID）を通じて参照する。たとえ、その外部データがURLによって参照可能な場合においても、OID経由で参照される。ASN.1によって表記されるデータについてディジタル署名や暗号化が行われる前には、DAR（Distinguished Encoding Rules）[2]エンコードによって正規化（Canonicalization）される。データの冗長性をなくしたり、混在している等価な表現をある統一形式に整形したりすることによって、データについて下ごしらえを施しておくのである。
　一方、XMLによる表記を扱うことについては、読者の抵抗感は少ないかもしれない。タグは「読み物」となるように柔軟に定義される。また、外部データを参照する際には、直接、URLを記入することができる。XMLデータについてディジタル署名や暗号化が行われる前にも、正規化（Canonicalization）するための規格が発行されている。

(2) 2000年以降の標準化

　2000年以降に行われてきたXMLデータへのディジタル署名と暗号化に関する規格についてふり返る。
　まず、ディジタル署名を付す規格についてはW3CとIETFの共同文書として策定された。

• RFC 3075，「XML 署名文法と処理（XML-Signature Syntax and Processing）」（初版：2001，2nd Edition：2008）
• RFC 2807，「XML 署名要件（XML Signature Requirements）」（2000）

　一方、一連の処理の中で暗号化する手続きに関する規格はW3C単独による文書として策定された。この5章の中で暗号アルゴリズムも指定されている。

• 「XML暗号化の文法と処理（XML Encryption Syntax and Processing」）（2002）²

　さらに公開鍵の有効性検証用の規格もW3Cの文書として策定された。

• 「XML鍵管理仕様（XKMS：XML Key Management Specification）2.0」（2005）³

(3) 今期報告されたXML関連の攻撃可能性

　XML署名と暗号化に関する攻撃法を分類した資料があるので、その一覧を示す。[5]

        1. C14N Denial of Service
        2. Transform Injection
        3. Hash Collision attack against SignedInfo with comments
        4. External Reference Attacks
        5. Reference Complexity
        6. Element Wrapping Attacks 
        7. Untrusted Keys

　今期、注目された脆弱性は「6. Element Wrapping Attacks」に関するものであった。

• Shibboleth Security Advisory:“OpenSAML software is vulnerable to XML Signature wrapping attacks”（2011-07-25）
• W3C,“Some notes on the recent XML Encryption attack”（2011-10-24）[6]

　後者は、2011年10月に開催された「CCS'11 conference」⁴において発表された研究論文[7]に対応してW3Cが表明したものである。
　XML暗号化の規格は、単にXMLデータ構造体を暗号化するものではなく、一連の手続きの中で条件を指定して指定する暗号アルゴリズムに処理を行わせるフレームワークを提供している。広く使われているアルゴリズムは、AES-CBC（AESアルゴリズムのCBCモード）である。この攻撃法は特定のアルゴリズムを選ばず、CBCモード全般についての「選択暗号文攻撃」であり、典型的なWebサービスサーバの実装が攻撃可能な対象となってしまう。
　この攻撃がXML暗号化の規格と実装に与える影響として、いくつかの対策の可能性が掲げられている。
　まず、規格に関しては、必須実装アルゴリズムを変更し、AES-GCM（AES アルゴリズムの Galois/Counter モード）を含むようにすることを検討している。XML暗号化の規格は、任意の暗号アルゴリズムで動作するように設計されているので、仕様に関する変更は少数に留まる見通しであるという。暗号アルゴリズムの交換可能性（algorithm agility）の確保は重要である。
　次に、実装については、下記の対策を施す可能性があるという。

1. 暗号化のみならずインテグリティをも保証するアルゴリズム（例：AES-GCM）を使えるようにすること
2. 暗号化されたメッセージのインテグリティを確保する他の手法を組み合わせて使う執筆時点ではまだ動作するAES-GCMは見あたらない。実装ライブラリが整備されることが期待される。

(1) XMLとの違い

　前期（2011年上期）の報告[3]においても述べたように、JSONを書くためには、XMLを書く際のようにタグを覚えることが不要なので簡単に書ける。

(2) 2011年のJOSE

　2011年9月、IETFのSecurity AreaにJOSE（Javascript Object Signing and Encryption）WGが設置された。当初、このWGの名称はWOES（Web Object Encryption and Signing）とすることが構想されていた⁵。
　また、このWGの作業は、当初、「JSONを使用するプロトコル間のセキュリティ機能の相互運用性を増加させるためにふたつのセキュリティーサービス、インテグリティ保護（ディジタル署名とMAC）および暗号化を標準化することである」とされていた。

• ディジタル署名に関する規格：
  JSONデータ構造を含むデータについて、インテグリティ保護を適用する方法を指定するスタンダードトラックの文書。このインテグリティ保護には、共通鍵MACと共に公開鍵ディジタル署名も含まれる。
• 暗号化に関する規格：
  JSONデータ構造を含む)データについて、暗号化を適用する方法を指定するスタンダードトラックの文書。

　その後、WGはJOSEに改名され、ふたつの案件が追加されて、標準化が行われている。

• 公開鍵のエンコードに関する規格：
  JSONを構造化したオブジェクトとして公開鍵をエンコードする方法を指定するスタンダードトラックの文書。
• 必須暗号アルゴリズムに関する規格：
  上記の3つの規格において実装することが必須のアルゴリズムを指定するスタンダードトラックの文書。

(3) JOSEの注目点

　XML暗号化の規格と見比べると、JSONには正規化（Canonicalization）に関する規格が見受けられない。筆者は、JSONにおいてもデータの冗長性をなくしたり、混在している等価な表現をある統一形式に整形したりする必要性がある（例： ハッシュテーブルの表現等）と考えるので、今後の標準化における議論に注目していきたい。

以上