[openpgp] Re: Ideas for alternative user interface terms for OpenPGP structures
Daniel Huigens <[email protected]> Thu, 26 Feb 2026 14:52:28 +0000
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Message-ID | <ToHY-TeLHRTAjgA4LOROiKc8k5qzO_nSRmLNq1PMyvMKyGbFSx3R076jUO5eHPhfQXCzVe0AeA5m131_BzBYqjohaPt5Byw1lRu7I0mgiO8=@protonmail.com> |
Hi Kai & all, I'm gonna take a controversial position and claim that the terms "public key" and "private key" are actually fine to refer to TPK and TSK in UI. Obviously they're not perfect as technical terms because they contain multiple cryptographic keys and also metadata, but from a UI perspective they have a couple advantages: - The first word (public / private) makes it clear whether it should be shared or not (and getting that wrong is one of the most catastrophic failure modes in public key cryptography, so it should be emphasized) - The second word (key) makes it clear that it's related to encryption or at least security, while "certificate" may sound more related to credentials or trainings - The symmetry between public / private key makes it clear that they're related to each other, unlike certificate / private key - They're easy to google and there's a lot of information online to explain what they are and what they're used for - They've been used in this context for a long time Additionally, the things that make it a bad technical term are actually not really relevant to end users (who cares whether it contains one component key or two?) Similarly to how a video file also has audio and a photo file also has metadata, the fact that a public key contains more than a single cryptographic public key shouldn't really worry us so much. In technical contexts we can use TPK and TSK, but for UI we don't really need a new term, IMHO. We've used the terms "public key" and "private key" in Proton Mail since the beginning and haven't had complaints. We do also try to explain what they're used for inline, and obviously we also have support pages explaining what they are and so on. As a final aside, I think the best thing we can do for UX is actually to make sure that users don't have to worry about or manually deal with public / private keys at all (as much as possible), rather than worry about what we call them. Best, Daniel On Thursday, February 26th, 2026 at 11:37, Kai Engert <[email protected]> wrote: > Hello, > > this message isn't about protocols, algorithms or packet structures. > It's just about user interface terms. > > I have been struggling with the use of the term "certificate" in the > context of OpenPGP. My pain points are: > - it implies third party certification even when there is none, > which is often missing in OpenPGP transferable keys. > - it overlaps with the established use of the term with S/MIME, > which is particularly relevant in applications that offer > both OpenPGP and S/MIME functionality to users. > > The alternative term "OpenPGP public key" also isn't perfect, because > the objects that users work with contain more than just the public key. > > Also overall, I think the terms "OpenPGP certificate" and "OpenPGP > public key" and "secret key" are difficult to understand for users. > (Especially when the word key is used for the public key, because in > human language, a key is used for unlocking something, so there is risk > of confusing secret and public keys. That's an argument for avoiding the > term key when talking about public keys to users.) > > I'd like to propose an alternative set of terms for OpenPGP objects to > be used in user interfaces, to make it easier for users to understand. > > I propose the term "Message Crypto Patterns" (or Mail Crypto Patterns) > (MCP) as a user understandable abstraction as a replacement for > "transferable public key" or "OpenPGP certificate. > > Based on the name, users can tell "this is the thing I need to make > cryptography work" and because cryptography is about transforming an > object, "this is the pattern that is used for the transformation". > > UI language could say Alice tries to find Bob's MCP. She can find > candidate MCPs. She could see that one of them is a certified MCP > (because it contains a certification signature). Alice can manually > verify an MCP. > > An MCP can contain multiple individual patterns. (That's why the > suggested expanded form of the acronym says patterns, not pattern.) > > The MCP can contain an encryption pattern (encryption subkey) and/or a > signature pattern (signing subkey). > > Alice uses the encryption pattern from Bob's MCP to encrypt a message > for Bob. To verify a signed message from Bob, Alice checks that the > signature matches Bob's signing pattern. > > Patterns can be old (expired/revoked), new patterns can get added. An > MCP can get updated to contain a new pattern. > > It would also work to say "Bob's MCP contains a Post-Quantum encryption > pattern". (The PQ pattern is a more advanced pattern to transform > messages in a stronger way.) > > The counterpart is the Message Crypto Secret (MCS), which contains the > private crypto material. > > What do you think? I'm looking forward to your feedback. > > Thanks, > Kai > > > _______________________________________________ > openpgp mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ openpgp mailing list -- [email protected] To unsubscribe send an email to [email protected]