18:26:52
icon

tesaguri/rsa-signature-2017-rs: [WIP] Rust implementation of `RsaSignature2017` cryptosuite of Linked Data Signatures spec
github.com/tesaguri/rsa-signat
はい(?)

Web site image
GitHub - tesaguri/rsa-signature-2017-rs: [WIP] Rust implementation of `RsaSignature2017` cryptosuite of Linked Data Signatures spec
18:29:52
icon

PoCを試みているときに良い感じのLD Signaturesの署名用のツールがないものかとざっと探したところめぼしいものが見当たらなかったので、なら自分で書くかと思って書き始めて途中で正気に戻って一旦放棄したやつです(?)

18:30:54
icon

そういう経緯なので検証機能はTODO

18:40:33
icon

まあ、Mastodonのドキュメント(<docs.joinmastodon.org/spec/sec>)にも書かれているとおり、Linked Data Signaturesというドラフト段階の仕様は必要がないなら実装するべきでないですよね(今言うことか?)

18:47:11
icon

古いドラフトの仕様が使われているという点についてはcavage-http-signaturesにも言えることだけど、Linked Data Signaturesは当時のドラフト(<github.com/w3c-ccg/ld-signatur>)のSecurity Considerations節が空っぽだったという点において微妙さのレベルが一段違うと思う

Web site image
ld-signatures/index.html at d0af56856684924156a94838f9482a27766bb2be ?? w3c-ccg/ld-signatures
18:57:27
icon

ところで`RsaSignature2017`の定義(というかより仕様中でsignature suiteの例として示されていただけの定義だけど……)としては`"digestAlgorithm": "registry.ietf.org/ietf-digest-" `としか指定されていたのに対してMastodonの実装ではCreate Verify Hash Algorithmにおける"the message digest algorithm"相当の処理で入力をSHA-256でハッシュしてから16進法表現にエンコードしている(<github.com/mastodon/mastodon/b>)のだけど、この16進法表現の根拠がいまいち分かっていない

Web site image
mastodon/app/lib/activitypub/linked_data_signature.rb at 1726085db5cd73dd30953da858f9887bcc90b958 ?? mastodon/mastodon
18:57:55
icon

もしかしたら<registry.ietf.org/ietf-digest->に何か書いてあったのかも知れないけど、リンクが切れている(というかregistry.ietf.orgとかいう強そうな名前のドメインでも落ちるものなのか……)

19:01:47
2024-05-02 18:56:33 Posting kphrx kPherox@pl.kpherox.dev
icon

FediverseがDDoSツールになるの、外部の最も修正すべきって意見はわかるけど理念的に最も修正困難な問題だし手のつけようがないのではって気持ちにもなる

19:01:49
2024-05-02 18:58:35 Posting kphrx kPherox@pl.kpherox.dev
icon

連合先を信用するなら連合先がDocumentかPageオブジェクトをLinkの代わりにつけて取得を回避とかになるかもしれないけど信用するもんじゃないだろうしなぁ

19:01:51
icon

そこでIPFS(?)