Gather implementations for HTTP Signatures spec for IETF standardization push #1
Comments
|
FWIW, some of the test vectors at the bottom of draft -06 are incorrect. I had to fix them up in the copy of the write-up that's in the Javascript impl repository (and added automated checks to make sure they still work): TritonDataCenter/node-http-signature@0ebeaf2 I believe this impl is updated to the -06 changes at the moment, though I should probably go back through and double-check it all. It might also be worth looking at updating the list of signature algorithms, before pushing the spec forwards further -- I've also been planning to add support for Ed25519 to my impl once the CURDLE IETF group have the pkix spec for that algo published. |
|
@arekinath Ok, thanks for letting me know about the issues wrt. the test vectors. Those will definitely have to be fixed. I thought @davidlehn fixed that a while ago. I haven't heard back from many of the other implementers yet, and until I do, the work will be dead in the water until we get enough people that have done implementations to say that they'll update their implementations to match the spec. |
|
As far as I know, the Perl implementation is compliant with the specification you linked. |
|
https://github.com/kislyuk/requests-http-signature is compliant with https://tools.ietf.org/html/draft-cavage-http-signatures-07. Looking forward to getting the RFC finalized! |
|
ahknight/httpsig is now up to date with draft 9, including the new test cases. |
|
Does anyone support the trailer variant yet? https://web-payments.org/specs/source/http-signature-trailers/ (and/or an http/2 header frame, which was spec'd after that draft, I believe). Trailers seem particularly crucial for proxies, cdns, streaming, etc. Not sure why the draft expired. |
None that I know of...
I think BBC's implementation is purely HTTP/2? /cc @LPardue |
|
We have used only signature in Google QUIC and aim to migrate to IETF-QUIC. In our usage we control sender (server) and receiver (client). Google QUIC uses HTTP/2 framing. IETF QUIC uses its own HTTP framing that is very similar. For our purposes, there is no difference if the Signature appears in leading headers or trailing headers. There were issues where our multicast HTTP/QUIC draft incorrectly allowed trailers in the wrong context. Our use case is a bit unique. Trailers may cause issues for intermediaries if they were to try testing signatures themselves. |
|
as far as I can tell, Pleroma is complaint with revision 10. I will update the URL to the latest draft... |
|
@Nerddan wrote: Awesome, thank you, added to the top of this issue. |
|
@Nerddan ... added those last two... wow, lots of implementations in Javaland. :) |
|
We wrote a PHP implementation too: https://github.com/CopernicaMarketingSoftware/http-signatures-php |
|
@EmielBruijntjes wrote:
Thanks, added you to the list above! |
|
There is now a test suite for the latest version of the spec: https://github.com/w3c-dvcg/http-signatures-test-suite Please test your implementations against that. We'll be compiling a list of conforming implementations over the next couple of months. |
|
https://github.com/spacemonkeygo/httpsig has been around since Feb 2017. I'll run it a against the test suite though when I get a chance. There is an open PR to add ECDSA signature support for v12. |
|
Maybe a bit late, but: |
|
@azdagron wrote:
Added to the list above. Thank you, @azdagron! @DavidLievrouw wrote:
Not late at all, the party is still going. The spec is getting picked up by the IETF HTTP WG, so expect global standardization to happen in the next year or two. Thanks @DavidLievrouw! |
|
Maybe a little late too, but https://github.com/equalitie/ouinet partially implements HTTP Signatures (-12) in C++ to sign, cache, and later on share and verify responses. Also we added a We didn't check against the test suite either and the code would need some effort to be splitted out of the rest of the repo code, but it can be used as a start. 😄 |
|
A Python implementation from me https://github.com/michalc/python-http-signature-client |
|
And now a server-side Python implementation from me https://github.com/michalc/python-http-signature-server |
|
A Python/Django implementation: https://github.com/backupbrain/drf-keypair-permissions/ NodeJS (crypto) and browser (crypto.subtle) implementations: https://github.com/backupbrain/client-http-keypair-authorization-headers/ |
|
HTTP Signatures is now an official IETF RFC: https://www.rfc-editor.org/rfc/rfc9421.html Please start updating all of your implementations to align with RFC 9421; there are quite a number of important changes in there that need to be implemented. /cc @jricher |
Hi all, My name is Manu and I'm the editor of the "Signing HTTP Signatures" (aka HTTP Signatures) spec at IETF. I just got back from IETF 98 in Chicago and there is interest in pushing this spec onto the Internet Standards track. We are getting ready to do the final push to make the HTTP Signatures spec an official IETF RFC. I have the go-ahead to try to put it into the IETF HTTP2 Working Group. In order to do this, we have to demonstrate implementation and deployment uptake, which I think we have plenty of. Here's what I have so far:
Javascript (@arekinath, @davidlehn, @mcavage): https://github.com/joyent/node-http-signature
Ruby (@pda, @Gargron): https://github.com/99designs/http-signatures-ruby and https://github.com/tootsuite/mastodon (1 million users, 2000+ servers)
Java (@adamcin, @mbarbero, @tomitribe, @joyent): https://github.com/adamcin/httpsig-java, https://github.com/mbarbero/http-messages-signing, https://github.com/tomitribe/http-signatures-java, and https://github.com/joyent/java-http-signature
Python (@davidlehn, @ahknight, @kislyuk, @michalc, @backupbrain): https://github.com/ahknight/httpsig https://github.com/kislyuk/requests-http-signature https://github.com/michalc/python-http-signature-client https://github.com/michalc/python-http-signature-server https://github.com/backupbrain/drf-keypair-permissions/ https://github.com/backupbrain/client-http-keypair-authorization-headers/
PHP (@liamdennehy, @navitronic, @pda, @zotlabs, @EmielBruijntjes): https://github.com/liamdennehy/http-signatures-php/ https://github.com/99designs/http-signatures-php https://github.com/CopernicaMarketingSoftware/http-signatures-php https://github.com/redmatrix/hubzilla/blob/master/Zotlabs/Web/
C# (@karlbohlmark @puckipedia @DavidLievrouw): https://github.com/karlbohlmark/http-signatures-csharp https://github.com/puckipedia/Kroeg/blob/master/Kroeg.Services/ https://github.com/DavidLievrouw/HttpMessageSigning
Go (@vektah @cjslep @ductm54 @azdagron): https://github.com/99designs/httpsignatures-go https://github.com/go-fed/httpsig https://github.com/gin-contrib/httpsign https://github.com/spacemonkeygo/httpsig
Perl (@mrallen1): https://github.com/mrallen1/Authen-HTTP-Signature
BBC HTTP/2 Multicast QUIC Sender/Receiver (@LPardue) - https://datatracker.ietf.org/doc/draft-pardue-quic-http-mcast/ (partial conforming)
C (@dstein90): closed source implementation (nginx module)
C++ (@ivilata): https://github.com/equalitie/ouinet
Elixir (@kaniini): https://git.pleroma.social/pleroma/pleroma/blob/develop/lib/pleroma/
Extension Specifications -PSD2 compliant Access to Account Interface (used by many European Banks) https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf
The specification is now an RFC (please implement to the RFC):
https://www.rfc-editor.org/rfc/rfc9421.html
The text was updated successfully, but these errors were encountered: