- From: Ludin, Stephen <sludin@akamai.com>
- Date: Wed, 3 Jul 2013 09:43:23 -0500
- To: Yoav Nir <ynir@checkpoint.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Zero intention of doing so. The "rewrite TLS" comment was there simply to point out how far afield the idea was going. For the record, I am open to most any ideas but my goal was not to suggest we tweak TLS but more to point out a potential direction to spur more conversation. Will and Roberto handily redirected the conversation to the experimental SPDY world. Thanks for the pointer to the RFC and the other suggestions! -stephen On 7/3/13 12:33 AM, "Yoav Nir" <ynir@checkpoint.com> wrote: > >On Jul 3, 2013, at 3:02 AM, "Ludin, Stephen" <sludin@akamai.com> wrote: > >> Here is an idea to chew on. It has been discussed before, but if there >> was a concept of returning multiple certs in the ServerHello which >> indicate other common names the origin is authorized to serve I tight >> provide a path forward to serving related content from those domains. >>For >> example, if the origin serves an html response on domain1.com which has >> references to objects on otherdomain.com AND the origin has a valid >> certificate for otherdomain.com it has a mechanism to 'prove' to the >> client that it is authorized to push that content. >> >> At this point I am rewriting TLS as well as getting far from the >>original >> subject. Probably best to continue in a fresh thread if there is >>interest. > >Hi Stephen. > >This is authorization at the HTTP level. I don't think this should go in >TLS just because TLS has a mechanism for showing certificates. Also if >you do want it to go in TLS, there's an RFC for that: >http://tools.ietf.org/html/rfc5878 . This allows for sending arbitrary >authorization information. > >Alternatively, you could add this in HTTP as a header or as a new frame >type. > >Yoav >
Received on Wednesday, 3 July 2013 14:44:03 UTC