要約

  • 11月2日付のdraft-ietf-rpp-core-01は、IETF作業部会が検討するRESTful Provisioning Protocolに転送規則を追加した。現段階ではRFCではなくInternet-Draftだ。
  • サーバーが使える転送応答はHTTP 307と308だけで、転送先には絶対HTTPS URLを示す。クライアントが従う場合、本文とヘッダー、RPP-Cltridを保つ。
  • 転送先が別のオリジンなら、既存の認証ヘッダーをそのまま送れない。既知の別名か、転送先で有効な別の認証情報が必要になる。

案内板に鍵の受領権はない

レジストリの接続先変更は、普通なら設備更新の話で終わる。だが、レジストラの端末が持っているのは、ドメインの作成や変更につながる要求だ。行き先を示すサーバーが、その要求に付随する認証情報の受取人まで決めてよいのか。RPPの新版は、そこを曖昧にしなかった。

まず移動そのものを絞る。サーバーは307または308だけを使い、Locationには絶対HTTPS URLを入れる。両コードならHTTPメソッドは保たれる。クライアントは転送に従ってもよいが、本文とヘッダーを同じまま送り直し、取引識別子RPP-Cltridも維持しなければならない。途中の機器が返したものを含め、その他の転送コードはプロトコルエラーとなる。

認証情報には別の境界がある。オリジンが変わると、AuthorizationとRPP-Authorizationは原則送信禁止だ。クライアントが新しいオリジンを元の別名と知っている場合か、新しい相手に有効な認証情報を持ち、それを使う場合に限って道が開く。転送先の提示だけでは、秘密を受け取る資格は生まれない。

さらに新版は、要求を送る前にTLS証明書の信頼できる連鎖と、URLのホスト名との一致を確認するよう求める。失敗すれば送信しない。サービスの場所を見つけること、応答する機械を確かめること、認証情報を託すことは、それぞれ別の判断だ。

この文書は作業部会の草案で、実運用や事故の記録は示していない。今回の具体的な動きは、接続先を変える権限と、レジストラの秘密を渡す権限をプロトコル上で切り離した点にある。

一次資料