[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]