W3C home > Mailing lists > Public > public-web-security@w3.org > December 2009

Re: STS and lockCA and EVonly (was: STS and lockCA (Gerv))

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Wed, 09 Dec 2009 16:14:46 -0800
Message-ID: <4B203D76.1070904@KingsMountain.com>
To: W3C Web Security Interest Group <public-web-security@w3.org>
Gerv mused on Thu, 12 Nov 2009 10:20:19 +0000:
 > Musings: STS already has an expiration mechanism. However, a site like
 > Paypal wants ForceTLS basically forever


 > but may at some point want to switch CAs.


 > If we tie LockCA expiry to STS expiry, they have
 > to weaken their STS protection to switch CAs.

Unless we defined the LockCA directive to be able to declare a list of CAs, eg..

  STS: max-age=8000000; includeSubDomains; LockCA=fooCA,barCA,zedCA;

..which would allow us to plan for migration and/or emergency fallbacks. And so 
having the simple max-age for the browsers' STS cache entry (for us) might be 

However, we might just prefer to declare that the cert must be an EV cert, and 
not lock it to any particular CA, eg..

  STS: max-age=8000000; includeSubDomains; EVonly

...where LockCA and EVonly are not mutually-exclusive; rather, they are 

Adam observed:
 > I think we should resist expanding the scope of the core STS proposal.
 >   There are many different kinds of tokens one could imagine adding to
 > mitigate different threat models.  Instead of adding them all in v1,
 > we should allow / encourage this kind of experimentation by defining a
 > forwards-compatible grammar for the STS header.

Yes to the latter comment wrt grammar -- e.g. the "more flexible ABNF for STS" 
msg. will incorp in STS spec -06.

though, we might really want to get something like at least EVonly into the v1 
"standardized" spec.

Received on Thursday, 10 December 2009 00:21:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:23 UTC