Jump to content

Talk:HTTP Public Key Pinning

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by ChristophLukas (talk | contribs) at 20:56, 27 October 2017 (Upcoming deprecation of HPKP). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Future of HPKP

The chrome devs want to deprecate and remove public key pinning: https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ

"This will first remove support for HTTP-based PKP (“dynamic pins”), in which the user-agent learns of pin-sets for hosts by HTTP headers. We would like to do this in Chrome 67, which is estimated to be released to Stable on 29 May 2018."

The article should probably reflect this, but I'm unsure about phrasing and placement. ChristophLukas (talk) 20:55, 27 October 2017 (UTC)[reply]

Controversies

What happend to the following statement? Why was it removed by @Hello71?

Second, the reporting mechanism is suppressed from broken pinsets. The reporting of the broken pinset is called out as MUST NOT report, so a complying user agent will be complicit in the cover up after the fact.

Was it simply wrong or what's wrong with this statement?

At least in https://tools.ietf.org/html/rfc7469#section-2.1.4 I could not find any information that the client 'must not' report broken pinsets. --rugk (talk) 22:23, 28 June 2015 (UTC)[reply]

I put my reasoning on User talk:Noloader:
do you have any sources for #Controversies? ⁓ Hello71 17:30, 27 June 2015 (UTC)[reply]
Yes. This is from the IETF, which approved the standard: Comments on draft-ietf-websec-key-pinning. This is from OWASP, which is an organization dedicated to software security: Certificate and Public Key Pinning | HTTP Pinning
the former is an email to the IETF, and the latter appears to be a) an unofficial "wiki", and b) cites... Wikipedia as the source of information. furthermore, while the first source does complain about the first "reason", it does not appear to state anything about the second, i.e. "The reporting of the broken pinset is called out as MUST NOT report". I was unable to find any "MUST NOT" sections in the RFC related to the reporting, so I am removing that part from the article. feel free to reinstate it if you have some references. ⁓ Hello71 15:52, 28 June 2015 (UTC)[reply]
(this is not formatted very well, feel free to make less terrible) ⁓ Hello71 01:28, 29 June 2015 (UTC)[reply]
Okay, thanks. I did not see that. Nice to have it mentioned here too. So it seems that this was a wrong information. (fortunately) --rugk (talk) 20:49, 29 June 2015 (UTC)[reply]
Hi, I am a co-author of the RFC and the author of https://noncombatant.org/2015/05/01/about-http-public-key-pinning/.
I removed all of Noloader's Controversies section. (The "by whom?" is: By Noloader. See e.g. https://www.ietf.org/mail-archive/web/websec/current/msg02306.html and other messages to that list.) As stated, the section was vague, but entirely inaccurate as far as it went. A conformant and correct client with a live pin set will only trust servers that can establish connections that pass Pin Validation *based on that pin set*, including trusting the server to change the pin set. --noncombatantorg 04:50 6 June 2015 UTC — Preceding undated comment added 04:54, 6 July 2015 (UTC)[reply]