New issue
Advanced search Search tips
Starred by 5 users
Status: Fixed
Closed: Mar 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment
Drop HPKP maximum max-age to 60 days
Project Member Reported by, Aug 22 2015 Back to list says "UAs MAY cap the max-age value at some upper limit".

Should we enforce a maximum max-age of 60 days ("However, a value on the order of 60 days (5,184,000 seconds) may be considered a balance between the two competing security concerns")?
Comment 1 by, Aug 22 2015
+rsleevi, davidben

Questions: 1.) I can't find a place where we enforce a maximum max-age for HPKP; am I missing it? 2.) Has this been considered in the past? Is there a reason we don't have a maximum?
Status: Available
Actually, from that code, we're capping at HSTS max (1 year), rather than a saner HPKP max. Feel free to drop that number down Emily :)
Comment 4 by, Aug 23 2015
Status: Assigned
Summary: Drop HPKP maximum max-age to 60 days (was: Consider enforcing maximum HPKP max-age value)
Aha, I totally missed that, thanks.
Comment 5 by, Feb 25 2016
Status: Started
Comment 6 by, Feb 25 2016
So is the team officially moving forward with this rather than keeping it at 1 year? Because I can think of at least one use case that's potentially significantly adversely affected by this change.
Comment 7 by, Feb 25 2016
Cyph's users would be significantly adversely impacted by this change. However, I do understand the risks that need to be balanced here (e.g. the possibility of sites getting permanently DoS'd by a one-off TLS MitM).

My vote: move forward with this change, but ONLY for non-EV certs.
Comment 8 by, Feb 26 2016
Re #6: could you elaborate a bit please? Unfortunately there's probably not be a value that is perfect for every use case. See this thread discussing the issue:

Re #7: I don't see a PKP header on and it doesn't appear to have preloaded pins either. Are you perhaps thinking of HSTS? The HSTS max max-age will remain at 1 year.
Comment 9 by, Feb 26 2016
#6 refers to #7.

#7, see rather than uses HPKP to intentionally force the browser to treat as being offline (the key deployed by the server is consistently rotated, rendering previous pins invalid), thereby forcing the browser to refer exclusively to appcache or serviceworker logic. The max-age for a key pin is expected to be long-lived as this mechanism serves to trap code-signing logic within the browser.

In essence, this mechanism is what guarantees Cyph's Trust-on-First-Use model for enabling js crypto. Reducing the max-max-age needlessly degrades this and other use cases where long-lived key pins are strongly desired/required in favor of mitigating the risk of others shooting themselves in the feet.

