HSTS data is kept by each web browser.
When a request is made to a domain that implements HSTS, the response headers will contain a Strict-Transport-Security header that notes the maximum age of the record and optionally some other HSTS-related values.
This maximum age effectively gives a time-to-live starting at the time when the response is received.
This is illustrated, though not explicitly spelled out, by RFC 6797 section 11.2 (non-normative), which states:
The "constant value into the future" approach can be accomplished by
constantly sending the same max-age value to UAs.
and
The "fixed point in time" approach can be accomplished by sending
max-age values that represent the remaining time until the desired
expiry time. This would require the HSTS Host to send a newly
calculated max-age value in each HTTP response.
So if a domain has used HSTS in the past, then in a situation where the HSTS max-age has not been changed previously, the earliest time when no client can be expected to rely on old HSTS data is the time of the last request that returned HSTS data, plus the time that was stated in that HSTS data at that time. If the HSTS max-age has been lowered, then these time periods form sliding windows; that which ends last is the earliest time when no client can be expected to rely on old HSTS data. This is a consequence of one of the requirements in section 8.1.1 (normative):
A Known HSTS Host is "expired" if its cache entry has an expiry date
in the past. The UA MUST evict all expired Known HSTS Hosts from its
cache if, at any time, an expired Known HSTS Host exists in the
cache.
On any request, if the response is received over a secure transport and includes HSTS data, then as stated in section 8.1, the client UA must update its list of known HSTS hosts (normative):
If /.../ the UA MUST [either]: /.../
Update the UA's cached information for the Known HSTS Host if
either or both of the max-age and includeSubDomains header field
value tokens are conveying information different than that already
maintained by the UA.
The max-age value is essentially a "time to live" value relative
to the reception time of the STS header field.
As a consequence, turning on HSTS is effectively a promise to keep offering valid HTTPS for no less than the duration of the max-age HSTS parameter, counting from the moment of the response.
As a further consequence, there is no fixed "expiration" date and time for HSTS data unless the server uses the "fixed point in time" approach described non-normatively in the RFC.
