Use case: non repudiation

[ioggstream]

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?

[jyasskin]

The Signature header here is already somewhat useful for non-repudiation for the response, although I believe that non-repudiation has more to it than just a signature with a possibly-stolen private key.

Is there a reason to use the same header definition for both requests and responses? The semantics are noticeably different, especially in that a response has a matching request that (I think) needs to be included in the signature, but a request stands alone.

Do non-repudiable requests need to be done with an HTTP header, or should there be a signed blob in the request payload that conveys the real request?

key=ed25519-base64 would generally be fine. I currently have ed25519key in the parameters just to reduce the number of parsers we have to use. I'd expect to add new otheralgorithmkey parameters just as freely as we'd define new key= prefixes. RSA is forbidden in order to reduce the complexity of implementations and because there have been various attacks on multi-purpose RSA keys, which we side-step by banning RSA here. See the links from #181 for more discussion around this.

The difference between the existing Digest header and mice-02's MI header is just that MI allows the headers and payload to be checked and processed incrementally and with a fixed-size buffer, while Digest requires the recipient to receive and buffer the whole payload before checking or processing any of it. If MICE changes to specify the top-level hash in the Digest header, that'll still allow the fixed-size buffer.

[ioggstream]

... non-repudiation has more to it than just a signature with a possibly-stolen private key.

Can you share your non-repudiation requirements? iiuc if you lose your private key there's nothing you can do (other that demonstrate the iat|exp > revocation time). See "Legal non-repudiation" NIST definition above.

Is there a reason to use the same header definition for both requests and responses?

It is fair to use two different headers. My goal is a shared RFC for non-repudiable request/responses.

My basic idea was just to use signed claims containing:

• basic claims (iss, sub, ... )
• further claims that could be legislation-dependant (nbf, body_hash, request_id, correlation_id, ...)

The semantics are noticeably different, .. a response has a matching request that (I think) needs to be included in the signature, but a request stands alone.

See above claims body_hash, request_id, ... feedback welcome!

Do non-repudiable requests need to be done with an HTTP header, or should there be a signed blob in the request payload that conveys the real request?

I'd avoid encapsulation or json extension as this modifies the service interface. Eg.

• I want to implement a non-repudiation wrapper around google storage api
• using headers I just have to add/validate the signature header with limited changes to the google api interface

key=ed25519-base64 would generally be fine.

ok

... I'd expect to add new otheralgorithmkey parameters ...as we'd define new key= prefixes

Ok.

RSA is forbidden... because there have been various attacks on multi-purpose RSA keys, which we side-step by banning RSA here. See the links from #181

Interesting

... MI allows the headers and payload to be checked and processed incrementally

Agree (I stubbed a crappy MICE implementation in python, dunno if it's worth sharing).

Digest requires the recipient to receive and buffer the whole payload...

doesn't that depend on the hash algorithm?

If MICE changes to specify the top-level hash in the Digest header, that'll still allow the fixed-size buffer.

So that's fine for you https://github.com/martinthomson/http-mice/issues/11 ?

Questions (I'll add to MICE):

• should the mi-sha256 header contain the buffer size?
• How can I validate the mi-sha256 hash of a given payload (eg. an existing file)?

[jyasskin]

I guess my "non-repudiation has more to it" comment was trying to ask for more precise requirements from you. I don't deal with non-repudiation, so I don't know what it should require. What do you and folks like the Berlin Group mean by "non-repudiation"? The document you linked to doesn't mention key compromise or signing oracles. It mentions revocation, but doesn't describe how anyone discovers that a key is revoked. It mentions expiration, but seems to do so only around OAuth2 tokens and not signatures. There's just not enough there to pull requirements from. Actual security folks would probably notice even more ambiguities.

I also don't know what it means to have a non-repudiation wrapper around the google storage api. It sounds like you'd need to store a duplicate copy of whatever was sent to the API, so that you could produce it with its signatures later?

A "request ID" is probably not enough to tie a response to a particular request. It could be if we could trust everyone not to re-use IDs, even maliciously, but that's a tall order. It needs to be the bytes of the request itself, or their hash, which is difficult in HTTP where proxies modify the set of headers.

Digest:SHA-256=... requires the whole payload to be buffered not because SHA-256 needs the whole payload at once to produce a hash—it doesn't—but because the program trying to consume the payload can't start processing the first byte until the whole hash is computed, which requires the last byte to be available before the first byte can be processed and released. Digest:MI-SHA256=... wouldn't have this problem because of the interaction between the content encoding and the digest algorithm.

Discussion about the details of the mi-* encoding does belong over in martinthomson/http-mice and not here.

[ioggstream]

@jyasskin

... ask for more precise requirements from you

The European eIDAS directive defines requirements on electronic signatures. In the next days I will try summarize the parts which may be relevant to this discussion.

The document you linked to doesn't mention key compromise or signing oracles

I can anticipate that a x509 signed document (eg. a .p7m) from an unrevoked key is considered non-repudiable. Eventual claims of frauds / compromised keys should be judged by a Court.

It mentions revocation, but doesn't describe how anyone discovers that a key is revoked.

I will ask them clarification about their OCSP workflow (see eIDAS above).

It mentions expiration, but seems to do so only around OAuth2 tokens and not signatures.

Yes, I contacted them asking why not mimic JWT fields ;) I hope we all converge on this spec.

There's just not enough there to pull requirements from. Actual security folks would probably notice even more ambiguities.

Thanks for your great analysis. I'll try to cover them all!

I also don't know what it means to have a non-repudiation wrapper around the google storage api. It sounds like you'd need to store a duplicate copy of whatever was sent to the API, so that you could produce it with its signatures later?

The idea was to:

• attach Signature headers to request and responses
• log those headers thus tracing the communications
• don't store a duplicate copy, just forward the data to the API after logging its signature

Implementing this workflow with headers allows this process to be "transparent" and independent by the underlying API. Let's say I'd prefer to use http headers without altering the payload.

A "request ID" is probably not enough to tie a response to a particular request.

Right, see the request_hash in the issue. The cbor-representation should do the job, right? https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#cbor-representation

which is difficult in HTTP where proxies modify the set of headers.

iiuc if proxies mess with headers:

• Signature is affected too, right?
• the request/response flow won't finish successfully so you won't have your signed response, and the parties acknowledge there's an issue.

Thanks for all your time, again!