You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
2.[Cavage](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures) and subsequent [RichAnna](https://datatracker.ietf.org/doc/html/draft-richanna-http-message-signatures)
16
+
1.[HTTP Working Group spec](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures)
17
+
2.[Network Working Group spec](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures)
14
18
15
19
## Approach
16
20
17
-
As the Cavage/RichAnna specification is now expired and superseded by the HTTPbis one, this library takes a
18
-
"HTTPbis-first" approach. This means that most support and maintenance will go into the HTTPbis
19
-
implementation and syntax. The syntax is then back-ported to the as much as possible.
21
+
As the Network WG specification is now expired and superseded by the HTTP WG one. This library takes a
22
+
"HTTP WG" approach. This means that most support and maintenance will go into the HTTP WG
23
+
implementation and syntax. The syntax is then back-ported to the legacy specification as much as possible.
20
24
21
25
## Caveats
22
26
23
-
The Cavage/RichAnna specifications have changed over time, introducing new features. The aim is to support
24
-
the [latest version of the specification](https://datatracker.ietf.org/doc/html/draft-richanna-http-message-signatures)
25
-
and not to try to support each version in isolation.
27
+
The specifications are in draft and are liable to change over time, introducing new features and removing existing ones.
28
+
The aim is to support the [latest version of the specification](https://datatracker.ietf.org/doc/html/draft-richanna-http-message-signatures)
29
+
and not to try to support each version in isolation. However, this library was last updated against
30
+
[revision 13](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-13) of the HTTP WG specification.
26
31
27
32
## Limitations in compliance with the specification
28
33
@@ -43,7 +48,7 @@ application and must be derived from a URL.
43
48
44
49
The [`@request-target`](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures#section-2.2.5)
45
50
component is intended to be the equivalent to the "request target portion of the request line".
46
-
See the specification for examples of what this means. In NodeJS, this line in requests is automatically
51
+
See the specification for examples of what this means. In Node.js, this line in requests is automatically
47
52
constructed for consumers, so it's not possible to know for certainty what this will be. For incoming
48
53
requests, it is possible to extract, but for simplicity’s sake this library does not process the raw
49
54
headers for the incoming request and, as such, cannot calculate this value with certainty. It is
@@ -61,51 +66,232 @@ message context for signatures that need to be reinterpreted based on other sign
61
66
### Padding attacks
62
67
63
68
As described in [section 7.5.7](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-13#section-7.5.7)
64
-
it is expected that the NodeJS application has taken steps to ensure that headers are valid and not
69
+
it is expected that the Node.js application has taken steps to ensure that headers are valid and not
65
70
"garbage". For this library to take on that obligation would be to widen the scope of the library to
66
71
a complete HTTP Message validator.
67
72
68
73
## Examples
69
74
70
-
### Signing a request
75
+
> NB: These examples show the "minimal" signature implementation. That is, they provider a proof of possession of the
76
+
key by the sender, but don't provide any integrity over the message. To do that, you must add HTTP fields / components
77
+
to the signing object. Please see the tests for further examples, or the type definitions.
78
+
79
+
### Signing a request (Node.js)
80
+
81
+
This library has built-in signers/verifiers for Node.js using the native `cryto` package to perform all the required
82
+
cryptographic operations. However, this is designed to be easily replaced with any other crypto library/runtime
83
+
including `SubtleCrypto` or even a hosted KMS (Key Management Service).
0 commit comments