[gentoo-dev] [PATCH 3/3] glep-0063: Include a rationale

[Michał Górny]

---
 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
+@g.o 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