About RFC 9421

[tamaina]

RFC 9421 - HTTP Message Signatures

概要

https://datatracker.ietf.org/doc/html/rfc9421

• 2024-02-14発行
• ActuvityPubで使われているHTTP Signatureの正式版だが、それとは互換性がないらしい (nullkal 1),(nullkal 2)
  • （実装に関わってないので私はいつのドラフトを使ってるのか知らない）
• node.jsの実装は見つからなかった

Related to #11129

Misskeyで対応する？

• 他のソフトの対応
  • Mastodon: Issue, Discussionにはなかった
  • Pleroma: Issueは見つからなかった
• ドラフトとの二重実装ができれば互換性を持たせられる (できるのか調べてない)
• そもそも採用するのか？
  • RFCに則った方が後発実装もやりやすいのでそうするべきではある

[tamaina]

でRFCだとこうなるのか

https://datatracker.ietf.org/doc/html/rfc9421#name-multiple-signatures

[mei23]

3.2. Verifying a Signature
→ 3.2.6 Determine the algorithm to apply for verification:
検証アルゴリズムの判定or拒否方法が具体的になっている
わけわからんhs2019消えた🎉

[tamaina]

（hs2019ってed25519のことを言っているのか）

[mei23]

（hs2019ってed25519のことを言っているのか）

ほぼ違うわ。

hs2019は、どんな鍵アルゴリズムでも署名アルゴリズムでもあり得るはず。

鍵の署名アルゴリズムは、実際のメッセージで指定されてきたアルゴリズム (これは時にsha1等脆弱なアルゴリズムを指定して攻撃されるかもしれない) は信用してはいけなくて、ユーザーが実際に公開鍵と一緒に指定された署名アルゴリズムを信用するべきという考えから、hs2019というもので実際の鍵を見て鍵アルゴリズムと署名アルゴリズムを判定するべきというものから生まれたのだと思ってるのだわ。

ただ、鍵アルゴリズムは実際の公開鍵から判定できても、使用するべき署名アルゴリズムはユーザーが (例えば鍵と一緒に) 明示的に公開しない限りわかるわけなくて、現状はその仕組はなくてerrata的な感じになってたと思うのだわ。(EdDSA鍵は署名アルゴリズム固定だからわかるけど)

なんか結局詰むから消えて判定ロジックを具体的に書くようになったのだと思ってるのだわ。

[mei23]

あまり検証してないメモだわ

鍵部分に関しては、現状のなんでもrsa-sha256に加えて、ed25519 (解釈時alt: ed25519-sha512) が使えるようになればいいかな感
ECDSAはややこしいので今更いいかな感

検証
alg=rsa-sha256 => デファクト 文字通り rsa-sha256 として解釈する、今はできてる
alg=hs2019 => 消えたが最終的にrsa-sha256としてフォールバック出来ればOK、今はできてる
alg=ed25519 => ed25519 with sha512 として解釈する、今はできてるかな？わからない
alg=ed25519-sha512 => 文字通り ed25519 with sha512 として解釈する、今はできてるはず

鍵公開/対応鍵の明示
rsa-sha256 + 追加でed25519でいいかな (追加分はNodeinfoなどで明示するなど)

署名
rsa-sha256 => デファクト
ed25519 => 相手が解釈できそうなら使う (例えば上のNodeinfoで拾う)

[tamaina]

alg=ed25519 => ed25519 with sha512 として解釈する、今はできてるかな？わからない

https://github.com/Chocobozzz/node-http-signature/blob/eaba61699775ad0d30be612d0661e0b240c46992/lib/utils.js#L52

できてそう

[mei23]

いや動かない、見るのは実際の鍵タイプじゃなくてalg[0]の方

[tamaina]

ほんまや（全然違う

[mei23]

現状のhttp-signatureのverify実装だとed25519-sha512で送るしかないけど、ed25519の署名はsha512固定なので (crypto.signでもverifyでもアルゴリズムを明示するとコケる、というかOpenSSLでコケる) のでハッシュアルゴリズムが付いてるのはなんかキモいのだわ。

RFCでも ed25519
https://datatracker.ietf.org/doc/html/rfc9421#name-eddsa-using-curve-edwards25

http-signatureのverify実装を直す手もあるけど、この実装のed25519の検証めちゃくちゃ遅いので結局使えない感だわ。
Node.crypto使用のverifyロジックはあるけど https://github.com/mei23/crytest/blob/2a01148781485fd6eae8d812e087a29cb28e5f38/src/http-signature.ts#L38 ヘッダとSignatureのパーサーをどっかから持ってこないといけないわね。

[mei23]

ヘッダとSignatureのパーサーをどっかから持ってこないといけないわね。

http-signatureから拝借でいいかも

[mei23]

そもそもフォーマットとかは概要の通り互換ないから無理そうだけどだわ

RFC
https://datatracker.ietf.org/doc/html/rfc9421
was https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/19/

現状APで使われてそうな系統 (RFCにならなかったやつのドラフト)
https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12

※Misskeyの実装
https://github.com/TritonDataCenter/node-http-signature/blob/master/http_signing.md + 改修

[mei23]

MastodonのIssueは、draft-ietf-httpbis-message-signatures ドラフトの 03 のタイミングで出たこれかしら
mastodon/mastodon#21429

[mei23]

ドラフトとの二重実装ができれば互換性を持たせられる (できるのか調べてない)

二重実装の可能性調べるのややこしそうだから、もうnodeinfoにrfc9421フラグでも作ってあったらそことは新実装で連合しちゃうとか…
誰が実装するかは知らないけどだわ

[tamaina]

できそうではある

[tamaina]

嘘、無理

Signatureヘッダが同じ名前なのに全然別物だった