Use case: non repudiation

[ioggstream]

I wish

I wish to use the Signature header for non repudiation.

Example:

• client sends a request with a Signature of given headers and payload
• server replies with a Signature that may contain e.g. the request hash

Non repudiation

See nist 800-32 and nist glossary

Assurance that:

• the sender is provided with proof of delivery
• and that the recipient is provided with proof of the sender's identity

so that neither can later deny having processed the data.

Technical non repudiation refers to the assurance a Relying Party has that if a public key is used to validate a digital signature, that signature had to have been made by the corresponding private signature key.

Legal non-repudiation refers to how well possession or control of the private signature key can be established.

Elements for non repudiation

Non repudiation via PKI is usually achieved adding

1- in a request

• an hash of the request representation
• a signature of the above hash and further elements, eg: issuer, audience, subject, issued_at, not_before, expires, similar to JWS claims
• sender informations

2- in a response

• an hash of the response representation
• a signature of the above hash and further elements, including an hash of the original request
• original request informations (eg. the hash) may be added in the response representation

Further informations may include:

• URL or content of the certificate to be used for validating the signature

Signature and Non Repudiation

There are various similarities b/w the informations contained in this spec and Non Repudiation.

• Digest can be used to guarantee the integrity of the representation (eg. with other values of Content-Encoding)
• Signature covers a list of Signed-Headers which may cover all necessary headers

References

An example of non-repudiation via HTTP Headers is defined in:

• Berlin Group Financial API §11 based on https://tools.ietf.org/html/draft-cavage-http-signatures-10

Notes

Related to WICG/webpackage#248

[martinthomson]

I think that you will find that most digital signature algorithms do not provide non-repudiation. It's a common myth.

A recent example of this myth biting us is in ACME, where the duplicate signature key selection attack was quite serious.

[ioggstream]

I agree that a signature is "just a number" and it is responsibility of the parties to establish a suitable context when using digital signatures (algorithms, constraints, interactions, ..).

Nonetheless current frameworks rely on digital signatures as a building block for non repudiation and
the design of Signatures should try to support this use case - with all the caveats.

[jricher]

@ioggstream I believe the @request-response derived component should fit this use case, could you please read through how it works and see if that fits your goals? In summary this component allows a server to sign a specific signature sent in the request, without replicating that signature's contents in the response. The server can also sign other parts of the response as usual.

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-07.html#name-request-response-signature-

[martinthomson]

Perhaps this paper would be useful input: https://dennis-jackson.uk/assets/pdfs/signatures.pdf Pay attention to the list right at the start of the introduction.

[ioggstream]

@jricher I'll tacke this during this week :) Thanks for reaching out!

[jricher]

I believe this use case is fully covered by current technology, but does not warrant a specific callout in the text.

Suggest we close without action.

[ioggstream]

@jricher I close it now and will reopen if needed. Thanks