Use case: non repudiation

I wish signed exchanges to cover the non-repudiation use-case

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

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

Questions from #88

About https://github.com/WICG/webpackage/pull/88#discussion_r152628889

• agree JWS security issues though not everybody agrees on deprecating JOSE see those tweets on jose vs paseto

• support for different curves and rsa is useful: is CSP-style eg key=ed25519-base64 that dangerous, considering that we should somewhat converge in some way? Clearly RSA would be insanely longer

• about algos, in your opinion will ed25519 replace all the other algos in the near future so that we should "hardcode" its name? Should we "deprecate" RSA signatures?

No implementation files or tests are named. Begin by reviewing the current signed-exchange Signature and Digest design, then read the referenced issue #88 discussion and Berlin Group example; done would require an agreed design for request/response hashes, signatures, identity metadata, certificates, and supported algorithms.