I agree with Tom Ritter, with one caveat: The spec should very clearly
call out the issue (balance between too soon pin expiry and too long),
rather than not mentioning it. I haven't found such language (i.e.
guidance to UA implementers) in the document, but I might have looked in
the wrong place (I looked at every piece of text that contained the
three letters 'max').
Regards, Martin.
On 2013/05/12 5:09, Tom Ritter wrote:
On 7 May 2013 03:13, Yoav Nir<[email protected]> wrote:
How should we handle the max-max-age issue:
(1) No hard limits, but allow UAs to limit the pin time. Suggest a month
(2) Set a hard limit of one month in the RFC. Longer pins are truncated.
(3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't been
observed for some time (like a month)
(4) Adopt some gradual confidence-building scheme a-la-TACK.
"None of the above" is possible, but MUST come with argument and proposed text.
None of the above: No hard limits, leave limiting the pin time
unspecified, make no suggestion. I don't believe any text changes are
necessary.
I think UAs that are sufficiently worried about websites bricking
themselves come up with creative solutions that work well for them,
but may not be applicable to others. (Chrome's will (or would) expire
hardcoded pins if there hasn't been a Chrome update in a month - they
could do the same for max-ages.) I don't like the idea of suggesting
that UAs unilaterally override a site's possible desire to pin for
more than 1 month.
-tom.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
