See http://tools.ietf.org/html/draft-ietf-websec-key-pinning-09#section-2.3.2:
> [...] the UA MUST note this host as a Known Pinned Host, caching > the Pinned Host's domain name and noting along with it the time of the > observation (also known as the Effective Pin Date), the value of the > max-age directive, whether or not the includeSubDomains or strict > directives are asserted, the value of the report-uri directive (if present), > and any other metadata from optional or future PKP header directives. In order to maximize the number of entries that can be stored in a limited amount of storage space, we (Mozilla) want to store HSTS/HPKP/etc. information in as compact of a form as possible. With that in mind: 1. Why must a UA store the effective pin date and the max-age directive, instead of storing just the calculated expiration time = effective pin date + max-age? I think that a UA can do a good enough job at making sure it uses the latest available pin data without needing to store the two separate items. 2. The requirement to store "future PKP header directives" seems to mean that a UA must store directives that it doesn't understand, presumably with the intention that it will process those stored directives if/when it starts understanding them. This requirement is unreasonable because it means that a UA may need to store huge HPKP headers full of directives that it will never process. This limits our options for efficiently encoding the stored information and also makes it unnecessarily difficult for us to calculate storage costs for this feature. In general, it seems to me that if it is safe for a UA to ignore a directive when it is first received, then it will be safe for the UA to ignore that directive until it receives a new HPKP header in some future response. If this is not the case, then I recommend changing the draft so that it would be safe. Regardless, I think the draft should be changed so that implementations are not required to store directives that they do not understand. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
