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

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

yes.

 > but may at some point want to switch CAs.

yep.

 > 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 
sufficient.

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 
composable.


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.

=JeffH
PayPal

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