W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Please don't re-write TLS (Was: HTTP/2.0 -04 candidate)

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>
Message-ID: <CDF9856F.46253%sludin@akamai.com>
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!


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.
>> 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
>> subject.  Probably best to continue in a fresh thread if there is
>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
Received on Wednesday, 3 July 2013 14:44:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC