Hi all In recent weeks we've had quite a lively discussion on both issues. Going over those threads, I think the inevitable conclusion is that there is not consensus in the group to make any of these proposed changes, and in fact there is rough consensus to defer making those changes to a future revision of the protocol.
The CA names idea (#58) was met with a lot of enthusiasm in the group, and indeed, what's not to like? 'pin-name="Certigna"' is much easier to configure than 'pin-sha1="4n972HfV354KP560yw4uqe/baXc="'. But after much discussion, it turned out that there were a lot of gotchas. Names change, meanings change, human readable strings need to be kept in sync with machine readable hashes. Both UAs and human administrators have to be made aware of changes to names and equivalent hashes, and they both need a policy on what to do if they cannot update. We don't currently have the infrastructure to make this reliable. So we'll go with Gervase's suggestion ([1]) and define the syntax so that future pin formats can be added, and close this issue. The well-known URI idea (#60) also looked cool. No data going to non-supporting UAs, and those only reading the data once per session, rather than with every request, reducing header bloat. It works for favicon, why not for PKP? And I agree with Mark, that if we do it in headers now, we'll never move it to the well-known resource. However, people who do have implementations dismissed the argument about header bloat ([2]), and were worried timing issues with when to fetch the resource, and how long it needs to be cached, etc. I do think we should take the suggestion to treat a missing header as a no-op rather than as something that nullifies pinning. This can allow sites to reduce header bloat by sending the HPKP header only seldom, although with proxies, this is no guarantee of success either. It should be noted that the current spec of HTTP/2 solves the header bloat issue, by having the header only on the first request in the connection. Tobias & Yoav [1] http://www.ietf.org/mail-archive/web/websec/current/msg01851.html [2] http://www.ietf.org/mail-archive/web/websec/current/msg01772.html _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
