要約

  • RFC 3923はCPIMメッセージをS/MIMEで保護し、XMPPの要素で運んだ。この要素の名前空間自体はメッセージの意味を定めない。
  • XMPP-CPIMゲートウェイはサービス側の包みを外したり付けたりできるが、保護されたオブジェクトを変更してはならない。

ゲートウェイに許された変更

異なるプロトコルを使うメッセージングサービス同士をつなぐのがゲートウェイだ。しかし中継者がメッセージを変換するなら、どこまで変更しても信頼境界の内側にとどまれるのか。2004年10月にIETF標準として公開されたRFC 3923は、信頼の単位を意図的に小さく切り分けた。XMPP-CPIMゲートウェイは一方のサービスの包みを外し、他方の包みを付けられる。だが、内側の署名済みまたは暗号化済みS/MIMEオブジェクトは変更できない。

この区別により、両サービスのプロトコルを理解する中継者がいても、少なくともプロトコル境界ではエンドツーエンド保護を維持できる。ゲートウェイは暗号処理の終端ではない。保護されたオブジェクトを不透明なペイロードとして運ぶ。相互接続の仕事と、内容に署名し、暗号化し、解釈する仕事とを別々にした設計である。

XMPPスタンザに入る保護オブジェクト

送信側はまずMessage/CPIMオブジェクトを作る。ヘッダーと本文の双方を含み、RFC 3923は両方をS/MIME署名または暗号化の対象とする。その結果はXMLのCDATA区間に置かれ、XMPPのmessageまたはpresenceスタンザ内の<e2e/>子要素に収められる。用途によってはPIDFプレゼンス文書やXMPP XMLオブジェクトを包むこともできる。

<e2e/>は運び手であって、内容の解釈者ではない。RFC 3923によれば、この名前空間に固有の意味はない。中に入るオブジェクトの意味はCPIM、PIDF、XMPPそれぞれの仕様が定義する。したがって、中継者は外側のXMPPスタンザを解析できても、保護された内容まで理解する必要はない。

ゲートウェイの規則はこの分担から導かれる。XMPPから外へ送るときは、<e2e>タグを含むXMPPの包みを取り除き、multipart S/MIMEオブジェクトを取り出して経路に載せる。必要なら宛先側サービスの包みを加える。逆方向では非XMPP側の包みを外し、同じオブジェクトをXMPPの包みに入れてスタンザを送る。RFCは、包まれたS/MIMEオブジェクトが不変であり、ゲートウェイが変更してはならないと明記している。

完全な安全機構ではなく、ひとつの境界

不変性は強いプロトコル要件だが、実際のゲートウェイが守ったことの証明にはならない。包みが周辺の事実すべてを信頼可能にするわけでもない。受信者は証明書を入手して検証し、署名が送信者について何を示すのかを判断する必要がある。RFC 3923は証明書の登録方法を範囲外とし、受信エージェントには証明書を取得する仕組みを求めた。つまり保証するのは、特定の相互接続経路で保護オブジェクトを維持することまでであり、本人性、鍵配布、ユーザー画面の問題まで解決するものではない。

実運用上の取引条件も明らかだ。不透明な中継なら、書き換えてはならない内容を運べる一方、変換や検査の余地は小さくなる。変換が必要なサービスでは、その処理地点と署名への影響が重大になる。署名対象の変更は中立な翻訳ではない。設計は、その判断を通信の両端に残す。

10年後のRFC 7165は、S/MIME方式が広く普及していないと述べ、鍵管理の難しさとS/MIMEオブジェクトの処理の難しさを要因の一部に挙げた。これは2014年の標準文書に記された歴史的観察で、現在の利用状況の調査でも唯一の原因説明でもない。それでも、境界を明確にして暗号上の意味を守れても、製品化と鍵管理は難しいまま、という教訓を補強する。RFC 3923の意義はゲートウェイを信頼できる存在にしたことではない。相互運用のために、両端が保護した内容まで書き換える必要はないと示したことにある。

出典