Skip to content

Multi-Device software logic outlined in A.1 - is it too concrete?

I wonder if the behavior of Alice's software in A.1 is too "concrete". First off, I think it's good that the example outlines how a user's software can produce and consume replacement key subpackets, that is surely helpful for readers to deepen their understanding of the proposed mechanisms.

However, I worry that the example might imply an overly concrete approach to the UX/security tradeoffs involved. My (possibly mistaken?) understanding of the example workflow is that it might enable an attacker to silently leverage control over one device and key into a more wide-ranging compromise of more of Alice's keys.

My suggestion would be to try and make the example text more agnostic about the exact UX (e.g. whether Alice's software will ask Alice for confirmation about her intent to migrate to a new key). If it's possible for the draft to just give no (implicit) UX guidance, that would seem like the safest approach?

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information