Open snarfed opened 1 year ago
Merging #472 in here. From that issue:
Looks like https://mostr.pub/ is currently sending us hs2019 sigs, which we don't yet support. Example, with added newlines for readability:
Signature:
keyId="https://mostr.pub/users/82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2#main-key",
algorithm="hs2019",
headers="(request-target) date host digest",
signature="QKlTxp2ax7u5crANhXF5n9dK2sN/5Y2ZpD/FIIai2POoxCXY1x+Ca8WUAa15UbHkX3hXEzz2t0drbGnVlQfQxisKn/ViNRpJ0WMVAFTO+XH8rGpMoRoorxDSzoMcV/TFkjZ387d30gbC/ddPck4WPZyfeRZilEKXQ1gi437Xg4A="
Related:
Checking these libs for hs2019 support. Looks like https://codeberg.org/socialhome/python-httpsig-socialhome.git has it.
Nothing in pyauth-http-signatures: https://github.com/pyauth/http-message-signatures/search?q=hs2019&type=
Am I even understanding this right? https://arewehs2019yet.vpzom.click/ makes it sound like hs2019 isn't a cipher/algorithm at all, but a directive that passes through to rsa-sha256 or 512 or something.
Aha. From https://github.com/TritonDataCenter/node-http-signature/issues/106 :
In the newest version of the specification draft (https://tools.ietf.org/html/draft-cavage-http-signatures-12) it is recommended to hide the algorithm from the signature by using hs2019. In fact in appendix E.2. it states that every other algorithm is deprecated.
...but that version of the spec is superceded by https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-16, which doesn't mention hs2019 at all 🤷
conclusion seems to be that the fediverse is still generally on cavage v12 at most, and hasn't migrated to httpbis yet.
sounds like hs2019 technically moves algorithm into either key metadata or sec:signingAlgorithm LD context, but I haven't seen examples of either of those in the wild yet. in practice people often seem to be just assuming rsa-sha256.
I hacked this in 842f8ac96402d89a6adb66c9667c2121fbb721c7 and ba38d6853b752d60df42487dadd924842f805061 by hard coding hs2019 to rsa-sha256. 😎
This is very confusing! Thank you for documenting it!
We currently use https://github.com/ahknight/httpsig, but it's been unmaintained since 2018. We're already on our own fork, https://github.com/snarfed/httpsig, to get https://github.com/ahknight/httpsig/pull/26.
Looks like https://dev.funkwhale.audio/funkwhale/requests-http-message-signatures is more recently maintained. Or if not, maybe https://github.com/pyauth/http-message-signatures, but less likely.