Summary

  • Azat Davliatshinが11月2日に公表した報告は、草案本文から検証器を実装し、AAT -01とAsor -02の委任鎖を形式的に比較した。両草案の著者とは別の調査だ。
  • AAT -01では、親トークンが示す保持者の鍵で子トークンを署名する。報告が読むAsor -02では、検証器が承認した鍵で子を署名でき、親の保持者が署名に加わる必要はない。
  • 報告のモデルでは、承認済みの署名鍵を一つ奪われると、正当な親の下に子を追加できる。末端のDPoPが証明するのは提出者の鍵の所持であり、親保持者の承諾ではない。実運用の侵害報告ではない。

鎖が短くなるほど、署名者を見失いやすい

どちらの案も、根から子へ権限を広げない。子は親の内容に暗号学的に結び付き、有効期限と委任の深さに縛られる。末端で鍵の所持も示す。この共通点を並べるだけなら、違いは実装上の好みに見える。だが、子を成立させる署名は誰のものか。

Niki Aimable NiyikizaのAAT -01は、親が指定する鍵の保持者に答えを置く。I1の条件では、その鍵が次の輪を署名しなければならない。DavliatshinがAsor -02から実装した手順は別の場所を見る。検証器の設定で受け入れる鍵なら署名を検証でき、親の保持者が子の作成に参加したという条件は置かれていない。

報告はこの差を、鍵の侵害を仮定したモデルで試した。正当な親の保持者の鍵は無事でも、検証器が受け入れる別の署名鍵を攻撃者が持てば、Asorの読み方では親の下に子を作れる。攻撃者は子に自分の末端鍵を記し、その鍵でDPoPを通す。DPoPは最後に現れた者を確かめる。前の保持者が委任を認めたという記録にはならない。

Asor側のモデルだけを親保持者の署名方式に変えると、この差は消えた。原因を切り分けるための変更であり、Asor -02の規定そのものではない。報告が形式的に調べたのは -02だ。10月27日に出たAsor -03でも、各署名の検証にはローカル設定の鍵とアルゴリズムを使い、末端の保持者確認は別の段階に置かれる。新しい版の文章と古い版のモデル結果は混ぜて扱えない。

ここにあるのは規格化前の提案と研究用の検証器だ。実際のサービスの侵害例は示されていない。次の改訂で子の署名者を明記するかどうかが、委任権限の所在を決める。

公式原資料