On 21 Jan 2015, Daniel Kahn Gillmor wrote: > What attack does the cookie prevent?
The cookie helps in a scenario where the URI of a linked identity changes, but the reference stays the same. For example, if I have a linked identity to my website, with a pinned ssl fingerprint, I imagine the URI something like this pgpid:generic;fp=abcde@https://website.com/pgpkey.txt Now, say I have to change my certificate for whatever reason. I revoke the linked identity on my pgp key. Without a nonce on the website, I have no way to "revoke" the cookie which is valid for that linked identity with that fingerprint, other than never to use the resource uri again for that keyring. Granted, it's a slightly contrived scenario. I still think it can be useful, and if we have a user attribute anyways it adds little to no complexity to the verification mechanism. Where it *does* add complexity is the UX. It makes the difference between a one-way place-check-certify ("tell me the uri where the cookie is placed - ok I checked, everything seems in order, create linked identity for this?") and a generate-place-check-certify ("here's the cookie, please place it at the site and hit ok to proceed - ok I checked...") mechanism. I'm not sure if the latter is desirable in all cases, but it does feel more foolproof. On the topic of putting linked identity URIs in user ids, while this would give more exposure, I feel it would also confuse users who have clients which don't support it - especially since it is common practice to just sign all user ids once you have seen a person's id and compared fingerprints. "Watch out for those new URI user ids, don't sign them by accident!" sounds like a bad position to be in. - V _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
