From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 27D20138334 for ; Thu, 25 Apr 2019 11:32:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 88F02E090A; Thu, 25 Apr 2019 11:32:18 +0000 (UTC) Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2BEE6E08FB for ; Thu, 25 Apr 2019 11:32:17 +0000 (UTC) Received: by mail-pf1-f175.google.com with SMTP id 188so11026035pfd.8 for ; Thu, 25 Apr 2019 04:32:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ANB8KUUhBQthfALXHBjDK/xwlwZMbvRssoKFP4lId/A=; b=e0jECajuUjlAI8LTaK7csg8e54vAN+hQ1a/iUERMyGmDnHLSxPj2pFvAWMYxwpuVwh AcIWA0BEc18CkGFdzZj2sw97aHZ2rzGg8YssopgIW8txVUFhfWgCHBTQfsvWQjCLIEgx Zwi3djZAgo1dEsZzqYf1Y1eRUGuz4TxNd/+JQWwWP6/NTgrr02BVO0EujmVABhmFlXfs hsU6dng+nwoAcQ+sPk5vnUV//cIWYfy1BltsEsGWceygmvLMXJcUA6NlbJ6U5Ff2133o dRXsEm8m3fOtHG5aTpq/vU0Qe1/T99NmZ18BruXS9IfifoAoN7Ylg1FjVr6yQG1xkRHD cT+Q== X-Gm-Message-State: APjAAAUU8Y1htkJB47j1JpdX9WVTIEnyjWeJVhxGE2AhSbpvOCPah+SI rtTOL4KG8cZZ2ruc/Ua4n7xsGXmBIkYSkhuL1/VNKCiUgIY= X-Google-Smtp-Source: APXvYqxY1MyXpMW/TIDLxtqIzO+p0/+/tn7pAQPMeDl9kSf74aEWvsKhIxx0pOEsEXxvXLU61Ep/r8L6ix4Rkas3Bqk= X-Received: by 2002:a63:4241:: with SMTP id p62mr36570070pga.379.1556191935642; Thu, 25 Apr 2019 04:32:15 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 From: Rich Freeman Date: Thu, 25 Apr 2019 07:32:04 -0400 Message-ID: Subject: [gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards To: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 05e82054-0815-4786-bdee-2e0177242038 X-Archives-Hash: d05070a200e4f5858642d308d9b3e39f The OpenPGP smartcard standard, and the Nitrokey Pro smartcards that are being distributed to Gentoo developers, do not support having a separate primary/signing key for keys that are generated on the cards. As a result they can only be used in accordance with our current requirements if the keys are generated in software, which places them at a higher risk of compromise. The intent of the separate primary key is to reduce the risk of it being compromised by keeping it offline. However, if it were generated on a smartcard it would be exclusively be maintained offline, so it is counterproductive to require that it be generated online and then recommend that it be kept offline after this. Additionally this key needs to be brought back online anytime the key expiration is updated, which is at least annually. I believe this is creating a false sense of security, and that developers should be encouraged to generate new keys using their smartcards, so that these keys are never stored outside the protected hardware. By default gpg creates revocation certificates at this time as well. If a key is lost it can still be revoked, and of course the gpg fingerprint associated with the developer can be changed in any case and is the de-facto root of our trust system. These failure modes really are no different from an offline primary key that is separate from the signing keys. The revision adds an exception for keys generated on a smartcard. It does not prohibit those who wish to have separate keys from doing so, though doing this with card-generated keys requires having two smartcards. An obvious objection I can see is that nobody will be able to tell whether any particular key was generated on a smartcard or not. While this is true, it is also the case that there is no way to verify that a primary key is being stored offline, or used on a non-compromised PC, or that it even has a passphrase set. Unless we want to use some kind of hardware key that supports remote attestation we're going to have to trust developers to be security conscious, and IMO making it easy to generate keys on smartcards actually will facilitate security. This change actually makes the more secure mode of operation simpler than the less secure one (unless the primary key is kept online, in which case it provides no benefit). Full version online at: https://gist.github.com/rich0/7d11e2297d8b8a5586997baec2a99e30 Patch follows: diff --git a/glep-0063-v3.rst b/glep-0063-v3.rst index 5895873..86e5fd9 100644 --- a/glep-0063-v3.rst +++ b/glep-0063-v3.rst @@ -12,6 +12,12 @@ OpenPGP key management policies for the Gentoo Linux distribution. Changes ======= +v3 + The requirement to have a separate signing and primary key was removed + in the case of keys generated/stored on smartcards, to encourage the use + of these keys, and acknowledging that the main use case for a separate + primary key is largely fulfilled by having all the keys stay offline. + v2 The distinct minimal and recommended expirations have been replaced by a single requirement. The rules have been simplified to use @@ -69,7 +75,8 @@ not be used to commit. at least 256-bit. All subkey self-signatures must use this digest. 2. Signing subkey that is different from the primary key, and does not - have any other capabilities enabled. + have any other capabilities enabled. This requirement does not apply + if the primary key was generated on a smartcard. 3. Primary key and the signing subkey are both of type EITHER: -- Rich