# Non-Repudiation and RSA considered legacy **URL:** \ **Category:** Sicurezza\ **Created:** [17 Ottobre 2018, 2:58pm UTC](https://forum.italia.it/t/non-repudiation-and-rsa-considered-legacy/5152 "2018-10-17T14:58:05Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Roberto\_Polli](https://forum.italia.it/user_avatar/forum.italia.it/roberto_polli/32/1127_2.png) [@Roberto\_Polli](https://forum.italia.it/u/Roberto_Polli)\ **Post date:** [17 Ottobre 2018, 2:58pm UTC](https://forum.italia.it/t/non-repudiation-and-rsa-considered-legacy/5152/1 "2018-10-17T14:58:05Z")
There are currently two RFC drafts for sending signed HTTP requests or replies - both containing the `Signature` and`Digest` headers: - 1 [draft-cavage](https://tools.ietf.org/id/draft-cavage-http-signatures-10.html) with a minimal approach and anterior to the new specifications of http RFC723x - 2 [signed-exchanges](https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses) was born within the Web Incubator Community Group and has a more modern and radical approach , with an eye to HTTP2 and TLS1.3. Let’s see some distinctive points. draft-cavage: - oriented to generic exchanges over HTTP - presents _imho_ some [security gaps](https://github.com/w3c-dvcg/http-signatures/issues/36#issuecomment-417325510) - supports RSA - is a candidate for use in some banking APIs ([stet.fr](http://stet.fr), [berlin-group.org](http://berlin-group.org)) signed-exchanges: - oriented to the response and distribution of content signed by third parties - developed mostly by Google, will be implemented in Chrome - supports multiple authority signatures - mutual security strategies from TLS1.3 and other specifications - uses the new draft of the HTTP working group [Structured Headers](http://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html) that allows to specify binary data and strings delimiting with `*` data encoded in base64 `` Example-DictHeader: en = "Applepie", from = * w4ZibGV0w6ZydGUK = *` ` - uses the draft `Content-Encoding: mi-sha256` [MICE](https://github.com/martinthomson/http-mice/blob/master/draft-thomson-http-mice.md) - [deprecates RSA](https://github.com/WICG/webpackage/pull/181) in favor of ECDSA We are discussing these specifications in workgroups so that: 1- become a basis for implementing [non-repudiable exchanges](https://github.com/WICG/webpackage/issues/248); 2- find a summary on the `Signature` header; 3- improve draft-cavage security eg [# 35](https://github.com/w3c-dvcg/http-signatures/issues/35) and [# 36](https://github.com/w3c-dvcg/http-signatures/issues/36) A somewhat related draft is [Encrypted Content-Coding](https://tools.ietf.org/html/rfc8188). To contribute to the discussion you can see the tickets of the two specifications here: - [https://github.com/w3c-dvcg/http-signatures/issues](https://github.com/w3c-dvcg/http-signatures/issues) - [https://github.com/WICG/webpackage/issues](https://github.com/WICG/webpackage/issues) and / or contact me here or @ioggstream on twitter and github. ---
**Author:** ![vncz](https://forum.italia.it/user_avatar/forum.italia.it/vncz/32/1133_2.png) [@vncz](https://forum.italia.it/u/vncz)\ **Post date:** [13 Febbraio 2019, 7:25pm UTC](https://forum.italia.it/t/non-repudiation-and-rsa-considered-legacy/5152/2 "2019-02-13T19:25:08Z")
Hello! I’ve been asked by @Roberto_Polli to have a look into this thread to see if I can bring any opinion on the matter. Quick introduction so I can brag myself: My name is **Vincenzo Chianese** , I live in Madrid and I work for ([https://stoplight.io](https://stoplight.io)) — a platform for designing/building/testing APIs; for the last 4 years I’ve been working for API Companies ([https://apiary.io](https://apiary.io)). I also maintain an open source API Gateway written in JavaScript ([https://express-gateway.io](https://express-gateway.io)) * * * **First Foreword:** I do APIs (badly), and I am even worse with security. What I’m saying here could be completely non-sense. **Second Foreword:** I haven’t really looked into the first proposal. The draft is in _expired_ state and apparently you’ve done a first round analysis which led you towards the direction of neglecting/discarding it. I’m going to cope with that. # TL, DR Use mutual TLS, and you get what you need. * * * # Long story I’ve been looking to the RFC and I have the following considerations: 1. Not all the HTTP headers are signed by default. They must be explicitly [set using another header](https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-05#section-5.1.2). Albeit this is not a showstopper, I think this might be a problem in case of an intermediary server adding/modifying/removing a header on the way. 2. The use case that is leading this proposal is not really about non-repudiation. The reason of the whole toy here (or at least, the main use case) is to serve a content from an Origin — that’s in turn fetched from another Origin. Having a look at the author of the proposals (Google) I do see the motivations. This seems interesting for CDNs providers and, in my opinion, an attempt to fix AMP. 3. The whole RFC, to me, is simply reimplementing at the HTTP level what mutual TLS has been doing for a very long time (the reason are in the point 2); I’d be way more inclined to leverage the existing technology rather than trying to adapt another one for this specific purpose. Moreover, although today HTTP is the thing, tomorrow it might not be the case anymore. I understand that `XMLHttpRequest` was meant do to something really different and then it turned out to be the driver for Ajax and all the stuff around, but * * * That said, regardless of the technology (HTTP Signed Messages, mutual TLS), there’s the big problem of authenticating the current user, which can be done with confidentiality **exclusively** through a certificate issued by a CA (the government, in this case, and ultimately there is more to ponder on issuing, revoking and securely deliver such certificate to the client (the citizen, I guess). Cheers V. ---
**Author:** ![Roberto\_Polli](https://forum.italia.it/user_avatar/forum.italia.it/roberto_polli/32/1127_2.png) [@Roberto\_Polli](https://forum.italia.it/u/Roberto_Polli)\ **Post date:** [14 Febbraio 2019, 2:48pm UTC](https://forum.italia.it/t/non-repudiation-and-rsa-considered-legacy/5152/3 "2019-02-14T14:48:15Z")
Hi @vncz and thanks for your comment! I’ll shed more light on that. The post assumes some background that instead I gave for granted: your comment is very useful even for integrating it. a) on `mutualTLS`: Though it’s not clear from my post (I have to find a way to explicit that), this is _on top_ of mutualTLS; TLS provides security only while the exchange is happening. Once the connection is closed, the ony evidences that data was sent via TLS are connection logs, which may be tampered. That’s the reason why only mutualTLS is not enough; 1- if intermediary servers alter the `resource representation` and the related headers `content-type, content-encoding, ...` the representation has been tampered and it’s fine to have a problem. If you need non-repudiation, the `resource representation` should be preserved and you shouldn’t accept an altered one. 2- the proposal goal, as you said, is about AMP. It contains many of the building blocks for implementing a request/response signature. 3- see a) the problem with `mutualTLS` is that it’s ephemeral and you may need a proof of your exchanges. I understand that’s subject is quite regulatory. Your comment on XMLHttpRequest is very interesting tough. 4- about certificates and CAs, there’s a lot of ongoing work eg on [https://www.certificate-transparency.org](https://www.certificate-transparency.org) Thank you and feedback welcome! R. ---
**Author:** ![vncz](https://forum.italia.it/user_avatar/forum.italia.it/vncz/32/1133_2.png) [@vncz](https://forum.italia.it/u/vncz)\ **Post date:** [14 Febbraio 2019, 3:43pm UTC](https://forum.italia.it/t/non-repudiation-and-rsa-considered-legacy/5152/4 "2019-02-14T15:43:58Z")
Hey, > Once the connection is closed, the ony evidences that data was sent via TLS are connection logs, which may be tampered. I might be missing something then. How would signed exchanges solve this problem? 🤔 You would have to save/store the traffic somewhere regardless of signatures or not in case you want to display/replay it as proof of non repudiation, isn’t it? In case of Mutual TLS, you can save the whole TLS stream and open it on the spot in case you need to. I think this is a non-issue. > this is _on top_ of mutualTLS Hmm, this is weird to me. In mutual TLS (where both client and server have a certificate) you already have all the guarantees you need. I struggle to see the value of re-encrypting (most likely with the exact same set of keys) the whole traffic. In case you’d go with HTTP Signatures, I think you can ditch [mutual TLS](https://tyk.io/docs/security/tls-and-ssl/mutual-tls/) entirely for Server-Only TLS > the problem with `mutualTLS` is that it’s ephemeral I believe it is not. You can store the stream and reopen it in case you need to check out what happened in that particular exchange. * * * Again, I might be missing some context here, to feel free to fill in in case it’s needed. ---
**Author:** ![Roberto\_Polli](https://forum.italia.it/user_avatar/forum.italia.it/roberto_polli/32/1127_2.png) [@Roberto\_Polli](https://forum.italia.it/u/Roberto_Polli)\ **Post date:** [19 Novembre 2020, 1:17pm UTC](https://forum.italia.it/t/non-repudiation-and-rsa-considered-legacy/5152/5 "2020-11-19T13:17:29Z")
An update on the spec. [Message-Signatures](https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-message-signatures.md) is a specification derived from draft-cavage and has recently been adopted by the IETF http workgroup. It is more similar to [Signed-exchanges](https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html) now and: - supports multiple signatures for the message; - uses now two headers. In the meantime, ETSI released a [draft for a JWS-Signature header](https://www.openbankingeurope.eu/media/1735/preta-obe-jws-stable-draft.pdf)