W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: STS and lockCA

From: Gervase Markham <gerv@mozilla.org>
Date: Thu, 12 Nov 2009 10:22:45 +0000
Message-ID: <4AFBE1F5.40502@mozilla.org>
To: Adam Barth <w3c@adambarth.com>
CC: Bil Corry <bil@corry.biz>, public-webapps@w3.org

On 12/11/09 09:08, Adam Barth wrote:
> On Wed, Nov 11, 2009 at 7:25 AM, Bil Corry <bil@corry.biz> wrote:
>> Would LockCA prevent the site from loading if it encountered a new cert from the same CA?
> My understanding is that it would not.
>>  Or are you talking about a site that wants to switch CAs and is using LockCA?
> I think Gervase means that you want some overlap so that folks that
> connect to your site the day after you renew your certificate are
> protected.
>> How about instead there's a way to set the max-age relative to the cert expiration?  So -3024000 is two weeks before the cert expiration and 3024000 is two weeks after.  I'm in agreement with Devdatta that it would be easy for someone to lock out their visitors, and I think this is easier to implement.
> That seems overly complicated and contrary to the semantics of max-age
> in other HTTP headers.
> I'm not convinced we need to paternally second-guess site operators.
> Keep in mind that the site operator can supply a lower max-age in a
> subsequent request if they realize they screwed up and want to reduce
> the duration. 

Except that some clients may not come back to see the lower max-age.
Then, they make their first revisit after the lower max-age has expired
and before the higher one has expired, and the site has changed its
site, and boom.

> That said, it might be worth caping the max-age at one
> or two years.

A 1-year cap is probably wise.

Received on Thursday, 12 November 2009 10:23:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC