feat: add manual of trust management

1 files changed, 94 insertions, 0 deletions

diff --git a/src/content/docs/guides/openpgp-trust-manage.md b/src/content/docs/guides/openpgp-trust-manage.md
new file mode 100644
index 0000000..aeb7d76
--- /dev/null
+++ b/src/content/docs/guides/openpgp-trust-manage.md
@@ -0,0 +1,94 @@
+---
+title: Best Practices for OpenPGP Trust Chain Management
+---
+
+## Background: Understanding Trust Management
+
+Trust management is a fundamental concept in OpenPGP-based systems. Users must
+establish whether they can trust a particular public key to authenticate
+communications and verify signatures. Building a secure and efficient trust
+model is essential for maintaining communication integrity without relying on
+centralized authorities.
+
+In decentralized environments, the responsibility for managing trust rests with
+each individual user. This document introduces the key mechanisms behind trust
+management in GpgFrontend and outlines current behaviors and design decisions.
+
+## Owner Trust Mechanism
+
+The Owner Trust mechanism in OpenPGP is a way for users to manage the
+trustworthiness of public keys in a decentralized manner. After verifying the
+fingerprint of a key and ensuring its authenticity, a user can assign an "Owner
+Trust" level to the key. This level indicates how much the user trusts the key
+owner to sign other people's keys accurately.
+
+Owner Trust is not about whether the key itself is valid; rather, it defines the
+user's confidence in the key owner's ability to vouch for others. This
+distinction allows users to build personalized and scalable Web of Trust models
+without relying heavily on external signatures or centralized authorities.
+
+Typical trust levels include:
+- **Unknown**: No trust decision has been made.
+- **None**: The key owner is not trusted to certify other keys.
+- **Marginal**: The key owner is partially trusted.
+- **Full**: The key owner is completely trusted.
+- **Ultimate**: The user owns this key personally (automatically assigned to
+  their own keys).
+
+By using Owner Trust, users can securely manage communication without requiring
+constant updates from key servers, maintaining both simplicity and control over
+their trust network.
+
+## Signing UIDs and Current Limitations
+
+In GpgFrontend, users can sign the UID (User ID) of another user’s OpenPGP
+public key to confirm its authenticity. However, during the initial design
+phase, the potential need to synchronize these signatures with key servers was
+not fully considered.
+
+Currently:
+- GpgFrontend does not automatically upload signed UIDs to OpenPGP key servers.
+- Whether a signature update is accepted depends entirely on the specific key
+  server’s policy.
+
+Reasons for not enforcing automatic synchronization:
+
+Uncontrollable Behavior of Key Servers
+- Different servers (e.g., keys.openpgp.org, SKS servers) have varied policies
+  regarding third-party signatures.
+- Some servers accept them; others require UID validation or reject them
+  altogether. 
+
+Potential Key Size Inflation
+- Each additional signature increases the public key’s size.
+- Frequent uploads of third-party signatures would cause key bloat, impacting
+  synchronization and performance. 
+
+3.	Practical User Behavior
+- Most users verify fingerprints manually and rely on Owner Trust.
+- Synchronizing all third-party signatures to public servers is often
+  unnecessary for typical use cases.
+
+## Special Considerations for Organizational Users
+In organizational environments (e.g., large enterprises), simple Owner Trust is
+often inadequate. In these cases, a Certificate Authority (CA)-based trust model
+is used:
+
+- A trusted internal CA signs the members' keys.
+- Members only need to trust the CA's signature rather than validating each
+  colleague's key individually.
+- This process is similar to the X.509 certificate system and is often
+  implemented through gpgsm (S/MIME-based solutions).
+
+Currently, GpgFrontend does not support gpgsm or CA certificate management, but
+future development may consider it based on user demand.
+
+## Possible Future Enhancements
+
+- Provide an optional prompt after signing a UID, asking if the user wishes to
+  upload the updated key to a key server.
+- Clearly warn users about potential issues of key bloat when uploading
+  third-party signatures.
+- Explore the implementation of organizational trust models such as CA-based
+  signature management and certificate presentation.
+