I sent the mail below to the draft-ietf-websec-key-pinning-06 authors, and Chris Palmer suggested I raise the points on this mailing list. He also mentioned a previous discussion (which I haven't been able to locate) around a well-known host security information URL; if there's a good place to get up to speed on that discussion, a pointer would be much appreciated.
Thanks, David I really like the overall approach taken in Public Key Pinning Extension for HTTP (draft-ietf-websec-key-pinning-06). Particularly, the public key (including algorithm) seems like exactly the right thing to pin. A couple of thoughts on other areas of the draft (my apologies if these have been discussed before elsewhere; I'm only familiar with the draft text): 1. It would be nice to avoid including full public key data with every HTTP response. Particularly if there are multiple public keys in use, there's a bit of potential data overhead on every response. Would it make more sense to have the public key data in a separate resource? As a first step, perhaps having every resource just have a pointer, using a header something like the following: Public-Key-Pin-Location: /pins Where "/pins" would be a separate resource that would have Public-Key-Pins header data. Or, to go one step further, this data could then appear in the entity-body (perhaps in JSON format) and use normal HTTP resource-level mechanisms-for example, using Cache-Control to specify the expiration rather than a custom max-age header directive. 2. It would be nice to have the public key specified in a central place for the host, rather than by any resource, since the public keys are at the TLS level and don't vary per resource. I'm not sure there's an ideal solution here, but a couple of options might be: a. Have a fixed, well-known resource per host for retrieving public key pin data (such as "/well-known-pins" or something like that). b. An OPTIONS * request might be a good fit here, it was apparently intended for server-level information. Perhaps the response to an OPTIONS * could have the public key data (like the Public-Key-Pins header). Alternatively, to combine the two ideas, the OPTIONS * response could, instead of having the public key data itself, instead have a header with a URL for a public key pins resource (like the Public-Key-Pin-Location header mentioned above). Thanks for considering these ideas.
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
