On Fri, Oct 14, 2011 at 3:05 PM, =JeffH <[email protected]> wrote:
> In order for this "un-pinning" pin-break-verifier-and-code mechanism to > generally work, the UA still connects and and makes an HTTP request and > reads response headers. Note that the TLS layer could still abort the connection if the connection doesn't pass the pinning test (i.e. if the connection was made with a server certificate that does not contain any previously pinned public keys). Thus, in order to successfully use a breakc, you would still have to serve it with a cert containing a public key you had pinned. (Including, perhaps, your backup pin.) However: > In examining the various such situations (aka "disasters") outlined in Sec > 3, it appears that essentially all of them are mitigated if the host > operators allocated a backup server key/cert as advised, and have properly > issued a pin to it, along with their pin to their present operational > key/cert. In this situation, it appears that having the > pin-break-verifier-and-code mechanism isn't strictly necessary. Chris E. and I now agree with this, and are probably going to remove breakc and breakv from the draft specification. Even if they stay, they probably won't appear in the first rev of the Chrome implementation. The thinking is now, "Get the simplest thing implemented, see how people like it, and implement breakc/v if there is demand." This would probably/almost certainly imply that pins expire when the server stops mentioning them in the pins directive (or when max-age expires, whichever is soonest). _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
