On 02/14/2013 02:29 PM, Stephen Farrell wrote: > Brian searches for "front for the ..." at noon Thu. and gets > a href for JPF with PIN1 valid until Saturday. > > JPF rekey late Thursday. Let's say it was an emergency.
according to the HPKP draft, they switch to their backup pin, right? https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-4.1 I'm assuming Brian hasn't followed the link to the JPF yet. > Brian visits JPF Friday morning and PIN1 no longer matches > the JPF TLS server cert. in this worst-case scenario, this is the first time Brian has visited the JPF, and he is still following the link he received on thursday. > What happens then? It sounds to me like an S-link-compatible browser would refuse to follow the link. so then Brian could still decide to search again, i guess, and hope for an updated S-link? Maybe this suggests that any S-link should embed a backup pin as well, and that an S-link-compatible user agent should require the backup pin to be present. Thinking about this stuff makes me worry that we're heading down a path of making a particularly ephemeral variant of a URL, though; and ephemerality violates some long-standing guiding principles behind URLs, e.g. http://www.w3.org/Provider/Style/URI It might be worth trying to think through what the bigger-picture consequences of that change would be if S-links were widely adopted. --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
