In the current version of the specification draft (https://tools.ietf.org/html/draft-cavage-http-signatures-12) the special headers (created) and (expires) are defined.

They should be supported in this library.

Try to validate signatures generated by httpsig, with other languages i.e.: https://github.com/joyent/node-http-signature.

It appears that httpsig does not add the Signature value at the beginning of the header. According to the Signing HTTP Messages draft-cavage-http-signatures-10

Draft example

 Authorization: Signature keyId="rsa-key-1",algorithm="rsa-sha256",
   headers="(request-target) host date digest content-length",
   signature="Base64(RSA-SHA256(signing string))"

Http sig

Authorization: keyId="pubKeyId",algorithm="rsa-sha512",headers="date digest",signature="Base64(RSA-SHA256(signing string))"

Make this package compatible with golang's proposed semantic versioning package manager.

Existing, deprecated header style:
Digest: SHA256=abc,SHA512=xyz

Newer, IETF HTTPBIS (RFC track) header style:
Content-Digest: SHA256=:abc:,SHA512=:xyz:

The difference is that the header key is changed, and the base64 values are enclosed with colons (per Structured Headers).

Would be nice if we could have an option to use the newer header style.

At the moment the only asymmetric encryption supported is RSA, we should also support ECDSA encryption.

This commit 221cfc4
hides the algo from the receiver.

I'm integrating against apis that don't expect this.
Are we open for making this behaviour configurable?

At the time of verification, we use the value of digest header(if required) for verifying signature.
This opens a gate to the attackers. Suppose someone was able to tamper with the request/response body without touching any of the headers, signature verification will still be OK because we are using the digest header sent for the verification purpose.

To prevent such attack , we should
Either,
i) recalculate the 'digest' to be used in signature verification.
Or,
ii)Compare the[ 'digest' header value] with the [re-calculated 'digest' from body] , if the signature calculation method for verification remains as is.

Maybe tag a v1.0.1 release?

Some clients require signing from an agent.

Hi, I'm @msporny, primary author of the HTTP Signatures specification at IETF for many years now. You've implemented some variation of that specification.

I need your help to move that specification towards a global standard at IETF. Hearing from implementers, such as you, is a big part of determining if the work toward a global standard should proceed. The IETF HTTP Working Group is determining whether the work should proceed right now. This is very good news, because the European Banking API community, W3C DID Working Group, W3C Credentials Community Group and other standards setting organizations depend on implementations standardizing on a way to do HTTP Signatures.

The deadline for noting your support is Jan 31st 2020 (in ~10 days).

Here's where you can make a difference...

Here is the IETF HTTP WG Call for Adoption:

https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0002.html

To note your support of the specification:

1. Go here and click "subscribe to this list": https://lists.w3.org/Archives/Public/ietf-http-wg/
2. Verify your subscription by checking your email and clicking on the link that is mailed to you.
3. Go here and click "respond to this message": https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0002.html
4. Write an email stating:
   4.1 That you support the adoption of the draft.
   4.2 Why you support the adoption of the draft.
   4.3 How you plan to make use the specification, either directly, or indirectly (via someone else's software).
5. Set up an email filter to put all mail sent to [email protected] into its own folder. The mailing list averages ~350 emails/month. You can also leave the mailing list immediately after sending the email above if that amount of email traffic is unacceptable to you.

For an example of the type of email you could write, see this:

https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0018.html

Thanks a ton for supporting the specification through your implementation. I hope you consider helping us take the specification across the goal line by voicing your support in the IETF HTTP Working Group!

Hi, I used this with a go modules project and by default it sets the version to v0.1.0, which seems to be old.
Would it be possible to bump the version to v0.1.1 or something?

motivation

I've been using a go project sending to another go project which worked great!

Now I need to send the request from a c++ client, anyone can recommend a library for this?

Description

Currently the (request-target) header is using URL; however it should according to the spec use the path

If the header field name is (request-target) then generate the header field value by concatenating the lowercased :method, an ASCII space, and the :path pseudo-headers (as specified in HTTP/2, Section 8.1.2.3 [7]). Note: For the avoidance of doubt, lowercasing only applies to the :method pseudo-header and not to the :path pseudo-header.

So currently:

(request-target): post http://example.com/foo

Should be:

(request-target): post foo

Hi,
I have not been able to figure out how to use this library, even from the code in the README.md. I also cannot find any examples on Github. Can you please provide a short example from start to finish?