On Mon, Jun 24, 2013 at 2:29 PM, Chris Palmer <[email protected]> wrote:
> If you haven't already, I'd urge everyone to take pcaps of a web > session to their bank or to their web mail provider or whatever. I > think you'll quickly see that even a large HPKP header, say 500 bytes, > is not going to be the thing that makes web traffic bloated. > (Sometimes, the certificate chains themselves outweigh the pins — and > that traffic occurs before the crucial point of widening the TCP > window! Whereas HTTP headers most likely occur afterward.) > > Also, at one point somebody raised an idea of saying you could pin to > a set of keys — say, Symantec or StartCom's issuing certs — with a > single directive. Something like: > > Public-Key-Pins: max-age=...; pin-set: symantec; includeSubDomains > I like that! It would be a lot easier to list your pin as "symantec,comodo,godaddy" than the equivalent set of keys, particularly since keys per CA change over time. > There'd need to be some kind of registry for the names of sets, of > course, which is complicated. And how do UAs learn of updates to the > sets, and so on. It seems like a registry IANA could maintain. Any CA in a major root store could register their name and a URL where they keep the list of keys necessary to pin them. Browser vendors will download these key lists (over pinned HTTPS, of course) and push updates to browsers on some regular basis. Seems pretty workable... > It's a nice idea that would improve on-the-wire size > in bytes, and also enable web application providers to pin more > easily. If there is demand, perhaps we could create such an extension > to HPKP/TACK/et c. But I don't think it should be a blocker for this > I-D. > TACK wouldn't do this, we're focused on self-chosen signing keys. But it would be a great v2 feature for HPKP, in my opinion... Trevor
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
