vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-22 07:32:05 +01:00
Code Issues Projects Releases Packages Wiki Activity

move certificate freshness to a new section called best practices and recommendations, summarizing key directions

Browse source
This commit is contained in:
Tammi L. Coles 2024-02-16 14:50:52 +01:00
parent 0367dc98a4
commit b7cd4888e5
1 changed files with 27 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

39
book/source/adv/certificates.md
View file

@ -271,17 +271,6 @@ SKS-style keyservers have historically facilitated the exchange of OpenPGP certi
The progression from SKS-style keyservers to innovative solutions like Hockeypuck and Hagrid demonstrates the OpenPGP community's commitment to safeguarding the OpenPGP ecosystem against evolving threats, ensuring a more secure and reliable infrastructure for certificate distribution.
(certificate-freshness)=
## Certificate freshness: Triggering updates with an expiration time
For a certificate holder, one problem is that their communication partners may not regularly poll for updates of their certificate.
A certificate holder usually prefers that everyone else regularly obtains updates for their certificate. This way, a third party will, for example, not mistakenly keep using the certificate indefinitely, after it gets revoked. Setting an expiration time on the certificate, ahead of time, limits the worst case scenario: communication partners will at most use a revoked certificate until its expiration time, even if they never learn of the revocation.
Once the expiration time is reached, third parties, or ideally their OpenPGP software will have to stop using the certificate, and may attempt to obtain an update for it. For example, from a keyserver, or via WKD. Ideally, certificate updates are obtained automatically, by the user's OpenPGP software, without any need for human intervention.
After the update, the updated copy of the certificate will usually have a fresh expiration time. The same procedure will repeat once that new expiration time has been reached.
## Challenges in certificate management
The management of OpenPGP certificates encompasses various challenges, ranging from security vulnerabilities to privacy concerns. This section addresses some of the most significant challenges and the responses developed by the OpenPGP community to mitigate these issues.
@ -320,4 +309,30 @@ Efforts to mitigate this include selective certification sharing, anonymizing as
OpenPGP allows for the addition of unbound, local user IDs to certificates, enhancing personalization and operational flexibility. These IDs, not globally verified, can attach context-specific aliases or metadata. However, this flexibility introduces challenges related to certificate validity, trust, and potential misuse.
The OpenPGP community, including implementations like [Sequoia PGP](https://sequoia-pgp.org/blog/2023/04/08/sequoia-sq/#an-address-book-style-trust-model), advocates for responsible management of local user IDs and their integration. Sequoia certifies these IDs with local trust anchors and marks these binding signatures as "local" artifacts using [Exportable Certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-exportable-certification) subpackets to prevent unintended distribution (e.g., to public keyservers), balancing personalization with security and privacy.
The OpenPGP community, including implementations like [Sequoia PGP](https://sequoia-pgp.org/blog/2023/04/08/sequoia-sq/#an-address-book-style-trust-model), advocates for responsible management of local user IDs and their integration. Sequoia certifies these IDs with local trust anchors and marks these binding signatures as "local" artifacts using [Exportable Certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-exportable-certification) subpackets to prevent unintended distribution (e.g., to public keyservers), balancing personalization with security and privacy.
## Best practices and recommendations
### Guidelines for certificate minimization
Minimization involves presenting a partial view of a certificate by filtering out some components for specific use cases, such as email encryption where only necessary keys are retained. It serves to enhance performance, address security vulnerabilities like certificate flooding, and protect user privacy. Best practices include:
* omitting unnecessary components and third-party certifications not required for the use case
* employing strategies like GnuPG's `clean` and `minimize` commands, which compact certificates by removing superseded or irrelevant signatures
* considering the use case and context when minimizing, ensuring enough historical self-signatures are included for validation
(certificate-freshness)=
### Handling certificate freshness and expiration
Freshness concerns ensuring certificates are up-to-date, compelling users or their software to poll for updates, such as from a keyserver. Expiration acts as a passive mechanism for certificates to time out, promoting regular updates to reflect the current cryptographic stance of their owners. Best practices include:
* setting appropriate expiration times to force regular updates and limit the use of revoked certificates
* encouraging automatic updates by OpenPGP software, ideally without human intervention, to maintain certificate relevance and trustworthiness
### Securely distributing and verifying certificates
Distribution mechanisms like WKD, Hagrid, and SKS-style keyservers facilitate the exchange of OpenPGP certificates, each with unique properties affecting security, privacy, and usability. Recommendations for secure distribution and verification include:
* leveraging verifying keyservers like Hagrid for controlled, privacy-aware distribution
* utilizing WKD for decentralized, domain-controlled certificate hosting
* adapting to evolving keyserver designs that mitigate vulnerabilities like certificate flooding