On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom <[email protected] > wrote:
> > On 24/06/13 09:13, Trevor Perrin wrote: > > Depends on the number of pinned keys. Chrome's existing preloads [1] > have 9, 5, 19, 36, 2, and 2 keys. That's a mean of 12, which would be >500 > bytes with SHA256. > > IMHO the expected session will be 2 keys with SHA-160 to SHA-512 per host. > I don't know what the common case would be. The numbers I cited are from the Chromium's preloaded key pins: https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json Note that a commercial CA might have several subordinate and root certificates, with different keys. To pin yourself to this CA, you may need to list several of these keys, and to be conservative a site might pin multiple CAs. (Are you suggesting that sites would list both a SHA256 and SHA1 hash for each pinned key? That seems unnecessary.) > Just for my understanding: Do you think this will create too much header > overhead and there want to the reference to the pin? > I don't know how much data a site could add to every HTTP Response before it starts becoming a problem. But that's the issue David raised. If it's a real problem, the idea of putting pin assertions in, say, a JSON file at a "well-known" URI seems reasonable. E.g.: http://www.example.com/.well-known/public-key-pins Trevor
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
