Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix: #75. Reference representation data, not message body. #76

Open
wants to merge 2 commits into
base: gh-pages
Choose a base branch
from
Open

Fix: #75. Reference representation data, not message body. #76

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
48dfa52
Fix: #75. Reference representation data, not message body.
ioggstream Jun 12, 2019
c3cd1f0
fix typo
ioggstream Oct 14, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions index.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -197,8 +197,8 @@ alter headers for operational reasons, so a sender cannot rely on the
recipient receiving exactly the message transmitted.
By allowing a sender to sign specified headers, and recipient or
intermediate system can confirm that the original intent of the sender
is preserved, and including a Digest header can also verify the message
body is not modified. This allows any recipient to easily confirm both
is preserved, and including a Digest header can also verify that the representation data
is not modified. This allows any recipient to easily confirm both
the sender's identity, and any incidental or malicious changes that alter
the content or meaning of the message.
</t>
Expand Down Expand Up @@ -575,7 +575,7 @@ Note that the use of the `Digest` header field is per
<xref target="RFC3230">RFC 3230</xref>, <eref
target="https://tools.ietf.org/html/rfc3230#section-4.3.2">Section 4.3.2</eref>
and is included merely as a demonstration of how an implementer could include
information about the body of the message in the signature.
information about the representation of the resource in the signature.
The following sections also assume that the "rsa-key-1" keyId asserted by the
client is an identifier meaningful to the server.
</t>
Expand Down Expand Up @@ -685,7 +685,10 @@ content-length: 18
The "Signature" HTTP Header provides a mechanism to link the headers of a
message (client request or server response) to a digital signature. By
including the "Digest" header with a properly formatted digest,
the message body can also be linked to the signature. The
the representation data defined in
<xref target="RFC7230">RFC 7231</xref>, <eref
target="https://tools.ietf.org/html/rfc7231#section-3.2">Section 3.2</eref>
can also be linked to the signature. The
signature is generated and verified either using a shared secret (e.g. HMAC)
or public/private keys (e.g. RSA, EC). This allows the receiver and/or any
intermediate system to immediately or later verify the integrity of the
Expand Down Expand Up @@ -996,7 +999,7 @@ Authorization: Signature keyId="Test",algorithm="rsa-sha256",

<section anchor="all-headers-test" title="All Headers Test">
<t>
A strong signature including all of the headers and a digest of the body of
A strong signature including all of the headers and a digest of the representation data of
the HTTP request would result in the following signing string:
<figure>
<artwork>
Expand Down