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: Yoav Nir <ynir@checkpoint.com>
Date: Wed, 3 Jul 2013 20:50:16 +0000
To: "Ludin, Stephen" <sludin@akamai.com>
CC: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <52D577F3-E8E9-4526-9905-CFCD0A01E76D@checkpoint.com>
I should add that this RFC I mentioned is problematic as there are IPR claims. 


On Jul 3, 2013, at 5:43 PM, "Ludin, Stephen" <sludin@akamai.com> wrote:

> 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 20:50:53 UTC

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