From nobody Mon May 7 11:10:20 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D2A127978 for ; Mon, 7 May 2018 11:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sumptuouscapital-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqcTta8ZxZVH for ; Mon, 7 May 2018 11:10:17 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1BE12783A for ; Mon, 7 May 2018 11:10:16 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id y14-v6so41608569lfy.12 for ; Mon, 07 May 2018 11:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sumptuouscapital-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version; bh=S49+pgcNV0LKYq6QCrXQBKgUG1kqNAhHusUoGs2csFw=; b=hGAGKmiyHNzb1yj1n/Q1hbqjAp1NkFnR2VQDC/544H0jd2k5QMkLEnMJrwkS0LW6VO V+v36TwbZ83u00ZkRIKqow5r004eOsEkKEIUQR9u4F322Jrcep7t0EcSkI6bVXXQj+4U 5MPRVGm04mvMSIVuR4TYRqUjLk7jgAiWrXVFTy96CcIkTH3eLX/CL5wScYx4Hkgo3yrf gddAnECyy86VQtwsMlqorjcC9BgRm+pmx0KQhdumhj4nRVHzDsk/1OejVCEM573qFpmO WAUwsG1Mlb81BfqCPeSKukR6Xpn0I+aFxsJRwkCqMBK5B/xHDGlKubALy+WywdmFw68F QfSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version; bh=S49+pgcNV0LKYq6QCrXQBKgUG1kqNAhHusUoGs2csFw=; b=cGff0vhsTqKm5wSiZndAg8Y4OSnL6alYCctAyH9a0Z7ffbpo9SzxUIt3WbeV/Q7Z17 CDzjspXUH1aImkL5TzhVwfiHVAUIhh45jEh8O3rIO2jghE9HzZ0Q1YYCcOzx/JFF4z22 tKtDThey6TZnilCHgmZx8yVJ4xWbs7z1AEj20etfbDVX2q3JBNFk62nytLABgt9q50Iz qpORSyPU3YuJ3FlOiDmgenLy1yQS5PRWxnwb0sHx8dfJ1KIIr0r81AzABf9xa8qk0jMH zbNDsjmGAAdocAi4iEpSpHMOBdfIrtsbEBrHbP2cNt1KhYY2VuK95XjSWI7c1MttsE3u SIQg== X-Gm-Message-State: ALKqPwepfbMokNv/vfHQEZNcZ2IUIpVaGbTfHRfzoNCD1h5/Sv5RrtMf 53ByWUh4KSJEoZ84heulCKmuy4KHDg4= X-Google-Smtp-Source: AB8JxZrgr22Z10wgfDaRNALYPBMfPC9FnZJb/Z/dClapWzcs5RapbnyuOdjkvg6oUCQYgOfmmorQdw== X-Received: by 2002:a19:4e1c:: with SMTP id c28-v6mr4116123lfb.61.1525716614940; Mon, 07 May 2018 11:10:14 -0700 (PDT) Received: from [10.144.0.4] (host-37-191-226-104.lynet.no. [37.191.226.104]) by smtp.googlemail.com with ESMTPSA id w63-v6sm5038786lfk.0.2018.05.07.11.10.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 May 2018 11:10:13 -0700 (PDT) To: IETF OpenPGP From: Kristian Fiskerstrand Openpgp: preference=signencrypt Autocrypt: addr=kristian.fiskerstrand@sumptuouscapital.com; prefer-encrypt=mutual; keydata= xsFNBEdj//4BEAC3zjKRryW1mLec38x0w9ByG50h6KJddkZe3UNdGhAa3S5E4NAi/fUoe3gD LUDDmpHZNqtbMgrobwUNjLrp+PDZNdMJFAnbWXvmsMwuax0SWJzy4alem34tvir3a2PpnVr9 ylyAyxPChMM0ANelT/fiYIEysjAbHXjri89qdT+yA16CMljoun7vIOmq7ohKdNd1Dci6qoyj 0NllvR2AiBI+ZJnoF4hkRKO1PNUJROzn/ku88idaNkWyq7rREI+WkhS+K6xg1R/d6mTp+bHP tmwGlN4U1Lgx9qeitYzirkQeA8EGK/EEPPZG85WvXSrTftoPvQswOtW7I+jkTdd30GHXf6JH Rq4oR0mT65mqckycPjXNw6RM0fxyx06/kbVG8x3tzc3roJF+hR+h5QWIWsQOc3ZAhbJPWnfP D/kEN20yvb6EXWha+70QJbrBsnN0M8MLF7x+ZWTKESOVpshUBG67iq/FWCpv3st2VTq4M0Ep b/ORIKlfEgSsGv6waooF0ik41ey3k6PIcuHTq/sCoFoC6EH75wqsbmLkVSyqTKm3MSjlN26d ei425iCXJSyH0L1WmeS0i0rzcF5BCu9V280DmNFHWkr4iHiyrVcNyccocMTeh6/ZG7XSI0wc TONVNnKtofVHkzwHMdDlDx4lFRG+V0ftimR5THlxtG8AzQKY9QARAQABzUJLcmlzdGlhbiBG aXNrZXJzdHJhbmQgPGtyaXN0aWFuLmZpc2tlcnN0cmFuZEBzdW1wdHVvdXNjYXBpdGFsLmNv bT7CwX8EEwEIACkCGwMCHgECF4ACGQEFCwkIBwMEFQoJCAUWAgMBAAUCWiWhXAUJFMX2sgAK CRALf4tg4+364/YeEACSDL8stCAArMoqgXlTAdAKQFedJHyoS2QFVzuLx+k7CCGt0jVrNh3d HRQ92pF2QJScWKw76/LHvh6lMBPJwBEXRIvQNDNUb/zyBx96FipC+Dkd8Fxu3s4W+6YCqUBa lmC5XKB6uF/W5wanvpAn1K8bvUb3sq86RYTD0qZui4LMhvm8A0A1Na4+ZeGyfBFhcH5Oh+nh wkZjL7mbMTe25QCeCs4wQpYowia70EZLcQF4MboF9GzH5PIb0ipG5Jtfk9QfSlT+bnkRL1KR DR6rHo7iAYcMt4oJVU1qo1akSBe0MsMI37OdWDtNvUy2Svd2BCLZl49KZnErleC3R/axrtkL 2w1f0P4FoiuPq7mPeiUBhLaZLlc2fz490cEwjsgsY6GuiCWlbyjBMtp0OKM4VBqt5tdxBo/R X5Y6kNOGWpDHx8D+Dl8ToTDJuH2I0k2wfcUibYzWfwXpPpwZ5iXidwLYXbBQ2qqlyB7MP3Po z3zl+UulJyxIYGjg2sO4FmmRs0tThceaNIiDtP5uPLu77oCkAAsWuFSfa6Iwq9+PIQTqTFhH nJ1v/xrdqKWSYB6tm9Tkb0KkUKxFhc7QVyphvh473UEAQ78bQFWrGHqiejQtiiR3MOubwUyt YkNi+ef068rs27SPfRmBAvRw2EMZWhWyX/P2xM4PPp24reOn4ZuAAM7ATQRVZfyNAQgAvppy gWUI21WpA8IZZC+HXywKOqAIXgEQG8m62kVE048A8gjwk8vcmDKU0vlD6OGZ0capeWzWK5kN Gi8kl4ejvgULXKQCAV8ycEUWXmBSmzabhGruMY96Hy1OILc9tb3Wpg3wggW+PZjc5IuLIa1k 9AiDg6SQExDhC27x1EUKZkxkIG+EThSKHbCFB3t4tbwlI8Na4LUfjOxCILA2KVl7CXD/eUNr apJeSGJOtYEhgNFhuHoSG7Po9k6cy2eRrviq9X9cEW10Y3ocCypKvenuUjrN4bUd0IUsODLy cZ3aL+zEmIdhZsG7dQeFmFeJKK+XDgLIMNgr+EP9+89U/COZ5QARAQABwsFlBBgBCAAPAhsM BQJXwxA2BQkE4salAAoJEAt/i2Dj7frjuDIP/2qDloXeGXfMLASc85cp09JLKrbISlTQZkvH WCQREQWzv9LJ4nUcELIhPTc18ntLhU+xJXLP+9d09cOlIiWWjRXXVCZ8IkcSkUplwCQz0Z2h XpmIOm/kycIDgo+qDCRrQhOCX3IhXGwslT7hWjUf/BlKN9f89Uy7VjBFLACOyP3hBZ1uLswN PcSfks/BzTtGTRZ/TEQxgmw0K2BwyJAwnMFqj8kQwc39P6euHln+33alzmUHDsp5rKUsMl58 x18jrV9KLokU/mDHZXoFeLY61dm9Nr46g+T9YYQagvGYfxIAyR9XcHeK1VxxCieSfC/jLKIT A9pu4Hgevl7DGm5/NHzUtqpwRwcbCqvj95Rgfe6lBwuD5g3olAXpZIQKbx73pWdoH0rwXGrQ Bs1weeFbIyVvoCozWoAoU7wVQSr8rHHZeq70b3Zp9DFdkXiSMu3LhU8Byl/spT3rQyLzCBoW DKDrKkifp+HV4mHoypxwD90CcEjeVObpCmhIEaxIDGKl2QaTm+RTwmVWCqr4YFv7QHRMmFVu STZpPmonZzK6VQJByeJMTDlbL0OpczJ8oVHp6txESKj/17xTs8JU1e/SSsdcYjFuLpzHvb97 0F5NQwMZeVuYRvJlCxL7z4Bpj7oPweATfwP43b+JWAser874u7AlBfonXTxe47pbYMioHPnb wsFlBBgBCAAPAhsMBQJaJaF0BQkGw/ojAAoJEAt/i2Dj7frjgbYQAIYDkXvyczRVnEZloYQb HsqjGwekWXTkTk74yYF5U+GoGGzbdFAmF2FhhWxlwIoPLtWoUXmdBknyqtAHCIlYrqPi0fsY 6SdIU3qdDDESjR9gixoPKOP5pFRC3KsPn0MNUXElbkdHvn0YSjuj0GdBi8YUa1XGRNW/O8PH 4HP900OipflQhuEC3yI5AYiq+Grd80RzJg8F108bn8YmoHapV5zZGfzp5L3pHCNOGsBlpTDr QA3XvlKti3AujaF88Nq3tj5kTsj73I30WOctGH3d9QWdySuK5RekAYvMSHU7M9oHtwV9dfVd RFbbuP4fhf+yF56Syu0k7jGe8e0d1xshwOMIXu8/3z4hYOpPfAvkl7n3QNHeqtT1KwRYqCCw KeK8pKZZlsBJ3D6XPuEZyTc/JIiZr8yALslTYubCCNyYQj7fByxM7neVPPaciNhbkGHImwfJ GPBSEuP/UXciroUcrvwwGfY76+WvezaU+O3SLcrT9i+emo9uA14Syb51RWz8h/x55Yu2UpON hArhearvW+0kJBx/YzG0Us7TLMNAiiQYlGibMmaBgRWW33vMXWT9H3FIN8L1NI/Qvy3/N0zD HawUOUvVMNtAzbWexFtxXQ7zyxLUBHHhFdezpWyXmm71qEaOMdDLnTwLqv3ENHUfZzmCc2Kt ZjTX0qrgBQD08nPn Message-ID: Date: Mon, 7 May 2018 20:09:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4uZWfmB2s32r8SyABwz5eH2lvot0JHZ5V" Archived-At: Subject: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 18:10:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4uZWfmB2s32r8SyABwz5eH2lvot0JHZ5V Content-Type: multipart/mixed; boundary="lgVPVX8zBh4k5XzdHss5Eewfe5nSy6pg9"; protected-headers="v1" From: Kristian Fiskerstrand To: IETF OpenPGP Message-ID: Subject: Clarify status of subkeys with certification use --lgVPVX8zBh4k5XzdHss5Eewfe5nSy6pg9 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, =46rom time to time there have been discussions about whether certification subkeys are valid according to rfc4880. I don't believe they should be, and I also believe the current specs can be read in a way that it isn't, however I would ask that we are more explicit on it in 4880bis in order to avoid any ambiguity. As far as I'm aware current implementation will ignore certify capabilities of such subkeys. Some background; section 11.1 of rfc4880 includes; After the User ID packet or Attribute packet, there may be zero or more Subkey packets. In general, subkeys are provided in cases where the top-level public key is a signature-only key. However, any V4 key may have subkeys, and the subkeys may be encryption-only keys, signature-only keys, or general-purpose keys. V3 keys MUST NOT have subkeys. =2E.. Each Subkey packet MUST be followed by one Signature packet, which should be a subkey binding signature issued by the top-level key. For subkeys that can issue signatures, the subkey binding signature MUST contain an Embedded Signature subpacket with a primary key binding signature (0x19) issued by the subkey on the top-level key. Arguably if certification was intended for subkeys, the list in the former paragraph would likely not be explicitly mentioning encryption-only and signature-only as well as general purpose keys, without mentioning certifying keys, but rather say all subkeys or similar. This is further strengthened by the second part that mentions signatures (which is used for data in our context, whereby the use flag for certifying other keys is clearly marked as such) In any case, there have been discussions along the way, so I propose we explicitly mark certification subkeys forbidden and ignored by implementations. Maybe something like; "when generating a subkey binding signature, the implementation MUST NOT set the certify usage flag. When interpreting a subkey binding signature, implementations MUST ignore the certify subkey binding usage flag if it is set." PS! As a tangent point, we likely also want to change the default behavior for no usage flag specified for v5 to be ignored as not having a recognized flag, instead of defaulting to all features, although I don't have a specific proposal for this. --=20 ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Ab esse ad posse =46rom being to knowing --lgVPVX8zBh4k5XzdHss5Eewfe5nSy6pg9-- --4uZWfmB2s32r8SyABwz5eH2lvot0JHZ5V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEtOrRIMf4mkrqRycHJQt6/tY3nYUFAlrwlj4ACgkQJQt6/tY3 nYXr+Af/epwEMGYZmgcnanWcGsQTWSbJrk8sfXeqET51mA3H+KFv0+vT0BwPfKno eNvRxZa3hn73Mm2anDhKxiffHL57s9RqMBsfS825F+MqrisjIMJFQERV1H1JU1yF xq60cxCC/1NMh6iHKYnwaXy3SefkuPY2zzpOrTlbw78aLJXqQ5lDa93JjDNILBDw LNvyXjhvhhod8aKcYauDVUq7iePzY1CEMRchYXJ73OEto+iKhZwWCj+i+jfzKziH twuYqd2bAXoeCEBIn5Y1FTYjyd9rR+F1P25HoVrp5ssmPK3gU0x/t1CQyxhyNvsY 4L2GPONXnUOAUTW6dnYtaJTzqZe4yA== =RmaF -----END PGP SIGNATURE----- --4uZWfmB2s32r8SyABwz5eH2lvot0JHZ5V-- From nobody Thu May 10 16:44:53 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D0C12D7F6 for ; Thu, 10 May 2018 16:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FjQXIUO2FGF for ; Thu, 10 May 2018 16:44:51 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EBA1250B8 for ; Thu, 10 May 2018 16:44:51 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id C5578F99A; Thu, 10 May 2018 19:44:45 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 327C12058C; Thu, 10 May 2018 19:44:40 -0400 (EDT) From: Daniel Kahn Gillmor To: Kristian Fiskerstrand , IETF OpenPGP In-Reply-To: References: Date: Thu, 10 May 2018 19:44:39 -0400 Message-ID: <87efijjct4.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 23:44:53 -0000 On Mon 2018-05-07 20:09:01 +0200, Kristian Fiskerstrand wrote: > In any case, there have been discussions along the way, so I propose we > explicitly mark certification subkeys forbidden and ignored by > implementations. > > Maybe something like; > "when generating a subkey binding signature, the implementation MUST NOT > set the certify usage flag. When interpreting a subkey binding > signature, implementations MUST ignore the certify subkey binding usage > flag if it is set." I like this proposed text. > PS! As a tangent point, we likely also want to change the default > behavior for no usage flag specified for v5 to be ignored as not having > a recognized flag, instead of defaulting to all features, although I > don't have a specific proposal for this. This is a separate point, but it also seems reasonable to me. I'd be fine either way -- but we probably still want to specify that v5 implementations making a subkey MUST include a key usage subpacket in the hashed subpackets section. --dkg From nobody Fri May 18 13:26:13 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5989C12DA6C for ; Fri, 18 May 2018 13:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T40dW22uDH1E for ; Fri, 18 May 2018 13:26:07 -0700 (PDT) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527C912DFDB for ; Fri, 18 May 2018 13:26:06 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 6d4f939c for ; Fri, 18 May 2018 20:26:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=to:from:subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=grym-20170528; bh=HcNhi9xtpp1TrKmJ l+DImTpxfKc=; b=gPIgdViPRhAUqU5cvgAFUkTKL14A2fH7PYn9gwNSvr+i/7nf lEEEnVO18ZGVP+jgUT46XsJzOB/U/DbwyDuvjgrAXZR5Naw+xlWygeU/r0NSnW4F a2tQVC29TFH2io47p3MBtUiEu+0q8ZeXRkesHjtOuFtYz1hWvPpYBmVMSfw= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id e4a31ff2 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Fri, 18 May 2018 20:26:03 +0000 (UTC) To: openpgp@ietf.org From: Leo Gaspard Openpgp: preference=signencrypt Autocrypt: addr=leo@gaspard.io; prefer-encrypt=mutual; keydata= xsFNBFXhpEQBEADhOlZssy/qmNV0acTKB/ucRTGhsPt25v0R0HQ0AlpU/bY0rWbTMEYAJhFM 0owTsdJ1ATHvQCbRz9EWNGSL10nTjdX7LDrpCBURUu8LabQ0VpKvyvj6WqmeiOP0bQaIAHMA FHWCaq4FAXCcWl6DvN3h5yYbkN3k0IoCPoOnvSg7qYXwhMOzk2wHc+6T40cCj2PmTqP4lrnl vpl8UZubRlrCDihCTxvzKU5vlywgj6xeCsKUykPH/i62NWW6M0n/ChERkD2IFXYK+1zGVHpq SLyEpsC4ShJ1wswbI6e5Pw0W4XHjEr+voq6ljdrFZiyGbjdDSx+euZdXb4Y/3y3Y9HdXWLBj uN1+yY47ikpVBVoG6yEFarOhYz/SeWObFj8AUUphlUgqbn8W+7hRCDIOXMgA5YuSoeS1hQ+n 0fwpUYgPd1AvNz61P6sNO5Z4vgxmBQATv4z1/MuVMmstsVwPHnCVF9xX9ebcaU/RvJI6EmaW AnhiPLfeFZ+hYvIkk69elEgAhKNcDdKVeQY8K0n+wfb1S8kZxNTne2twILr0rLZ1BzRe7DUG yg0x4s6Jx0ChzwI0Non0csecaCM7bHIhv1+kc20KD9uNlAWmlRrQRpcRVaq1Y230SHS/hS5K saKRsWeQDsfmMxgesz2v5dxc2Dx32GxXPnxoZwk/93EQqhbbeQARAQABzRxMZW8gR2FzcGFy ZCA8bGVvQGdhc3BhcmQuaW8+wsGABBMBCAAqAhsBBQsJCAcCBhUICQoLAgQWAgMBAh4BAheA AhkBBQJaDFmwBQkGIQDsAAoJEGWY8jXyP7KuzEwP/A4rynzccNlRuJgV1giMvRBb+osRW+2H FYXu6gOdRTpkcRD903nstbYbC+LiQB5wwAhoJrWxOChY8fwVJqbrpD3ZbBlAYBZ79NKCSzYA iJsVgpYXMXe+7F0g/eldJccluR82ipHQgUaCnGMMUWTgbmPVH7K0ytobCbHaFIALG0uqe+XH PJ5OGD9giefox5ntuQKDhJRs7783CObwHa/0pk3hPCbYE6DtfhWx5teiW6+GsEf0kAIZ5E+7 cEfCiNj/0AqVph0M+3A68x4nOMV//maM3yWVv77zumeyaPsRlWiqK/9YTYUh/lZtbPezBytP hGtsqEStGdmhAoc2M02gPIXzmBjUTzXSnfWWOJsxsptqAo2LIZrRBCsM1laRBX5EAQrfFeZg eFKIJfRzX+IA/UbfdDKSjEU7Ei+ChQdW3mXOFlJkcsTICurgjwrGIrh6k0ifkerVdTX/0agn kDImfMenj5x7Xf6d+M62PIcX0efVe7BtSji/nJPowEcOlWhzQH3W5bup50ZWnowcyT2CJx8b 1J7aIn1dPnmKmUvl2HiOGF6XtyVivQLrth941Tr3o5u/b/R3hsIoL+azlRWXonPBnBc21KGR 7GVdDjAPcMAqjx0KJfUSKVGkE1WxHJH+xwieFNZlPwnrCx5xOAF5rN6BYWg5adkqC20Y5zyw 5VH/zsDNBFhATnYBDADJd9VSNqYfQ6xnQ+SH3pBuAd721I00JG+ewmtChbTFC1Hw19Ks6c2K 3IXl7f1aVIjJzz0eQ+rG9FhmlswPnMtsWu0phV1EtuOWZPpvQMEikc/tzJ8SGgt4g80LPUSU ew04q5Q21MtoTAYqY4PfWZSp8YkvTjpTLWnmrNVBcqctHfWzElEYpPDD+j1ID7GJbVKFuTXs ZvGktr8Quyb3rIiRESvn08w2usviiHIvIypa4r8jOEnwAAEcSz/2By9zhCdie/r78co7bWHK hAX/oThylKXgTEwmiDRl2/iu0MBT8PmYavu8Cmjg09HWUFXdZNkPOPLD9bymb9mARRS3/OMb Uu5Vg/d6TgLFjao8/KKdlFK1k3asM9mXxz98VtUOxgtOP/DOEuIPaYJLnhV0AyezmuddPLYk 5s1BYk9wBolOf7+iq4MlnUzgKT6gfQiB3NZkhdChULLeaZZifRKrENQ/beDqhbzA63xg2vzJ T+AyL4fKAjS8fiTaplUta59Tc0kAEQEAAcLBZQQYAQgADwUCWEBOdgIbDAUJAeEzgAAKCRBl mPI18j+yrsu+D/9v13WE8OJxlqsVnrOcsLw2Gnd78lqHwGu4FOBiGJfg2Kt9YcSbFvdg6Agm erNgt+W1Xdair4CXyr4CRSCAfqLdZSNLetjudy6rKrrzWPxiCAkW/HQrqI5RGTx8GPFDLLhd 4avAPA1270W3gWUVYPk/R5SdUVIKHA/2Hum/aR0+6zHA/NOmX3P6KAPixDY+raKLdSTy5wWo 8j6YArJIpwol0N98EqXBpT+H4++eY+x/fr4V3w1YnASKRRIETsTVFP6uk7v5EH32cXSSHW+O HIMUMP/4f0KC1sVqVjiZT6uRKTkujYaZbg01s5SM4jR11zXKQEQOIEfisQ8Kb0o8uRQkE//I Adf5u/d9Ed0UTPYiyWU8wPqndpwmvCX7ddfzaiZbSYXQvQ7KFVVqUnbdbcqSqTuEkzk2+Zkz OS2ZQaw/ZVjs6X2PjTrzqTF1S/1kvZ96fLsxJ/xHLjFQJlUykF5LxtNUyBiPvSmqwGnYSMqj 3u8e65kHVhcRgHxKqfg+TXGgHsfdsXw42ofMiAIoi39oWkQC+qRFGrfvSeg2h3jHER/d6ryA 2Lm1Fwe1GFx4lnhBZ+hsyAPNP+37BS2aNixnoFSQR5JHsF1EfcsSAOnZqHrtz0fC6UpnggKI QJgn62UqdB16FG80fI/Ic9BpEJmB6W0kQyty1DUq7YGUfK5mN8LBZQQYAQgADwIbDAUCWgxa GQUJA8JXIwAKCRBlmPI18j+yrnGYEACKZYR8/hjckHSrwfbdltS5NOrBOpNM/pQv1ZXO2jm1 pYZLf8qSwQSy7NRd1A8ebk6LiqKZeMvOxP+zFWpABdjOlgrGGaVtIqWKvqBhw/Db7sXvsPvr gGiKYupKwGe3K/LIrp7aCq1Rx42mp6ZaclDry2JoD/4orx8zlZIDx27LwOdLMHTQD1rVKdrr dKUXFxwNWT1QF94/uxI3Qs5UJPD7/uONFmPPdz/e0OrCVusNvvwVumJdP0WRXgsWcbtP7wZl YzIi/tVzXd+seq/ZCdgQZiw909wlmG4vA4wOwbJE/CTiGaJGRmGc+dNTziGadsndRN2QmXUt z1/6AP2eufnoDyQ2IffEL3iCVhMZ21hjpT3Km8pGddcROSu4sCCiWStAgRk4BfqR74vZMo+8 oybArbnMF5CnC6Aak8sBz17B4jqKIck+1Krge/EgbbBt25hEokdRZJXfvecYEVpj8EGG1KBz JZI+Zgz8Za1hjoAlPbqlYMqR6gn9cq8kmAjWFBU3ajkvcL0SMrmAJdYQ0rE0+Jz8ceBLZqUy rwoipQp5C+ShkUiwXZRv5OQvWkHa6fKLQMKBpPhL7TfPzyljnRRSkXtOcYhV1pdKzK5nPrvs z53hmaWDgBqsbXyfPhckLi+GHPQXFn0ib8CINJiGn3g6imILS2/30RtVcwGiCBMtzw== Message-ID: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> Date: Fri, 18 May 2018 22:26:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [openpgp] Scoped trust (signatures) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 20:26:11 -0000 Hello, I have subscribed to this list only recently (late 2016), so please forgive me if this has already been discussed, as I couldn't find it in the ML archives. I also hope I didn't miss something fundamental while writing down this idea. As I understand it, currently, with OpenPGP, it is possible to simulate the Certificate Authority model: * The clients wishing to use it assign full trust to the root CAs * Root CAs use 255-trust trust signatures for subordinate CAs * Subordinate CAs sign the verified OpenPGP keys I think it would be great to also be able to simulate the DNSSEC model, so that as a client I would be able to say “I trust [this key] to make statements about [this set of keys].” I see it as, is in a way, a logical follow-up of Web Key Directory. As I understand it, RFC4880 already has a provision for such a model, with §5.2.3.14 _Regular Expression_. However, there is from my reading an issue with (the wording of) this section: it only restricts one-level trust signatures. In other words, from my reading, if: * User U trusts(255, r".*<.*@ca-a.com>") "A " * root@ca-a.com trusts(255, r".*<.*@example.org>") "B " * b@ca-a.com signs "C " Then, from A's point of view: * root@ca-a.com has trust(255, r".*<.*@ca-a.com>") * b@ca-a.com has trust(254, r".*<.*@example.org>") * c@example.org is valid However, I don't think c@example.org should be valid, as user U only wanted to give permissions on r".*<.*@ca-a.com>" to root@ca-a.com. So I think all regular expressions in the trust chain should have to match in order to not be rejected -- in a similar fashion as the DNSSEC model. So the “wrong” line here would be b@ca-a.com's trust, which should be calculated as trust(254, r".*<.*@example.org>" AND r".*<.*@ca-a.com>"). Another issue of this scheme, obviously, is that noone “in the wild” currently uses regular expression subpackets (that I know of). However, I hope this could change, were this change to allow creation of scoped CAs, that would interact nicely with WKD. For instance, a mail provider could set up such a “CA”, that would automatically sign all keys that would pass the WKD test, and for which the UID would be confirmed as valid by the internal database. Then, users could start trusting such mail-provider-provided CAs, for additional validation of the user ID (in addition to the localpart already “validated” by HTTPS), while still restricting them for only being valid for the domain(s) they own. For easy discovery, mail-provider-provided CAs could have a path at .well-known/openpgpkey/mail-provider-key, and the user could decide to add some trust to this CA. The aim of this proposal being to make OpenPGP easier to use by introducing ways to reduce the work required for setting up a secure channel, while leaving control over these to the user (or to the implementer, for opinionated implementations) What do you think about this? Cheers, Leo From nobody Mon May 21 13:04:27 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5DE12D86B for ; Mon, 21 May 2018 13:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIzi-KnzyAD1 for ; Mon, 21 May 2018 13:04:23 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850B4127010 for ; Mon, 21 May 2018 13:04:22 -0700 (PDT) Received: from localhost (i59F77C56.versanet.de [89.247.124.86]) by mail.mugenguild.com (Postfix) with ESMTPSA id AD66C5FAFE for ; Mon, 21 May 2018 22:04:20 +0200 (CEST) Date: Mon, 21 May 2018 22:04:10 +0200 From: Vincent Breitmoser To: openpgp@ietf.org Message-ID: <20180521200410.kxq7nj6gyki5yvhx@calamity> References: <20180305231951.GA21944@calamity> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180305231951.GA21944@calamity> Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= User-Agent: NeoMutt/20180323 Archived-At: Subject: Re: [openpgp] Intended Recipient Fingerprint signature subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 20:04:26 -0000 No feedback on this at all? Should I maybe create a website and logo for a surreptitious forwarding attack? I'll add some more motivation: There is currently no way to distinguish signatures made for plaintext messages from signatures made for encrypted messages. This opens up a scenario where a message is sent as signed cleartext (which many people do by default), and only encrypted at a later point, for example by an inbound message encryption feature. At that point, there is no way for a mail client to tell whether this was actually an e2e encrypted message, or sent in the clear. As a straightforward fix, I propose an additional "sent in the clear" subpacket that indicates when a signature was made over a message that is sent in the clear, and wasn't intended to authenticate an encrypted message. - V Vincent Breitmoser(look@my.amazin.horse)@Tue, Mar 06, 2018 at 12:19:51AM +0100: > Hey folks, > > dkg and I have been discussing an "Intended Recipient Fingerprint" > subpacket, that pins a signature to be valid only in an encrypted > context to the indicated recipient. > > Use of this subpacket removes some wiggling room for signed+encrypted > messages. This can be used to prevent replay attacks, where a signature > is taken out of its context and forwarded to a different recipient. > > Please see https://0xacab.org/schleuder/schleuder/issues/158 for a > complete description of an attack scenario in the context of the > Schleuder remailer. The given scenario is solved with this subpacket on > the openpgp layer. > > Diff attached for rfc4880bis, please comment. > > - V > From nobody Mon May 21 13:07:34 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A920812D87A for ; Mon, 21 May 2018 13:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOEFjzw0kbSI for ; Mon, 21 May 2018 13:07:31 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7D912D86B for ; Mon, 21 May 2018 13:07:31 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w4LK6tEe006698; Mon, 21 May 2018 21:07:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=pUJFfzFkq5GhZ6dvhcGr7jkbwLhTyRnlWvzYTVcz2sc=; b=n5dYfDlS5Sowz/qrCKBr3gWpNmJ0iOWAbrlNdalZir0oBdOggv0eRg50l3PcFK2E2IuV 65EYJ+oriovR1zVHjmVRbC0XD03fuwZAb6475rpWdfXUY7rl9oNRThurFmQAnfq3uW1W GYA7pAP5wG5wTo0H3Ou/Go26Lp42WH2E7gVgjpCKe4S4RHszHvyn7hQ16/CdaLA1Tj4I GDJmlsdaMbaLu9E3sdSBJFiIcc6aveJC3ZrjeJeLCMvWthSx7hd0/BjF+TtwoZ+VMRCK 5x3z1AXowt531uWAZbwAZ0SblNX2dkoxsL0Xsm3FMdSO9l5KerBSwbEfNrUiKA3TjYA1 KQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2j2bf1q9aj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 May 2018 21:07:30 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4LK6Vk0026432; Mon, 21 May 2018 16:07:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2j2f8w1k3f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 21 May 2018 16:07:29 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 21 May 2018 15:07:28 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Mon, 21 May 2018 15:07:28 -0500 From: "Salz, Rich" To: Vincent Breitmoser , "openpgp@ietf.org" Thread-Topic: [openpgp] Intended Recipient Fingerprint signature subpacket Thread-Index: AQHT8T7zR0rIb3H8Y0adUtWHpFxTT6Q6rPOA Date: Mon, 21 May 2018 20:07:27 +0000 Message-ID: <135B4665-FC34-4689-A413-1DB46B9D1D14@akamai.com> References: <20180305231951.GA21944@calamity> <20180521200410.kxq7nj6gyki5yvhx@calamity> In-Reply-To: <20180521200410.kxq7nj6gyki5yvhx@calamity> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.0.180513 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.189] Content-Type: text/plain; charset="utf-8" Content-ID: <6E9C1D2FF45B47459F851FEE06562634@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-21_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=295 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805210239 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-21_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=245 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805210239 Archived-At: Subject: Re: [openpgp] Intended Recipient Fingerprint signature subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 20:07:33 -0000 WW91IG1pZ2h0IGZpbmQgaXQgaW50ZXJlc3RpbmcgdG8gbG9vayBhdCBhIHBhcGVyIGJ5IERvbiBE YXZpcywgIkNvbXBsaWFuY2UgRGVmZWN0cyBpbiBQdWJsaWMta2V5IGNyeXB0b2dyYXBoeS4iDQoN Cg0K From nobody Mon May 21 14:37:47 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B5512D88C for ; Mon, 21 May 2018 14:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqxVHAuCw1c7 for ; Mon, 21 May 2018 14:37:45 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA48C12D88B for ; Mon, 21 May 2018 14:37:44 -0700 (PDT) Received: from localhost (i59F77C56.versanet.de [89.247.124.86]) by mail.mugenguild.com (Postfix) with ESMTPSA id C64445FAFE; Mon, 21 May 2018 23:37:42 +0200 (CEST) Date: Mon, 21 May 2018 23:37:37 +0200 From: Vincent Breitmoser To: "Salz, Rich" Cc: "openpgp@ietf.org" Message-ID: <20180521213737.zzirb6imki5joecx@calamity> References: <20180305231951.GA21944@calamity> <20180521200410.kxq7nj6gyki5yvhx@calamity> <135B4665-FC34-4689-A413-1DB46B9D1D14@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <135B4665-FC34-4689-A413-1DB46B9D1D14@akamai.com> Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= User-Agent: NeoMutt/20180323 Archived-At: Subject: Re: [openpgp] Intended Recipient Fingerprint signature subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 21:37:47 -0000 > You might find it interesting to look at a paper by Don Davis, "Compliance > Defects in Public-key cryptography." I looked it up, but I don't really see the connection. Can you elaborate on this? - V From nobody Fri May 25 02:59:59 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3C412D957 for ; Fri, 25 May 2018 02:59:57 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGmuZJwMiNOR for ; Fri, 25 May 2018 02:59:54 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A901E12D958 for ; Fri, 25 May 2018 02:59:54 -0700 (PDT) Received: from [62.119.166.9] (helo=chu.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1fM9Vl-000821-LY; Fri, 25 May 2018 09:59:49 +0000 Date: Fri, 25 May 2018 11:59:44 +0200 Message-ID: <8736yg2gz3.wl-neal@walfield.org> From: "Neal H. Walfield" To: Kristian Fiskerstrand cc: Justus Winter Cc: IETF OpenPGP In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 09:59:58 -0000 Hi Kristian, Justus and I have been thinking about how to realize per-device keys and approximate forward secrecy. These two things are related: if we want devices to do their own key rotation (and I think this is sensible, as the alternative is to somehow regularly transfer secret key material to each device), then the devices need to be able to generate self-signatures. Since we don't want all devices to have access to the primary key, each device could have its own certification subkey. We also want the master device to be able to revoke individual devices if the device is compromised or retired, etc. Using certification subkeys, it is straightforward to revoke an individual device: we just revoke its certification subkey, which automatically revokes any self-signatures that that certification subkey might have made. (For those familiar with object capability terminology: one way to think of a certification subkey is like a capability wrapper.) Consequently, please do not remove certification subkeys from RFC 4880bis. If anything, I would prefer that RFC 4880bis clarifies that certification subkeys should be supported. Thanks, :) Neal & Justus On Mon, 07 May 2018 20:09:01 +0200, Kristian Fiskerstrand wrote: > > [1 ] > [1.1 Clarify status of subkeys with certification use ] > [1.1.1 ] > Hi, > > From time to time there have been discussions about whether > certification subkeys are valid according to rfc4880. I don't believe > they should be, and I also believe the current specs can be read in a > way that it isn't, however I would ask that we are more explicit on it > in 4880bis in order to avoid any ambiguity. As far as I'm aware current > implementation will ignore certify capabilities of such subkeys. > > Some background; section 11.1 of rfc4880 includes; > > After the User ID packet or Attribute packet, there may be zero or > more Subkey packets. In general, subkeys are provided in cases where > the top-level public key is a signature-only key. However, any V4 > key may have subkeys, and the subkeys may be encryption-only keys, > signature-only keys, or general-purpose keys. V3 keys MUST NOT have > subkeys. > ... > Each Subkey packet MUST be followed by one Signature packet, which > should be a subkey binding signature issued by the top-level key. > For subkeys that can issue signatures, the subkey binding signature > MUST contain an Embedded Signature subpacket with a primary key > binding signature (0x19) issued by the subkey on the top-level key. > > Arguably if certification was intended for subkeys, the list in the > former paragraph would likely not be explicitly mentioning > encryption-only and signature-only as well as general purpose keys, > without mentioning certifying keys, but rather say all subkeys or > similar. This is further strengthened by the second part that mentions > signatures (which is used for data in our context, whereby the use flag > for certifying other keys is clearly marked as such) > > In any case, there have been discussions along the way, so I propose we > explicitly mark certification subkeys forbidden and ignored by > implementations. > > Maybe something like; > "when generating a subkey binding signature, the implementation MUST NOT > set the certify usage flag. When interpreting a subkey binding > signature, implementations MUST ignore the certify subkey binding usage > flag if it is set." > > PS! As a tangent point, we likely also want to change the default > behavior for no usage flag specified for v5 to be ignored as not having > a recognized flag, instead of defaulting to all features, although I > don't have a specific proposal for this. > > -- > ---------------------------- > Kristian Fiskerstrand > Blog: https://blog.sumptuouscapital.com > Twitter: @krifisk > ---------------------------- > Public OpenPGP keyblock at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 > ---------------------------- > Ab esse ad posse > From being to knowing > > [1.2 OpenPGP digital signature ] > Signature made by expired key 250B7AFED6379D85 Kristian Fiskerstrand > [2 ] > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Fri May 25 03:27:02 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D239126C0F for ; Fri, 25 May 2018 03:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koZmU8q914ko for ; Fri, 25 May 2018 03:26:59 -0700 (PDT) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7361200A0 for ; Fri, 25 May 2018 03:26:58 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 12cfb35f for ; Fri, 25 May 2018 10:26:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=uldqEJ5kFMYTzwSoILGGRE44C8E=; b=b7jbhokqSW1kW3 O5h1qMmtMnp+3oRds+JuzVXk1519aDHklEiMled9C07ffJ1qE8GVz9PaaKgRLtoh gaCHYMhlBf05HYaf/USphGhU6wkwWXhn2L157bWHfvRfo9IM5AwWb//6YX/zYPRV rPTn1yoUQCJx0yHg5EDeltTxZxdqA= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id c317f0fe (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Fri, 25 May 2018 10:26:54 +0000 (UTC) To: openpgp@ietf.org References: <8736yg2gz3.wl-neal@walfield.org> From: Leo Gaspard Message-ID: <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> Date: Fri, 25 May 2018 12:26:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <8736yg2gz3.wl-neal@walfield.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 10:27:02 -0000 On 05/25/2018 11:59 AM, Neal H. Walfield wrote: > Hi Kristian, > > Justus and I have been thinking about how to realize per-device keys > and approximate forward secrecy. These two things are related: if we > want devices to do their own key rotation (and I think this is > sensible, as the alternative is to somehow regularly transfer secret > key material to each device), then the devices need to be able to > generate self-signatures. Since we don't want all devices to have > access to the primary key, each device could have its own > certification subkey. > > We also want the master device to be able to revoke individual devices > if the device is compromised or retired, etc. Using certification > subkeys, it is straightforward to revoke an individual device: we just > revoke its certification subkey, which automatically revokes any > self-signatures that that certification subkey might have made. > > (For those familiar with object capability terminology: one way to > think of a certification subkey is like a capability wrapper.) > > > Consequently, please do not remove certification subkeys from RFC > 4880bis. If anything, I would prefer that RFC 4880bis clarifies that > certification subkeys should be supported. > > Thanks, > > :) Neal & Justus Another use case supporting this opinion: certification subkeys are also a way to increase the security of an offline OpenPGP key, as with them it becomes possible to put the master key behind a diode while still being able to certify keys, and only ever move data out: 1. On the machine with the master key, generate a certification subkey 2. Move the certification subkey to another system, less trusted 3. Push the to-be-signed key to this other system 4. On this other system, certify the to-be-signed key 5. Rotate the certification subkey from time to time to be able to revoke one were it compromised This thus enables people to participate to the WoT without compromising master key security. I wanted to do this for my key, but learned that it was a not-very-supported capability bit, and had to fallback to pushing the to-be-signed keys to my offline system, thus making it handle untrusted data. So I think clarifying that certification subkeys MUST be supported would be better indeed, so that people can assume RFC4880bis-compliant implementations do support them, both for the use case described by Neal (ie. usability) and this one (ie. security). Just my 2¢, Leo From nobody Fri May 25 08:17:30 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA78812EAAF for ; Fri, 25 May 2018 08:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sumptuouscapital-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lfh3fAN3GSEg for ; Fri, 25 May 2018 08:17:27 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974171200C5 for ; Fri, 25 May 2018 08:17:26 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id x9-v6so9856444wrl.13 for ; Fri, 25 May 2018 08:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sumptuouscapital-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=IKdygk3rUTmEoadwFigdoSDr172Gw/uPy0jn2oAmEA0=; b=U4QJkoH4+uMsGReI6cPv5ZtMuuISjEigm5aW5X1+kUPpWb/VbRdg/kaRDWQBlkMy+g psvk5tCN6uD5J2PAH3sjqcid7nI7SHP+WOt8aQIKY69xsqO323uxeUFwx/bNbsYJ4COm iMhj/G/ULpPh/1vSsfI2XkAb/GbE5e58ca+Zes28rVEX9Fo9AKs0oINGed64U/Sk9QzJ 56ZxYiTe+H8zFpMeYLML+7dEXnL2Vf5G8aHOqoi6YzLXMKLwHsUrptCKgZYDpFM7u6L+ 0E/t/pv3DEnWsP9QF9x0WTOBsgornEHTjwonPMgC7alGDfGnK1f5Fw2VwpX2izXxVvhf u1Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=IKdygk3rUTmEoadwFigdoSDr172Gw/uPy0jn2oAmEA0=; b=jWIvy/K04NtHNDqdrRrhm/9lzsHvQb56lGFKl0QCQ0OUolmIKS9TDYN8r5mFKAMHrB AXLAFO6ciXNJzlv9G6IHFbZgmWZQCKn78MpAn9aD/UF+3aRSAeKAg7SWytMP++/NspvJ aESes2CjiR5nzxnqH49qt1U7bDf602FMNJl/bc8kIpu2kYcmXAV/YCzxjhwvL2cBEepI IzVqE4hnvYrnR2qN+mKyEJkaL78VIuz5nZsgvamF9oEgx5fixhPUTvH97IB8ergy++mE s/R4EGl6LzIga2ehhWSfitnPGqcsj+q8RJWbfa0ur/gKYLAu5jkoD+CcSUZfYhVUYWdq ysOA== X-Gm-Message-State: ALKqPwewj3MF+2IUJ6evyJKpupPJ93GcBbulPO/TFrqXMGLIRvgvjKcp UbGTzWLvdYluUDmCwcPxUfdLzLRwgqA= X-Google-Smtp-Source: ADUXVKJzy769+1WHv8f1N6JjFlu7esL360sO83BM2dr+PFoCy5KKiFFHApkAean5nmOnAVte+euzAg== X-Received: by 2002:a19:d763:: with SMTP id o96-v6mr1782598lfg.89.1527261444810; Fri, 25 May 2018 08:17:24 -0700 (PDT) Received: from [192.168.185.150] ([195.69.7.73]) by smtp.googlemail.com with ESMTPSA id t4-v6sm5552767lff.48.2018.05.25.08.17.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 May 2018 08:17:23 -0700 (PDT) To: "Neal H. Walfield" Cc: Justus Winter , IETF OpenPGP References: <8736yg2gz3.wl-neal@walfield.org> From: Kristian Fiskerstrand Openpgp: preference=signencrypt Autocrypt: addr=kristian.fiskerstrand@sumptuouscapital.com; prefer-encrypt=mutual; keydata= xsFNBEdj//4BEAC3zjKRryW1mLec38x0w9ByG50h6KJddkZe3UNdGhAa3S5E4NAi/fUoe3gD LUDDmpHZNqtbMgrobwUNjLrp+PDZNdMJFAnbWXvmsMwuax0SWJzy4alem34tvir3a2PpnVr9 ylyAyxPChMM0ANelT/fiYIEysjAbHXjri89qdT+yA16CMljoun7vIOmq7ohKdNd1Dci6qoyj 0NllvR2AiBI+ZJnoF4hkRKO1PNUJROzn/ku88idaNkWyq7rREI+WkhS+K6xg1R/d6mTp+bHP tmwGlN4U1Lgx9qeitYzirkQeA8EGK/EEPPZG85WvXSrTftoPvQswOtW7I+jkTdd30GHXf6JH Rq4oR0mT65mqckycPjXNw6RM0fxyx06/kbVG8x3tzc3roJF+hR+h5QWIWsQOc3ZAhbJPWnfP D/kEN20yvb6EXWha+70QJbrBsnN0M8MLF7x+ZWTKESOVpshUBG67iq/FWCpv3st2VTq4M0Ep b/ORIKlfEgSsGv6waooF0ik41ey3k6PIcuHTq/sCoFoC6EH75wqsbmLkVSyqTKm3MSjlN26d ei425iCXJSyH0L1WmeS0i0rzcF5BCu9V280DmNFHWkr4iHiyrVcNyccocMTeh6/ZG7XSI0wc TONVNnKtofVHkzwHMdDlDx4lFRG+V0ftimR5THlxtG8AzQKY9QARAQABzUJLcmlzdGlhbiBG aXNrZXJzdHJhbmQgPGtyaXN0aWFuLmZpc2tlcnN0cmFuZEBzdW1wdHVvdXNjYXBpdGFsLmNv bT7CwX8EEwEIACkCGwMCHgECF4ACGQEFCwkIBwMEFQoJCAUWAgMBAAUCWiWhXAUJFMX2sgAK CRALf4tg4+364/YeEACSDL8stCAArMoqgXlTAdAKQFedJHyoS2QFVzuLx+k7CCGt0jVrNh3d HRQ92pF2QJScWKw76/LHvh6lMBPJwBEXRIvQNDNUb/zyBx96FipC+Dkd8Fxu3s4W+6YCqUBa lmC5XKB6uF/W5wanvpAn1K8bvUb3sq86RYTD0qZui4LMhvm8A0A1Na4+ZeGyfBFhcH5Oh+nh wkZjL7mbMTe25QCeCs4wQpYowia70EZLcQF4MboF9GzH5PIb0ipG5Jtfk9QfSlT+bnkRL1KR DR6rHo7iAYcMt4oJVU1qo1akSBe0MsMI37OdWDtNvUy2Svd2BCLZl49KZnErleC3R/axrtkL 2w1f0P4FoiuPq7mPeiUBhLaZLlc2fz490cEwjsgsY6GuiCWlbyjBMtp0OKM4VBqt5tdxBo/R X5Y6kNOGWpDHx8D+Dl8ToTDJuH2I0k2wfcUibYzWfwXpPpwZ5iXidwLYXbBQ2qqlyB7MP3Po z3zl+UulJyxIYGjg2sO4FmmRs0tThceaNIiDtP5uPLu77oCkAAsWuFSfa6Iwq9+PIQTqTFhH nJ1v/xrdqKWSYB6tm9Tkb0KkUKxFhc7QVyphvh473UEAQ78bQFWrGHqiejQtiiR3MOubwUyt YkNi+ef068rs27SPfRmBAvRw2EMZWhWyX/P2xM4PPp24reOn4ZuAAM7ATQRVZfyNAQgAvppy gWUI21WpA8IZZC+HXywKOqAIXgEQG8m62kVE048A8gjwk8vcmDKU0vlD6OGZ0capeWzWK5kN Gi8kl4ejvgULXKQCAV8ycEUWXmBSmzabhGruMY96Hy1OILc9tb3Wpg3wggW+PZjc5IuLIa1k 9AiDg6SQExDhC27x1EUKZkxkIG+EThSKHbCFB3t4tbwlI8Na4LUfjOxCILA2KVl7CXD/eUNr apJeSGJOtYEhgNFhuHoSG7Po9k6cy2eRrviq9X9cEW10Y3ocCypKvenuUjrN4bUd0IUsODLy cZ3aL+zEmIdhZsG7dQeFmFeJKK+XDgLIMNgr+EP9+89U/COZ5QARAQABwsFlBBgBCAAPAhsM BQJXwxA2BQkE4salAAoJEAt/i2Dj7frjuDIP/2qDloXeGXfMLASc85cp09JLKrbISlTQZkvH WCQREQWzv9LJ4nUcELIhPTc18ntLhU+xJXLP+9d09cOlIiWWjRXXVCZ8IkcSkUplwCQz0Z2h XpmIOm/kycIDgo+qDCRrQhOCX3IhXGwslT7hWjUf/BlKN9f89Uy7VjBFLACOyP3hBZ1uLswN PcSfks/BzTtGTRZ/TEQxgmw0K2BwyJAwnMFqj8kQwc39P6euHln+33alzmUHDsp5rKUsMl58 x18jrV9KLokU/mDHZXoFeLY61dm9Nr46g+T9YYQagvGYfxIAyR9XcHeK1VxxCieSfC/jLKIT A9pu4Hgevl7DGm5/NHzUtqpwRwcbCqvj95Rgfe6lBwuD5g3olAXpZIQKbx73pWdoH0rwXGrQ Bs1weeFbIyVvoCozWoAoU7wVQSr8rHHZeq70b3Zp9DFdkXiSMu3LhU8Byl/spT3rQyLzCBoW DKDrKkifp+HV4mHoypxwD90CcEjeVObpCmhIEaxIDGKl2QaTm+RTwmVWCqr4YFv7QHRMmFVu STZpPmonZzK6VQJByeJMTDlbL0OpczJ8oVHp6txESKj/17xTs8JU1e/SSsdcYjFuLpzHvb97 0F5NQwMZeVuYRvJlCxL7z4Bpj7oPweATfwP43b+JWAser874u7AlBfonXTxe47pbYMioHPnb wsFlBBgBCAAPAhsMBQJaJaF0BQkGw/ojAAoJEAt/i2Dj7frjgbYQAIYDkXvyczRVnEZloYQb HsqjGwekWXTkTk74yYF5U+GoGGzbdFAmF2FhhWxlwIoPLtWoUXmdBknyqtAHCIlYrqPi0fsY 6SdIU3qdDDESjR9gixoPKOP5pFRC3KsPn0MNUXElbkdHvn0YSjuj0GdBi8YUa1XGRNW/O8PH 4HP900OipflQhuEC3yI5AYiq+Grd80RzJg8F108bn8YmoHapV5zZGfzp5L3pHCNOGsBlpTDr QA3XvlKti3AujaF88Nq3tj5kTsj73I30WOctGH3d9QWdySuK5RekAYvMSHU7M9oHtwV9dfVd RFbbuP4fhf+yF56Syu0k7jGe8e0d1xshwOMIXu8/3z4hYOpPfAvkl7n3QNHeqtT1KwRYqCCw KeK8pKZZlsBJ3D6XPuEZyTc/JIiZr8yALslTYubCCNyYQj7fByxM7neVPPaciNhbkGHImwfJ GPBSEuP/UXciroUcrvwwGfY76+WvezaU+O3SLcrT9i+emo9uA14Syb51RWz8h/x55Yu2UpON hArhearvW+0kJBx/YzG0Us7TLMNAiiQYlGibMmaBgRWW33vMXWT9H3FIN8L1NI/Qvy3/N0zD HawUOUvVMNtAzbWexFtxXQ7zyxLUBHHhFdezpWyXmm71qEaOMdDLnTwLqv3ENHUfZzmCc2Kt ZjTX0qrgBQD08nPn Message-ID: Date: Fri, 25 May 2018 17:16:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <8736yg2gz3.wl-neal@walfield.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aiYffyeH6LkU3EXxqMqb8HFiaXZwlU8Fn" Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 15:17:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aiYffyeH6LkU3EXxqMqb8HFiaXZwlU8Fn Content-Type: multipart/mixed; boundary="0l3hFriJlcjdiGO8CXyEuvhtFaBVMKSmP"; protected-headers="v1" From: Kristian Fiskerstrand To: "Neal H. Walfield" Cc: Justus Winter , IETF OpenPGP Message-ID: Subject: Re: [openpgp] Clarify status of subkeys with certification use References: <8736yg2gz3.wl-neal@walfield.org> In-Reply-To: <8736yg2gz3.wl-neal@walfield.org> --0l3hFriJlcjdiGO8CXyEuvhtFaBVMKSmP Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/25/2018 11:59 AM, Neal H. Walfield wrote: > Hi Kristian, Hi Neal and Justus, >=20 > Justus and I have been thinking about how to realize per-device keys > and approximate forward secrecy. These two things are related: if we > want devices to do their own key rotation (and I think this is > sensible, as the alternative is to somehow regularly transfer secret > key material to each device), then the devices need to be able to > generate self-signatures. Since we don't want all devices to have > access to the primary key, each device could have its own > certification subkey. Wouldn't you anyways break the per-device nature if using this certification subkey to sign a third party keyblock, and the loss of one of the devices impacted your validity calculation across the ecosystem? Using this in such a per-device nature also seems to require rather special attention from the user/client, I could easily imagine ending up with a web of cross-signatures across multiple devices here. On 05/25/2018 11:59 AM, Neal H. Walfield wrote: > Consequently, please do not remove certification subkeys from RFC > 4880bis. If anything, I would prefer that RFC 4880bis clarifies that > certification subkeys should be supported. if we are removing it and not just making the current state more precise = :) In any case; I'm not sure if this is a use-case I favor much personally, but it is an interesting concept so thanks for bringing it up for discussion. --=20 ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital." (Aaron Levenstein) --0l3hFriJlcjdiGO8CXyEuvhtFaBVMKSmP-- --aiYffyeH6LkU3EXxqMqb8HFiaXZwlU8Fn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEtOrRIMf4mkrqRycHJQt6/tY3nYUFAlsIKN0ACgkQJQt6/tY3 nYUgLgf+OIzPlY55qfX16s/84cd/bhhVCo8jSCjwSaIuPso/RnTGwbICxVcH2DRf jI3mERuQm9OUjp/hdQW9Umzq3fdY3649ZnBnVOtTrPfv8giZoFkK0iZ30a5r419V vwcNlYGQwjIMx1DxxPJ9eTLqYP6yTWHAC0pKIDPhYD5pyCVW/QA/4F6rBeTWCVD8 6TySPwAU/jNi5HIolSXwtQjQmaJLNJI9nvtW0tlT90O3DamCwZZM7+3t/fgCJEAK 4wSnlzfnbuvb1rAhvNFqUrckkTRnrHAWEWcVNisKb5NxLEw6PZ0oPInKCaoe1N/V neKifvcl63CUB7VVugm7d9DahdrrLQ== =eWI9 -----END PGP SIGNATURE----- --aiYffyeH6LkU3EXxqMqb8HFiaXZwlU8Fn-- From nobody Fri May 25 08:25:46 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484FD127863 for ; Fri, 25 May 2018 08:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sumptuouscapital-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUNS_z9i3AIy for ; Fri, 25 May 2018 08:25:43 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88B61271DF for ; Fri, 25 May 2018 08:25:42 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id y15-v6so9906014wrg.11 for ; Fri, 25 May 2018 08:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sumptuouscapital-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=Ni3ogK3tSDaQY0kVcpU4mCqmn/TcMYLXCdtYmNIcGd8=; b=DTiAmrqHkJ/1N04TwB4dJqEsvBAe0vbZukIv7/wu2aYFaWkO1NfAz5f9q1GnaWnnoR nVLwCGE20peKElWZDXtUXvLE6VH5SbJxYGjlCHRqIPrY++3xtwKioIUMkYT2fBFw8zLm YvkA4tH1Ke8TULrNPF9jBrBOw+PmBNF1B6d4HART5mNXVjg+0IaNcGpCRaYMSGCgGqGy FMaMuwjdeq22gzZel8mc7rdA09TKAy4lz8TmmDVtqehU3s25CYMbB+VSMnKXmPZ8geXP wanjcEMDOXHp0r8wrh+FzbbKrVJcYFAhxYkAhuAm6/sjQ8LhW4duKX142Ilk4hPa44Jw BjwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=Ni3ogK3tSDaQY0kVcpU4mCqmn/TcMYLXCdtYmNIcGd8=; b=lumbnXHoa1L30qpu5HsMYF2z8CLuudIkGH70dfEbWrd1865JhMPBjhcAG7OJ0GiEBw 28EFjTUWGjDUC3KCLMx63/MnPEKK9weK4hlR9ZrD1tuKKPBFqKFtms0bSHHUplt/WbGa ZlsuY4ppWavy3V4E2zAjZQxZ/IKVQBZtvTWvfLgyLoejimJFIy7PoDjLa9rDHXYqZEhe jHvm53uQIBKhNImeE3W0FjRgjLMg/p2sMmScT1tzMbq1MMM12hKja6i+/bpgYfMfNSOg pRcfZMP3szSD4psEdYnpsrtMgyrp4wayDLcHVvLTrFWuTAPVEjf4JEJmh8eEA2HO+nI1 j1VA== X-Gm-Message-State: ALKqPwdpuqc5mQoO0ssZ1bbmh6FCs4l4GMDmt3eGIX66Bv9CsCBorG0V rFbXISTZjSY+aTxYtc3QvNiBak7NKuk= X-Google-Smtp-Source: ADUXVKKUW0CCMI6YTt0mctKbqsTnJGdQQJukyhkM43UCYv6owF4G89pXfRReibqFxpDr/7Rym5vDhA== X-Received: by 2002:a19:1714:: with SMTP id n20-v6mr1819793lfi.54.1527261940974; Fri, 25 May 2018 08:25:40 -0700 (PDT) Received: from [192.168.185.150] ([195.69.7.73]) by smtp.googlemail.com with ESMTPSA id u8-v6sm4530209ljg.40.2018.05.25.08.25.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 May 2018 08:25:40 -0700 (PDT) To: Leo Gaspard , openpgp@ietf.org References: <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> From: Kristian Fiskerstrand Openpgp: preference=signencrypt Autocrypt: addr=kristian.fiskerstrand@sumptuouscapital.com; prefer-encrypt=mutual; keydata= xsFNBEdj//4BEAC3zjKRryW1mLec38x0w9ByG50h6KJddkZe3UNdGhAa3S5E4NAi/fUoe3gD LUDDmpHZNqtbMgrobwUNjLrp+PDZNdMJFAnbWXvmsMwuax0SWJzy4alem34tvir3a2PpnVr9 ylyAyxPChMM0ANelT/fiYIEysjAbHXjri89qdT+yA16CMljoun7vIOmq7ohKdNd1Dci6qoyj 0NllvR2AiBI+ZJnoF4hkRKO1PNUJROzn/ku88idaNkWyq7rREI+WkhS+K6xg1R/d6mTp+bHP tmwGlN4U1Lgx9qeitYzirkQeA8EGK/EEPPZG85WvXSrTftoPvQswOtW7I+jkTdd30GHXf6JH Rq4oR0mT65mqckycPjXNw6RM0fxyx06/kbVG8x3tzc3roJF+hR+h5QWIWsQOc3ZAhbJPWnfP D/kEN20yvb6EXWha+70QJbrBsnN0M8MLF7x+ZWTKESOVpshUBG67iq/FWCpv3st2VTq4M0Ep b/ORIKlfEgSsGv6waooF0ik41ey3k6PIcuHTq/sCoFoC6EH75wqsbmLkVSyqTKm3MSjlN26d ei425iCXJSyH0L1WmeS0i0rzcF5BCu9V280DmNFHWkr4iHiyrVcNyccocMTeh6/ZG7XSI0wc TONVNnKtofVHkzwHMdDlDx4lFRG+V0ftimR5THlxtG8AzQKY9QARAQABzUJLcmlzdGlhbiBG aXNrZXJzdHJhbmQgPGtyaXN0aWFuLmZpc2tlcnN0cmFuZEBzdW1wdHVvdXNjYXBpdGFsLmNv bT7CwX8EEwEIACkCGwMCHgECF4ACGQEFCwkIBwMEFQoJCAUWAgMBAAUCWiWhXAUJFMX2sgAK CRALf4tg4+364/YeEACSDL8stCAArMoqgXlTAdAKQFedJHyoS2QFVzuLx+k7CCGt0jVrNh3d HRQ92pF2QJScWKw76/LHvh6lMBPJwBEXRIvQNDNUb/zyBx96FipC+Dkd8Fxu3s4W+6YCqUBa lmC5XKB6uF/W5wanvpAn1K8bvUb3sq86RYTD0qZui4LMhvm8A0A1Na4+ZeGyfBFhcH5Oh+nh wkZjL7mbMTe25QCeCs4wQpYowia70EZLcQF4MboF9GzH5PIb0ipG5Jtfk9QfSlT+bnkRL1KR DR6rHo7iAYcMt4oJVU1qo1akSBe0MsMI37OdWDtNvUy2Svd2BCLZl49KZnErleC3R/axrtkL 2w1f0P4FoiuPq7mPeiUBhLaZLlc2fz490cEwjsgsY6GuiCWlbyjBMtp0OKM4VBqt5tdxBo/R X5Y6kNOGWpDHx8D+Dl8ToTDJuH2I0k2wfcUibYzWfwXpPpwZ5iXidwLYXbBQ2qqlyB7MP3Po z3zl+UulJyxIYGjg2sO4FmmRs0tThceaNIiDtP5uPLu77oCkAAsWuFSfa6Iwq9+PIQTqTFhH nJ1v/xrdqKWSYB6tm9Tkb0KkUKxFhc7QVyphvh473UEAQ78bQFWrGHqiejQtiiR3MOubwUyt YkNi+ef068rs27SPfRmBAvRw2EMZWhWyX/P2xM4PPp24reOn4ZuAAM7ATQRVZfyNAQgAvppy gWUI21WpA8IZZC+HXywKOqAIXgEQG8m62kVE048A8gjwk8vcmDKU0vlD6OGZ0capeWzWK5kN Gi8kl4ejvgULXKQCAV8ycEUWXmBSmzabhGruMY96Hy1OILc9tb3Wpg3wggW+PZjc5IuLIa1k 9AiDg6SQExDhC27x1EUKZkxkIG+EThSKHbCFB3t4tbwlI8Na4LUfjOxCILA2KVl7CXD/eUNr apJeSGJOtYEhgNFhuHoSG7Po9k6cy2eRrviq9X9cEW10Y3ocCypKvenuUjrN4bUd0IUsODLy cZ3aL+zEmIdhZsG7dQeFmFeJKK+XDgLIMNgr+EP9+89U/COZ5QARAQABwsFlBBgBCAAPAhsM BQJXwxA2BQkE4salAAoJEAt/i2Dj7frjuDIP/2qDloXeGXfMLASc85cp09JLKrbISlTQZkvH WCQREQWzv9LJ4nUcELIhPTc18ntLhU+xJXLP+9d09cOlIiWWjRXXVCZ8IkcSkUplwCQz0Z2h XpmIOm/kycIDgo+qDCRrQhOCX3IhXGwslT7hWjUf/BlKN9f89Uy7VjBFLACOyP3hBZ1uLswN PcSfks/BzTtGTRZ/TEQxgmw0K2BwyJAwnMFqj8kQwc39P6euHln+33alzmUHDsp5rKUsMl58 x18jrV9KLokU/mDHZXoFeLY61dm9Nr46g+T9YYQagvGYfxIAyR9XcHeK1VxxCieSfC/jLKIT A9pu4Hgevl7DGm5/NHzUtqpwRwcbCqvj95Rgfe6lBwuD5g3olAXpZIQKbx73pWdoH0rwXGrQ Bs1weeFbIyVvoCozWoAoU7wVQSr8rHHZeq70b3Zp9DFdkXiSMu3LhU8Byl/spT3rQyLzCBoW DKDrKkifp+HV4mHoypxwD90CcEjeVObpCmhIEaxIDGKl2QaTm+RTwmVWCqr4YFv7QHRMmFVu STZpPmonZzK6VQJByeJMTDlbL0OpczJ8oVHp6txESKj/17xTs8JU1e/SSsdcYjFuLpzHvb97 0F5NQwMZeVuYRvJlCxL7z4Bpj7oPweATfwP43b+JWAser874u7AlBfonXTxe47pbYMioHPnb wsFlBBgBCAAPAhsMBQJaJaF0BQkGw/ojAAoJEAt/i2Dj7frjgbYQAIYDkXvyczRVnEZloYQb HsqjGwekWXTkTk74yYF5U+GoGGzbdFAmF2FhhWxlwIoPLtWoUXmdBknyqtAHCIlYrqPi0fsY 6SdIU3qdDDESjR9gixoPKOP5pFRC3KsPn0MNUXElbkdHvn0YSjuj0GdBi8YUa1XGRNW/O8PH 4HP900OipflQhuEC3yI5AYiq+Grd80RzJg8F108bn8YmoHapV5zZGfzp5L3pHCNOGsBlpTDr QA3XvlKti3AujaF88Nq3tj5kTsj73I30WOctGH3d9QWdySuK5RekAYvMSHU7M9oHtwV9dfVd RFbbuP4fhf+yF56Syu0k7jGe8e0d1xshwOMIXu8/3z4hYOpPfAvkl7n3QNHeqtT1KwRYqCCw KeK8pKZZlsBJ3D6XPuEZyTc/JIiZr8yALslTYubCCNyYQj7fByxM7neVPPaciNhbkGHImwfJ GPBSEuP/UXciroUcrvwwGfY76+WvezaU+O3SLcrT9i+emo9uA14Syb51RWz8h/x55Yu2UpON hArhearvW+0kJBx/YzG0Us7TLMNAiiQYlGibMmaBgRWW33vMXWT9H3FIN8L1NI/Qvy3/N0zD HawUOUvVMNtAzbWexFtxXQ7zyxLUBHHhFdezpWyXmm71qEaOMdDLnTwLqv3ENHUfZzmCc2Kt ZjTX0qrgBQD08nPn Message-ID: Date: Fri, 25 May 2018 17:25:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tin3W6twNvoLs0cOxIfYpy7EK46dlwKAS" Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 15:25:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tin3W6twNvoLs0cOxIfYpy7EK46dlwKAS Content-Type: multipart/mixed; boundary="JhLXoXir4LrQtpKT2oyhIMZQSTvDxWRFe"; protected-headers="v1" From: Kristian Fiskerstrand To: Leo Gaspard , openpgp@ietf.org Message-ID: Subject: Re: [openpgp] Clarify status of subkeys with certification use References: <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> In-Reply-To: <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> --JhLXoXir4LrQtpKT2oyhIMZQSTvDxWRFe Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/25/2018 12:26 PM, Leo Gaspard wrote: > Another use case supporting this opinion: certification subkeys are als= o > a way to increase the security of an offline OpenPGP key, as with them > it becomes possible to put the master key behind a diode while still > being able to certify keys, and only ever move data out: > 1. On the machine with the master key, generate a certification subkey= > 2. Move the certification subkey to another system, less trusted > 3. Push the to-be-signed key to this other system > 4. On this other system, certify the to-be-signed key > 5. Rotate the certification subkey from time to time to be able to > revoke one were it compromised I'm not sure I buy this argument, the WoT is expected to be long-term, if needing to do rotation of certification subkey, it sounds like you're making it more temporary of sorts. Wouldn't just having a separate CA key that is fully trusted (presumably locally signed and not exportable) accomplish much of the same for more "temporary" signatures, i.e those not exported to view of the rest of the ecosystem / external users? --=20 ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- There are two tragedies in life. One is to lose your heart's desire. The other is to gain it. - George Bernard Shaw --JhLXoXir4LrQtpKT2oyhIMZQSTvDxWRFe-- --tin3W6twNvoLs0cOxIfYpy7EK46dlwKAS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEtOrRIMf4mkrqRycHJQt6/tY3nYUFAlsIKswACgkQJQt6/tY3 nYWc3wf9GkuAx597fftK8xk/H2tXD3v+jx0ie3QFSHejBFuiZTMNEi9BBuVBvWKo Rs523rtk/MZBf68eqX0nt1+mR533V3Y6VSrhSFFBuv7ZueZ8JeCIvJMrdZ4iSeNC zPS26za2Ph5D4yqDiPJBKvty07DrgywJ4QvK0x+gr1UA7dM4QYnl79D3ezuv/3iu f7Od84TfoMC0v03WGgX1P9D3LLxCA7f+h9tKDjcnDn9DX0ERFlau5CDPulysyYxx IjYpo6slJuG1qIm5sogTuDz6XuN6+jqQsdC/M/JS95zj1dIzE92QUeD6Wf4pVhNB q2P2KqQNTZqjGFUsmo8h3QpgEn8RpA== =v1GT -----END PGP SIGNATURE----- --tin3W6twNvoLs0cOxIfYpy7EK46dlwKAS-- From nobody Fri May 25 13:01:12 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA9312E8D2 for ; Fri, 25 May 2018 13:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz5nMtlxlwwl for ; Fri, 25 May 2018 13:01:05 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349B112E8CA for ; Fri, 25 May 2018 13:01:05 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 7D5DDF99A; Fri, 25 May 2018 16:01:03 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 335BE20670; Fri, 25 May 2018 16:01:01 -0400 (EDT) From: Daniel Kahn Gillmor To: "Neal H. Walfield" , Kristian Fiskerstrand Cc: IETF OpenPGP , Justus Winter In-Reply-To: <8736yg2gz3.wl-neal@walfield.org> References: <8736yg2gz3.wl-neal@walfield.org> Date: Fri, 25 May 2018 16:00:58 -0400 Message-ID: <87h8mvfqth.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 20:01:10 -0000 --=-=-= Content-Type: text/plain On Fri 2018-05-25 11:59:44 +0200, Neal H. Walfield wrote: > Justus and I have been thinking about how to realize per-device keys > and approximate forward secrecy. These two things are related: if we > want devices to do their own key rotation (and I think this is > sensible, as the alternative is to somehow regularly transfer secret > key material to each device), then the devices need to be able to > generate self-signatures. Since we don't want all devices to have > access to the primary key, each device could have its own > certification subkey. I've also been thinking about how to do forward secrecy, but i think i've come to the opposite result as Neal and Justus here. Per-device keys are bad for user privacy (they leak how many devices the user has), and they either complicate any potential interface for cryptographic identity verification (i now need to somehow both know and understand the range of devices held by my peer), or they provide a convenient mechanism for a wiretap capability (sneak in an extra certification key for a user somehow). you can still keep a primary certification-capable key offline (or on a "master" client), while retaining the ability to revoke access to certain clients -- you just need to revoke existing subkeys, and provide all remaining good clients with the new subkeys, so i don't see certification-capable subkeys as a win there either. And i believe that sensible clients connected to a single account will need a way to synchronize *other* state as well -- not just secret keys -- so there's not much of a savings on the difficulty of state synchronization here anyway. Additionally (as i wrote elsewhere in this thread) i think they represent pretty serious implementation complexity, which i don't think is healthy for the ecosystem. So i'm still on the side of trying to make more explicit the current assumption that only primary keys hold certification capabilities. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCWwhregAKCRBsHx7ezFD6 U4M4AQCYic6Dz1Wg2N1RcvR7495hLVeSDNUrYh2SaaNhXaXKHQD+PLMjT+uFCC+H ev9J/MHP4QFYAdxHJacjm9QZ9EPP7ws= =p5Xw -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 25 13:01:18 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB36612E88C for ; Fri, 25 May 2018 13:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbfJkb7iqypS for ; Fri, 25 May 2018 13:01:05 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C072212E866 for ; Fri, 25 May 2018 13:01:05 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 11395F99B; Fri, 25 May 2018 16:01:03 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id AF1C72048D; Fri, 25 May 2018 15:46:45 -0400 (EDT) From: Daniel Kahn Gillmor To: Leo Gaspard , openpgp@ietf.org In-Reply-To: <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> References: <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> Date: Fri, 25 May 2018 15:46:42 -0400 Message-ID: <87k1rrfrh9.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 20:01:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri 2018-05-25 12:26:54 +0200, Leo Gaspard wrote: > > Another use case supporting this opinion: certification subkeys are also > a way to increase the security of an offline OpenPGP key, as with them > it becomes possible to put the master key behind a diode while still > being able to certify keys, and only ever move data out: you might have made the master key "more secure", but you've done so by transfering the capabilities of the master key (certification) out to the less-controlled keys. what's the win here? secret keys are not in themselves important objects -- what's important is the capabilities that the network assigns to the corresponding public keys. Also, when some certification in a chain has an expiration date on it, is the whole chain of certifications bound by the narrowest ("bottleneck") expiration date, or is there some other governing principle? And when a leaf certifiation expires earlier than marked because some middle element in the chain becomes unusable (remember, subkey expiration dates can change; subkeys can be revoked), how would you present this change to the user? And further still: how many levels deep should such a certification chain go? I think it's pretty easy to argue "0 levels" (i.e. "no certification-capable subkeys") for simplicity of implementation and usability concerns. I'd suggest that no implementation is willing to argue for "=E2=88=9E level= s" because at some point the chain of verification becomes too expensive to cope. Are you arguing for some particular limited level of depth? if so, how do you justify that level? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCWwhoIgAKCRBsHx7ezFD6 U7T6AP0Xmgg1WcsPRa0nUfHrlYdtGzMh8z1NzTcels9fWvJlwQEAgaC6dDBlgazH HvHUoIXtcWu+9APicZdJNke70NGDDQw= =LdFa -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 25 14:54:32 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C5C12D0C3 for ; Fri, 25 May 2018 14:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8EIcuS02MXJ for ; Fri, 25 May 2018 14:54:28 -0700 (PDT) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44AA6128959 for ; Fri, 25 May 2018 14:54:27 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 4f09a8f0; Fri, 25 May 2018 21:54:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=TgIeO1jbOuKVyOGGOPCY+lcDmfM=; b=Xh17jCk2z9Rgud qoCbhKSsY3+Ao1Tbnj4WQ8gSWGnUbFkKubzVJpts4ovnAi37kUKeaQwSzJz6SEkO /CfMuN2RanlL7vHCqFd+ANzWRMu/Y9ml66aX/u9Q1U/qwyr59RE+5tow6NQ1yMA0 ghY4JDHUEdoRmlr2pXrw61o+ib9V0= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 891bfd02 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO); Fri, 25 May 2018 21:54:21 +0000 (UTC) To: Kristian Fiskerstrand , openpgp@ietf.org References: <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> From: Leo Gaspard Message-ID: Date: Fri, 25 May 2018 23:54:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 21:54:31 -0000 On 05/25/2018 05:25 PM, Kristian Fiskerstrand wrote: > On 05/25/2018 12:26 PM, Leo Gaspard wrote: >> Another use case supporting this opinion: certification subkeys are also >> a way to increase the security of an offline OpenPGP key, as with them >> it becomes possible to put the master key behind a diode while still >> being able to certify keys, and only ever move data out: >> 1. On the machine with the master key, generate a certification subkey >> 2. Move the certification subkey to another system, less trusted >> 3. Push the to-be-signed key to this other system >> 4. On this other system, certify the to-be-signed key >> 5. Rotate the certification subkey from time to time to be able to >> revoke one were it compromised > > I'm not sure I buy this argument, the WoT is expected to be long-term, > if needing to do rotation of certification subkey, it sounds like you're > making it more temporary of sorts. Wouldn't just having a separate CA > key that is fully trusted (presumably locally signed and not exportable) > accomplish much of the same for more "temporary" signatures, i.e those > not exported to view of the rest of the ecosystem / external users? Sorry if I was unclear, the idea was not to make the certification subkey temporary, but to only use it for a given period of time, and then delete it (while not revoking or expiring it). This way so long as there is no compromise of the certification subkey things stay exactly the same, but when a certification subkey is compromised (eg. because it had to parse a malformed public key to sign it, or due to an attack on the way the data was transferred or any other attack), it can simply be revoked, without compromising the master key and its UID signatures. The idea of rotation was thought to not invalidate all the previously-made signatures in case of compromise, but an alternative could be to not rotate so long as the certification subkey is not compromised, and on certification subkey compromise tighten the WoT by that much. Sorry for the wording of point 5, it was not clear at all indeed. Hopefully it's better now. From nobody Fri May 25 15:02:03 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6F812DA3E for ; Fri, 25 May 2018 15:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u288mEObmp3f for ; Fri, 25 May 2018 15:01:53 -0700 (PDT) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52ED612DA3F for ; Fri, 25 May 2018 15:01:52 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id f0303d65 for ; Fri, 25 May 2018 22:01:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=zxRsRPLnAVBNVaAZp/UaUiRl/ig=; b=WEG0shzrCGHDpw JhOYj+MQKb4wsJJ5LreMdUSl2+aCOnA4d+x7IdYy7rtu1KeB5/xxKNGfiNXKAcMh WVjq4xb/GVkZp1sIPomYq2/mBEdOxh8geQdK2hezNPFdS/p9sMctxuQnVI010LXL aL/Xrvee78OL1PB4ZVyUeU8/cwC9E= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 952fce1b (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Fri, 25 May 2018 22:01:48 +0000 (UTC) To: openpgp@ietf.org References: <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> <87k1rrfrh9.fsf@fifthhorseman.net> From: Leo Gaspard Message-ID: <8ab6499f-e874-9aa8-3f8e-1f1c77d1fe4c@leo.gaspard.ninja> Date: Sat, 26 May 2018 00:01:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <87k1rrfrh9.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 22:01:57 -0000 On 05/25/2018 09:46 PM, Daniel Kahn Gillmor wrote: > On Fri 2018-05-25 12:26:54 +0200, Leo Gaspard wrote: >> >> Another use case supporting this opinion: certification subkeys are also >> a way to increase the security of an offline OpenPGP key, as with them >> it becomes possible to put the master key behind a diode while still >> being able to certify keys, and only ever move data out: > > you might have made the master key "more secure", but you've done so by > transfering the capabilities of the master key (certification) out to > the less-controlled keys. what's the win here? secret keys are not in > themselves important objects -- what's important is the capabilities > that the network assigns to the corresponding public keys. Well, I'd argue the master secret key *is* an important object: it has accumulated UID signatures that may become impossible to recover were it to have to be revoked. Hence this idea, allowing to revoke a certification subkey, that in itself has no value indeed. > Also, when some certification in a chain has an expiration date on it, > is the whole chain of certifications bound by the narrowest > ("bottleneck") expiration date, or is there some other governing > principle? I'd say the narrowest expiration date would make most sense (actually, I can't think of any other reasonable way to handle expiration dates). > And when a leaf certifiation expires earlier than marked because some > middle element in the chain becomes unusable (remember, subkey > expiration dates can change; subkeys can be revoked), how would you > present this change to the user? Well, isn't that the same issue as when a previously-trusted master key that had signed the end-of-chain key expires / is revoked? > And further still: how many levels deep should such a certification > chain go? > > I think it's pretty easy to argue "0 levels" (i.e. "no > certification-capable subkeys") for simplicity of implementation and > usability concerns. > > I'd suggest that no implementation is willing to argue for "∞ levels" > because at some point the chain of verification becomes too expensive to > cope. > > Are you arguing for some particular limited level of depth? if so, how > do you justify that level? For my use case (ie. protecting the master key), a single level is necessary, and there is a need only for a single certification subkey For Neal's use case, I haven't thought extensively about it, but think one could be enough, depending on whether we want the user to have to access his master key when adding a device (and I guess we want, as otherwise revocation of a device-that-had-signed-another-device becomes a UI nightmare) So, I'd say, one ? From nobody Sat May 26 14:16:03 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9900412E8C4 for ; Sat, 26 May 2018 14:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyWBR3htJO7r for ; Sat, 26 May 2018 14:15:58 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A7D1276AF for ; Sat, 26 May 2018 14:15:58 -0700 (PDT) Received: from 4.250.26.109.rev.sfr.net ([109.26.250.4] helo=chu.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1fMgXZ-0003e4-FX; Sat, 26 May 2018 21:15:53 +0000 Date: Sat, 26 May 2018 23:15:51 +0200 Message-ID: <87y3g615ko.wl-neal@walfield.org> From: "Neal H. Walfield" To: Daniel Kahn Gillmor Cc: Kristian Fiskerstrand , IETF OpenPGP , Justus Winter In-Reply-To: <87h8mvfqth.fsf@fifthhorseman.net> References: <8736yg2gz3.wl-neal@walfield.org> <87h8mvfqth.fsf@fifthhorseman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 21:16:02 -0000 Hi Daniel, Thanks for your comments. We want to put forth a more complete proposal so that you hopefully better understand what we are trying to do. This will hopefully clarify some of your concerns. Forward Secrecy and Multi-Device Support ======================================== We want to support automatic forward secrecy in a multiple device context. At least initially, we intend to do it a bit like Ian Brown et al. described in their internet draft [1]. [1] https://tools.ietf.org/html/draft-brown-pgp-pfs-03 Basically, we want to automatically rotate encryption subkeys on a regular basis. (Perhaps later we can figure out how to do something like Signal's double rachet.) If the user has multiple devices, we see two ways to do key rotation. First, the primary device (however that is selected), periodically generates a new encryption subkey, and somehow(!) shares it with the other devices. If the user doesn't use the primary device for awhile, and the subkeys expire, some other device will have to create the new keys. But, this introduces a potential race. Second, each device rotates its own encryption subkey. Whereas in the first case, all devices did not strictly require access to a certification-capable key, now all devices need access to one. The simplest solution would be to just give each device a copy of the primary key, as you appear to suggest. But, providing each device with its own certification-capable subkey has the advantage that it is possible to revoke a device. Users already understand this workflow: if you have a google account, an amazon account, etc., it is possible to decommission individual devices. Further, using certification-capable subkeys makes it possible to keep the primary key offline. When the user revokes a device, the UI could ask the user whether certification-capable subkeys signed by that key, and third-party certificates created by that key should remain valid. For instance, if "laptop" was used to provision "cell phone" and "laptop" is decommissioned from "desktop", then decomissioning "laptop" transitively decomissions "cell phone". To avoid this, "desktop" could recertify "cell phone". In the above example, we named the devices. It might be reasonable to make this information first class. This way the UI can use sensible names. Also, similar to Jabber with its named resources, it is easy to imagine some advanced option that allows the sender to make her message decryptable on only a subset of the recipient's devices. Finally, if accidental commissioning of a fake device is a real concern, the user's OpenPGP software could show a note when it detects that a new device has been commissioned similar to: "It looks like device 'foo' recently commissioned device 'bar', if this was not intended, then 'foo' was probably compromised." Forward Secrecy =============== The basic idea behind forward secrecy is that old keys are deleted after a sunset period. OpenPGP has traditionally been used to protect both data at rest as well as data in motion. At first blush, this usage appears to be at odds with forward secrecy. But, OpenPGP actually already has provisions for forward secrecy. Moreover, it is possible to have both transport encryption and storage encryption in a backwards compatible way. First, OpenPGP foresees two types of encryption keys: 0x04 - This key may be used to encrypt communications. 0x08 - This key may be used to encrypt storage. https://tools.ietf.org/html/rfc4880#section-5.2.3.21 When generating a key in Sequoia, we intend to generate two encryption subkeys: a communication encryption subkey, and a storage encryption subkey. When a program using Sequoia wants to encrypt a message, it specify whether protection is only needed during transportation or whether the message is intended to be archived. Since only one storage encryption subkey is needed (it is not rotated), it can be stored on a smart card (along with the primary certification key!). It turns out this usage is nearly completely backwards compatible to GnuPG: when GnuPG generates an encryption capable subkey, it makes it both a communication and a storage encryption key. The only issue, is that if there are multiple valid encryption subkeys, GnuPG only uses the newest one, AFAIK. But, there is precedence for encrypting to all valid encryption capable subkeys: this is what OpenKeychain does. Session Key Store ================= People assume that, e.g., their email remains readable long after they've received it. Unfortunately, if we use forward secrecy and don't change the MUAs to locally store the decrypted message, this will no longer be the case. To work around this, we can maintain a session key store. This is just a map from an encrypted session key to the decrypted session key. Then, once a message is decrypted, we don't need the asymmetric key to decrypt it again. Unfortunately, if the session key store is somehow compromised, this means that a copy of the message remains decryptable even if the user deleted the message. This can be partially mitigated by allowing programs (e.g., a MUA) to purge session keys when they delete the message. Of course, this is not so easy when there are multiple devices. But, even ignoring this problem, having a session key store is no worse than the status quo. And, if this behavior is embraced, developers will hopefully change their software to improve their behavior. Changing notmuch would probably be very straightforward. Alternatively, we could keep old messages readable by reencrypting the session key using, e.g., the storage encryption key. This requires the ability to rewrite the message, which is not always possible or desirable. Another option is to not actually delete the old encryption subkeys, but to encrypt them using the storage encryption key. Key Distribution ================ If we aggresively rotate keys (and, we are currently thinking of doing this once a week), then we need to distribute the keys. The key servers appear to be a convenient way to do this. But, many users are concerned about having their personal information published. To resolve this conflict, we plan to *not* publish user id or user attribute packets. This is better than Signal's key servers, which, AIUI, associate keys with telephone numbers. Key Rotation ============ To avoid having a period of time during which no encryption-capable key is available for a device either because the device hasn't had an opportunity to generate new keys, or the sender hasn't been able to refresh the key from the key servers, we plan to publish keys in advance. For instance, we will create keys covering, say, the next 6 months. By setting the creation time and expiration time appropriately, only one key per device will be valid at any given time. AFAIUI, recent versions of GnuPG respect this. We plan to generate new keys when a low-water mark is reached, say, three months before the last key expires. On Fri, 25 May 2018 22:00:58 +0200, Daniel Kahn Gillmor wrote: > On Fri 2018-05-25 11:59:44 +0200, Neal H. Walfield wrote: > > > Justus and I have been thinking about how to realize per-device keys > > and approximate forward secrecy. These two things are related: if we > > want devices to do their own key rotation (and I think this is > > sensible, as the alternative is to somehow regularly transfer secret > > key material to each device), then the devices need to be able to > > generate self-signatures. Since we don't want all devices to have > > access to the primary key, each device could have its own > > certification subkey. > > I've also been thinking about how to do forward secrecy, but i think > i've come to the opposite result as Neal and Justus here. > > Per-device keys are bad for user privacy (they leak how many devices the > user has), This is leaked in other ways. And, this is also leaked by Signal, AFAIUI. If this is a serious concern, it would be possible to publish decoy keys. > and they either complicate any potential interface for > cryptographic identity verification (i now need to somehow both know and > understand the range of devices held by my peer), I don't understand this. Using a certification-capable subkey, there is still only a single cryptographic identity established by the primary key. > or they provide a convenient mechanism for a wiretap capability > (sneak in an extra certification key for a user somehow). I don't understand this argument either: if someone is able to trick me into generating an extra certification subkey and sending it to them, they could probably just as easily trick me into send them a copy of my master key. > you can still keep a primary certification-capable key offline (or on a > "master" client), while retaining the ability to revoke access to > certain clients -- you just need to revoke existing subkeys, and provide > all remaining good clients with the new subkeys, so i don't see > certification-capable subkeys as a win there either. If the primary certification-capable key is offline, then we can't easily do key rotation. > And i believe that sensible clients connected to a single account will > need a way to synchronize *other* state as well -- not just secret keys > -- so there's not much of a savings on the difficulty of state > synchronization here anyway. Perhaps. But, regularly transmitting key material seems like a bad idea. If the new subkey is encrypted using the old one, then if an attacker exfiltrates any subkey, it is possible to get all subsequent ones. If the subkeys are created on the device, then when the subkeys are rotated, the attacker's access is lost and the exfiltration must be repeated. > Additionally (as i wrote elsewhere in this thread) i think they > represent pretty serious implementation complexity, which i don't think > is healthy for the ecosystem. I don't think that the added complexity is that large. When I verify a signature, I can't assume it was made by the primary key, but I need to find the right certification key, and also validate that key, if it is not the primary key. :) Neal & Justus From nobody Sun May 27 02:32:14 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA81112025C for ; Sun, 27 May 2018 02:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzNjIhxST7y4 for ; Sun, 27 May 2018 02:32:10 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4241267BB for ; Sun, 27 May 2018 02:32:10 -0700 (PDT) Received: from [163.5.220.17] (helo=chu.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1fMs23-0007Gz-UK; Sun, 27 May 2018 09:32:08 +0000 Date: Sun, 27 May 2018 11:32:05 +0200 Message-ID: <874lit1m22.wl-neal@walfield.org> From: "Neal H. Walfield" To: Leo Gaspard Cc: openpgp@ietf.org In-Reply-To: <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> References: <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 09:32:13 -0000 On Fri, 25 May 2018 12:26:54 +0200, Leo Gaspard wrote: > Another use case supporting this opinion: certification subkeys are also > a way to increase the security of an offline OpenPGP key, as with them > it becomes possible to put the master key behind a diode while still > being able to certify keys, and only ever move data out: FWIW, this workflow does not require certification subkeys. You can instead create two keys, an offline key and an online certification-only key. Then, you *t*sign the certification key using the offline key. This means that anyone who adds your offline key as a trusted introducer will automatically trust your online certification key. Check out Section 6.3.12 of the following text for more details: https://gnupg.org/ftp/people/neal/an-advanced-introduction-to-gnupg/an-advanced-introduction-to-gnupg.pdf :) Neal From nobody Sun May 27 03:00:12 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C19112D775 for ; Sun, 27 May 2018 03:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUVpecImtiFG for ; Sun, 27 May 2018 03:00:09 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D231612D87D for ; Sun, 27 May 2018 03:00:08 -0700 (PDT) Received: from [163.5.220.17] (helo=chu.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1fMsT7-0007Ok-Ad; Sun, 27 May 2018 10:00:05 +0000 Date: Sun, 27 May 2018 12:00:03 +0200 Message-ID: <8736yd1krg.wl-neal@walfield.org> From: "Neal H. Walfield" To: Daniel Kahn Gillmor Cc: Leo Gaspard , openpgp@ietf.org In-Reply-To: <87k1rrfrh9.fsf@fifthhorseman.net> References: <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> <87k1rrfrh9.fsf@fifthhorseman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 10:00:10 -0000 On Fri, 25 May 2018 21:46:42 +0200, Daniel Kahn Gillmor wrote: > you might have made the master key "more secure", but you've done so by > transfering the capabilities of the master key (certification) out to > the less-controlled keys. what's the win here? secret keys are not in > themselves important objects -- what's important is the capabilities > that the network assigns to the corresponding public keys. The difference between a primary key and a certification subkey is that the primary key is the user's globally unique, long-term identity. If the certification subkey is somehow compromised, it can be revoked without requiring the user to get a new cryptographic identity, which is a pain to distribute. > Also, when some certification in a chain has an expiration date on it, > is the whole chain of certifications bound by the narrowest > ("bottleneck") expiration date, or is there some other governing > principle? I'm not sure what you mean here. It seems obvious to me that if any edge in a trust path is broken, then the path becomes invalid just like in the WoT. > And when a leaf certifiation expires earlier than marked because some > middle element in the chain becomes unusable (remember, subkey > expiration dates can change; subkeys can be revoked), how would you > present this change to the user? Why do you think it is necessary to present this information to the use? Right now, signatures and keys can be revoked and this breaks trust paths in the WoT in a similar way, but there is no UI to show what happened. But, if you wanted to, sure, you could create some UI to prompt the user to either extend the expiration of the middle certification subkey or to hoist up the leaf certification subkey, but signing it with a still-valid certification key. > And further still: how many levels deep should such a certification > chain go? > > I think it's pretty easy to argue "0 levels" (i.e. "no > certification-capable subkeys") for simplicity of implementation and > usability concerns. > > I'd suggest that no implementation is willing to argue for "$B!g(B levels" > because at some point the chain of verification becomes too expensive to > cope. Unless it is possible to create a quine, the chain can't be infinite. (But, it is worth pointing out that we do need to detect cycles.) Because I think auditable delegation of authority is useful, I'd argue for something like 32 levels as a recommended limit. 32 levels is probably more than enough for most uses without requiring too much acrobatics from the implementations. :) Neal From nobody Sun May 27 10:00:14 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7490A12F28C for ; Sun, 27 May 2018 10:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBWh8UWEgVsY for ; Sun, 27 May 2018 10:00:10 -0700 (PDT) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9212B126D0C for ; Sun, 27 May 2018 10:00:09 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id eb237c09; Sun, 27 May 2018 17:00:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=UP68bLPcB6/NTOWSgwt9B10TKN0=; b=b5hP5OrLRD1iQA MqTYmaPm9yIk2ZrBspFYw//7M9LsK2Vqw3sJxZyMqdxmhpt3sVTNzemSA0604nA6 zVl9tkpAh9Pc9lMpc8y6gfTaARmCPR8Ap+3tuwcfwqesgAGUOoRXkCmKqWgudLcu iv41JtLFtV2BPOvtm7fRgPIYYeDrs= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 2187ffd3 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO); Sun, 27 May 2018 17:00:05 +0000 (UTC) To: "Neal H. Walfield" Cc: openpgp@ietf.org References: <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> <874lit1m22.wl-neal@walfield.org> From: Leo Gaspard Message-ID: <58cf1a73-12cf-0f86-d23c-1603273aabe2@leo.gaspard.ninja> Date: Sun, 27 May 2018 19:00:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <874lit1m22.wl-neal@walfield.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 17:00:13 -0000 On 05/27/2018 11:32 AM, Neal H. Walfield wrote: > On Fri, 25 May 2018 12:26:54 +0200, > Leo Gaspard wrote: >> Another use case supporting this opinion: certification subkeys are also >> a way to increase the security of an offline OpenPGP key, as with them >> it becomes possible to put the master key behind a diode while still >> being able to certify keys, and only ever move data out: > > FWIW, this workflow does not require certification subkeys. You can > instead create two keys, an offline key and an online > certification-only key. Then, you *t*sign the certification key using > the offline key. This means that anyone who adds your offline key as > a trusted introducer will automatically trust your online > certification key. Check out Section 6.3.12 of the following text for > more details: > > https://gnupg.org/ftp/people/neal/an-advanced-introduction-to-gnupg/an-advanced-introduction-to-gnupg.pdf > > :) Neal Indeed it's already possible, the issue with this solution being that people willing to rely on signatures by the master key now need to download two keys (the master key and the trusted introducer), and another one after any compromise, while certification subkeys are downloaded and updated at the same time as the master key, thus making for more easy-to-use WoT. Then, I do agree that it's a somewhat infrequent use case, which is the reason why I did not post it here until you came with a more convincing one :) Leo From nobody Sun May 27 13:56:31 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E625F12FB62 for ; Sun, 27 May 2018 13:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHZWu3q4v3Ys for ; Sun, 27 May 2018 13:56:15 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727DC12FB56 for ; Sun, 27 May 2018 13:56:15 -0700 (PDT) Received: from 4.250.26.109.rev.sfr.net ([109.26.250.4] helo=chu.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1fN2i3-0002SX-78; Sun, 27 May 2018 20:56:11 +0000 Date: Sun, 27 May 2018 22:56:10 +0200 Message-ID: <871sdw24yd.wl-neal@walfield.org> From: "Neal H. Walfield" To: Leo Gaspard Cc: openpgp@ietf.org In-Reply-To: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [openpgp] Scoped trust (signatures) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 20:56:30 -0000 Hi Leo, On Fri, 18 May 2018 22:26:03 +0200, Leo Gaspard wrote: > As I understand it, RFC4880 already has a provision for such a model, > with $B!x(B5.2.3.14 _Regular Expression_. > > However, there is from my reading an issue with (the wording of) this > section: it only restricts one-level trust signatures. In other words, > from my reading, if: > * User U trusts(255, r".*<.*@ca-a.com>") "A " > * root@ca-a.com trusts(255, r".*<.*@example.org>") "B " > * b@ca-a.com signs "C " > > Then, from A's point of view: > * root@ca-a.com has trust(255, r".*<.*@ca-a.com>") > * b@ca-a.com has trust(254, r".*<.*@example.org>") > * c@example.org is valid For reference, here's the relevant text: 5.2.3.14. Regular Expression Used in conjunction with trust Signature packets (of level > 0) to limit the scope of trust that is extended. Only signatures by the target key on User IDs that match the regular expression in the body of this packet have trust extended by the trust Signature subpacket. I interpret this differently. I interpret "to limit the scope of the trust that is extended" to mean that the source extends *its* trust to the target. That is, trust is not somehow reset when following an edge in the graph, but either passed on as is or narrowed. > However, I don't think c@example.org should be valid, as user U only > wanted to give permissions on r".*<.*@ca-a.com>" to root@ca-a.com. So I > think all regular expressions in the trust chain should have to match in > order to not be rejected -- in a similar fashion as the DNSSEC model. > > So the $B!H(Bwrong$B!I(B line here would be b@ca-a.com's trust, which should be > calculated as trust(254, r".*<.*@example.org>" AND r".*<.*@ca-a.com>"). Even if the standard is wrong here, this is definitely a more useful and non-broken approach, and, I suspect, almost certainly what was intended. > Another issue of this scheme, obviously, is that noone $B!H(Bin the wild$B!I(B > currently uses regular expression subpackets (that I know of). Not only does almost no one use regular expressions, but regular expression support is not very widely supported (GnuPG doesn't support regular expressions on Windows), and until recently broken in GnuPG (see https://dev.gnupg.org/T2923). I would like to make a counter proposal, that Vincent and I came up with at FOSDEM: I think that we should deprecate Regular Expression support and replace it with a list of domains (optionally prefixed with "*." to indicate any subdomain). First, most users don't understand regular expressions. And, although it would be possible to allow users to enter one or more domains and then convert them to a regular expression, it is not easy to reverse this process, which is essential for explanatory purposes and editing. Second, not including an RE engine reduces complexity. :) Neal From nobody Sun May 27 13:58:59 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A1E12EBF2 for ; Sun, 27 May 2018 13:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkcbGW4KfDs3 for ; Sun, 27 May 2018 13:58:57 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102A012711A for ; Sun, 27 May 2018 13:58:56 -0700 (PDT) Received: from 4.250.26.109.rev.sfr.net ([109.26.250.4] helo=chu.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1fN2kh-0002T7-Dj; Sun, 27 May 2018 20:58:55 +0000 Date: Sun, 27 May 2018 22:58:54 +0200 Message-ID: <87zi0kzugh.wl-neal@walfield.org> From: "Neal H. Walfield" To: Leo Gaspard Cc: openpgp@ietf.org In-Reply-To: <58cf1a73-12cf-0f86-d23c-1603273aabe2@leo.gaspard.ninja> References: <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> <874lit1m22.wl-neal@walfield.org> <58cf1a73-12cf-0f86-d23c-1603273aabe2@leo.gaspard.ninja> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 20:58:58 -0000 On Sun, 27 May 2018 19:00:04 +0200, Leo Gaspard wrote: > Indeed it's already possible, the issue with this solution being that > people willing to rely on signatures by the master key now need to > download two keys (the master key and the trusted introducer), and > another one after any compromise, while certification subkeys are > downloaded and updated at the same time as the master key, thus making > for more easy-to-use WoT. That's true. But, I'd argue that this is more of a tooling problem: when the tool is computing the WoT and it encounters a trusted introducer has tsigned a key, which is not available, it should proactively download the key. :) Neal From nobody Sun May 27 14:31:48 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D32112FB32 for ; Sun, 27 May 2018 14:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfwqOzVZKden for ; Sun, 27 May 2018 14:31:44 -0700 (PDT) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A58F127869 for ; Sun, 27 May 2018 14:31:43 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id a484d4a5; Sun, 27 May 2018 21:31:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=GWaNZJmiYzfvGMe6hK+ar71Kbm0=; b=jH/etB7Zz26Ahr vjQ7o4yY0BWeYs/R8V2AIVLXUIRmKpnlw+zfkAFHxhmHDxuXL00eAK3LpyN5X2Vo xWJWOzZpU2oSqe+7uqCz6pMS6apzMtqYj7v2Db5ALI7KCjB3GA8hethrARBET4Mv xED6dgiUAX4OUVbS8AryBRAGcWzzw= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 4d2e03a4 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO); Sun, 27 May 2018 21:31:40 +0000 (UTC) To: "Neal H. Walfield" Cc: openpgp@ietf.org References: <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> <874lit1m22.wl-neal@walfield.org> <58cf1a73-12cf-0f86-d23c-1603273aabe2@leo.gaspard.ninja> <87zi0kzugh.wl-neal@walfield.org> From: Leo Gaspard Message-ID: <163c6eb8-7eeb-d2ce-db2b-09633db7b597@leo.gaspard.ninja> Date: Sun, 27 May 2018 23:31:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <87zi0kzugh.wl-neal@walfield.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 21:31:46 -0000 On 05/27/2018 10:58 PM, Neal H. Walfield wrote: > On Sun, 27 May 2018 19:00:04 +0200, > Leo Gaspard wrote: >> Indeed it's already possible, the issue with this solution being that >> people willing to rely on signatures by the master key now need to >> download two keys (the master key and the trusted introducer), and >> another one after any compromise, while certification subkeys are >> downloaded and updated at the same time as the master key, thus making >> for more easy-to-use WoT. > > That's true. But, I'd argue that this is more of a tooling problem: > when the tool is computing the WoT and it encounters a trusted > introducer has tsigned a key, which is not available, it should > proactively download the key. Hmm, I'm not sure it's possible? I mean, if I'm a user, there are 3 keys to me: 1. The master key that I trust 2. The trusted introducer 3. The key whose validity I want to check As a user, I have only access to 1 and 3: 1 because I signed it, and 3 because I want to check it. I have /a priori/ no access to key 2. When could I fetch it? By policy (and I think it's reasonable for metadata protection reasons), (most?) implementations do not fetch keys on-the-fly during things like signature checking or encryption. So I must have had access to the key 2 before that. However, there is no way (as far as I know) to fetch key 2 when I have only key 1, as the information of which key a key has tsigned is not stored in the tsigning key. So the only moment left for the tooling to download key 2 is when fetching key 3: when downloading a key, it would automatically download all keys that have signed it. I think that's possible, but not necessarily reasonable, as it'd lead to surprising behaviour (importing more keys than expected), and thus potentially to vulnerabilities on other tools that wouldn't expect this behaviour. Now, I was putting this forward mostly for giving another use case that would naturally benefit from certification-able subkeys, I agree that it certainly wouldn't deserve the added complexity were it the only use case of them :) From nobody Sun May 27 15:27:27 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5412C12D7F3 for ; Sun, 27 May 2018 15:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoTrY-7uxvKb for ; Sun, 27 May 2018 15:27:23 -0700 (PDT) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5630127419 for ; Sun, 27 May 2018 15:27:22 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 0a1d3358; Sun, 27 May 2018 22:27:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=lGyKFzptltUmGtF9kINkp9V5ad0=; b=lPNrOMRbwuWbkW kAEc40+6wfiSW2JWSAd5RL8STvupPw+BxMfo7pr8iENmQFLEHC+zzcGUxpoC4HqA IAyThDigjZKrPpIWPtmifIOrH3J4mVA1V4ZQSf2IH/6RxqgnM9XD6rst1o4JOlyz GlHvnonZo8Iz1z6UFAniSww2jsSbE= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id b0ee5349 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO); Sun, 27 May 2018 22:27:19 +0000 (UTC) To: "Neal H. Walfield" Cc: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> From: Leo Gaspard Message-ID: Date: Mon, 28 May 2018 00:27:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <871sdw24yd.wl-neal@walfield.org> Content-Type: text/plain; charset=iso-2022-jp Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [openpgp] Overhauling User IDs / Standardizing User Attributes (was: Re: Scoped trust (signatures)) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 22:27:26 -0000 On 05/27/2018 10:56 PM, Neal H. Walfield wrote: >> Another issue of this scheme, obviously, is that noone $B!H(Bin the wild$B!I(B >> currently uses regular expression subpackets (that I know of). > > Not only does almost no one use regular expressions, but regular > expression support is not very widely supported (GnuPG doesn't support > regular expressions on Windows), and until recently broken in GnuPG > (see https://dev.gnupg.org/T2923). > > I would like to make a counter proposal, that Vincent and I came up > with at FOSDEM: I think that we should deprecate Regular Expression > support and replace it with a list of domains (optionally prefixed > with "*." to indicate any subdomain). First, most users don't > understand regular expressions. And, although it would be possible to > allow users to enter one or more domains and then convert them to a > regular expression, it is not easy to reverse this process, which is > essential for explanatory purposes and editing. Second, not including > an RE engine reduces complexity. Issue ----- This is what I had in mind at the beginning, but then I came upon a stumbling block: User IDs. They are not at all standardized, so it's not possible to assume they are in the form $B!H(BName (Comment) $B!I(B. And, even if assuming this, how could the implementation validate the $B!H(BName$B!I(B and $B!H(BComment$B!I(B parts, when the Regular Expression support is replaced by something to validate by domain? So I think there are two problems here: 1. User IDs are not standardized 2. User IDs contain many unrelated information I already explained point 1, so I'll now explain point 2. User IDs as currently used tie in a name and an email (I'll omit the Comment part). Which are two completely unrelated things: I have a single real-life name (well -- most people do), a pseudonym, and a lot of e-mail addresses. When I want to sign someone's User ID, I need to both check their real-life name (with eg. a state-provided ID) and their e-mail address. And if someone has put a pseudonym on the User ID, should I sign it? This tight coupling of name and email address in User IDs is already an issue for me (in choosing what User ID(s) I should put, choosing whether to sign a User ID I only know part of$B!D(B), and is now again an issue in fixing the standard to be both more simple and more usable. Idea ---- So here is my idea: drop User IDs in v5 keys, and standardize more User Attributes. In particular, standardize at least a $B!H(Bname$B!I(B, an $B!H(Bemail$B!I(B and a $B!H(Bpseudonym$B!I(B user attribute. (I'm not sure about the $B!H(Bcomment$B!I(B user attribute, and would prefer seeing it handled otherwise, see the $B!H(BPossible extensions$B!I(B section) Consequences ------------ So what would happen were this done? First, when picking my User IDs, I wouldn't have to think over whether I really want to associate such email address with my name or with my pseudonym. Then, when signing User Attributes, I could just sign all user attributes I checked. I could sign $B!H(Bemail$B!I(B User Attributes after checking I could send and receive mail to the provided email, I could sign $B!H(Bname$B!I(B attributes after checking a state-provided ID, and I could sign $B!H(Bpseudonym$B!I(B and $B!H(Bcomment$B!I(B attributes depending on my local signing policy (which I haven't really determined yet). Finally, this would make the scoping-by-domain-name proposal possible: it'd be $B!H(Bcan only sign `email` User Attributes and the part after the last @ must match this restriction$B!I(B. Possible extensions ------------------- So now with this change it would become possible to handle extensions of the User IDs that have been proposed. First, the $B!H(B[project] signing key$B!I(B comment, that can be seen eg. [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0x8B3F30F9C8C0C2EF). This could be handled by adding a $B!H(Brole$B!I(B User Attribute, that could be $B!H(BQubes OS developer$B!I(B here. And thus the organization only needs to validate the keyholder is a QubesOS developer when signing this, without having to also validate a name, an email address or whatever else. Then, the $B!H(BI have this account on this website$B!I(B, that can be seen eg. [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0xAC6D00DB7F24B2C2), and is the point that, as far as I understand, lead to the birth of keybase.io (which did show some traction). It could be handled by a $B!H(Baccount-on$B!I(B that would store both a domain name (for the website) and a username. Finally, I think it would be good to stay more $B!H(Bopen to extensions$B!I(B than the current scheme of (mis)using User IDs, by eg. reserving attribute type 255 for $B!H(Bplaintext key-value user ID$B!I(B, so that implementations that can't reasonably fit some data in one of these User Attributes could just use it with raw key/values instead of using one of the 100-110 reserved values, which wouldn't be displayed by implementations not aware of them. Remaining issues ---------------- The foremost issue with this change is the one of the UI to display the user: currently, in Enigmail (the only end-user-oriented UI I know of), the primary User ID of the key is displayed. With this change, there would no longer be a primary User ID. I can currently think of two UIs. The first would check that the name and the email address of the received mail are valid, and error-out otherwise. The second one would just pick a name and an email address from the list of valid ones, and display it. In my opinion, the first option is *way* better than the second one, and it's the reason why I didn't propose an extension of the Primary User ID flag to handle multiple primary User Attributes (would be one name and one email, for instance). For instance, a problem with primary User IDs/Attributes is the following: let's assume I can validate a few UIDs on the key, but not the primary one. What should I display? I think there is no good answer to this question apart from $B!H(Bvalidate the one it came as$B!I(B or $B!H(Bshow all the valid ones$B!I(B, and thus removing the Primary UID may remove some traps naive implementations may fall in, like displaying a non-validated primary UID. >> As I understand it, RFC4880 already has a provision for such a model, >> with $B!x(B5.2.3.14 _Regular Expression_. >> >> However, there is from my reading an issue with (the wording of) this >> section: it only restricts one-level trust signatures. In other words, >> from my reading, if: >> * User U trusts(255, r".*<.*@ca-a.com>") "A " >> * root@ca-a.com trusts(255, r".*<.*@example.org>") "B " >> * b@ca-a.com signs "C " >> >> Then, from A's point of view: >> * root@ca-a.com has trust(255, r".*<.*@ca-a.com>") >> * b@ca-a.com has trust(254, r".*<.*@example.org>") >> * c@example.org is valid > > [snip] > > I interpret this differently. I interpret "to limit the scope of the > trust that is extended" to mean that the source extends *its* trust to > the target. That is, trust is not somehow reset when following an > edge in the graph, but either passed on as is or narrowed. Indeed, it looks like I had misinterpreted this, thanks! From nobody Sun May 27 15:55:23 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0475F12EACC for ; Sun, 27 May 2018 15:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HANiP-BUCxaK for ; Sun, 27 May 2018 15:55:19 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F1A126CD6 for ; Sun, 27 May 2018 15:55:19 -0700 (PDT) Received: from localhost (mue-88-130-57-131.dsl.tropolys.de [88.130.57.131]) by mail.mugenguild.com (Postfix) with ESMTPSA id DF8F15FB11; Mon, 28 May 2018 00:55:16 +0200 (CEST) Date: Mon, 28 May 2018 00:55:15 +0200 From: Vincent Breitmoser To: Leo Gaspard Cc: openpgp@ietf.org Message-ID: <20180527225444.u6cxwxaxcybz43or@calamity> References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= User-Agent: NeoMutt/20180323 Archived-At: Subject: Re: [openpgp] Overhauling User IDs / Standardizing User Attributes (was: Re: Scoped trust (signatures)) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 22:55:22 -0000 > Then, the “I have this account on this website”, that can be seen eg. > [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0xAC6D00DB7F24B2C2), > and is the point that, as far as I understand, lead to the birth of > keybase.io (which did show some traction). It could be handled by a > “account-on” that would store both a domain name (for the website) and a > username. Been there, done that: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01 It's also implemented and deployed as an experimental feature in OpenKeychain. As a more general note, it would be nice if we could drop the requirement to have at least one (unsigned) user id, in which case the primary key gets its properties from a (then mandatory) direct key signature. For key distribution models other than searchable-by-uid keyservers (including autocrypt and wkd), user ids can quickly become unnecessary metadata. - V From nobody Sun May 27 16:28:04 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB46D12EAE9 for ; Sun, 27 May 2018 16:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOK1EwTbYfYp for ; Sun, 27 May 2018 16:28:00 -0700 (PDT) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83394127775 for ; Sun, 27 May 2018 16:27:59 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id abcf1415; Sun, 27 May 2018 23:27:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=M7l4Zpyh6S84YYZDcacgJZi6fTI=; b=UdIoCorcJY4Y+N 0mUc4j/NBCce6UKevu3ECdGJZ61b8tvdROT2rLpQfPsh6T/pVmLPMmk+NdC3ZaVg i2stQpvzv6TRfBt9EWWOeQ/qEfX6MpCbqDUI+Cuw0WFidwNx23jhmZpV7cQVksMk Z3U3i09JYZUk6NX4X9aW57vGgUEfQ= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 94813cf1 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO); Sun, 27 May 2018 23:27:55 +0000 (UTC) To: Vincent Breitmoser Cc: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <20180527225444.u6cxwxaxcybz43or@calamity> From: Leo Gaspard Message-ID: <231c1ab6-a3c0-daad-1641-0db31d2fd702@leo.gaspard.ninja> Date: Mon, 28 May 2018 01:27:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180527225444.u6cxwxaxcybz43or@calamity> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Overhauling User IDs / Standardizing User Attributes (was: Re: Scoped trust (signatures)) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 23:28:03 -0000 On 05/28/2018 12:55 AM, Vincent Breitmoser wrote: >> Then, the “I have this account on this website”, that can be seen eg. >> [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0xAC6D00DB7F24B2C2), >> and is the point that, as far as I understand, lead to the birth of >> keybase.io (which did show some traction). It could be handled by a >> “account-on” that would store both a domain name (for the website) and a >> username. > > Been there, done that: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01 > It's also implemented and deployed as an experimental feature in OpenKeychain. Hmm, this sounds like not solving the exact same issue: I was thinking of a user asserting “I am [X] on service [Y]”, and (if I read correctly your I-D) your proposal included having the OpenPGP implementation doing the validation of this statement. I think having the OpenPGP implementation doing the validation of such statements is *really* hard to do. For instance, the section 4.4 of your I-D doesn't explain how to do it, and I don't think it reasonably could (you mention yourself that a proper VERIFY operation requires additional insight on the specifics of each service). This is the reason why I was only proposing a way to include in a User ID “I am [this person]”, and then leave validation of this statement to the same mechanism as the usual User IDs: I think this has a chance to get in RFC4880bis, while having a more complex and modifying-the-trust-model scheme could only live in a separate RFC, especially when it potentially has implications on the privacy (as the services would then know when I attempt to verify a User ID). As for the validation of this User ID, with only my proposal, it could be handled in the same way as email addresses: scoped trust for the domain, that would be trusted to sign User IDs. Or scoped trust for keybase.io (or any other equivalent service), that would be trusted to validate the cookie online and sign the keys accordingly. Actually, email is just a special case of an account on an online service, but I think handling it separately makes sense, as eg. @github.com email addresses won't be the same as @users.noreply.github.com ones. That said, I do believe there is value in your proposal (eg. not relying on a trusted third-party when the upstream service doesn't have a public key that could be trusted), but I also think these two approaches are complementary. > As a more general note, it would be nice if we could drop the requirement to > have at least one (unsigned) user id, in which case the primary key gets its > properties from a (then mandatory) direct key signature. For key distribution > models other than searchable-by-uid keyservers (including autocrypt and wkd), > user ids can quickly become unnecessary metadata. With the changes I proposed, there would no longer be any User ID in v5 keys (the User ID subpacket would just be forbidden there, and likely Primary User ID too). There could be an arbitrary number of User Attributes, like now, because, as you mentioned, it may make sense to not have any for eg. TOFU use. From nobody Sun May 27 17:45:51 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674061204DA for ; Sun, 27 May 2018 17:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-CkB590Vd6E for ; Sun, 27 May 2018 17:45:47 -0700 (PDT) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CBE12D0C3 for ; Sun, 27 May 2018 17:45:47 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P9E00J00XK47S00@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Mon, 28 May 2018 00:44:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1527468265; bh=Cr69IcA0TL8UFkRa7uzGmJIzaEe8QBeL+GTFatFWPzg=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=RUWcMkXREHMORE5PmxUspV7V++Kla25PZajJRXByzhWjxIszkxzXBOKEyiCCYlWFB BnGUuA+dF+gLGvg9FCyG+wgJeIjEfR74/QvECjFCl/P8OXAZLP/jmFlUDCOV1HbDcL Vknr/TIAQdKIDilZRk+zAe/UiQfno7hQ/8dzHRPlVbwMD96qH8T2BUzNWkbp3mzKb7 KvZAlvIiMIqUftjNY2ftGKj4VGNjSB/h6qqKXfNyOoKA7Btr6q8nJ+lF/oOHiDiXS5 YHsigBAgbkEZmftAy/UW5IwHUGv26TkdiY+rFqT2f8WahsvjfleIvJuyFmRRndhtrV oFrJ/KLt4qqlg== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P9E008BZY1YOY10@st13p27im-asmtp004.me.com>; Mon, 28 May 2018 00:44:24 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-05-27_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1805280008 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Jon Callas In-reply-to: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> Date: Sun, 27 May 2018 17:44:21 -0700 Cc: Jon Callas , openpgp@ietf.org Content-transfer-encoding: quoted-printable Message-id: <3C4F6769-2D79-469B-B7B6-01B1D02B99AA@icloud.com> References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> To: Leo Gaspard X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [openpgp] Scoped trust (signatures) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 00:45:50 -0000 > On May 18, 2018, at 1:26 PM, Leo Gaspard = wrote: >=20 > Hello, >=20 > I have subscribed to this list only recently (late 2016), so please > forgive me if this has already been discussed, as I couldn't find it = in > the ML archives. I also hope I didn't miss something fundamental while > writing down this idea. No problem. Since I wrote that text, I can provide some color. I think = gentle persons can also disagree, so I'm not saying what I think is law, = merely that I wrote it, and therefore I think I can give some indication = of what the group consensus meant. Group consensus is often vague, = wishy-washy, etc. >=20 > As I understand it, currently, with OpenPGP, it is possible to = simulate > the Certificate Authority model: > * The clients wishing to use it assign full trust to the root CAs > * Root CAs use 255-trust trust signatures for subordinate CAs > * Subordinate CAs sign the verified OpenPGP keys That's pretty much the intent. The idea is that you should be able to = mark a key as being something like a CA. Two important things to remember about OpenPGP philosophy are: (1) = OpenPGP democratizes being a CA. All keys can sign, endorse, etc. and = (2) Trust is also democratized in that trust is in the eye of the = beholder. Also note that in many cases the beholder might be an = organization. That organization might push its policy to its members, = and be polite enough to scope that trust only to keys operating in that = environment. >=20 > I think it would be great to also be able to simulate the DNSSEC = model, > so that as a client I would be able to say =E2=80=9CI trust [this key] = to make > statements about [this set of keys].=E2=80=9D I see it as, is in a = way, a > logical follow-up of Web Key Directory. I suppose.=20 >=20 > As I understand it, RFC4880 already has a provision for such a model, > with =C2=A75.2.3.14 _Regular Expression_. >=20 > However, there is from my reading an issue with (the wording of) this > section: it only restricts one-level trust signatures. In other words, > from my reading, if: > * User U trusts(255, r".*<.*@ca-a.com>") "A " > * root@ca-a.com trusts(255, r".*<.*@example.org>") "B " > * b@ca-a.com signs "C " >=20 > Then, from A's point of view: > * root@ca-a.com has trust(255, r".*<.*@ca-a.com>") > * b@ca-a.com has trust(254, r".*<.*@example.org>") > * c@example.org is valid >=20 > However, I don't think c@example.org should be valid, as user U only > wanted to give permissions on r".*<.*@ca-a.com>" to root@ca-a.com. So = I > think all regular expressions in the trust chain should have to match = in > order to not be rejected -- in a similar fashion as the DNSSEC model. >=20 > So the =E2=80=9Cwrong=E2=80=9D line here would be b@ca-a.com's trust, = which should be > calculated as trust(254, r".*<.*@example.org>" AND = r".*<.*@ca-a.com>"). Well, I think I disagree. I think that if I am trusting ca-a.com with = scope at the root, subordinates cannot widen that scope. Scope is = supposed to be narrowed only through subordinates. If that weren't true, = then your subordinate that issues trust for example.org could just as = easily issue it for ".*" and now all of a sudden the subordinate gets to = sign everything, and that's the opposite of what scoping even means. >=20 > Another issue of this scheme, obviously, is that noone =E2=80=9Cin the = wild=E2=80=9D > currently uses regular expression subpackets (that I know of). = However, > I hope this could change, were this change to allow creation of scoped > CAs, that would interact nicely with WKD. Yup, it's a little-used feature. So little used that I don't know of = anyone using it, either. >=20 > For instance, a mail provider could set up such a =E2=80=9CCA=E2=80=9D, = that would > automatically sign all keys that would pass the WKD test, and for = which > the UID would be confirmed as valid by the internal database. Then, > users could start trusting such mail-provider-provided CAs, for > additional validation of the user ID (in addition to the localpart > already =E2=80=9Cvalidated=E2=80=9D by HTTPS), while still restricting = them for only > being valid for the domain(s) they own. For easy discovery, > mail-provider-provided CAs could have a path at > .well-known/openpgpkey/mail-provider-key, and the user could decide to > add some trust to this CA. I believe that is pretty much the intended use case. The idea is that if = I'm a member of an club (or company, etc.), then that club can bring in = new members and I don't have to go to the trouble of trusting their = keys, it happens for me. In the naive trust model, I can say, "Whatever Alice signs is okay with = me." This is obviously giving Alice a lot of power. The trust-extension feature says, "Alice can deputize others to sign for = her" and also permits those deputies to have deputies to some specified = depth. This is obviously extending Alice's power in huge ways. Even with = a level of only one, the only limit on Alice's power is that she has to = deputize new deputies, but she has unbounded power to deputize. The scoping feature is there so you can say, "Whatever Alice signs about = our club is okay with me." It limits Alice's power. This is a reasonable = and arguably important thing, especially if you're going to let Alice = deputize people who can deputize people. It's so that the second = assistant to the deputy undersecretary of the membership committee can't = just go sign anything and I'll believe it. >=20 > The aim of this proposal being to make OpenPGP easier to use by > introducing ways to reduce the work required for setting up a secure > channel, while leaving control over these to the user (or to the > implementer, for opinionated implementations) Sure! If there's anything OpenPGP needs it's more ease of use and work = reduction. >=20 > What do you think about this? I am not sure what you're really proposing, though. I think you might be = proposing the very thing I described, but I'm not sure. If that's not what I described, then do me a favor and describe the = problem you want solved. Jon >=20 > Cheers, > Leo >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Sun May 27 19:07:08 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C0812E886 for ; Sun, 27 May 2018 19:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWG-Ot09Yr3W for ; Sun, 27 May 2018 19:07:04 -0700 (PDT) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65EAB127286 for ; Sun, 27 May 2018 19:07:04 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P9F00L001P0GJ00@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Mon, 28 May 2018 02:07:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1527473223; bh=TcdL2Wf4LC2RBoYEN1KP4rj220X7IxcvZgyHhNCYgaU=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=eNofv3kGwyhJgj3eS4t6QlQBEXaV628BFEKuc421NFCjSKVZV9JkzXjBTfrLNVLrp I0VK4bZ2PfmNd1INn0Hu6KHywdFB51DWqsejvIzyr8WId0+r99jljkOonho1xeeuNH VYj54T4OplIs+mZxA4LIqBDjJLlUZYiqphLQyFufN5zIywLkEUkgxIHJ/1s2wx4+rF nxegK21s/kMCGHPQNIKb1DKodp18HoUv+0DDvWlVYOz9GyxScnNAIWYTjykDAcxoDG NVorENJGRCek+XhFfeihc3/Fj+C79AtBcVt35U5ouyPUsBuU8ufrX2JPeB72/l4a0l asHR1opAkgrGQ== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P9F00M2O1VOJ100@st13p27im-asmtp004.me.com>; Mon, 28 May 2018 02:07:03 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-05-28_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1805280024 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Jon Callas In-reply-to: <871sdw24yd.wl-neal@walfield.org> Date: Sun, 27 May 2018 19:06:59 -0700 Cc: Jon Callas , Leo Gaspard , openpgp@ietf.org Content-transfer-encoding: quoted-printable Message-id: References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> To: "Neal H. Walfield" X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [openpgp] Scoped trust (signatures) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 02:07:07 -0000 > On May 27, 2018, at 1:56 PM, Neal H. Walfield = wrote: >=20 >=20 [...[\] > I would like to make a counter proposal, that Vincent and I came up > with at FOSDEM: I think that we should deprecate Regular Expression > support and replace it with a list of domains (optionally prefixed > with "*." to indicate any subdomain). =20 I believe you can do this. A regexp that is "domain_1|domain_2" does this just fine. > First, most users don't > understand regular expressions. And, although it would be possible to > allow users to enter one or more domains and then convert them to a > regular expression, it is not easy to reverse this process, which is > essential for explanatory purposes and editing. Second, not including > an RE engine reduces complexity. My response is that that was not what the working group consensus was. The working group consensus was that we didn't want to debate specifics, = but regular expressions are sufficiently powerful to meet any reasonable = (and probably lots of unreasonable) scoping. I understand what you're saying, but I gotta reply, "So what?" I think = I'm going to end up in a small rant in the following. I apologize in = advance for any offense I might give in this small rant. Let me shift the discussion to something slightly related. I have email = accounts on a number of servers, and several of them allow me to do = server-side filtering of my email. They provide a handy web page that = lets me set up my own filtering rules. At the bottom of everything, all = of these sites do filtering with Sieve. Sieve, like OpenPGP is an IETF = standard, it is RFC 5228 and a lot more. Each of the email servers I use has a slightly different web-GUI = framework for specifying a rule. One of them, for example, is structured = so that I have to enter "To" and "CC" on separate lines. Another one = lets me specify "To" or "Any Recipient" (which means either To or CC). = On another, I have to actually use the generic filter on some line and = type in the CC if I want to filter on CC. In the actions phase of this, = one of them automatically terminates after matching one other rule, = while another one makes me put in an action line to stop processing = following rules. But at the end of the day, they're all Sieve scripts. (Oh, and one of them lets me upload my own Sieve script, but If I do = that, I can no longer use the web GUI. Well, I can, but the GUI will = likely overwrite all or part of the rules in ways that might totally = break everything.) There is *nothing* in OpenPGP that says you have to expose the full = details of regular expressions to the user. Just like with Sieve, = there's a full grammar that has expressive power that doesn't need to be = used, and probably shouldn't be. I agree completely that most users don't understand regexes. I agree = that they shouldn't be subjected to them, and that the vast majority of = what anyone needs is pretty much what you said =E2=80=94 a list of = domains. And yes, sensible software that does something nice for the = user is not going to be able to ingest in an arbitrary regular = expression and display it simply. Just like these server filtering web = pages don't expose all the power of Sieve, a sensible program that lets = people construct trust scope doesn't have to be just a text box that = someone types a regexp into. A protocol standard like OpenPGP specifies a grammar for messages. It's = a way to encode a message so that other people can understand it as well = as a way to interpret a message that someone else hands you. In English, you can go up a staircase. You can also mount the staircase, = ascend it, climb it, mount it, and even more. Grammar and vocabulary do = not require you to put all the synonyms on the sign by the stairs. Up = and Down are wonderful things to put on the sign. Ascend and Descend are = a bit pretentious and non-native speakers might have trouble with them; = thus they're compliant but have UX issues. The symbol =E2=AC=86 (that's = the "Up Arrow" emoji in case it doesn't display properly) is not = strictly standards-compliant, but if you're a fan of the Postel = meta-rule, knock yourself out. =20 Protocol standards are not specifications for software implementations = nor are they requirements documents. GnuPG is a wonderful piece of = software that tries very hard to be a reference implementation that = implements every single feature. It is not a requirement that every = implementation implement every feature. That's why we have the RFC 2119 = keywords. You gotta do the MUSTs. It would be nice to do the SHOULDs. = You don't have to do the MAYs.=20 If you look at Section 5.2.3.1 of RFC 4880, it is perhaps more = convoluted than it could be, but whatever. The gist of it is that since = it says that an implementation SHOULD implement the preference = subpackets as well as the Reason for Revocation, which at least implies = that the others are all MAYs. It further says that you SHOULD ignore = anything you don't "recognize" (which I interpret to be a synonym for = "implement") and that if the critical bit it set, you SHOULD sit in the = corner and sulk about anything you don't recognize. Moreover, there's a regular expression helpfully defined in Section 8 = that is a pretty bog-simple language, but like any regular expression = matcher, you can create patterns that will drive weak people to strong = drink. Nowhere are you *required* to let your user do things legal but = silly. The reason it's there is to *permit* people to do complex things, = not to expose the complexity to every user. It doesn't break the = standard to implement a list of domains. It doesn't break the standard = to let someone type in "*.example.com" for their scoping as opposed to = ".*\.example\.com". I believe that part of the reason so many people rail about the horrors = of OpenPGP is that lots of us have the idea that OpenPGP is a software = specification for GnuPG. That GnuPG is such a good piece of software is = ironically part of the problem. It's as if every web browser revolved = around the "curl" command.=20 I agree with you completely about scoping up until you want to change = the standard. The scoping is the way it is so that simple things are = easy and complex things are possible. If we make it so that only simple = things are possible it doesn't help anyone. (And as I said before, = working group consensus was such that the bog-simple regular expressions = were the way to go.=20 Okay, thanks for reading this far. Jon= From nobody Sun May 27 23:08:09 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F51124239 for ; Sun, 27 May 2018 23:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H-7kQswQBdk for ; Sun, 27 May 2018 23:08:06 -0700 (PDT) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BA01200FC for ; Sun, 27 May 2018 23:08:04 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id c9c6e3b8; Mon, 28 May 2018 06:08:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=7SVwr4LexXPuriHKirvcCBuRPro=; b=wXDuY6ZHnoudo0 2bL/d0MiZLCsMUbk8+iMO4eA7NTiqw+Dm+FapgUOrkRjDdpObgTz1eH4Lhuwjkv9 F8se0cytQN/wcAJvMRkrvqMlocIVp4UMb//T2rGp8yrwfDMzmGeHspyzddCWuD0E 4Y/pRhzDsu+pYMp4Ub3g1czaq2WVE= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id ab296277 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO); Mon, 28 May 2018 06:08:01 +0000 (UTC) To: Jon Callas Cc: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <3C4F6769-2D79-469B-B7B6-01B1D02B99AA@icloud.com> From: Leo Gaspard Message-ID: <18431e7f-ca69-dedd-3f63-acc7d73f971a@leo.gaspard.ninja> Date: Mon, 28 May 2018 08:08:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3C4F6769-2D79-469B-B7B6-01B1D02B99AA@icloud.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Scoped trust (signatures) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 06:08:09 -0000 On 05/28/2018 02:44 AM, Jon Callas wrote: >> The aim of this proposal being to make OpenPGP easier to use by >> introducing ways to reduce the work required for setting up a secure >> channel, while leaving control over these to the user (or to the >> implementer, for opinionated implementations) > > Sure! If there's anything OpenPGP needs it's more ease of use and work reduction. > >> >> What do you think about this? > > I am not sure what you're really proposing, though. I think you might be proposing the very thing I described, but I'm not sure. You're right, now that I understand that the RFC already meant what I was trying to do, my message didn't make much sense. > If that's not what I described, then do me a favor and describe the problem you want solved. The problem I want solved is “no-one is using regular expressions and thus implementations are likely non-existent or broken”. At first I assumed it was because of what I thought was an issue of wording in the RFC that would make it useless (hence my first post), but upon more thought I think it is due to the following: > The scoping feature is there so you can say, "Whatever Alice signs > about our club is okay with me." It limits Alice's power. I think the issue here is this “Whatever Alice signs about our club is okay with me”. It can't really be encoded well in regular expressions: I can not even say “Alice is only allowed to sign UIDs that end with @myclub.example.org>”, because that would allow Alice to sign keys with any name in it, and I would then implicitly trust Alice to have verified the real-world identity of the key. So upon more thought, I think the issue I'm feeling is there is better described by my forked-from-this-thread “[openpgp] Overhauling User IDs / Standardizing User Attributes (was: Re: Scoped trust (signatures))”, as with these changes it would become possible to scope the trust of Alice to verify email addresses in @myclub.example.org and roles ending with “at my club”, and even to scope the trust of a government's key to sign any name whatsoever (as they already can issue any state-provided ID thus make anyone fall for it at a keysigning party) but not any email or role. That said, it is a big change and I'm not sure it could gather enough momentum to be accepted. But I think (hope?) that with such a simplification in the way User IDs are handled (ie. without coupling of unrelated parts of a user's identity), regex filtering (or by-domain filtering) would become a tool adapted to the problem to solve, that is delegating limited trust. This way, automated CA-like systems for OpenPGP could appear without having issues with signing real names, mailbox providers could sign their user's email addresses without having to fear the risk that a user's real name is not the one on the User ID, etc. Does what I'm saying make sense? Anyway, thank you for this information on the background of this RFC! Leo From nobody Mon May 28 00:06:08 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3752127775 for ; Mon, 28 May 2018 00:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5hFNNBSPA1n for ; Mon, 28 May 2018 00:06:04 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C69127869 for ; Mon, 28 May 2018 00:06:04 -0700 (PDT) Received: from localhost (i59F77C1B.versanet.de [89.247.124.27]) by mail.mugenguild.com (Postfix) with ESMTPSA id 6DA555FB06; Mon, 28 May 2018 09:06:02 +0200 (CEST) Date: Mon, 28 May 2018 09:06:00 +0200 From: Vincent Breitmoser To: Jon Callas Cc: "Neal H. Walfield" , openpgp@ietf.org, Leo Gaspard Message-ID: <20180528070559.5cj2y7ebqzt7rplc@calamity> References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= User-Agent: NeoMutt/20180323 Archived-At: Subject: Re: [openpgp] Scoped trust (signatures) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 07:06:07 -0000 > Each of the email servers I use has a slightly different web-GUI framework for > specifying a rule. One of them, for example, is structured so that I have to > enter "To" and "CC" on separate lines. Another one lets me specify "To" or > "Any Recipient" (which means either To or CC). On another, I have to actually > use the generic filter on some line and type in the CC if I want to filter on > CC. In the actions phase of this, one of them automatically terminates after > matching one other rule, while another one makes me put in an action line to > stop processing following rules. But at the end of the day, they're all Sieve > scripts. I believe you've described the very problem with this approach here: A powerful and flexible mechanism leads to many inconsistencies between implementations, that's just unavoidable. For sieve scripts you might be fine with that, at worst some messages will go in the wrong folder once in a while. But are you really okay with same level of inconsistency in a trust model? - V From nobody Mon May 28 01:22:15 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD46126B6D for ; Mon, 28 May 2018 01:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r00l1KV71RPp for ; Mon, 28 May 2018 01:22:11 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485EE126DCA for ; Mon, 28 May 2018 01:22:11 -0700 (PDT) Received: from [195.25.201.50] (helo=chu.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1fNDPs-0006It-DM; Mon, 28 May 2018 08:22:08 +0000 Date: Mon, 28 May 2018 10:22:02 +0200 Message-ID: <87wovoyytx.wl-neal@walfield.org> From: "Neal H. Walfield" To: Leo Gaspard Cc: openpgp@ietf.org In-Reply-To: <163c6eb8-7eeb-d2ce-db2b-09633db7b597@leo.gaspard.ninja> References: <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> <874lit1m22.wl-neal@walfield.org> <58cf1a73-12cf-0f86-d23c-1603273aabe2@leo.gaspard.ninja> <87zi0kzugh.wl-neal@walfield.org> <163c6eb8-7eeb-d2ce-db2b-09633db7b597@leo.gaspard.ninja> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 08:22:13 -0000 On Sun, 27 May 2018 23:31:39 +0200, Leo Gaspard wrote: > On 05/27/2018 10:58 PM, Neal H. Walfield wrote: > > On Sun, 27 May 2018 19:00:04 +0200, > > Leo Gaspard wrote: > >> Indeed it's already possible, the issue with this solution being that > >> people willing to rely on signatures by the master key now need to > >> download two keys (the master key and the trusted introducer), and > >> another one after any compromise, while certification subkeys are > >> downloaded and updated at the same time as the master key, thus making > >> for more easy-to-use WoT. > > > > That's true. But, I'd argue that this is more of a tooling problem: > > when the tool is computing the WoT and it encounters a trusted > > introducer has tsigned a key, which is not available, it should > > proactively download the key. > > Hmm, I'm not sure it's possible? I mean, if I'm a user, there are 3 keys > to me: > 1. The master key that I trust > 2. The trusted introducer > 3. The key whose validity I want to check > > As a user, I have only access to 1 and 3: 1 because I signed it, and 3 > because I want to check it. I have /a priori/ no access to key 2. When > could I fetch it? Right. One thing that you can do right now is to fetch the keys that signed the master key: it is not unusual for key validation to be symmetric. The other thing is for the key servers to add an extension to return all keys signed by a given key. > By policy (and I think it's reasonable for metadata protection reasons), > (most?) implementations do not fetch keys on-the-fly during things like > signature checking or encryption. So I must have had access to the key 2 > before that. Accessing the keys via Tor partially mitigates this problem. But, there is no reason to only fetch the keys when needed. See, for instance, parcimonie for how to do this in a privacy preserving way. :) Neal From nobody Mon May 28 01:42:28 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC1C124217 for ; Mon, 28 May 2018 01:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjLGdhwFC89s for ; Mon, 28 May 2018 01:42:24 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C8F1201FA for ; Mon, 28 May 2018 01:42:24 -0700 (PDT) Received: from [195.25.201.50] (helo=chu.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1fNDjS-0006TX-RA; Mon, 28 May 2018 08:42:22 +0000 Date: Mon, 28 May 2018 10:42:22 +0200 Message-ID: <87vab8yxw1.wl-neal@walfield.org> From: "Neal H. Walfield" To: Jon Callas Cc: openpgp@ietf.org, Leo Gaspard In-Reply-To: References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] Scoped trust (signatures) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 08:42:26 -0000 On Mon, 28 May 2018 04:06:59 +0200, Jon Callas wrote: > Moreover, there's a regular expression helpfully defined in Section > 8 that is a pretty bog-simple language Implementing regular expression support might be bog-simple, but I think it is still orders of magnitude more complicated than just a list of domains. And, I think, the general lack of support for this feature is strong evidence that this is the case. Thus, it seems to me, that making the complicated theoretically possible has made the simple practically impossible. That's unfortunate. Do you know of any examples where a list of domains is not sufficient? Thanks! :) Neal From nobody Mon May 28 05:13:00 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78A41200C5 for ; Mon, 28 May 2018 05:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29iAnGyIt9gg for ; Mon, 28 May 2018 05:12:56 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DDBC124D37 for ; Mon, 28 May 2018 05:12:56 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1fNH1B-0005v1-S1 for ; Mon, 28 May 2018 14:12:53 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1fNGt0-0003LK-4V; Mon, 28 May 2018 14:04:26 +0200 From: Werner Koch To: "Neal H. Walfield" Cc: Daniel Kahn Gillmor , IETF OpenPGP , Kristian Fiskerstrand , Justus Winter References: <8736yg2gz3.wl-neal@walfield.org> <87h8mvfqth.fsf@fifthhorseman.net> <87y3g615ko.wl-neal@walfield.org> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: "Neal H. Walfield" , Daniel Kahn Gillmor , IETF OpenPGP , Kristian Fiskerstrand , Justus Winter Date: Mon, 28 May 2018 14:04:25 +0200 In-Reply-To: <87y3g615ko.wl-neal@walfield.org> (Neal H. Walfield's message of "Sat, 26 May 2018 23:15:51 +0200") Message-ID: <871sdwj8ae.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=9/11_genetic_asset_insurgency_CIDA_jihad_threat_AIEWS_Project_Monarc"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Clarify status of subkeys with certification use X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 12:12:59 -0000 --=9/11_genetic_asset_insurgency_CIDA_jihad_threat_AIEWS_Project_Monarc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 26 May 2018 23:15, neal@walfield.org said: > First, OpenPGP foresees two types of encryption keys: > > 0x04 - This key may be used to encrypt communications. > 0x08 - This key may be used to encrypt storage. Which was done to mimic the X.509 usage. X.509 required such a flag to differentiate between a sinnging and an encryption certificate. Even in the case that two certificates are issued (additional costs to the user) there is no fine grained distinction. Note that I am talking about certificates for mail processing. OpenPGP does not need this because subkeys are a more useful thing than trying to find matching certificates. Fine grain key usage flags doesn't gain you anything than complexity and unclear semantics. See X.509's keyUsage and extendedKeyUsage extensions to see where it will lead. > the newest one, AFAIK. But, there is precedence for encrypting to all > valid encryption capable subkeys: this is what OpenKeychain does. I doubt that this has any practical security gain over copying all needed subkeys to all devices. After all you want to read with all devices and the sender has no way to tell which device you are currently using. Rotating the keys is a much cleaner way to limit damage in case of a device compromise. > advance. For instance, we will create keys covering, say, the next 6 > months. By setting the creation time and expiration time > appropriately, only one key per device will be valid at any given > time. AFAIUI, recent versions of GnuPG respect this. Actually this was implemented ~20 years ago after consultation with Caspar Bowden of FIPR and Ben Laurie. The use case back then was to limit the damage done by the RIPA. Salam-Shalom, Werner p.s. Proper key rotation requires a lot of OPSEC and diligent use of comminucation tools. The problem we have are not forward secrecy but the general non-use of encryption and, worse, the insecurity of the equipment. =2D-=20 # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=9/11_genetic_asset_insurgency_CIDA_jihad_threat_AIEWS_Project_Monarc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWwvwSQAKCRD/gK6dHew1 jQZMAQC/NIaVpzO/HeA3dA/Hmq4f+l6DiHWPGg7kfz/eS1EBNAEAnejxW4ekiJjD DO29NrlTcX8cs/0YdaliAM1q90UB/gQ= =toRV -----END PGP SIGNATURE----- --=9/11_genetic_asset_insurgency_CIDA_jihad_threat_AIEWS_Project_Monarc--