On Wed, Nov 11, 2009 at 7:25 AM, Bil Corry b...@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
On 11/11/09 15:25, Bil Corry wrote:
Would LockCA prevent the site from loading if it encountered a new
cert from the same CA?
No. Hence the name - lock _CA_. :-P
(BTW, I'm not subscribed to public-webapps; you'll need to CC me on any
conversation you want me in.)
Or are you talking about a
On Tue, Nov 10, 2009 at 7:40 PM, Bil Corry b...@corry.biz wrote:
Gervase Markham wrote on 10/01/2009 5:51 PM:
I therefore propose a simple extension to the STS standard; a single
token to be appended to the end of the header:
lockCA
One idea to consider, especially for lockCA, is to somehow
One idea to consider, especially for lockCA, is to somehow denote that STS
should expire at the same time
as the cert, perhaps by omitting max-age or allowing max-age=cert, etc.
This will prevent accidentally
causing STS to last longer or shorter than the cert expiration, especially
On 11/11/09 08:57, Adam Barth wrote:
Why do we need a browser mechanism for that? It seems like the site
can easily compute whatever max-age value it wishes to set.
Not to mention the fact that you normally don't actually want the LockCA
to expire at exactly the same time as the cert, because
Gervase Markham wrote on 11/11/2009 6:28 AM:
On 11/11/09 08:57, Adam Barth wrote:
Why do we need a browser mechanism for that? It seems like the site
can easily compute whatever max-age value it wishes to set.
Not to mention the fact that you normally don't actually want the LockCA
to
Gervase Markham wrote on 10/01/2009 5:51 PM:
I therefore propose a simple extension to the STS standard; a single
token to be appended to the end of the header:
lockCA
One idea to consider, especially for lockCA, is to somehow denote that STS
should expire at the same time as the cert,
On 02/10/09 23:54, Hodges, Jeff wrote:
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.
Agreed, see the thread entitled more flexible ABNF for STS?
That would be a great thing :-) I
This is an interesting proposal. It addresses a different threat
model than the core STS proposal (because you assume the attacker has
a valid certificate for victim.com).
I think we should resist expanding the scope of the core STS proposal.
There are many different kinds of tokens one could
Dear public-webapps,
I would like to propose a small extension to the current draft
specification for Strict Transport Security.
http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html
The Problem
---
At the moment, if one CA
10 matches
Mail list logo
