--- glep-0063.rst | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 129 insertions(+)
diff --git a/glep-0063.rst b/glep-0063.rst index e40ddd3..cab52b0 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -132,6 +132,122 @@ of the fingerprint field. In any place that presently displays the "``gpgkey``" field, the last 16 hex digits of the fingerprint should be displayed instead. +Rationale +========= + +Foreword +-------- + +This policy aims to provide a good set of OpenPGP usage policies both +to protect Gentoo resources from unauthorized access and to protect developer +identities from being spoofed. The former is significant since it could +be used to deliver malicious content to Gentoo users; the latter because +it could be used to damage the reputation of Gentoo. + +Separate signing subkey +----------------------- + +The specification requires that a separate subkey is used for signing. This +is a subset of more general recommendation of using the primary key only for +the purpose of important key operations and storing it offline, while using +separate subkeys for day-to-day operations. + +The main purpose of this is to reduce the attack surface. By reducing the use +of primary key and keeping it offline, the risk of attacks against it is +reduced. If the attacker manages to compromise the developer's keyring, only +subkeys are compromised and the developer can revoke them without having +the whole key compromised. + +Furthermore, the specification requires separate subkeys for different +purposes. This is a generally agreed on practice (e.g. GnuPG defaults to +using a separate encryption key) aiming to further reduce the attack surface. +Kristian Fiskerstrand points out e.g. it is technically possible to obtain +a valid signature over crafted data while using the subkey for purposes +of authorization [#COUNCIL-MEETING-20180729]_. + +Revocation certificate +---------------------- + +The specification recommends the best practice of storing a copy +of the revocation certificate off site. A common recommendation is to have +the ASCII-armored version of the certificate printed on paper, to protect +against hardware failures (but beware that print servers may store a copy +of the data!). + +The goal of the revocation certificate is to provide the developer with +ability to revoke the key in case the access to it is lost, e.g. due to +hardware damage combined with lack of backups, major events resulting +in backups being destroyed as well, or more importantly in the event +of hardware being stolen or lost. + +Key algorithm and length +------------------------ + +The choice of key algorithm and length defines the resistance of the key +against brute-force attacks. + +Originally, the specification permitted using DSA keys. However, there is no +compelling reason to continue using DSA. According to the GnuPG FAQ, RSA has +much wider support in smart-card solutions [#GNUPG-FAQ-11-1]_. Furthermore, +the RFC 4880bis draft removes the requirement of DSA support in clients favor +of obligatory RSA (and ECDSA) support [#RFC4880bis]_. + +The RSA algorithm is recommended as it is considered secure at the moment +and provides for the best interoperability. The 2048-bit key length +is considered sufficiently secure for all our uses. Historically, this +specification recommended 4096-bit keys. However, while longer keys are still +permitted, they are no longer recommended as they give little in regards +to security, yet are capable of causing performance problems, especially +when using external hardware [#GNUPG-FAQ-11-4]_. + +Additionally, elliptic curve algorithms using Curve 25519 are allowed. +However, they are not recommended due to compatibility concerns +(in particular, not being supported by GnuPG prior to 2.1). +The remaining curves supported by GnuPG (and appropriately listed +in RFC 4880bis draft) are not allowed since there are concerns about safety +of those curves [#SAFECURVES]_. + +Key expiration +-------------- + +It is important to note that the expiration dates as required by this +specification are not to be conflated with key rotation. This specification +does not enforce any specific key rotation scheme; expiration serves purely +the purpose of requiring periodic prolongation. + +This policy serves two purposes. Firstly, it provides a last fallback option +in the event of access to the secret keys being lost and there being +no possibility of revoking them. In this case, the keys eventually expire +and users can clearly see that they are no longer being used. Secondly, it +ensures that the developers periodically confirm their access to the primary +key. + +The expiration period has been chosen as a matter of compromise between being +secure and causing major trouble to developers keeping keys in secure vaults. +The period of 900 days represents the baseline of 2 years with roughly half +a year grace period for extending the expiration date early. Specifying it +in days makes it possible to automatically verify it without having to account +for different lengths of year. + +Additionally, the specification requires renewing the key at least two weeks +before expiration. This is meant to provide the developers early notice +of upcoming expiration and provide time for both the users and Gentoo +Infrastructure to refresh keys. + +Key distribution +---------------- + +The specification requires that the key used by the developer includes his [email protected] e-mail address in one of the UIDs, and the key is uploaded +to the SKS keyservers. This ensures that the developer keys can easily +be found by the users. Furthermore, the latter is also necessary +for the Gentoo Infrastructure to fetch the key and its updates. + +Currently the specification does not specify establishing a Web of Trust +between Gentoo developers. While this is generally a good recommendation, it +is not considered possible for all developers to be actually able to meet +other developers, and no other solution has been agreed on so far. + Backwards Compatibility ======================= @@ -160,6 +276,19 @@ References .. [#GNUPG-FAQ-11-4] GnuPG FAQ: Why doesn’t GnuPG default to using RSA-4096? (https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096) +.. [#COUNCIL-MEETING-20180729] Gentoo Council 2018-07-29 meeting log + (https://projects.gentoo.org/council/meeting-logs/20180729.txt) + +.. [#GNUPG-FAQ-11-1] GnuPG FAQ: Which ciphers are recommended, and why? + (https://www.gnupg.org/faq/gnupg-faq.html#recommended_ciphers) + +.. [#RFC4880bis] OpenPGP Message Format; draft-ietf-openpgp-rfc4880bis-05 + (https://tools.ietf.org/id/draft-ietf-openpgp-rfc4880bis-05.txt) + +.. [#SAFECURVES] Daniel J. Bernstein, Tanja Lange. SafeCurves: choosing + safe curves for elliptic-curve cryptography (as of 2018-08-04) + (https://safecurves.cr.yp.to/) + .. [#DEVMANUAL-MANIFEST] Gentoo Development Guide: Manifest (http://devmanual.gentoo.org/general-concepts/manifest/index.html) -- 2.18.0