Ryan (#7) can detail it more for you out of band.
Comment 10 by, Feb 26 2016
Bryant's description is correct. More detail is available here if necessary:

That said, regardless of the impact on Cyph in particular, my proposal of removing the max-age cap for Extended Validation certificates seems like the ideal compromise. Browsers don't recognise EV certs whose CAs haven't gone through a special audit process[1], so this mitigates the risk of a random CA (e.g. company intranet Web filter) being used for a DoS attack. As far as the risk of accidental self-harm by administrators who manage their keys poorly, I would argue that this addresses that as well in that EV generally implies a sophisticated user/organisation who may well have a need for extended security capabilities such as longer-lived key pins.

At the very least, there should be some mechanism (maybe similar to HSTS Preload list) for sites that know what they're doing to voluntarily opt out of such "training wheels".


Project Member Comment 11 by, Feb 29 2016
The following revision refers to this bug:

commit a6c42bddb0ce6253b7da6f3b66460a243071d04f
Author: elawrence <>
Date: Mon Feb 29 18:00:42 2016

Limit Public-Key-Pins max-age to 60 days

Set the maximum validity period for
a Public-Key-Pins header to 60 days as suggested by

BUG= 523654 

Review URL:

Cr-Commit-Position: refs/heads/master@{#378231}


Comment 12 by, Feb 29 2016
@ryan (#10) looks like they're going ahead with it. Might as well convince the Firefox team to resist instead and just suggest Cyph users stick to Firefox for stronger persistence of code-signing logic.
Yes, I think we should go ahead with the max max-age of 60 days. Using HPKP to intentionally trigger violations seems like an unusual use case and not what it was designed for.
Comment 14 by, Feb 29 2016
The team doesn't believe that there's a justification for any site to override that limit? At all? Not even a case-by-case process for it? That strikes me as odd given that HPKP was designed first and foremost as a security boundary, and its usage in this context, though unusual, doesn't violate its premise as a security boundary at all. If anything, the use of HPKP in this way is a novel application of a security boundary.

Forcing 60 days on sites willing to take the risk of 1y max-age comes across as short-sighted.
Comment 15 by, Feb 29 2016
WebSign is one use case where this matters more than it might in most HPKP deployments, but it's just an example.

Capping max-age seems like it unnecessarily cripples the feature for a large number of sites that are managed in a professional manner and would benefit from a more sane key pin TTL.

The PKP preload list is basically the way that sites can override the maximum max-age and ensure that their pins stick for as long as they want. Preloading wouldn't work for your use case though, unfortunately.
Having read the Cyph document, I'm still not clear on what the threat model is.

What attack paths does the Cyph mechanism close? (Distinct from attack paths that reproducible/publicly logged builds close?)

Is there no other/better way to convince JavaScript running in a client that the server is unavailable?

Our design intention with HPKP was to reduce the number of allowable issuers for a given site; the Cyph mechanism is using HPKP in a decidedly "off-label" way. The trade-off HPKP poses is: greatly reduced set of issuers, but huge risk of bricking. Much of HPKP's ancillary mechanisms, such as requiring backup pins, max-age, and max-max-age, exist to mitigate the risk off bricking, while still retaining the benefit of reducing the # of issuers. We never anticipated purposeful self-bricking. And, I'm unclear on how self-bricking makes WebSign possible.

If the overall goal is "provide authenticated web application code, such that the authentication is resilient against even the code publisher" — a fine goal indeed — my first instinct would be to take the smooth path:

* Regular CA-signed HTTPS...
* ...with Certificate Transparency
* HSTS (max-age) with a very long max-age
* HPKP for bonus points (optional, less necessary in the coming CT world, but nice)
* Avoid "building"; if impossible, then reproducible builds
* Binary Transparency/Build Transparency/publicly logged object code (BT)
* Make the leap of faith — simply trust, upon first use — that the first code was honest...
* ...and have that code maintain the chain by checking the BT log before updating itself

If I understand WebSign correctly — and I'm not sure I do — then I think all the goals can be met without going off-label.

But, I could be wrong...
I should say: "And, I'm unclear on how self-bricking *uniquely* makes WebSign possible."
Comment 19 by, Feb 29 2016

Ahh, fair enough; that's definitely a good solution for every use case that isn't this one. I don't suppose it'd be possible to have that same preload list accept an input of "I don't want to preload my key, but I do want to be excused from the max-age cap"?

Also, for my edification, does the PKP preload already exist, and if so would you be able to link me to it? It'd still be useful for our non-WebSigned properties like


re: "Is there no other/better way to convince JavaScript running in a client that the server is unavailable?", finding a way to change a website's behaviour from TOEU to TOFU is really the fundamental problem that has made creating something like WebSign so difficult historically (leading to workarounds like only shipping Web-based cryptographic software as browser extensions). My understanding is that there was never a known way to do it until we landed on the HPKP suicide trick; so, while I would love to find a more elegant approach to self-bricking (e.g. some sort of client-side AppCache/ServiceWorker flag), at the moment I'm not aware of any that's viable.

The steps you describe below aren't that different from the code signing logic already present in WebSign, but all that is orthogonal to / dependent on the self-bricking aspect.

I'll email you to discuss in more depth out of band.
Yes, the PKP preload list exists:

I don't think we're likely to introduce another preload list for bypassing the max max-age; I suspect it would only be used by sites like yours that are using HPKP for an unintended purpose.
Labels: M-51
Status: Fixed
Revisiting this after further analysis: all of my commentary on the max-max-age is moot. I'm in favor of the general limit at this time. What's the currently targeted date for M-51?
#22: Chrome's Development Calendar can be found here:
Sign in to add a comment