This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of
computers,
computing, and
information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of
Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography articles
This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the
Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet articles
"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."
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?
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. ⁓
Hello7115:52, 28 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
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
HTTP Public Key Pinning vs static list Public Key Pinning
Public Key Pinning is a more general mechanism which encompasses HTTP Public Key Pinning (HPKP) and static list Public Key Pinning (static pins). Furthermore, HPKP was deprecated (in favor of Certificate Transparency and Expect-CT) and removed from Chrome 72+ (see article) and Firefox, the only other implementer of HPKP, announced plans to remove support and already disabled HPKP by default on development branch.[1]
Therefore, I propose:
1. Make Public Key Pinning into an actual article (currently it is just a redirect to "HTTP Public Key Pinning")
2. Update "HTTP Public Key Pinning" article to clarify relationship to PKP.
3. Update "HTTP Public Key Pinning" with the recent compatibility information (Firefox and others).