From nobody Fri Aug 2 21:20:29 2019 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 303EE12006F for ; Fri, 2 Aug 2019 21:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=n8yt+xpI; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=HuG3z542 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 7oSVP7yOGx14 for ; Fri, 2 Aug 2019 21:20:25 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E6F12006D for ; Fri, 2 Aug 2019 21:20:25 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1564806025; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=qVWOlg/Wspem5Gs/VoIrUZVQOvm9PaykFPhdzvp1R38=; b=n8yt+xpIzQ4AING6LkEOVuwJveutvmL9O7lX6KoAwFWHEplkXfLVO9kk /QtvSnO1IzjqBOITePr0fuTZ5zHMCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1564806025; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=qVWOlg/Wspem5Gs/VoIrUZVQOvm9PaykFPhdzvp1R38=; b=HuG3z542YLfKGyJQjc+rvsiHmFjmQvHsafQPSzxIfl565wjv01HZXIT+ VNLGruciZfCbETmp/oPzZdYUTvibhQFv73vD05EU9126wtX7zjFke+4rm9 VBUAthE6ZS8rNj+0jj0+fJ5Ktg/C0qYPK3mDZ8GG9cOvNcwUit7NgFYybg kpDDM1JouM2u5I5DrokPkfoBjJKik9aI9YA5woJ8c4V7HLS+Ct1FvVkE9n kK902fwcMkyTyqgscfZwe0c8zQqvb1JGHzX6XSDoykKZT6LFLeE6Lg75MU 8rDtRu5D134qrZMYG3X6onVToGalqhcgaa4t5Z8SX3fQxPsIkHaR2A== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:5cf3:eff:fee2:4b88]) (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 DCF4CF99F; Sat, 3 Aug 2019 00:20:24 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A9959204B5; Sat, 3 Aug 2019 00:19:20 -0400 (EDT) From: Daniel Kahn Gillmor To: Vincent Breitmoser , openpgp@ietf.org In-Reply-To: <20180305231951.GA21944@calamity> References: <20180305231951.GA21944@calamity> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Sat, 03 Aug 2019 00:19:20 -0400 Message-ID: <87ef22rid3.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Intended Recipient Fingerprint signature subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 04:20:27 -0000 --=-=-= Content-Type: text/plain On Tue 2018-03-06 00:19:51 +0100, Vincent Breitmoser wrote: > 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. Sounds like we have two different implementations already capable of producing this. I've opened https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/19 to track the request. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXUULSAAKCRB2GBllKa5f +LQ0AQCjGpT9wqx/T8H8TCW45nkfULpISRDsHXL1qoiya6WZnAEAomD1GMb9phP1 igVVjV7pO5rF3S2pFfw1KLCJrorevAQ= =oksk -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 2 21:20:36 2019 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 D5E81120077 for ; Fri, 2 Aug 2019 21:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=docmoGJ6; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Jpeb3J74 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 3KQ1RcAjI2-H for ; Fri, 2 Aug 2019 21:20:25 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C6B12001A for ; Fri, 2 Aug 2019 21:20:25 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1564806024; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=FqevkwJQYegYvNrfikz9HvdY2Lx9b15LuCCXsSYclxM=; b=docmoGJ6OajocX6UV1pw88uxMJKmXQwixvc3cXuXk+lfdW3ctuuBZiU8 LzbRyHU4WA+Ht03TKCgrEWvZaaiyCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1564806024; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=FqevkwJQYegYvNrfikz9HvdY2Lx9b15LuCCXsSYclxM=; b=Jpeb3J74RYw5jhwm42OxBi4iJzDqK5wMNSyFqShov0suD1D2xVfkowJV QOW5z0QrPKa2fuF86bd3Pm/KtYznED3Q4Amxg0mzmx36J6CssfxsBmARDC 2yDzaUOLfGD8XNrPzDOteAmJCHIZizwxO2fnP0KLFyIEB0ZTBczQPyb5IP 1pkB7Jci10SSNLDjBXXQbaOeyS/wqmYV8IFjDWiYzJNPYgAqzi5ay7Enrl mFWXYkVZ5QvhyLfTTgPDlYrFSqHb/jinFD4E94qFMgCtwC8DyADZjb44kH Ux05y57tuI0Xvzfr6mV08A3dA7GtkJDf5gRrVclAidFAAOkDH9jN3A== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (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 63C1AF99E for ; Sat, 3 Aug 2019 00:20:23 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8061520431; Sat, 3 Aug 2019 00:18:21 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF OpenPGP WG In-Reply-To: <20190731203444.4822-1-dkg@fifthhorseman.net> References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Sat, 03 Aug 2019 00:18:21 -0400 Message-ID: <87h86yrieq.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 04:20:29 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed 2019-07-31 16:34:44 -0400, Daniel Kahn Gillmor wrote: > This patch to the spec deprecates the "revocation key" subpacket and > replaces it with a "designated revoker" subpacket that includes the > full key, rather than the fingerprint. [...] > @@ -1039,7 +1039,7 @@ The value of the subpacket type octet may be: > 9 Key Expiration Time > 10 Placeholder for backward compatibility > 11 Preferred Symmetric Algorithms > - 12 Revocation Key > + 12 Revocation Key (deprecated) > 13 to 15 Reserved > 16 Issuer > 17 to 19 Reserved > @@ -1058,6 +1058,7 @@ The value of the subpacket type octet may be: > 32 Embedded Signature > 33 Issuer Fingerprint > 34 Preferred AEAD Algorithms > + 35 Designated Revoker > 100 to 110 Private or experimental >=20=20 > An implementation SHOULD ignore any subpacket of a type that it does I've updated the above to use subpacket ID 36 for "Designated Revoker" instead of 35, since 35 is already in use in the wild by the "Intended Recipient Fingerprint" subpacket in at least two implementations i'm aware of. (see message-id: 20180305231951.GA21944@calamity from 2018-03-05 on this mailing list, and subsequent discussion) I've opened https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/19 to track the "Intended Recipient Fingerprint" subpacket. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXUULDQAKCRB2GBllKa5f +Lk4AQCYaXTnwZrb4XgvPfP2IXxK2n96fS1wDSGJO88Mkg9RugD/W814XxcKG8BN pBm3vY/FoX1mJDu+I2AY1Q0pxNUoGQw= =fP8w -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 5 10:45:25 2019 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 CC6C41202BE for ; Mon, 5 Aug 2019 10:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 FXhEcGdenLc0 for ; Mon, 5 Aug 2019 10:45:12 -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 CFFD01202AC for ; Mon, 5 Aug 2019 10:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=h+3Ok0wQ11neF03SRMLbo/sdo6nZxjWMN5IgZqWkxGc=; b=FQoCuR+ASBXAMKfUIqiDBWG6cv gxAgamf1qklhWTe4HIg14VXoS60TLPSIKWzPAWFuN8doRCSUBfW2Dhhrre1A/wtN8B1OF8szdOe2O XST8icas/+SKKmfonOQj7oAAjHtd5cBBgRE8a0/4t7ILRIVZadMqZFC7GAHgyWOLMfIc=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1huh2i-0006B6-P7 for ; Mon, 05 Aug 2019 19:45:08 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1huh1d-0006wR-Jq; Mon, 05 Aug 2019 19:44:01 +0200 From: Werner Koch To: Daniel Kahn Gillmor Cc: IETF OpenPGP WG References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Daniel Kahn Gillmor , IETF OpenPGP WG Date: Mon, 05 Aug 2019 19:44:01 +0200 In-Reply-To: <20190731203444.4822-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 31 Jul 2019 16:34:44 -0400") Message-ID: <87wofrmrry.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=SADMS_H5N1_UMTS_MI5_.Hello_to_all_my_friends_and_fans_in_domestic=su"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 17:45:15 -0000 --=SADMS_H5N1_UMTS_MI5_.Hello_to_all_my_friends_and_fans_in_domestic=su Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 31 Jul 2019 16:34, dkg@fifthhorseman.net said: > The "revocation key" subpacket is problematic. It is the the most > fragile piece of the specification wrt the fingerprint (collisions > against a fingerprint can create surprising revocation effects). And With the move to v5 keys this will be solved en-passant. > replaces it with a "designated revoker" subpacket that includes the > full key, rather than the fingerprint. I view this as problematic in the light of our preparations to allow for larger key material. With PQC we may need megabyte large keys and then including an entire key would double the size of a keyblock. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=SADMS_H5N1_UMTS_MI5_.Hello_to_all_my_friends_and_fans_in_domestic=su Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXUhq4QAKCRD/gK6dHew1 jb/EAP9BxoB7+4nhSo2spdpJo7MjbzqEnbclhRXbdDf7NcdXSgEA7IQDoeL6D0WZ y6gwYe814luacNbJSGv40q+TbWdC/w0= =qADw -----END PGP SIGNATURE----- --=SADMS_H5N1_UMTS_MI5_.Hello_to_all_my_friends_and_fans_in_domestic=su-- From nobody Mon Aug 5 11:23:31 2019 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 AF1A512004A for ; Mon, 5 Aug 2019 11:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.ai 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 rTPv0cHJ9JXY for ; Mon, 5 Aug 2019 11:23:28 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) (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 7F91112003E for ; Mon, 5 Aug 2019 11:23:28 -0700 (PDT) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id B8BCBC0917 for ; Mon, 5 Aug 2019 18:23:27 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=5Oscjc7hqoOb5POduKZ4nuh731azuTdYM60woLxIMU4=; b=nK9lOmf5S082RauBCSCXmWEeivh4XLjGD9nrI1P3rHQYfydPkplF/HiS/mZOb8PN8K07etxFRM+7aUxXLNwpLS+FcxX/DgA+YJUVwAE8JRrBMVk1rUPQ9ND8gNA1cG7JTdOW2Jy2Qgg5Vck8ujpZjfDDwgtn9hVyfU4mo2ik3R4twhrwIPVSveiQA1hpHj0ZQls06TT3Q2MpjwEFO7RL985koMb3vjQ72vHxCbCeNsMe+7v+8Fk1fgp6A9PY+Ilf2afT6MY7fxaR5RzD3SIe8jpAING0YNlsG+PgADo5YxesTaDsoXlMJLtFQV7SkvUh3T8hifRKDDJbeMiPfhKqQg== Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS; Mon, 5 Aug 2019 18:23:26 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id AC15E20118; Mon, 5 Aug 2019 18:23:26 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 05 Aug 2019 14:23:26 -0400 To: "Werner Koch" , "Daniel Kahn Gillmor" Cc: "IETF OpenPGP WG" From: vedaal@nym.hush.com In-Reply-To: <87wofrmrry.fsf@wheatstone.g10code.de> References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> <87wofrmrry.fsf@wheatstone.g10code.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20190805182326.AC15E20118@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 18:23:30 -0000 On 8/5/2019 at 1:45 PM, "Werner Koch" wrote: >I view this as problematic in the light of our preparations to >allow for >larger key material. With PQC we may need megabyte large keys and >then >including an entire key would double the size of a keyblock. ===== There is a workaround which could avoid this; Generating a Revocation Certificate for the key, and keeping it in a separate place from the keyring, and also sending it to whomever the user wants to be the 'designated revoker', (which could change from time to time, without having to update the keyblock itself). If this seems reasonable, then maybe consider it as a 'suggestion/comment' to the rfc section dealing with revocation. vedaal From nobody Mon Aug 5 11:24:30 2019 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 49648120164 for ; Mon, 5 Aug 2019 11:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 5Un_VVyIoUKt for ; Mon, 5 Aug 2019 11:24:27 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 97A1D12003E for ; Mon, 5 Aug 2019 11:24:27 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 462R4T1L8HzFBJ; Mon, 5 Aug 2019 20:24:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1565029465; bh=0Om3qEFRokDR+1ha11b62Vl+XmL69QDn+YPOdd+CzG4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Z4CLw+Z3LRjIlERbFVqIenEtM4OVMaCpy2Ys4yIN4ufirSy397vZx3zEBLjNC3n2K QKNKnY01miPC+yxuh8VeXjfN2dz9xLoPfvInUeDkVKOE9eXTDISpOacbNEra6KHnTS vJ77fQa+9fFXqilztZdQPbkHVYttrRLTM3qgb88k= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5i-lacsflX90; Mon, 5 Aug 2019 20:24:24 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 5 Aug 2019 20:24:24 +0200 (CEST) Received: from [192.168.13.13] (nat05.wpe01.151FrontStW01.YYZ.beanfield.com [66.207.198.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 0BD6A5C853; Mon, 5 Aug 2019 14:24:23 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0BD6A5C853 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16F203) In-Reply-To: <87wofrmrry.fsf@wheatstone.g10code.de> Date: Mon, 5 Aug 2019 14:24:22 -0400 Cc: Daniel Kahn Gillmor , IETF OpenPGP WG Content-Transfer-Encoding: quoted-printable Message-Id: <61041EDB-DE08-48B9-AB01-EC1B12E700F1@nohats.ca> References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> <87wofrmrry.fsf@wheatstone.g10code.de> To: Werner Koch Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 18:24:29 -0000 > On Aug 5, 2019, at 13:44, Werner Koch wrote: >=20 >=20 > I view this as problematic in the light of our preparations to allow for > larger key material. With PQC we may need megabyte large keys and then > including an entire key would double the size of a keyblock. There is only one proposal in the NIST competition with that issue (McEliece= ) , and unlikely to be the winner, precisely because of that. Paul From nobody Mon Aug 5 13:03:52 2019 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 5664E120099 for ; Mon, 5 Aug 2019 13:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.ai 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 NsW4z3isKgQ6 for ; Mon, 5 Aug 2019 13:03:48 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) (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 9FE1112008C for ; Mon, 5 Aug 2019 13:03:48 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id 3CC89A0B1C for ; Mon, 5 Aug 2019 20:03:47 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=ppzyVzuqtNW+pMWwlixpN3WEf7sU3p5ybHejjs4EKGo=; b=L7PeECo/4IL105PaUpwOluFbQqQTrvi1Bk1PkdZQ21Tjy/0w2nk8aVopk3Q2vOSF6vuqt9gPLq4hV0nEOWUxjrrhY6EO0WIbfxjRIuwwHv6hcKeAGNpxjZxGT4YP/vo0DQdhEUc6X01R5qT2W0XN2gEoxi6INi2U/VepBiqIhhIEiZZUaUO1Bd+aMxnvYz3TeLSQC4VPlbXDSuzsv7wva6RhrFlKKylP1mxvE6w7iXFkkEZpyoAZj0SwNI5WNLnzUtrfuex2CAZQz3VZXekNrlXmYVUaMiwuJCiBQhE1+kYJ4UHXGe9WEbvunlVShrxUE41/r6areaTeOjoIB/wwow== Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS; Mon, 5 Aug 2019 20:03:46 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 3BB4B20116; Mon, 5 Aug 2019 20:03:46 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 05 Aug 2019 16:03:45 -0400 To: "Werner Koch" , "Daniel Kahn Gillmor" Cc: "IETF OpenPGP WG" From: vedaal@nym.hush.com In-Reply-To: <20190805182326.AC15E20118@smtp.hushmail.com> References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> <87wofrmrry.fsf@wheatstone.g10code.de> <20190805182326.AC15E20118@smtp.hushmail.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20190805200346.3BB4B20116@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] [Suspected Junk Mail] Re: [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 20:03:51 -0000 On 8/5/2019 at 2:23 PM, vedaal@nym.hush.com wrote: > >On 8/5/2019 at 1:45 PM, "Werner Koch" wrote: >>I view this as problematic in the light of our preparations to >>allow for >>larger key material. With PQC we may need megabyte large keys >and >>then >>including an entire key would double the size of a keyblock. > >===== > >There is a workaround which could avoid this; > >Generating a Revocation Certificate for the key ===== The command: gpg --gen-revoke works fine in GnuPG 2.x exactly as it did in 1.x, although --gen-revoke is not listed in --dump-options for GnuPG 2.x (--desig-revoke is listed in both). Are there any plans to do away with the --gen-revoke option in 2.x ? (if possible, keep it, please, please ;-) it really is very useful at times. TIA vedaal From nobody Tue Aug 6 04:27:00 2019 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 0CC431200C7 for ; Tue, 6 Aug 2019 04:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=ps7mvNYO; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=FQCZycCT 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 SdSdiEpQncHw for ; Tue, 6 Aug 2019 04:26:54 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94673120077 for ; Tue, 6 Aug 2019 04:26:54 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1565090813; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=gy37irzTcZyMonC/AUdXEIi3Rzt/W4ruJDaXzJmlm60=; b=ps7mvNYOz/+gqOn7mHwAxsLApUeW4s+ZmGXJSkQPTB1R7U3z7WxZlVPo 2pLhKBS3b+Pq5UMKaZ8MswHv21Z+BA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1565090813; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=gy37irzTcZyMonC/AUdXEIi3Rzt/W4ruJDaXzJmlm60=; b=FQCZycCT9Xez84w7qNc/oabnedmvTGYVq0eYyEj/CtM6dzzE1c7xnU6N 2VNS8VxOGPOZhncR4f/EKUu5+Khn2feHkRRgQLMQSBkoj+5F/iYgeqeULZ Q4Xiu15jvMRwUIiZ/m2RwjsPwDBvIyP91kUm6V7zKJIfh7rp8uergantSW eZdl5gaknypgVVP77mxpKKLvRByUL995vDtZpwrXAEzq1f+gDiug7TViD3 xdK0WCEjMAXu9HSZuTOT9hH/+7X5rd1UB0cqL9KLNA49A+aQ8YGPUaqmI0 bfR2VKEkFSccQ2W0eLONEY369rjFeFlsHBRt46QSsEipGR/vt1DgEw== Received: from fifthhorseman.net (unknown [98.11.158.111]) (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 33CC8F99D; Tue, 6 Aug 2019 07:26:51 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B6B23204C8; Mon, 5 Aug 2019 16:16:27 -0400 (EDT) From: Daniel Kahn Gillmor To: Werner Koch Cc: IETF OpenPGP WG In-Reply-To: <87wofrmrry.fsf@wheatstone.g10code.de> References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> <87wofrmrry.fsf@wheatstone.g10code.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Mon, 05 Aug 2019 16:16:27 -0400 Message-ID: <87v9vbpdus.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 11:26:57 -0000 --=-=-= Content-Type: text/plain On Mon 2019-08-05 19:44:01 +0200, Werner Koch wrote: > On Wed, 31 Jul 2019 16:34, dkg@fifthhorseman.net said: >> The "revocation key" subpacket is problematic. It is the the most >> fragile piece of the specification wrt the fingerprint (collisions >> against a fingerprint can create surprising revocation effects). And > > With the move to v5 keys this will be solved en-passant. Sure, but this isn't the most important part of the problem. The important part is that people need to be able to see the public key of the revoker, and it's not always clear that this will be available. >> replaces it with a "designated revoker" subpacket that includes the >> full key, rather than the fingerprint. > > I view this as problematic in the light of our preparations to allow for > larger key material. With PQC we may need megabyte large keys and then > including an entire key would double the size of a keyblock. I agree with you that this would make such a packet larger. And therefore, the people who want to make use of such a scheme -- and the peers that they contact -- would need to accept a larger certificate/keyblock size as a result. It's not quite doubling, though: given that there may be subkeys the certificate, and non-negligible certifications themselves (including self-sigs and subkey binding signatures, etc), such a subpacket is likely to be smaller than the rest of the surrounding certificate. and in any case, it's comparatively small compared to some things we distribute today in much more common circumstances than a "designated revoker". Moreover, the verifier who discovers a third-party revocation needs to check fetch the associated public key somehow no matter what. And it's always possible to distribute a "designated revoker" packet alongside the revocation itself. This approach increases the size of a revocation, but incurs *no extra cost* compard to "normal" certificate size (and no metadata leakage). For a single verification, this is likely to be less traffic for the verifier than if they were obliged to fetch the full transferable public key associated with the revoker in the first place. So: my argument here remains that shipping the revoker's key in "designated revoker" has benefits in terms of: * more convenience for verifiers * higher likelihood that verifiers can actually assess and accept a delegated revocation when encountered * better metadata properties (self-contained messages reduce side channels for their users) * lower traffic/bandwidth costs for a verifier who encounters a delegated revocation from an unknown key And is only a marginal costs in terms of: * in one possible deployment configuration, for the uncommon user of such a packet, a modest increase in certificate size. This seems like a clear win to me, though i acknowledge that it is not without some minor tradeoffs. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXUiOmwAKCRB2GBllKa5f +JO7AP9gDukxZRMPixewKR8munIAqEvOLfZDFMaZXjgecTcJOQD/c2RVTY4yvs4o xHwSzzoBkENigKO/nvRyr1sSfebtYw0= =Ewpv -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 6 04:27:08 2019 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 5AC98120077 for ; Tue, 6 Aug 2019 04:26:57 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=AHxXs385; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=G+R81fea 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 o_lhn6MJ8JuF for ; Tue, 6 Aug 2019 04:26:54 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946EA1200B7 for ; Tue, 6 Aug 2019 04:26:54 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1565090813; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=j0DdWgw9wlpGmLw/cKIUyYDeVy3G2py2wj2xFonb4ZM=; b=AHxXs385nBubaIr9kInHPUHvb3fTzgwja26pIXUIUri1xaAY51l6DZwB T3D7FTlD4iCoeIr2+2FAs0zgKzW0Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1565090813; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=j0DdWgw9wlpGmLw/cKIUyYDeVy3G2py2wj2xFonb4ZM=; b=G+R81feaq7LOeGg4TG/heCiuHOAuSynW4DdZufqGXrYslNWR+6tb/yZa F/5YL/Ptl7tG1o2fP+Rd+UumiokgM26UAqFoBWVhw0ci8o7G4WRUPPUtQY 3QfvR7AYkO5EQC1NcetqRnhWe7cvukKPz+kgaWJDy/zGFhYx7AF15buZu6 KADDdJGH2XIv1FZvqBT5Q1xhE2o5ZaQNmmYRyAseNonQvAmaozlowFMnje s7Wyuxmt/DGG4OSnQN49Xc+OINe2msPmcnfI+LVN879inSSRucDeypDe3E kFnBS3ndIyCatSHFtI3akj82CUgvt1MwIgyvdMS/RnVS5XuONFf1Sg== Received: from fifthhorseman.net (unknown [98.11.158.111]) (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 42902F99E; Tue, 6 Aug 2019 07:26:51 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 29DA1204B5; Mon, 5 Aug 2019 16:11:43 -0400 (EDT) From: Daniel Kahn Gillmor To: Paul Wouters , Werner Koch Cc: IETF OpenPGP WG In-Reply-To: <61041EDB-DE08-48B9-AB01-EC1B12E700F1@nohats.ca> References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> <87wofrmrry.fsf@wheatstone.g10code.de> <61041EDB-DE08-48B9-AB01-EC1B12E700F1@nohats.ca> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Mon, 05 Aug 2019 16:11:42 -0400 Message-ID: <87wofrpe2p.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 11:26:57 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon 2019-08-05 14:24:22 -0400, Paul Wouters wrote: >> On Aug 5, 2019, at 13:44, Werner Koch wrote: >>=20 >> I view this as problematic in the light of our preparations to allow for >> larger key material. With PQC we may need megabyte large keys and then >> including an entire key would double the size of a keyblock. > > There is only one proposal in the NIST competition with that issue > (McEliece) , and unlikely to be the winner, precisely because of that. I also note that PQ key material is most significantly relevant today for *encryption/decryption* keys, which *are not* likely to be designated revokers (McEliece itself is rarely used for signing, aiui). --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXUiNfgAKCRB2GBllKa5f +BRhAP9qmV8sVg63FDMNX+WPe2ML16oE9r+qy1q6KH7imN9EXAEAinVotfoPLKTm dElQ1TRZ4CBhfA8jWX4uV40p6AZSUgg= =0a4b -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 6 06:09:33 2019 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 0FC51120183 for ; Tue, 6 Aug 2019 06:09:32 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=3LeZEbVJ; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=FP/oNDCM 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 MFFWmjeGBJfF for ; Tue, 6 Aug 2019 06:09:30 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAB812013E for ; Tue, 6 Aug 2019 06:09:30 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1565096968; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=pgEYQGinjxHRaaGVFnVGSlxxKNYYTBDK1QWGIoRKnMc=; b=3LeZEbVJCBsW25XqWPhpJU9ZNE06vwZhAH4TF+MbIyXTN6y15GtTV4c7 cZ/O6Eg/XPutUIVyl3d0IizU/W+jBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1565096968; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=pgEYQGinjxHRaaGVFnVGSlxxKNYYTBDK1QWGIoRKnMc=; b=FP/oNDCMutGZBPoh406xIisKv7ULtgfVwmt6vG9YmUBIcSVsp8WeeKIo 6pYbRzWw+rXCfl5IQ3oAm1qnlWubI8HfJ+ZqNHh1I0eWDOY2h7RCHU13MG zzY3gqaxghAE5XjZzI49Oa+qyjdyymQ2n8e2kL3LjJxekMNodtXJCGdOFo 9GyDNS2RH6pt6xA802LcquVFYzRWJJggkMY3Ifri7lR9vfjyNQKBwBIyU2 rCIM4NIwqUJQVmfMuw0Vrh5j73DUmzQcO059yCzzCyHGiFaG+v5OXHWG39 J576FWhxuMXq/ioGcsfNxD5a9T0UQuFtSv4JHNMDty1WGcAJdUzArQ== Received: from fifthhorseman.net (unknown [98.11.158.111]) (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 4FEBCF99F; Tue, 6 Aug 2019 09:09:27 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CA7BA2024E; Tue, 6 Aug 2019 08:25:07 -0400 (EDT) From: Daniel Kahn Gillmor To: Thomas Arendsen Hein Cc: gpg4win-users-en@wald.intevation.org, openpgp@ietf.org In-Reply-To: <20190805132446.482087064.thomas@intevation.de> References: <87ftmnro0l.fsf@fifthhorseman.net> <20190805132446.482087064.thomas@intevation.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Tue, 06 Aug 2019 08:25:07 -0400 Message-ID: <87sgqepjks.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] WKD for OpenPGP certificate "Intevation File Distribution Key " X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 13:09:32 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [ Adding openpgp@ietf.org as i think this discussion is more standards-relevant, and is not just gpg4win-specific ] On Mon 2019-08-05 13:32:33 +0200, Thomas Arendsen Hein wrote: > The WKD RFC does not allow publishing multiple keys for the same > email address, unless all but one of they keys has been revoked. > > But it makes sense to only publish the new key, so I just replaced > it. Thanks for updating the key! I read https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08#page-5 and i can see how to read it via your interpretation, but i confess i read it with some ambiguity: The HTTP GET method MUST return the binary representation of the OpenPGP key for the given mail address. The key needs to carry a User ID packet ([RFC4880]) with that mail address. Note that the key may be revoked or expired - it is up to the client to handle such conditions. To ease distribution of revoked keys, a server may return revoked keys in addition to a new key. The keys are returned by a single request as concatenated key blocks. So when i read this, i think the MUST applies to the fact that a binary representation of the key needs to be present in the HTTPS response body, but other material can also be included. I don't see any constraint like "MUST NOT return multiple non-revoked keyblocks", and i *do* see "it is up to the client to handle such conditions=E2=80=A6" which makes me think that clients will need to underst= and what to do if multiple non-revoked OpenPGP certificates are returned anyway. What should a sensible OpenPGP client do if it encounters this case? Even if there was a "MUST NOT" added, what should a sensible OpenPGP client do if it encounters such a response? reject all the certificates? take only the first non-revoked one? take only the last non-revoked one? take the one with the most recent creation date that has algorithms that the local implementation can handle? What if two subsequent queries to the WKD endpoint (within an hour of each other, let's say) return different certificates? what should a client do? > Andre, do you think it would be helpful to keep old keys available > via WKD? If yes, either the WKD RFC needs to be adjusted (which > possibly can be helpful for people having multiple keys, too, e.g. > ed25519 and a more compatible fallback rsa3072 key, or during key > rollover when emails are still signed with the old key, but a new > key already is available) I think it would be concretely useful in cases of a planned key transition to be able to return multiple still-valid certificates via WKD. > or we need to use different email addresses, > e.g. distribution-key+2016@... for a key generated in 2016. Please don't resort to this approach. E-mail addresses should establish a constant long-term identity. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXUlxowAKCRB2GBllKa5f +IRBAQCFzyLflC9NODQHxav+x5eI4A2yqeHGUAXBHTNzBBVGiwD/V7dtdHqk/rpu b15r+sjABeAa2uhW6GsKeUZb7JuBogI= =eZQ2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 6 06:09:42 2019 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 EA1E812013E for ; Tue, 6 Aug 2019 06:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=dIi+Tpir; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=lhX6St08 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 0Ex53NrZv99X for ; Tue, 6 Aug 2019 06:09:31 -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 AB0FC120182 for ; Tue, 6 Aug 2019 06:09:31 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1565096970; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=3yK68XmwbZp6fjCz05Hia+6GUXBo9H1qErPrIyPudrs=; b=dIi+TpirCjU911t0Dxo2MU+R44J6eoRWRW46K4xnIXQ8rl/hGaoAuCbt EIBjLI4Wep1GaRLzzJuvWuuGiy6pCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1565096970; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=3yK68XmwbZp6fjCz05Hia+6GUXBo9H1qErPrIyPudrs=; b=lhX6St08DgrVoqTCNMKxxG+1UdC6iwLVwkxh/9HFsAxuR3sxBjMorOR9 0mrEXUe3iUw+yUoIU7A5d3HbulWpByooaQFapqsnwY5ucdhxM0UosJCImj ZsdaY5snlb1t32glmmViV6hpvEKrdVe27gt0WfDpfbAlRr/KUrEuf+hCcl pDS+0qy7xo2zteklZiyAYdfQY09TjM4tu/Pe6z/r6oxCUiUONVT0FFfHNy SBS0moDR7tYMh0iJJ1xyUK7zWXZIsE3xOmWeUIAoaJYXIJvvJPwaEMZQiR 1aFr7xIvJVeisFnstQR/I+Xv0lRkRkq0wn2BnwjkglUvv3L943ig6A== Received: from fifthhorseman.net (unknown [98.11.158.111]) (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 1D6BFF99E; Tue, 6 Aug 2019 09:09:27 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0FD3C204B5; Tue, 6 Aug 2019 08:28:47 -0400 (EDT) From: Daniel Kahn Gillmor To: vedaal@nym.hush.com, Werner Koch Cc: IETF OpenPGP WG In-Reply-To: <20190805200346.3BB4B20116@smtp.hushmail.com> References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> <87wofrmrry.fsf@wheatstone.g10code.de> <20190805182326.AC15E20118@smtp.hushmail.com> <20190805200346.3BB4B20116@smtp.hushmail.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Tue, 06 Aug 2019 08:28:46 -0400 Message-ID: <87pnlipjep.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [Suspected Junk Mail] Re: [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 13:09:33 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon 2019-08-05 16:03:45 -0400, vedaal@nym.hush.com wrote: > The command: gpg --gen-revoke=20=20 > works fine in GnuPG 2.x exactly as it did in 1.x, > although --gen-revoke is not listed in --dump-options for GnuPG 2.x=20 > (--desig-revoke is listed in both). it seems present for me in 2.2.17: 0 dkg@alice:~$ gpg --version | head -n1 gpg (GnuPG) 2.2.17 0 dkg@alice:~$ gpg --dump-options | grep revo =2D-quick-revoke-uid =2D-generate-revocation =2D-gen-revoke =2D-generate-designated-revocation =2D-desig-revoke 0 dkg@alice:~$=20 i don't think it's going away. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXUlyfgAKCRB2GBllKa5f +KbrAQCIuiKyGLq+a1oMcN9FOv9/lOaIxyuAPxn3PtSaJoBLiwD/W0tRSqFGEsGU zVGyhj0j88riU93AidS8Y0oGY4+Zrgc= =d1Hh -----END PGP SIGNATURE----- --=-=-=-- From bernhard@intevation.de Tue Aug 6 07:58:17 2019 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 8E7E412019F for ; Tue, 6 Aug 2019 07:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 Q7Wog5X2-XDD for ; Tue, 6 Aug 2019 07:58:15 -0700 (PDT) Received: from kolab.intevation.de (kolab.intevation.de [212.95.107.133]) by ietfa.amsl.com (Postfix) with ESMTP id 44774120173 for ; Tue, 6 Aug 2019 07:58:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 9C0BC624E2 for ; Tue, 6 Aug 2019 16:58:12 +0200 (CEST) X-Virus-Scanned: by amavisd-new at intevation.de Received: from kolab.intevation.de ([127.0.0.1]) by localhost (kolab.intevation.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw8U5NAi86XJ for ; Tue, 6 Aug 2019 16:58:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id B627E62731 for ; Tue, 6 Aug 2019 16:58:10 +0200 (CEST) Received: from ploto.hq.intevation.de (ploto.hq.intevation.de [192.168.11.18]) (Authenticated sender: bernhard.reiter@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 910E06205E; Tue, 6 Aug 2019 16:58:10 +0200 (CEST) From: Bernhard Reiter To: gpg4win-users-en@wald.intevation.org Date: Tue, 6 Aug 2019 16:58:05 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20141209.518c4af) Cc: Daniel Kahn Gillmor , Thomas Arendsen Hein , openpgp@ietf.org References: <87ftmnro0l.fsf@fifthhorseman.net> <20190805132446.482087064.thomas@intevation.de> <87sgqepjks.fsf@fifthhorseman.net> In-Reply-To: <87sgqepjks.fsf@fifthhorseman.net> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart173901862.hOUxVbFE2x"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201908061658.09774.bernhard@intevation.de> Archived-At: X-Mailman-Approved-At: Tue, 06 Aug 2019 08:41:33 -0700 Subject: Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key " X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 15:23:37 -0000 --nextPart173901862.hOUxVbFE2x Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Dienstag 06 August 2019 14:25:07 schrieb Daniel Kahn Gillmor: > On Mon 2019-08-05 13:32:33 +0200, Thomas Arendsen Hein wrote: > > The WKD RFC does not allow publishing multiple keys for the same > > email address, unless all but one of they keys has been revoked. > I read > https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08#page-5 > and i can see how to read it via your interpretation, but i confess i > read it with some ambiguity: > > The HTTP GET method MUST return the binary representation of the > OpenPGP key for the given mail address. The key needs to carry a > User ID packet ([RFC4880]) with that mail address. Note that the key > may be revoked or expired - it is up to the client to handle such > conditions. To ease distribution of revoked keys, a server may > return revoked keys in addition to a new key. The keys are returned > by a single request as concatenated key blocks. > > So when i read this, i think the MUST applies to the fact that a binary > representation of the key needs to be present in the HTTPS response > body, but other material can also be included. > > I don't see any constraint like "MUST NOT return multiple non-revoked > keyblocks", This could be clarified in the next revision. Implicitely from the intentions as written down in section 3. Web Key Directory it is understandable to have one public key delivered and that is considere= d=20 the currently associated pubkey for the email address that should be taken= =20 for encryption. > and i *do* see "it is up to the client to handle such=20 > conditions=E2=80=A6" which makes me think that clients will need to under= stand > what to do if multiple non-revoked OpenPGP certificates are returned > anyway. > > What should a sensible OpenPGP client do if it encounters this case? Display that sending the email will be less secure (towards evesdropping) as something is strange (against the WKD specification). It is up to the us= er=20 to decide if the email should still be send in this case. If the contents i= s=20 highly sensitive, the user will decide to not send. Otherwise the user will= =20 not care, not paying attention to the display and send anyway (not caring i= f=20 it is encrypted or not). The email client can then do whatever it would do if it has several pubkeys for an email address in its key store. > What if two subsequent queries to the WKD endpoint (within an hour of > each other, let's say) return different certificates? what should a > client do? Use the one gotten each time, and use the information into the trust level= =20 calculation for the second time, possibly downgrading the display of the=20 envisoned security to the email in question. (Maybe reading https://wiki.gnupg.org/AutomatedEncryption is interesting at= =20 this point.) > I think it would be concretely useful in cases of a planned key > transition to be able to return multiple still-valid certificates via > WKD. The idea with the current WKD is to solve the main use case first and well. And simple to implement. Other use cases can be considered afterwards. Regards, Bernhard =2D-=20 www.intevation.de/~bernhard =C2=A0 +49 541 33 508 3-3 Intevation GmbH, Osnabr=C3=BCck, DE; Amtsgericht Osnabr=C3=BCck, HRB 18998 Gesch=C3=A4ftsf=C3=BChrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver W= agner --nextPart173901862.hOUxVbFE2x Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEELheSPXYdkVSywaF2PEP0yO/11CoFAl1JlX0ACgkQPEP0yO/1 1CoB7Af+KlPppP7z8qV5ZPQ5EPYFFpq13JKNCHHmNy7z3QqwdE3If0mEyb5pPHk+ 5olIlx1iVpsi0a753n/ULwCtCQQ2AgeGzL9HzETM+2XWAcyfhfvV2rnzYpznxVmC wKbq+FZ+B6yNA1kjb1J4RtM/lYRbAll0ST9OAX39BkHfXGkH7fPdxp+yqN7C+4Zu /4m6dDdV683yEFH07SXbfWj1tF8PvyOviGaNYAUb4bkImi/RV1w0dmW1JiQKMO+U JdvBTuG0NrO+kgXxx5BJKWCyQQxGSkrgVjBywZE4FLOGUqYEox9BdRQb60EpSnm6 jT9XHDRInFv21F9K5HJaM3VXJ4ZpFg== =K4mX -----END PGP SIGNATURE----- --nextPart173901862.hOUxVbFE2x-- From nobody Tue Aug 6 10:08:44 2019 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 38A5212049A for ; Tue, 6 Aug 2019 10:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=WrhWPzqK; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=N9EXstis 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 S7dI0NI_3kZh for ; Tue, 6 Aug 2019 10:08:41 -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 F3EA5120478 for ; Tue, 6 Aug 2019 10:08:40 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1565111320; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=cnRhOmAAM7UNVf7n8ZNyc7W0W90qCiMS7q3ycMxB/W8=; b=WrhWPzqKO0LOjE0BjpFKP5xygRJAGz7N4A44OWrvvHRwjZrAeiJSIrNF 4djfSRYdgRxs+X9a8SpwcQ9uMHvJAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1565111319; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=cnRhOmAAM7UNVf7n8ZNyc7W0W90qCiMS7q3ycMxB/W8=; b=N9EXstisYi29ZiTriy2Yg+dWEd1KyKPkd9nogWOU8Uc8u3+Bp5h1Rgz1 mIm9VoaNkZLmh/ZdObpmefUNKb9GpHiDmh9CuLhaTAnRqvYZyrV5EOwsFi zCul/NrRE/UGAXXW8QF+njHK9MDyaTeWBZp+t/V1HjF3rj2bFOSyng1nxY BeyHTDROGlNAs2NjE7PntBWhPtcn5PKMJUe/qUXWeQaeh+NhmDP/AIVK2O lHdXlvf/vNdT1qBY1QQkRsEvAv2s2cBBwoOHs4rkItbijNN+5UbbdHQIEr X/TJoASfWKQNoA341SHnYQSsT3pelBo1WDdnEZXi4R/QrrUGZs3HOQ== Received: from fifthhorseman.net (unknown [98.11.158.111]) (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 72C69F99D; Tue, 6 Aug 2019 13:08:39 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 16532203F8; Tue, 6 Aug 2019 12:25:39 -0400 (EDT) From: Daniel Kahn Gillmor To: Bernhard Reiter , gpg4win-users-en@wald.intevation.org Cc: Thomas Arendsen Hein , openpgp@ietf.org In-Reply-To: <201908061658.09774.bernhard@intevation.de> References: <87ftmnro0l.fsf@fifthhorseman.net> <20190805132446.482087064.thomas@intevation.de> <87sgqepjks.fsf@fifthhorseman.net> <201908061658.09774.bernhard@intevation.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Tue, 06 Aug 2019 12:25:38 -0400 Message-ID: <87k1bqp8fx.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key " X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 17:08:43 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue 2019-08-06 16:58:05 +0200, Bernhard Reiter wrote: > Am Dienstag 06 August 2019 14:25:07 schrieb Daniel Kahn Gillmor: >> I don't see any constraint like "MUST NOT return multiple non-revoked >> keyblocks", > > This could be clarified in the next revision. > Implicitely from the intentions as written down in section > 3. Web Key Directory > it is understandable to have one public key delivered and that is conside= red=20 > the currently associated pubkey for the email address that should be take= n=20 > for encryption. I agree that this should be clarified one way or the other. > Display that sending the email will be less secure (towards evesdropping) > as something is strange (against the WKD specification). It is up to the = user=20 > to decide if the email should still be send in this case. If the contents= is=20 > highly sensitive, the user will decide to not send. Otherwise the user wi= ll=20 > not care, not paying attention to the display and send anyway (not caring= if=20 > it is encrypted or not). I'd love to see some studies about the usability of such a warning. how many fine gradations of "valid" is the user able to distinguish between in an actionable way? fwiw, i agree that more explicit and opinionated guidance for implementers would be useful here too. I would be pretty sad if that guidance was to specify some sort of "you should be worried, but probably you can't do anything differently to address that worry" alarm. Alarm fatigue is a real and well-studied thing: https://en.wikipedia.org/wiki/Alarm_fatigue > The idea with the current WKD is to solve the main use case first and > well. And simple to implement. Other use cases can be considered afterwar= ds. Here we have a concrete use case for an important vendor of OpenPGP-related software, who has found that WKD didn't align with their standard practice until an outside party brought it to their attention. I am in complete agreement with you that we should focus on the main use case, but if it's clear that the implemnentation doesn't work for important real-world cases, we ought to be able to reconsider it (or recommend some other approach that *does* match that use case). --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXUmqAgAKCRB2GBllKa5f +JUfAP4jMfvzamO4R3lVVUluo9t9+fXVaKWwD8jr2kbuKfCFFwD/Zm34siC5nJUp xDn9JqX5FislJKZbeZ3JHFmOzRqQ8Q0= =wE4I -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 7 00:53:41 2019 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 8BF6F120288 for ; Wed, 7 Aug 2019 00:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 fDnlF_YtPyPQ for ; Wed, 7 Aug 2019 00:53:38 -0700 (PDT) Received: from kolab.intevation.de (kolab.intevation.de [212.95.107.133]) by ietfa.amsl.com (Postfix) with ESMTP id C294312024C for ; Wed, 7 Aug 2019 00:53:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 4B6E7629E1 for ; Wed, 7 Aug 2019 09:53:34 +0200 (CEST) X-Virus-Scanned: by amavisd-new at intevation.de Received: from kolab.intevation.de ([127.0.0.1]) by localhost (kolab.intevation.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kuy_iprF7r0 for ; Wed, 7 Aug 2019 09:53:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 2E30F62A07 for ; Wed, 7 Aug 2019 09:53:32 +0200 (CEST) Received: from ploto.hq.intevation.de (ploto.hq.intevation.de [192.168.11.18]) (Authenticated sender: bernhard.reiter@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 09DBC629D3; Wed, 7 Aug 2019 09:53:32 +0200 (CEST) From: Bernhard Reiter To: Daniel Kahn Gillmor Date: Wed, 7 Aug 2019 09:53:24 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20141209.518c4af) Cc: gpg4win-users-en@wald.intevation.org, Thomas Arendsen Hein , openpgp@ietf.org References: <87ftmnro0l.fsf@fifthhorseman.net> <201908061658.09774.bernhard@intevation.de> <87k1bqp8fx.fsf@fifthhorseman.net> In-Reply-To: <87k1bqp8fx.fsf@fifthhorseman.net> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7385087.78WdL7rBIZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201908070953.28760.bernhard@intevation.de> Archived-At: Subject: Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key " X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 07:53:41 -0000 --nextPart7385087.78WdL7rBIZ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Dienstag 06 August 2019 18:25:38 schrieb Daniel Kahn Gillmor: > I agree that this should be clarified one way or the other. =46rom my reading it is clear from the whole document. I agree that the phrasing can be improved at the place you were pointing ou= t. > > If the contents is highly sensitive, the user will decide to not send. > > Otherwise the user will not care, not paying attention to the display a= nd > > send anyway (not caring if it is encrypted or not). > > I'd love to see some studies about the usability of such a warning.=20 The idea is not to have a "warning", but to show the state next to reach=20 recipient and in addition combined in vicinity close to the send action=20 element. The user can pay attention to it, but is not hassled by it either. (It would be fun and very useful to have more usability studies, but this=20 seems unrealistic as we yet do not know how to get a solid funding for=20 important parts of the core infrastructure like the keyserver implementatio= n.=20 OpenPGP implementations and the software and infrastructure for a good user= =20 experience are underfunded and have been underfunded for many years.) > how many fine gradations of "valid" is the user able to distinguish betw= een > in an actionable way? Many, I believe, because: This is more close to how people model talking about diffent things in "real life". If you happen to say something sensitive who will check who= m=20 you are talking to and where. You would not say something bad about your=20 school with the teacher on the next table for example. > fwiw, i agree that more explicit and opinionated guidance for > implementers would be useful here too. I would be pretty sad if that > guidance was to specify some sort of "you should be worried, but > probably you can't do anything differently to address that worry" alarm. > Alarm fatigue is a real and well-studied thing: > > https://en.wikipedia.org/wiki/Alarm_fatigue It shall be modelled not like an alarm, but as a normal situation as there are many reasons why a trust can be reduced. The issue is, that if= =20 you are really sending something sensitive you'll double check, most of the= =20 time you won't pay much attention. > > The idea with the current WKD is to solve the main use case first and > > well. And simple to implement. Other use cases can be considered > > afterwards. > > Here we have a concrete use case for an important vendor of > OpenPGP-related software, who has found that WKD didn't align with their > standard practice until an outside party brought it to their attention. Which use case and which vendor? (So far I was not aware of a use case in this conversation. The only vendor= I=20 was aware of was Gpg4win which would be us.) Getting other active pubkeys or old pubkeys can be handled by the public=20 keyserver network. (On gnupg-devel@ I've pointed out how an improved keyserver implementation can handle necessary data privacy requirements, be de-central, transport third-party signatures, including searchable=20 non-email ones, and defend against spamming and flooding attacks. Regards, Bernhard =2D-=20 www.intevation.de/~bernhard =C2=A0 +49 541 33 508 3-3 Intevation GmbH, Osnabr=C3=BCck, DE; Amtsgericht Osnabr=C3=BCck, HRB 18998 Gesch=C3=A4ftsf=C3=BChrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver W= agner --nextPart7385087.78WdL7rBIZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEELheSPXYdkVSywaF2PEP0yO/11CoFAl1Kg3QACgkQPEP0yO/1 1Cq1vQf+OAH4QWWxp+k/nTvOyE4QZNKKxXCvTTEZgjubi+I31jAFeRgpYgjh/789 0ygGtdwU+TvwMV5FxbMb5cG0AXVHe1obSRpYiA917f0lzPHsDmDhMc5CLkKevq0N 2CpzzhRyj+6tmH7Fwmcu6COyTwwaCdSg1q3HbAZaVpwcpSJpB7ky8Zx+TssYJOsh 7XJhDSXMRe/FrjMEby9/73W3TFSw7/+AXVsojHSxj3T9xgJ+FkjvcUqKF5lSkM2E c4AHApWlbqmjUgelysY1LqzYNrH/1lMEtNX4xLGG4Bi1Lnr0VIlaIODSPaJ8TqaO XDiQI8VIt4hoG1S3b0pMg+AJiHupiQ== =dAbA -----END PGP SIGNATURE----- --nextPart7385087.78WdL7rBIZ-- From nobody Thu Aug 8 03:04:27 2019 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 CD0E61202BA for ; Thu, 8 Aug 2019 03:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 DNvKjita7XaL for ; Thu, 8 Aug 2019 03:04:11 -0700 (PDT) Received: from kolab.intevation.de (kolab.intevation.de [212.95.107.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9553612012B for ; Thu, 8 Aug 2019 03:04:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 464A2621F0 for ; Thu, 8 Aug 2019 12:04:10 +0200 (CEST) X-Virus-Scanned: by amavisd-new at intevation.de Received: from kolab.intevation.de ([127.0.0.1]) by localhost (kolab.intevation.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK2KNfxCDcE9 for ; Thu, 8 Aug 2019 12:04:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 809E9627AD for ; Thu, 8 Aug 2019 12:04:09 +0200 (CEST) Received: from ploto.hq.intevation.de (ploto.hq.intevation.de [192.168.11.18]) (Authenticated sender: bernhard.reiter@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 5F85F621F0; Thu, 8 Aug 2019 12:04:09 +0200 (CEST) From: Bernhard Reiter To: gpg4win-users-en@wald.intevation.org Date: Thu, 8 Aug 2019 12:04:08 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20141209.518c4af) Cc: Thomas Arendsen Hein , Daniel Kahn Gillmor , openpgp@ietf.org References: <20190807152824.494103316.thomas@intevation.de> In-Reply-To: <20190807152824.494103316.thomas@intevation.de> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2601583.aPrAMXyRQg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201908081204.08647.bernhard@intevation.de> Archived-At: Subject: Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key " X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 10:04:26 -0000 --nextPart2601583.aPrAMXyRQg Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Mittwoch 07 August 2019 15:49:36 schrieb Thomas Arendsen Hein: > OpenPGP keys are needed when you want to encrypt to someone > _or_ when you want to verify a signature made by someone else. > > WKD should support these two basic use cases. The short answer is: Only publishing one active pubkey does this already, when you receive or send an email. As for old email's signatures, one good solution is that you will have the= =20 pubkey already in your database with a record when you have gotten it and=20 from where. Otherwise you get in from a keyserver and check other data, like third party signature with the special case of a signatures by the new key. There are more possibilities as well. However this is a brief and simplified answer, because I think we should pu= t=20 the discussion where most of it was done which is gnupg-devel and not on a= =20 list for users. Regards, Bernhard =2D-=20 www.intevation.de/~bernhard =C2=A0 +49 541 33 508 3-3 Intevation GmbH, Osnabr=C3=BCck, DE; Amtsgericht Osnabr=C3=BCck, HRB 18998 Gesch=C3=A4ftsf=C3=BChrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver W= agner --nextPart2601583.aPrAMXyRQg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEELheSPXYdkVSywaF2PEP0yO/11CoFAl1L85gACgkQPEP0yO/1 1CpuuQf/aC6od/lo091xtsbykGTRdd92t/H7J7Ag4l5wfmf7cdNGkr9Dq0pbdBrx jb2oyD8/C88C3PTNRWJMGICL7fdVnXftFhJKYoTs6dQOQL0ZBt+GqzWyiUdwuhM3 oy8SuYc/4KwNAfacr98yS/2Q8dXLfRq3aMJzxqHGKLjHGL5+l2023DGUgZe+Bvv9 PCDFRS5xcZZcRafsPIe/q409fh6Pnw66y9lYsmvmW0vxftPk3SbrQa25qQCS6Tg7 guJwMdkO4eWZBvy15g/ztAr3wN+8FKThsD1y4SPivL9V19l1znXOmDbNx/3xmGfY mZpHOFU8IbLXfs/NsELWZXXJmfN3sQ== =3saW -----END PGP SIGNATURE----- --nextPart2601583.aPrAMXyRQg-- From nobody Thu Aug 8 06:02:28 2019 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 54AEC1200C3 for ; Thu, 8 Aug 2019 06:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=pytY7h20; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=x0cJ3SAH 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 PbOeyg5xRu3o for ; Thu, 8 Aug 2019 06:02:24 -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 E9BBD1200B6 for ; Thu, 8 Aug 2019 06:02:23 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1565269342; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=kRlPJmXgXyKIRhHRwu7gfGiZhQ2V8vrutAk+h6qkKL0=; b=pytY7h20dFw5toD0KkPX5xROvogE//TSz5t4dBk4Z2bwIOEjTJojWUyW 3Eb4J+7/cnPh5i4iZrcqiGnyKpVJBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1565269342; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=kRlPJmXgXyKIRhHRwu7gfGiZhQ2V8vrutAk+h6qkKL0=; b=x0cJ3SAHSqm1E8HPgH94CSlucopZ/htDVFLyyeSg7NkEgcS2rflvYbMs xVCuypkfHK541cu5G+oHlff40e6WABZrfXRtWRTk9X92NmB6E2wvY2qQ6K /8E+b85KR4v/SUrIwg8XBD7Fx1NSxqfZpg6xX8uJTNl7UdItdQNdgV31dJ 6Za5+Zoc5IVD9qlQPNuAHWVxVMlPbL5OWF0NXy7AWXC4pOCFBa6CB2grAj vDdyLXdf1sFCM8N1bp+DIFwBU3dlxchV67dwzcUwFkC3eVE7m9Y/2E8s4b inMamEUldaHY7kIEKJKB5F/iwiRSyIwya/+reQfJrx3V3/nK9GlRMA== Received: from fifthhorseman.net (unknown [98.11.158.111]) (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 19DFDF99E; Thu, 8 Aug 2019 09:02:21 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 40655203F8; Thu, 8 Aug 2019 08:49:03 -0400 (EDT) From: Daniel Kahn Gillmor To: Thomas Arendsen Hein , Bernhard Reiter Cc: gpg4win-users-en@wald.intevation.org, openpgp@ietf.org In-Reply-To: <20190807152824.494103316.thomas@intevation.de> References: <20190807152824.494103316.thomas@intevation.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Thu, 08 Aug 2019 08:49:02 -0400 Message-ID: <874l2rq0u9.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key " X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 13:02:26 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed 2019-08-07 15:49:36 +0200, Thomas Arendsen Hein wrote: > OpenPGP keys are needed when you want to encrypt to someone > _or_ when you want to verify a signature made by someone else. > > WKD should support these two basic use cases. > > To avoid ambiguity when selecting a key for encryption, WKD should > not provide more than one valid key. > > For verifying signatures there is no ambiguity, because the signed > file/email is signed by a single key. If the WKD could provide this > key, all would be well here, but as my older mails/files are signed > by my older key and my newer mails/files are signed by by my newer > key, the person/software checking the signature of both mails/files > today should have a verified access to both, the old and the new > key. > > A way to allow both use cases would be to allow only one key for > encryption purposes and multiple keys for validating signatures. I think this is sound reasoning, and a great solution to the problem. Thanks, Thomas! It's good to have identified the underlying rationale for the two different use cases, as well as a solution that appears to meet them both. The one outstanding use case that isn't handled by this solution is two certificates which differ by public key algorithm and are both encryption-capable. I can imagine some even more subtle gradations of WKD requirements that would satisfy that use case as well, but perhaps they're too subtle to be worth specifying. If that final use case gets left unsolved, we're still in much better shape than the status quo. Perhaps you could propose some text to modify the WKD draft? If you want to propose an easily-applicable diff, the source is in this git repository: https://dev.gnupg.org/source/gnupg-doc.git in the file misc/id/openpgp-webkey-service/draft.org=20 Perhaps Werner can weigh in on where he would like diffs to be sent so that he can most easily track them for inclusion. As someone working with different OpenPGP implementations that themselves do some variant of WKD lookup at least, i think it would be great to post a proposed diff here to the openpgp@ietf.org mailing list as well, so that other implementers can consider it and weigh in about what makes sense for them. > * Bernhard Reiter [20190807 09:53]: >> Getting other active pubkeys or old pubkeys can be handled by the public= =20 >> keyserver network. > > No, because the old pubkey wouldn't come from a trusted source this > way. I agree that WKD provides some additional benefit of authenticity here. Without that, the signer might as well just ship the certificate with the signature, and let the end user verify it that way. i don't think it's bad to ship the certificate with the signature, fwiw. That approach has very nice properties from the perspective of metadata leakage -- no leakage at all, and also no dependencies on internet connectivity or third-party services which might have outages. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXUwaPgAKCRB2GBllKa5f +LY9AP9DOAiKtn3QrcRKhaslgqHs/F87vAwcGXH161rbBF/6zgD/ceTuhVLyT6uI M/u8zKG/uNAvBz7hag9q/7ldOWPOQgY= =EGUy -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 8 06:37:15 2019 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 6D93A1200B7 for ; Thu, 8 Aug 2019 06:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=zyg8szeT; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=vrnqEcnw 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 oPce2aSmy-5w for ; Thu, 8 Aug 2019 06:37:12 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CADA8120044 for ; Thu, 8 Aug 2019 06:37:11 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1565271430; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=urinuekCSfVcq/uNQOba7ijPJqMtxLEQNNfDPihEfFk=; b=zyg8szeTapu2dY2aJgtem9YKMmxulrg8kz++b9ve+DqYVceWnVrnEqv/ ZqTZIk3z3gKuXuy2Y9tpnkYIThbwBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1565271430; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=urinuekCSfVcq/uNQOba7ijPJqMtxLEQNNfDPihEfFk=; b=vrnqEcnweFVi29L1uiwvH3AGonUZTD+yG8gVn1/JmfXHGG3Gf9BTbesQ Pd+eAzNbqnPJXyXAm3VgCpoz/HciXmYvv9sSBihrSfxHg9guxPiX8C6r1N 27bJxkpqTXuMH8WBI11ro11cR0tjlT3zwsRe83vVbPW86AhnC21CL/BsD+ puFJZNNf43usR1RgNQPMcFlfYbANGbSJOvSwLhm7cnplSy65DUVpe8VZQt azaw8RFCnuN+08c2Kx00LBiPMyJobwMCVpVCeYx3UGSp8ZiZ7VhDeVJ0L/ 7054JegGpL6WeuV3hfNmhLtqYO3FcAnERiC6WTCk7V3ezSB17mvt6A== Received: from fifthhorseman.net (unknown [98.11.158.111]) (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 1AB73F99D; Thu, 8 Aug 2019 09:37:09 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A3DE6202DE; Thu, 8 Aug 2019 09:37:06 -0400 (EDT) From: Daniel Kahn Gillmor To: Bernhard Reiter , gpg4win-users-en@wald.intevation.org Cc: Thomas Arendsen Hein , openpgp@ietf.org In-Reply-To: <201908081204.08647.bernhard@intevation.de> References: <20190807152824.494103316.thomas@intevation.de> <201908081204.08647.bernhard@intevation.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Thu, 08 Aug 2019 09:37:06 -0400 Message-ID: <87sgqbok1p.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key " X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 13:37:14 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu 2019-08-08 12:04:08 +0200, Bernhard Reiter wrote: > However this is a brief and simplified answer, because I think we should = put=20 > the discussion where most of it was done which is gnupg-devel and not on = a=20 > list for users. I think openpgp@ietf.org is the right place for this discussion because it impacts other OpenPGP implementations that might also be consuming or publishing WKD. I agree that it's reasonable to drop gpg4win-users-en from this discussion at this point. I will drop it from any further contributions from me on this thread beyond this message. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXUwlggAKCRB2GBllKa5f +KTLAQCvPEXOLGu4DmoGJeweE5BubbeEuIxugaPy6pMEedHsBwD+OucRYX4J1K4q Y6YJZA4dCK5RIQ5oLWWx6njuYKL1UQs= =I9iW -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 20 14:00:32 2019 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 5491D120180 for ; Tue, 20 Aug 2019 14:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=Rkq29AYA; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=a+RKnQZl 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 jGfPzTsPPmr6 for ; Tue, 20 Aug 2019 14:00:28 -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 2BC43120086 for ; Tue, 20 Aug 2019 14:00:28 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1566334826; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=RFmHoSAddj7CgdhMFE8zh+FjtrmCWDScZf2+59zI3cw=; b=Rkq29AYAFdI2qsdoZw/cE41+hHoHGrsS3hXJLR+tbV9duulcuUTI+iN1 JLAgXpUyFlmDcQI/Isw6yy6l6v2XAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1566334826; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=RFmHoSAddj7CgdhMFE8zh+FjtrmCWDScZf2+59zI3cw=; b=a+RKnQZlcYIWj9nG8mFZaaPjH0GehPGG5DojAj+JWwam8w6rUnbbAowq ZxkjQkyPlzBqLhwjKFHR52MMBksQKHV8rxiWIaK16iEfX0eXln+ZuIyPlF uAyOTWszkagsdvwlFi1JbjN36GMDEWbo6kK7uV2sUpLOkHPTTdEBg7ZCpD 0dQ16nAUQw2PhOPLaCSrJ7/32WkzKS/l8RxQSNeiMmj6UJ/50C9DcBfdUM lQEiKxfV6B0rGv02yPwgt+rbre/rqTMIKwMGzLabGO2TNiyPVPk1xPlBiY z22gTcUIigGtnYM+R/g4T0dGa6pROmqtKSy6og+darf8f++Pqz02kw== 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 BC920F99D for ; Tue, 20 Aug 2019 17:00:26 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CD8952035D; Tue, 20 Aug 2019 17:00:23 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Tue, 20 Aug 2019 17:00:23 -0400 Message-ID: <87d0gzeemw.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] =?utf-8?q?WKD_lookup_advanced_=E2=86=92_direct_fallbac?= =?utf-8?q?k_clarification?= X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 21:00:31 -0000 --=-=-= Content-Type: text/plain https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08#page-4 says: There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. But it's not clear what "the required sub-domain does not exist" means exactly. I can imagine several different implementations/interpretations: 0) is there no DNS record at all at openpgpkey.example.org? 1) does a DNS query for A records for openpgpkey.example.org return an assertion of non-existence? 2) does a DNS query for A or AAAA records for openpgpkey.example.org return an assertion of non-existence? 3) are all of the A or AAAA addresses returned from such a query (after following CNAMEs) unreachable on the network? 4) if one is reachable, but port 443 is closed? 5) if port 443 is closed, but the TLS handshake authentication fails? 6) if the TLS connection completes, and an HTTP request can be sent, but the response is not an HTTP response? 7) if the HTTP response does not return 200 for the specific lookup? 8) if the 200 HTTP response is not a series of OpenPGP certificates? I *think* that (2) above is the right trigger for the fallback, but i'm not sure exactly how to implement it in many HTTP client libraries that abstract away the specific failures. i'm also not exactly sure how to implement it when connecting through a SOCKS5 proxy or other situation where as a client i don't have access to the DNS queries directly. Perhaps a concrete example about how/when to fallback would be a useful contribution to the doc? I've noted this question over on https://dev.gnupg.org/T4679 too, since that appears to be the bug tracker for this document. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXVxfZwAKCRB2GBllKa5f +EdzAP9rMjnS2BiXmvJd7Drk8r9xoZ3kzRemXE5rrl5fKIpBYwD/Y2zaoNiB/JSF BNknSOyb268a3WbTUjIHyF7tJDZaRw4= =DMOd -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 21 06:00:20 2019 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 350EF12091E for ; Wed, 21 Aug 2019 06:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=+A/wATNe; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=H/U2qEBX 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 uxHKD63mGee9 for ; Wed, 21 Aug 2019 06:00:18 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6FA12092A for ; Wed, 21 Aug 2019 06:00:17 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1566392416; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=kKujOdqIpypedtKCMMk4FC14ktUYBfRgpnOewR8u0fY=; b=+A/wATNe6spbnJYVT8bzr5wbEuODZ3NuhCx3xIxrY/ZiMW+neSme5Wnq j5CRHHXO2FdrKP07hYvlZ/AvfpacCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1566392416; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=kKujOdqIpypedtKCMMk4FC14ktUYBfRgpnOewR8u0fY=; b=H/U2qEBXTCBR9eJTnVfJCoEYBHGz7WTUfxIYRSAdbKDTX4MVLCZaEQHe 7Ac4QUqj/XxVBJ3y3vBc95mYXL/4121OCzljPD3wnkWdmD8Fg0QX1Zx7yf 1IlaM1vs8e52XLPNiwasROEGsgYLO7+DER6W8rm9kKwHCcG8e4qQseK1da 9E8qLKT8jictvWewtqEd1z7Ul5aJRMYx2vPMvOzvLQ8965MuRFXDV9bHXV Dxo+sq+g44F+HIq704ByetNCJ3y6WyOGz3Gfh7MtSFpXiHQ38LHqlLBklH KXm0y5oS7lT/t0C84Phu1WZnSEBdH4KaRtEsbMOS9BWFQYBaknLYjQ== 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 8C258F99D for ; Wed, 21 Aug 2019 09:00:15 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B17D220345; Tue, 20 Aug 2019 18:13:08 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org In-Reply-To: <87d0gzeemw.fsf@fifthhorseman.net> References: <87d0gzeemw.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Tue, 20 Aug 2019 18:13:08 -0400 Message-ID: <875zmreb9n.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] =?utf-8?q?WKD_lookup_advanced_=E2=86=92_direct_fallbac?= =?utf-8?q?k_clarification?= X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 13:00:19 -0000 --=-=-= Content-Type: text/plain On Tue 2019-08-20 17:00:23 -0400, Daniel Kahn Gillmor wrote: > But it's not clear what "the required sub-domain does not exist" means > exactly. Here's why i care: if different WKD clients choose different answers to this question, then some clients will get different responses for WKD than others. I think that would be a bad outcome. You'd generally want any WKD client on the public internet to get the same answer from a WKD query. For example, if client A accepts a 404 from the "advanced" URL as "does not exist", but client B goes ahead with a query to the "direct" URL, then client B could get a response that client A knows nothing about. Which one is "right"? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXVxwdAAKCRB2GBllKa5f +PF+AQCtt9t1F0WWNEFS+oEBbLmM1F48dFB1zj55aHAauGd6AAD+IjQOSC6MvjHa LkiZZCeUBHDziJTRvpD1egE65QqyDgc= =y591 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 22 15:03:33 2019 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 3942812001E for ; Thu, 22 Aug 2019 15:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=jBbfSIyd; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=aBnQtPd0 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 q3VvftlysvCb for ; Thu, 22 Aug 2019 15:03:29 -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 2A18212007C for ; Thu, 22 Aug 2019 15:03:29 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1566511408; h=from : to : subject : references : date : message-id : mime-version : content-type : from; bh=xZ4Mk8XGrCnYFuStiZI+ELgJDoLIDadBZRNoLhdl4Y4=; b=jBbfSIydo9LNdyqEWrVUytDA/9ChkVkkLzffIMhdGRi67L/gFVQLGOmZ 7GH2Vw6GR71YpzL1n+WTP6gGYAYZAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1566511408; h=from : to : subject : references : date : message-id : mime-version : content-type : from; bh=xZ4Mk8XGrCnYFuStiZI+ELgJDoLIDadBZRNoLhdl4Y4=; b=aBnQtPd0AAJSnLIva6HAY1vX6wxWk2MVYum/Wz1TvnJW0L6Qja80vW2C c/+5PwYn6hc8/Ayktm0U+WKTu/1GGPGnWX6GLKcgnbHTSIUt1dhG+TP1Yn O6iBnNt2eN1BxWaCui9QSvrk8pXP75f2+xHY6UQSx+96eVmCWOc30p6OAO cgBkspuLytNu82gwdrmSEw3Ppqi3RNGHr3FuElOeMlSs7VsDKv62V78XxA W3FWG/eyAb0tsxH8f3JCb4i/UZ9DYY/iOl2/vTTNLeEMyyDQ49hYWYuaOk CD5aLeCTqpye4vH4hyFJpaX4mCvt9u8QxfAUQVjvr0ehrLE1xKgIVw== 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 D55FBF99E for ; Thu, 22 Aug 2019 18:03:27 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1607420316; Thu, 22 Aug 2019 17:08:45 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Thu, 22 Aug 2019 17:08:44 -0400 Message-ID: <875zmodi1v.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Archived-At: Subject: [openpgp] [internet-drafts@ietf.org] New Version Notification for draft-dkg-openpgp-abuse-resistant-keystore-04.txt X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 22:03:31 -0000 --=-=-= Content-Type: text/plain Hi all-- I've just released version -04 of the OpenPGP Abuse-Resistant Keystores draft. substantive changes bewteen -03 and -04: * change "certificate update" to "certificate refresh" for clarity * relax first-party-attested third-party certification constraints at the suggestion of Valodim * introduce "primary key sovereignty" concept explicitly * describe how to distribute and consume attestation revocations * introduce augmentation to TPK for third-party certification revocation distribution Please take a look! --dkg --=-=-= Content-Type: message/rfc822 Content-Disposition: inline From: internet-drafts@ietf.org To: "Daniel Kahn Gillmor" , "Daniel Gillmor" Subject: New Version Notification for draft-dkg-openpgp-abuse-resistant-keystore-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2019 12:39:00 -0700 MIME-Version: 1.0 Content-Type: text/plain A new version of I-D, draft-dkg-openpgp-abuse-resistant-keystore-04.txt has been successfully submitted by Daniel Kahn Gillmor and posted to the IETF repository. Name: draft-dkg-openpgp-abuse-resistant-keystore Revision: 04 Title: Abuse-Resistant OpenPGP Keystores Document date: 2019-08-22 Group: Individual Submission Pages: 58 URL: https://www.ietf.org/internet-drafts/draft-dkg-openpgp-abuse-resistant-keystore-04.txt Status: https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-keystore/ Htmlized: https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-abuse-resistant-keystore Diff: https://www.ietf.org/rfcdiff?url2=draft-dkg-openpgp-abuse-resistant-keystore-04 Abstract: OpenPGP transferable public keys are composite certificates, made up of primary keys, direct key signatures, user IDs, identity certifications ("signature packets"), subkeys, and so on. They are often assembled by merging multiple certificates that all share the same primary key, and are distributed in public keystores. Unfortunately, since many keystores permit any third-party to add a certification with any content to any OpenPGP certificate, the assembled/merged form of a certificate can become unwieldy or undistributable. Furthermore, keystores that are searched by user ID or fingerprint can be made unusable for specific searches by public submission of bogus certificates. And finally, keystores open to public submission can also face simple resource exhaustion from flooding with bogus submissions, or legal or other risks from uploads of toxic data. This draft documents techniques that an archive of OpenPGP certificates can use to mitigate the impact of these various attacks, and the implications of these concerns and mitigations for the rest of the OpenPGP ecosystem. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=-=-=-- From nobody Thu Aug 22 15:03:39 2019 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 4722B12001E for ; Thu, 22 Aug 2019 15:03:32 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=CZ/DsH8r; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=JvSsR9bh 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 6BqiveI5Ofyv for ; Thu, 22 Aug 2019 15:03:29 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D011209D8 for ; Thu, 22 Aug 2019 15:03:29 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1566511408; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=MGqhnsoKWJtQDtdo9crIt7BgaLmzztug5LrnAlsJbMU=; b=CZ/DsH8r0S7sZVg+c7KiSLRl9yqvJuHVjqCTUNjOl3ShdqGPFBqovifQ dS1eRTAorxc0fYpGfBZTNsAMSLCbCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1566511407; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=MGqhnsoKWJtQDtdo9crIt7BgaLmzztug5LrnAlsJbMU=; b=JvSsR9bhs4ooplzFlGMTu0I4wkm7a79WXVOk5fXbRJI0UrCzvcnad68z 1ujOFw95NOit3kXiCNBBQoDrKHTXMlFLDcjOoYojH+dvLGiG3YO+mPliJw Hfe4FS/uVPZ8TNOoq6Ad78bstN1cpbmwdAJEvhECRlyWRmKGms1HkzUaZq sNQXVUuDAzhflkT9SLq52ifPzInby7T1cdAnIZGBiNiKkKZt/WmWBXKwRk 2+hS1NioyZlseLW0zg0pbloZqCrjuaJS1x7vOXuAUoyedZzynNdg+INOHq TTJ7E8+wYSWq7HTWZ/9AQKuKC8BRPXciIj4dH2aQ+KFqPRTty9p4eA== 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 C5C2DF99D for ; Thu, 22 Aug 2019 18:03:27 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5C9952045A; Thu, 22 Aug 2019 18:01:24 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org In-Reply-To: <875zmodi1v.fsf@fifthhorseman.net> References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Thu, 22 Aug 2019 18:01:23 -0400 Message-ID: <8736hsdfm4.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 22:03:32 -0000 --=-=-= Content-Type: text/plain On Thu 2019-08-22 17:08:44 -0400, Daniel Kahn Gillmor wrote: > * introduce augmentation to TPK for third-party certification revocation > distribution This bit is likely to be the most-controversial part of this update, so i wanted to explain it more. Sorry that this note is so long. The "first-party sovereignty" idea is that the certificate-holder (and *only* the certificate-holder) gets to decide what gets shipped with their certificate. But that makes for trouble when the first party appears to want to distribute a third-party certification, but the keystore is aware of a revocation from the third-party. A concrete example: - Alice is a popular and well-respected certifier. - Bob meets Alice and they exchange fingerprints. Alice certifies Bob's identity, and Bob attests to Alice's 3rd-party certification, shipping it with his OpenPGP certificate. - They go their separate ways. - Later, Alice learns from a reliable source that Bob's OpenPGP secret key material has fallen into the hands of Eve, or that Bob was not who he claimed to be, or whatever. She decides to revoke her certification, and she tries to reach Bob but he is uncontactable. - Alice pushes her revocation to the keystore so that it learns of it, and it can cryptographically verify it. - How does Alice's revocation get attached to Bob's certificate for redistribution? How does a keystore client learn of Alice's revocation? My first instinct option is for the keystore to just slap the revocation onto Bob's certificate directly. This is how SKS and other non-abuse-resistant keystores have done it in the past. This has a few problems: * It violates the "first-party sovereignty" idea. Bob doesn't get to decide whether this revocation is attached to his certificate or not. * It's open to abuse. What if Alice makes an abusively large revocation signature, or a revocation signature that contains toxic data? * What if Bob then revokes his attestation over Alice's third-party certification, so that the keystore won't ship it? Then presumably the keystore won't ship the revocation as well. But then clients that already know about Alice's certification don't get the revocation. All this is unsatisfactory, so there needs to be another approach. The approach i'm proposing in this draft is that revocations of third-party certifications are shipped with the *revoker*'s certificate (Alice, in the example above), not with the targeted certificate. This has some nice properties: * "Sovereignty" still holds: Alice still controls what's attached to her certificate, because she can avoid making a revocation if she doesn't want it to be visible there. * it's abuse-resistant, because Alice has a strong incentive not to make the revocation abusively large or toxic. * A user who cares about Alice's certifications should be regularly refreshing Alice's certificate anyway. Users who don't care about Alice's certifications don't need to care about her revocations either. You can see this as the keystore performing a CRL-like distribution service for each certificate that they distribute. That is, each OpenPGP certificate is followed by a "CRL" of zero or more certification revocation signature packets, issued by that certificate's certification-capable primary key. There are two downsides to this approach: A) it violates the definition of a transferable public key in RFC4880 (clients aren't expecting these packets) B) It's not obvious to to match up these revocation certificates with the certifications they revoke (A) isn't really a problem -- we can just update the spec; legacy clients will ignore the trailing "CRL" and discard it anyway. (B) requires a bit more engineering, but not much. Clients that know about this CRL can keep an index of all third-party certifications based on the SHA256 digest of the certifications. If all revocations have one or more "Target Signature" subpackets that use SHA256, to point to the certification(s) that they revoke, then an indexed keystore can find them and revoke them without much trouble. Note that this only works if there is a well-established convention about what digest algorithm to use. I don't want to keep a SHA256 and a SHA512 and a blake2b index of all the certifications i know about. Note also that SHA256 isn't used here for strong cryptographic purposes -- it's just a hash table indexer. For bandwidth optimizations, one can imagine a keystore that provides two "refresh" interfaces for a certificate: one with the "CRL" attached, and one without it. I think that would only be useful for a certificate that issues lots and lots of revocations (not common in the OpenPGP world), and if a client only selects "with CRL" for the certificates that it "trusts" as a certifier, it would expose the user's trust model, so i'm not inclined to propose such an interface explicitly. Anyway, i'm thinking that this "CRL" extension to the Transferable Public Key might belong in RFC4880bis. I will propose it as a separate patch to that draft, but i wanted to give some motivation behind why i think it's important and useful. I welcome feedback, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXV8QtAAKCRB2GBllKa5f +JNjAQCXP2DubHIWG9+8NdNiEvZ/abVpxLGYSAquYEsVhhJPUwD+JKvAcgYjKsW5 HMYnyS+l503SGsgKvPQGz92qIXu1hgw= =YeEm -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 23 08:48:47 2019 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 5A84E120105 for ; Fri, 23 Aug 2019 08:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.ai 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 0mTmEKW8-bSr for ; Fri, 23 Aug 2019 08:48:44 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) (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 37CBB12008A for ; Fri, 23 Aug 2019 08:48:44 -0700 (PDT) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id D1276C0AB7 for ; Fri, 23 Aug 2019 15:48:42 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=7xtqGuq2NO3AIi06jwpWTFI9VU2zV5M2AqL4dmuP7JQ=; b=0ZNfQ8fg4bb6AT4rv15/ThTscajEUgGx7R4Uw6DqwC2ALLWMb2HVp6s2PZ3A67+DXhyoPtKPPFIGMZIFhUkfWlBJcXymJLHz1bMUpvi0AUtSmASyobdH9GBFWddH7UD4yji81sXDXJ2ac9c5OsfbjFqvH1yXoHR8p4DFb4LDs3qt62xyNV+bV6CSpXo7yDz9PH3k4TCOpuJSfouQ1a8g5TscMl8rgxokvMlpp5UAFzUW5h6HZ6fINSTXqtJi/cHaIRY+2cKkioa9DMJb4r8JhgDmfjaBREhc30CPbUaK2cVOXaevA/2wSj+SklHmkj3oIEIci1fHnotKBf1LzSACXg== Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS; Fri, 23 Aug 2019 15:48:42 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 0F675A017C; Fri, 23 Aug 2019 15:48:42 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 23 Aug 2019 11:48:41 -0400 To: "Daniel Kahn Gillmor" , openpgp@ietf.org From: vedaal@nym.hush.com In-Reply-To: <8736hsdfm4.fsf@fifthhorseman.net> References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20190823154842.0F675A017C@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 15:48:45 -0000 On 8/22/2019 at 6:03 PM, "Daniel Kahn Gillmor" wrote: > >On Thu 2019-08-22 17:08:44 -0400, Daniel Kahn Gillmor wrote: >> * introduce augmentation to TPK for third-party certification >revocation distribution >A concrete example: > >- Alice is a popular and well-respected certifier. > >- Bob meets Alice and they exchange fingerprints. Alice certifies >Bob's identity, and Bob attests to Alice's 3rd-party certification, >shipping it with his OpenPGP certificate. > >- They go their separate ways. > >- Later, Alice learns from a reliable source that Bob's OpenPGP >secret key material has fallen into the hands of Eve, or that Bob was >not who he claimed to be, or whatever. She decides to revoke her > certification, and she tries to reach Bob but he is >uncontactable. ===== What if the third party signature just had an 'expiration' option ? (e.g. Signature validity: 0, Forever; 1, 1 year; n, n years) This allows for 'expiration' of validation in the event of possible compromise, and if it is not compromised, then the signer can 're-sign'/'update' the certification, send it to the key owner, who can then upload it to the server. vedaal From nobody Fri Aug 23 11:04:37 2019 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 E1CA912009E for ; Fri, 23 Aug 2019 11:04:35 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 T2wNCyxVc3vI for ; Fri, 23 Aug 2019 11:04:34 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01CA12006A for ; Fri, 23 Aug 2019 11:04:33 -0700 (PDT) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 125FA1F45E for ; Fri, 23 Aug 2019 18:04:32 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id A173B3FB5; Fri, 23 Aug 2019 14:05:00 -0400 (EDT) From: Michael Richardson To: openpgp@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Fri, 23 Aug 2019 14:05:00 -0400 Message-ID: <5409.1566583500@dooku.sandelman.ca> Archived-At: Subject: [openpgp] email death certificates X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 18:04:36 -0000 --=-=-= Content-Type: text/plain I had the unfortunate duty to remove an email address from a community email list because the person had passed away. I wonder how many other lists this rather active person is on, and how many years it will be before the lists are cleaned up. When my dad passed away in the fall of 2003, it wasn't until the end of April the following year that the University cleaned up his email account. There was clearly a need to keep the account open for quite some time due to other university business that hadn't yet closed. I was thinking this morning about an SMTP responses, a 55x-type, but it rather needs to be signed. Sigh, 2019, and still not enough useful email security to do this. But still. Is there something in openpgp spec that I'm missing here? I don't think that revoking the key is the right thing. In particular, nobody may know how to find the private key to revoke it. What's wanted is a revocation of the PGP signature with a reason. Has anyone given any thought to this? I suppose it might also apply to "does not work here anymore" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl1gKswACgkQlUzhVv38 QpDTqQf/X+HTGN6P8LjpaYH7h7nN9/SZCqjMToOHZG00B6NX4zdvQbR4iykYulHM lXtxFwMCyvtH4dgys+Hnzd6waRnbKngs5LzDgrNJ8IDoRlrvM8cEWX8Qxa0MrCxu UdZNGm2ci/+eb8T2DvVY+1AfrO6uajyN/Eqf7vq8ejfCSPwPzQgQgOY9OOgYu/cG nH1AIO+e+1g6zGmCK7mITE7tz8tmQN2AT7Kl4Uy+4M9NSaeTsl1WPr6HUZ7NiPh7 tvArkr4ChhKQG771mTzITAUExksAsL4moRbeE35XaGLENpSzFUw0AKniKATEKCtt Jgum8tJYKAkLG1nn0Hv5/M24TjLgzQ== =aGzN -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 23 11:08:23 2019 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 5FCF712006A for ; Fri, 23 Aug 2019 11:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 yukUGEel-OBZ for ; Fri, 23 Aug 2019 11:08:19 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4917F120044 for ; Fri, 23 Aug 2019 11:08:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 817E7E2045; Fri, 23 Aug 2019 14:08:15 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 15008-06; Fri, 23 Aug 2019 14:08:13 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 83BA0E2044; Fri, 23 Aug 2019 14:08:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1566583693; bh=+pzzG/xpatEjBDPTMGPS/yjwa/jqrMkbG1GTEcUJkyc=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=ZS+IzN2HyVkfz+mJMf5vwWMW0csYitOzcDeGmTfU4xh50MRPknQyvECRMSv+mZepF MOquoFZEYbmAoVrD/nv8RUGHnGg3778ZFp1a5hRUcVkwTIVRje6zbE0Wn7aMawYiP4 bljupmDi1+56PaA64h+9S8ItwXAME8gatbROIgNo= Received: from 169.231.97.194 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 23 Aug 2019 14:08:13 -0400 Message-ID: <9b0c6fddc26bc1480292cd880ec48e69.squirrel@mail2.ihtfp.org> In-Reply-To: <5409.1566583500@dooku.sandelman.ca> References: <5409.1566583500@dooku.sandelman.ca> Date: Fri, 23 Aug 2019 14:08:13 -0400 From: "Derek Atkins" To: "Michael Richardson" Cc: openpgp@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] email death certificates X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 18:08:22 -0000 There is the "designated revoker" feature? Not sure offhand if there are reason-codes. -derek On Fri, August 23, 2019 2:05 pm, Michael Richardson wrote: > > I had the unfortunate duty to remove an email address from a community > email list because the person had passed away. I wonder how many other > lists this rather active person is on, and how many years it will be > before the lists are cleaned up. > > When my dad passed away in the fall of 2003, it wasn't until the end of > April > the following year that the University cleaned up his email account. > There > was clearly a need to keep the account open for quite some time due to > other university business that hadn't yet closed. > > I was thinking this morning about an SMTP responses, a 55x-type, > but it rather needs to be signed. Sigh, 2019, and still not enough > useful email security to do this. But still. > > Is there something in openpgp spec that I'm missing here? > I don't think that revoking the key is the right thing. > In particular, nobody may know how to find the private key to revoke it. > What's wanted is a revocation of the PGP signature with a reason. > > Has anyone given any thought to this? > > I suppose it might also apply to "does not work here anymore" > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Aug 23 11:25:13 2019 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 6C57C120864 for ; Fri, 23 Aug 2019 11:25:12 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 L3V732wz4f5y for ; Fri, 23 Aug 2019 11:25:10 -0700 (PDT) Received: from mail.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94E5120808 for ; Fri, 23 Aug 2019 11:25:10 -0700 (PDT) Received: from [10.51.0.10] (unknown [144.121.22.178]) by mail.jabberwocky.com (Postfix) with ESMTPSA id C0B7A207889B; Fri, 23 Aug 2019 14:25:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: David Shaw In-Reply-To: <5409.1566583500@dooku.sandelman.ca> Date: Fri, 23 Aug 2019 14:25:09 -0400 Cc: openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <19127C2D-F9AA-4201-9A72-8C0A43B5D767@jabberwocky.com> References: <5409.1566583500@dooku.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [openpgp] email death certificates X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 18:25:12 -0000 On Aug 23, 2019, at 2:05 PM, Michael Richardson = wrote: >=20 > I had the unfortunate duty to remove an email address from a community > email list because the person had passed away. I wonder how many = other > lists this rather active person is on, and how many years it will be > before the lists are cleaned up. >=20 > When my dad passed away in the fall of 2003, it wasn't until the end = of April > the following year that the University cleaned up his email account. = There > was clearly a need to keep the account open for quite some time due to > other university business that hadn't yet closed. >=20 > I was thinking this morning about an SMTP responses, a 55x-type, > but it rather needs to be signed. Sigh, 2019, and still not enough > useful email security to do this. But still. >=20 > Is there something in openpgp spec that I'm missing here? > I don't think that revoking the key is the right thing. > In particular, nobody may know how to find the private key to revoke = it. > What's wanted is a revocation of the PGP signature with a reason. >=20 > Has anyone given any thought to this? >=20 > I suppose it might also apply to "does not work here anymore" There is a "Reason for Revocation" subpacket for the revocation = signature. It contains both a machine-readable byte giving various = reasons for revocation (key superseded, compromised, or retired, user ID = no longer valid, or a general "other"), followed by a human-readable = string. I suppose a death notification would be "key retired", with additional = information (if any) given in the human-readable string. This works = with the designated revoker feature as well as the regular (self) = revocation, so even if the private key is missing (or, being dead, the = owner is unable to enter a passphrase) the key can still be revoked. David From nobody Fri Aug 23 12:16:34 2019 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 82BF2120074 for ; Fri, 23 Aug 2019 12:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 TXfw_F1gei-E for ; Fri, 23 Aug 2019 12:16:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAE5120044 for ; Fri, 23 Aug 2019 12:16:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BB296BE2C; Fri, 23 Aug 2019 20:16:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB3fFOeOJeB3; Fri, 23 Aug 2019 20:16:25 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4D20CBE24; Fri, 23 Aug 2019 20:16:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1566587785; bh=kxQ7ymX/Djh2MnaGwCQ/9bB6rDOPfFwlGeVvj4RiXfc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Zb4V/EzZ5wdY1PG8ifxpoVwaP8ulWkH2jm3Yt/dGaQT+9gw7DHb3XHlYPjzaEksI7 ajt2gX9IrocVZidqYHgt8aVJlXXSo674isyi3aLO3WVBYZ22CS0hBcHTW2MW8SAyaz V2SaRUI9pwuBsQF5Y/FUoDfvWUxg8QUHa+8tknhk= To: Michael Richardson , openpgp@ietf.org References: <5409.1566583500@dooku.sandelman.ca> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 23 Aug 2019 20:16:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <5409.1566583500@dooku.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2k8xPETIZYXHifbLDGqsTJRLVgRlZ3eEt" Archived-At: Subject: Re: [openpgp] email death certificates X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 19:16:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2k8xPETIZYXHifbLDGqsTJRLVgRlZ3eEt Content-Type: multipart/mixed; boundary="r4qRunilAigqTV7lcRzl4ia44RLMfeXEP"; protected-headers="v1" From: Stephen Farrell To: Michael Richardson , openpgp@ietf.org Message-ID: Subject: Re: [openpgp] email death certificates References: <5409.1566583500@dooku.sandelman.ca> In-Reply-To: <5409.1566583500@dooku.sandelman.ca> --r4qRunilAigqTV7lcRzl4ia44RLMfeXEP Content-Type: multipart/mixed; boundary="------------CC38FB8B68CE3CE82D6516E7" Content-Language: en-GB This is a multi-part message in MIME format. --------------CC38FB8B68CE3CE82D6516E7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, (bit off topic, but whatever... ;-) On 23/08/2019 19:05, Michael Richardson wrote: > I was thinking this morning about an SMTP responses, a 55x-type, > but it rather needs to be signed. 25+ years ago I worked on X.400 mail. The X.400 specs had a recipient deceased non-delivery notification IIRC. I had a quick look but didn't find a reference so I guess that could be either a figment of my imagination or another demonstration that the OSI people's main error was being too far ahead of the implementations I guess;-) Cheers, S. --------------CC38FB8B68CE3CE82D6516E7 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------CC38FB8B68CE3CE82D6516E7-- --r4qRunilAigqTV7lcRzl4ia44RLMfeXEP-- --2k8xPETIZYXHifbLDGqsTJRLVgRlZ3eEt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1gO4cACgkQWrL68XsX K+oJKA//WZTNCNFYrq0yjq9wRZhuwUl930/YMEpG4BZXj2y+BDtfTjRJhMV3pNjd 5UcvIjGA5PPR0j2dL+tgH8lD+ABsq0PijafHGFvgxt5nyt0H0Ky/Ner9VrRyl/D8 6sAS8nA2Af9rCy8c4GDbSLBVAa2Ueo1YRBWjpKTPe/j2uyDSfSJXcX3M9cypxkOk 7xCG0CIw/6cmC4e8QNn3EgGnDxKuGzTLtExv+wB/y53sgyCchvda5LzqZfHm8ukx Ic48RipkVkWUFlgwqaqlOJO5iV5xx7gBfiqw3J9K3qdnO5RiWKmKYUOPE+W4ktda VkmXqBXy6YJ9DJ9ylCnf4kAt8A3T46Ik/6SSa1R4T6FF43HQfmo14XX7VkYji0km iwWjy8mttYKeWd457SiDO5cVnEwFJOgmJiEoD7y7/jgXjrW/ncxq25I73GNPz+bx bgvNp7QsZ2QMPdfmF5c0zxDTlMzT5zZfYcLZXH328LV6MD75JwluA+zMUAI9oK4w gFDWpNkidXD6iyo1Ko6MJaz4XfJqIyJf2hYy6D8rvWTLIdfoMxlBvtPDLWnuMahL tJQYkGq1rgzXupyIV93UiGoDxXlF5lI8TUfn1xGs+btDzS2LHEQrqbrkiTEtl/x1 pxyb9CZvAQGxYOJLCRg/7xNKF9fUNTgk+yMmU4mrAHthJ2UUIHo= =AfhL -----END PGP SIGNATURE----- --2k8xPETIZYXHifbLDGqsTJRLVgRlZ3eEt-- From nobody Fri Aug 23 13:42:05 2019 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 9BBBA1208AE for ; Fri, 23 Aug 2019 13:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=iY5FlOCl; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=jDaP9D40 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 GXpmrqHNLpRj for ; Fri, 23 Aug 2019 13:41:54 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35526120831 for ; Fri, 23 Aug 2019 13:41:52 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1566592911; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OWSeIArulvgHRB2CPh+toj2ZR/8GB/TXO3907thRfso=; b=iY5FlOClieTXeMyYXmMIgF7nbsEDCPIPoTGIfMp2tSWo0beGlF9rOGGP LGjoMmdYzPwtX/+l91ShwNIzQqMoCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1566592910; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OWSeIArulvgHRB2CPh+toj2ZR/8GB/TXO3907thRfso=; b=jDaP9D40xPSZq1Wv/vOWs0+xO51/iQmNtLW3z8OyrEVrrpxGvKsMxZMJ RUdvAfG92T3OQ5c7C9JDLqa8t/oYukKOqZd+Jl8lf5YpAC7XoDTjLo7a9h MByhLa8rSioXOFh/8vNmNdjiDN2bwvvefEzmnOBmgq56rjJG8jEjP+QMhS gOz2Rg7Xy7hDp+U2b+ULaTICntpC4ZMvt9HZByTHhGbSzTdJBDesreMcOP /PVV5FDvPYeGtme3cwYK/RPpWkuV1u4ZrCopg+I7tHF8kogQE/SRY+G/6d y8m82tLb0p0XJL2VnOh1Vdde2G6gU9wEReAW/CNwl/fVCyDhCZpUJQ== 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 A87A7F99D; Fri, 23 Aug 2019 16:41:50 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3764320303; Fri, 23 Aug 2019 16:41:47 -0400 (EDT) From: Daniel Kahn Gillmor To: vedaal@nym.hush.com, openpgp@ietf.org In-Reply-To: <20190823154842.0F675A017C@smtp.hushmail.com> References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> <20190823154842.0F675A017C@smtp.hushmail.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 23 Aug 2019 16:41:46 -0400 Message-ID: <87v9unbomt.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 20:42:03 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri 2019-08-23 11:48:41 -0400, vedaal@nym.hush.com wrote: > What if the third party signature just had an 'expiration' option ? > > (e.g. Signature validity: 0, Forever; 1, 1 year; n, n years) This is already possible! Most third-party certifications i make have such an expiration. It works fine with most implementations afaict. however, expirations are not the same as revocations. > This allows for 'expiration' of validation in the event of possible compr= omise,=20 > and if it is not compromised, then the signer can 're-sign'/'update' the = certification,=20 > send it to the key owner, who can then upload it to the server. In the scenario i described, the "key owner" is non-responsive, but the certifier still wants to make sure her certification is visibly revoked. She can't rely on the key owner's responsiveness -- they could even be dead! Her obligations are to the people who rely on her certifications, and she needs to make the revocation visible to them promptly, regardless of how the first party behaves. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXWBPigAKCRB2GBllKa5f +LEzAP97sweM486CCKj+OZGkKdIXj4q7gz1/XsF8uMZfA98MSQD/f8yoX+0GEagH gNsYkAkByTrDVfYbFO1W34simEgZ0A0= =a0Ze -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 23 17:03:31 2019 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 557721200A1 for ; Fri, 23 Aug 2019 17:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 MX2wW4cGMVJZ for ; Fri, 23 Aug 2019 17:03:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E5612002E for ; Fri, 23 Aug 2019 17:03:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AF7AC38191 for ; Fri, 23 Aug 2019 20:02:22 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A8BBDC07 for ; Fri, 23 Aug 2019 20:03:24 -0400 (EDT) From: Michael Richardson To: openpgp@ietf.org In-Reply-To: <19127C2D-F9AA-4201-9A72-8C0A43B5D767@jabberwocky.com> References: <5409.1566583500@dooku.sandelman.ca> <19127C2D-F9AA-4201-9A72-8C0A43B5D767@jabberwocky.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] email death certificates X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 00:03:28 -0000 --=-=-= Content-Type: text/plain David Shaw wrote: >> Has anyone given any thought to this? >> >> I suppose it might also apply to "does not work here anymore" > There is a "Reason for Revocation" subpacket for the revocation > signature. It contains both a machine-readable byte giving various > reasons for revocation (key superseded, compromised, or retired, user > ID no longer valid, or a general "other"), followed by a human-readable > string. > I suppose a death notification would be "key retired", with additional > information (if any) given in the human-readable string. This works > with the designated revoker feature as well as the regular (self) > revocation, so even if the private key is missing (or, being dead, the > owner is unable to enter a passphrase) the key can still be revoked. The designated revoker is singular. There is no k-of-n (or rather K) threshold the way that signature on UIDs works. If there was N signatures binding me@example.com to key 0x12345678, then it would be nice if the self-sign on the key could set a value k, which if at least K entities revoke their signature (not just expire) with an identical reason, would signal that the key<->UID is no longer valid. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1gfswACgkQgItw+93Q 3WUDrAgArmMfPTcDjUNE9AFZc73ZbB0m/oGs76ZK8NwpQ5XUIcYSgXuOUX0A1AUJ MKXQjhuIYA66EGwXV16//yZbcNvk6Rjz+j1KthYZ4R1REtYMjGnLJ1929ygh+muZ s/9uuS0vXdK2bqQDWrSJaxZ4u1E+AcxXvw5mfwLRBppAjyLGRUtoysWpl5Xu0g0n PAsoWRrAWxAozXyVd9YIv6xUTxinVn6hagztpNKcjOD0oCNfIziXX3hsPGFVqG0I zx5sHlU3o9fSMZmdlM29B9USaotnjuMjYLG2ISIdApMLl2zqYD6F0NTMH4Qapa3N x4ChnMLkFkPMXLEzjTtf9qs/59JpjA== =b9rv -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 24 05:46:38 2019 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 E3F54120071 for ; Sat, 24 Aug 2019 05:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 57BgZ3nIMdyW for ; Sat, 24 Aug 2019 05:46:34 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 3FB70120018 for ; Sat, 24 Aug 2019 05:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1566650794; x=1598186794; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uOEm6apiyobw4Ke11kKlFTXJfFUEwsN6V2T+MPOmasY=; b=i+Rnh877DWpYqUaUTamOV9GxbPxLtrS+ng8m8a/COzxMA8+z9EGJ6p+n K1lORB0B3/kmrlCDY0FXdh5vzwx7HAuSjVdxkdOM2jn2Va/7FFlSJtfvM YP9corZZagOrr7mPbRA/I6RdX6FVlbw3ps2t8PzZ1IDa97bYniBTAOu06 HFHxQ84zA7PhXuS6xduxEJxlrb0B7Ejz2KtuPQizOcx7ATEuKC8z29pJW w6A3O9Io3nwqRodypORlrCNpoIuk5Q6JLR9D2DM0xaskgQB7elT087M/P rNsjAPUxtdAgf+2ZyuroH2J+Ahaq27J4S4LjPsCc47l2i/2nt0pJ9DHm/ A==; X-IronPort-AV: E=Sophos;i="5.64,425,1559476800"; d="scan'208";a="77926215" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Aug 2019 00:46:29 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 25 Aug 2019 00:46:29 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sun, 25 Aug 2019 00:46:29 +1200 From: Peter Gutmann To: Stephen Farrell , Michael Richardson , "openpgp@ietf.org" Thread-Topic: [openpgp] email death certificates Thread-Index: AQHVWd1D4OJOH6MvzEuRkSIE7LiC3KcIUZuAgAHuYqA= Date: Sat, 24 Aug 2019 12:46:28 +0000 Message-ID: <1566650783176.74952@cs.auckland.ac.nz> References: <5409.1566583500@dooku.sandelman.ca>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] email death certificates X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 12:46:37 -0000 Stephen Farrell writes:=0A= =0A= >25+ years ago I worked on X.400 mail. The X.400 specs had a recipient=0A= >deceased non-delivery notification IIRC=0A= =0A= This is what an RFC822 address looks like in a certificate:=0A= =0A= rfc822Name IA5String=0A= =0A= This is what an X.400 address looks like in a certificate:=0A= =0A= ITU-Braindamge ::=3D SEQUENCE {=0A= built-in-standard-attributes SEQUENCE {=0A= country-name [ APPLICATION 1 ] CHOICE {=0A= x121-dcc-code NumericString,=0A= iso-3166-alpha2-code PrintableString=0A= },=0A= administration-domain-name=0A= [ APPLICATION 2 ] CHOICE {=0A= numeric NumericString,=0A= printable PrintableString=0A= },=0A= network-address [ 0 ] NumericString OPTIONAL,=0A= terminal-identifier [ 1 ] PrintableString OPTIONAL,=0A= private-domain-name [ 2 ] CHOICE {=0A= numeric NumericString,=0A= printable PrintableString=0A= } OPTIONAL,=0A= organization-name [ 3 ] PrintableString OPTIONAL,=0A= numeric-use-identifier [ 4 ] NumericString OPTIONAL,=0A= personal-name [ 5 ] SET {=0A= surname [ 0 ] PrintableString,=0A= given-name [ 1 ] PrintableString,=0A= initials [ 2 ] PrintableString,=0A= generation-qualifier [ 3 ] PrintableString=0A= } OPTIONAL,=0A= organizational-unit-name [ 6 ] PrintableString OPTIONAL,=0A= }=0A= built-in-domain-defined-attributes SEQUENCE OF {=0A= type PrintableString SIZE(1..64),=0A= value PrintableString SIZE(1..64)=0A= } OPTIONAL=0A= extensionAttributes SET OF SEQUENCE {=0A= extension-attribute-type [ 0 ] INTEGER,=0A= extension-attribute-value [ 1 ] ANY DEFINED BY extension-attribute-type= =0A= } OPTIONAL=0A= }=0A= =0A= Given that, I would hope that X.400 not only includes a recipient deceased= =0A= non-delivery notification but also a detailed record of what the cause of= =0A= death was, a complete autopsy report, and an address to send flowers to.=0A= =0A= Peter.=0A= From nobody Sat Aug 24 20:53:12 2019 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 4D13112008F for ; Sat, 24 Aug 2019 20:53:10 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 e5F-cP4DA470 for ; Sat, 24 Aug 2019 20:53:08 -0700 (PDT) Received: from mail.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2FC1120025 for ; Sat, 24 Aug 2019 20:53:08 -0700 (PDT) Received: from [172.16.2.7] (rb-sip2-206.greenmountainaccess.net [69.54.28.206]) by mail.jabberwocky.com (Postfix) with ESMTPSA id B0475206B9E6; Sat, 24 Aug 2019 23:53:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: David Shaw In-Reply-To: <14934.1566605004@localhost> Date: Sat, 24 Aug 2019 23:53:03 -0400 Cc: openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5409.1566583500@dooku.sandelman.ca> <19127C2D-F9AA-4201-9A72-8C0A43B5D767@jabberwocky.com> <14934.1566605004@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [openpgp] email death certificates X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 03:53:10 -0000 On Aug 23, 2019, at 8:03 PM, Michael Richardson = wrote: >=20 >=20 > David Shaw wrote: >>> Has anyone given any thought to this? >>>=20 >>> I suppose it might also apply to "does not work here anymore" >=20 >> There is a "Reason for Revocation" subpacket for the revocation >> signature. It contains both a machine-readable byte giving various >> reasons for revocation (key superseded, compromised, or retired, user >> ID no longer valid, or a general "other"), followed by a = human-readable >> string. >=20 >> I suppose a death notification would be "key retired", with = additional >> information (if any) given in the human-readable string. This works >> with the designated revoker feature as well as the regular (self) >> revocation, so even if the private key is missing (or, being dead, = the >> owner is unable to enter a passphrase) the key can still be revoked. >=20 > The designated revoker is singular. >=20 > There is no k-of-n (or rather K) threshold the way that signature on = UIDs > works. If there was N signatures binding me@example.com to key = 0x12345678, > then it would be nice if the self-sign on the key could set a value k, > which if at least K entities revoke their signature (not just expire) = with > an identical reason, would signal that the key<->UID is no longer = valid. Designated revoker is not quite singular. You can have more than one = designated revoker on a given key - it is true, though, that any single = one of them can revoke the key. I'd be somewhat afraid to use a scheme where people not chosen by me = could "gang up" and cause a UID to be revoked. Or for that matter, a = single angry person could make N keys, sign the UID and then revoke that = signature with each of those N keys. Designated revoker lets me, as the key owner, pick who is allowed to = kill my key. David From nobody Sun Aug 25 01:35:39 2019 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 325BF120129 for ; Sun, 25 Aug 2019 01:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 ZwdJrR8qJNcb for ; Sun, 25 Aug 2019 01:35:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 B5C6C12012A for ; Sun, 25 Aug 2019 01:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1566722128; bh=he8WlBG5tqJRWXyJpraM4Qx9tasefC5ruap4M8kvSzc=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=HplTki7AHB5MEbxY7AuAWErnKKg5Jw82/czGN/Y2oEOxzlHwTjqzPVyJEXsTfqMdj 1vJTW695L/Z+7GMaOc4FfzXPbgJ3BGlOsh8YzPsS/m124k7U7f0CTXHd4TbHz4uTT+ 5T0tQIIOIsq1tO2Xo9WOCC4waZq4u3p3ejk8ABr0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.22] ([80.132.231.254]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mel3n-1icWOA3kOL-00al51 for ; Sun, 25 Aug 2019 10:35:28 +0200 To: openpgp@ietf.org References: <5409.1566583500@dooku.sandelman.ca> <19127C2D-F9AA-4201-9A72-8C0A43B5D767@jabberwocky.com> <14934.1566605004@localhost> From: Heiko Stamer Openpgp: preference=signencrypt Autocrypt: addr=HeikoStamer@gmx.net; prefer-encrypt=mutual; keydata= mQGiBDdYKNkRBACRdsFzaQn0HChOX38WHXlIYcNZAAxBQxa7gdmPXTUK+tgwQuwAr/XViQxn ExKwyOteRhwHZNSYdoKPlCOJ3c3FWCKAdflINr53NvN/qnnaF+3M1HaluiwVdfHD9a0+k7fd NFZMq2bTpzSCQBsPGipSK0K8ET8UPrXm54pXhqYL2wCgsuMBOv64bmg2zjg6vHSTKADGykcD /Agjoa7y7Cpifk4WEKDKu8nlrE9OFOJppjZ9bdJedrmZq5A/jHr35UOgbZItTmgBiz7bfMLq 7HD05ZQ3BplBmmiE0412f55GadCjN4vvnCdTqZ/ewzWdz/rzQGaJm9IvW6rupuFgrTx0GJhf we7cr6GQQo0nqA0LMCyhGHQASC56A/9NOroBzLM6wl9QlE9lybxd3cxI2UnrfHIu63tklFKF vL1XnjyJ4YR0sDs6/f56JbtEGUKTCI7ZAw+241Va4MrbDVmmsGJjQBcKxNbHDfkkjoJ9NBwr pUo2nMT3BWyKHCfnMqoyT+nN04b0Em1ffbhptKiLJSeY1mcPxvA1h7PrKbQiSGVpa28gU3Rh bWVyIDxoZWlrb3N0YW1lckBnbXgubmV0Poh4BBMRAgA4AhsDAh4BAheAFiEEdvcwETKdJ9uN fD+XT1hOuPsr4U8FAlzqvfMFCwkIBwIGFQoJCAsCBBYCAwEACgkQT1hOuPsr4U8jZQCfbz7N emwAJ2OdrBP9mmsySktb4IQAnRWJOYy4bH3R42nh6KCUkbDXQoNhuQMNBDdYKtkQDACuGU2S WXmjpoyGIX/UHze60OolxBdtKzhvDZHhy1Sz8NNrdkI3ozuYOMxkKZZLTw/iQigVNQfwy+5f AUw6KaH8OPnwInqyeguI6PwG0qQK2cWlSTZDlTW8B2D3Qpjt8sYnnjGEIGKGb7ZAUgODmWYd sS35otyEQT0Un/kRIqjyQcvWgNH++t+LypXUxu0eD0dlD/kx46TP9kqTYsr/8vWWhD2J98x0 ZFrFMN8QDCIhO9x3p+qPyfSiAdnuI4iN1RYsKtC2ikb+cIc5bYysnRots1anAy3Pd5Q8bFtj lzxPPRh90v/Yq5RM/3IgbsbS0zDI0ldznld+DInezLs/EROsITmmbXrhIAHC8TjcXtxWR3ht nFLnIgmQ3Rag0bQesNF4Y5bXSGcw/MxwWcm6EXwcbm7Uc64k8YxXMYyNy+XX/bi1o7r5JdH0 mKUFeXTF9WLrNpF4jBylHk1RNDbR6kp6M87vPJeg/nQh19ItQQxYJGYu9KBhBGhFtDUIAyLT nTcAAwUL/2tHe52rFeCVvZo7RZ5SQy/aclx7hnPsvb3yTXcvg5c7hweOL7Zfsh/XnE3acRO0 YAfGb0LxMFJlfpHgcPuTZEd5rPgJz68GccACBPw8Z8MgQEBE5H/UiAR/HM9AQmEN+wfjeDlv 6ZGElmnY59gYIuCGUVsqw5pwCCsLBs3xlMTyCiNwDHERRao3YTGhaNy9hsCdqNHQcXdSzdF6 OtvfMnXI67QGyiNcbjVwXwQHlGAsxo4O3FMOl138o1Oa00JMSk7td8bClMAp7Hu4zrw533TZ 2Avp+6OFjUAQ4U4hdEDGePNm2hbQinKnUCd30PboqIdZDmYq4SSeNMbWKwy3Etx/a0GX39F/ gnjmveBHSWGGB+wSKcrK3yfXNXMa4OW683m/aH1msS0L0SFwbm2w7XdALp0DCV031x1JoGAn c0mVcstbVM7KNUGnCOA9D4USKHrj/IoZVoapx0b+bWPFHtfLhcm2lSDlq7F140DlQVL1xZmA nPcpLyXMmEmnS2JCZYhGBBgRAgAGBQI3WCrZAAoJEE9YTrj7K+FPcRMAn1CGZ3ucVm9L5DRU 5v/85ZEO/NGjAKCfndUvggtpJjpTv5oo1MHwHq+PpbkErgRPbbDUEQwA29DKEVd+djjC5B7e jHwAb2EbbVbapdz0JAftKEiTvETd8WqpRRhvhDoGJn+v3ysOp6pKzyOtCFPQoN8559cgqA+e MMrarkufk7NxyFmuq7VILm4VSouUFgDNttHB63nAT/7FnRY/ccvJClL5vrVwMiioBVmXEJTw 8Nnw36tZoerE68uG8jS/cJjypmXhWoSSVQAKjC/ErQ5z/qNzJqAsem+eV/LHUd2BLK+u7r7Q 98ksKUpmEp5xVCox8HF1JwcG7QdJndVUCHHiV2fWDdIM0P8DCbagLZ+jQWMky/BvJL04ejnh t2O1YDyKaz3PzLMKk/Sbf9tIDw1iKJL3PQNNsu3cPOORmGsZQbfX940qiqdfD0+V3gmCjKBg TtFM/lJFkcMC0H1XfwQZBADudRIqqZp6AKkznpu8fmH3ut6C7Gl7ZXib5dNSPFIWfjBxrGnb STNChlYg0AEy5Lsm80oo7ef8VymQ/Vg/EoSVJT4vke5sY669W7lshZVcKVaqUt4/AQD/DO6J 9jyHVVwvopSC9E17qd/9qIHvrY+m/wdaGEdcHwwAsP7Sqj7SdBn/BmeSLJiXqZ+OwhOEbv6B A3ZJExEuIlNm+46tuyi1hxczbZ5ZWfOCpVPTSYBIuyl31OR1S6ef1iAGY8kkFF+3tkmbu+nQ 2dpyyfw20ZnKFkWG0IhZhQZwMANrQ9nuQVEXMc3c1cybuiNTDeIA0wLwlnYkzoPYRk/aXUQj kYvaexfQsfBrbn2qU6YtE/aRybgBoGkuJn6tSwfa4LeMA5S5p8aF/pDKRNm5vt0LpxcqPrSI pzPeHD0Oucwv3ZqfDCTIOENZwBEPSyNz2XEA2b+bnKjggprFLguw5USwpca6F/eeXGArs278 WBdAmncAgdcvcDmjMJuaGke48n1zbDHYlC8NHGTUUvVpiJRZt2KLgIzIEz/5d1tiGUZqhYk2 c9o+lHjbnv4E+L+ITY8yPqyfWHV2aH3tKa7qoBX+EyGCtW9X42gATcj3ZzVBgWD5w3BnbIgW T0dLvieBFn4T25Fy80Md+cwj4yvcRgJsvZgkuR0UjoWDxgvpDACOnRYzI/WqTSBAS1T3vmfU VtjRdUCiYpptR+sNmj//nCRdy3yC8az0WHemmWmhhE4GUT6KqtD0WPBFb9L54hq5qWCzbjcR zPW8BZJAhjynhIp2ljLAskd+50dvpsOE6aL9vAlPySuRg95dFwa+425783Hvp5YIY/LloLtb YXyRH2nBLfmXGSt1JL4oOfCEWgwLENAOXel8+aet8HD7LN8OgP+971lJ5DtCSVs/Vw4I8NdV DlssId0NhoNW062Br5qmgga0fKiU4oU0SGDOWNBGp9oUW+jD0OhIiNIFLrsse8isZrQK1W5q 0zi+guiyBB7ftp5uJHSF7Y0Cc7rKSSFsMj1E+PTKDtHpcK+AFTEDiTlPmCNemNxwmm6LtM54 ybQ8R96psrbahOX2LeYhYTwXasKk9bQ6WTOt9biO9R4y/Z9Yy52LwMXCyHot+V4+TTG9iMe9 ZWYEe1bCMLBEh7E7RYVDWHpYmhW49/U23YdY/AeROldZzSduXZTgz8f64diIqQQYEQIACQUC T22w1AIbAgBqCRBPWE64+yvhT18gBBkRCAAGBQJPbbDUAAoJEFsRGI1BjexXd78BAOwbvtBU QhoTkYp84JaRc0gUQGd5Bo5S3hmSO6Xji72vAQC7kOqWQl1dptX1ux4R0FmGPyER0YLqV4qt pdZH1EOrr8KmAJwKqFMc6IqmdMM8wZIQEAv0W3HJ8wCfWbh1A1AAl6NslvvCKYsj+kZYLu2I YAQoEQIAIBYhBHb3MBEynSfbjXw/l09YTrj7K+FPBQJZJr7xAh0DAAoJEE9YTrj7K+FPLrQA oKRZEWwU0+MEqEgFOCHIZDuFAh7mAKCVdunDvK+/J0blWkCXFNh6AgS8tw== Message-ID: <81b30b52-8a32-c6de-1815-1ab4c31fd458@gmx.net> Date: Sun, 25 Aug 2019 10:35:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:pKTd2deSOIc+T+/ZPPZ8wTkAMdSqzfjW97umPWNekTQzw7nT0Eg /Cq5r9pl2oYHZUv8W/jWDFPXxw0enMsoZi2g4hLCnHAzoy8sTEZrOKT1fJ0QnDMFzQk+ZDd VZ5kqe7Z0XpNQRRxyb9kQ3WgzPih2JYKQ+nbB/uI87nn0X9F8PwlRAYZn1k9YWD0ckGkUdY y42Swmy1qPbcy+F2Kzo+A== X-UI-Out-Filterresults: notjunk:1;V03:K0:VWjmKgIINlw=:gJEN9Q3Y0G6CiPy2jcuEHo KddcA5F8BaXEEY5zetzkQeGsbv/IL8lJUQREZLGqAmHIBOArm0kxP9G5r7N0mKijyz1fIU833 efDhPe8M0CXyLefgUqG8gkjFUeDyiDZOjv1Uwpa4YKQwyLtHYV1sQ/Tx4a2OG1yz0mddLEv4s hLL0JP/jvzeBt3+MdsXO8oQujKqVvyDb/eNOjuAflnfBxwYmayeBWhSeMSzrw3lwbTNMM65VF CIT4kCVL4yay78QC65NwfCW4nueppdpW8ln0zuFil/0w2eUQ8bvEEsbGAGW9BbBkHjoxrIVIy yYfciWXewpAWmF9SmQsxjosLaZMX9zi7jeriDf/BhtuNOKz+trFUrbK/CVbXSoGcp92Te5eA2 xy5wm4YLo74J925/gpf4OBYlAEgAG34lPNGFE4tIRT+/m4sFuiA94OGyxFL8mpX3U0PU1Ihpz WJ5TaFNSV+YzY6U+FQxdC07FagmvJ128kEKK2TSD02/idNHMiDcfVWPhaQ1sud6PdBEfbiVLk ABHKEFcfVLV6tVJy2wXxXAdm696SI5cyv4D50hRM+itEAyEB0SaHCirtC8zHJ2RWRKH8YIep8 Mcop5zLBrm6oj55vnZEU0BRYLKjlUDPh5pUw9mnD9EhIqGe4FWNmzxPkS1Mm9iKtUvWHJFFCR f6jlgH234Gmj8z0pux6W6pGFSTY4p1357woBvc1kfuHUxkn6JGj6OdDYiLGvqlLdZG3B9sULE I9ocMdZEvvSohIPOK9nKQVotLqhzc3lT2oqwFh1zJN/CVrt/K9F/ho4Wzycg4Q+6+cc0c68Fh cJIlr13RDUvGrpHF+WSNHmqNUOv9GVAd7BOPMvtkGwYWyvylQZZX8o/WmvqZoMlrkx7FmWqP9 HJaAL4bthAUlkcRn4wLEA8+eT3Dqu+moJB1tQVVx/7ZoutVOrXBW9hNtMtvERo1a2yHHJWv0E NcNQgygpqIx7FIHFwrtNpTnqrp9y83qezpTUW5VfV2hUZi90BCBhIlS0JdPI2RM4PIKjw0gbw rbbSmg1AgnQ/jwo/cezFCcknXZ4AR8QRZj9ErbM3D5cwHgTjt/oTSuwIruVS6f8XONe2Pw52C NcC/Fjxj06z3DHP8p+TNJAtmbwXzdbflX/wvhXjG+nUicUBpBTyCoW4/iKViU+T729bjwBW3S pmOKzItfHHWu0sqNJb2YlG2J50kmU4WoaDl0QuJ4Ze5jBqlA== Archived-At: Subject: Re: [openpgp] email death certificates X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 08:35:38 -0000 On 25 Aug, 2019, at 05:53, David Shaw wrote: > Designated revoker is not quite singular. Right. Using a threshold signature scheme you can share the trust among multiple parties: https://nongnu.org/dkgpg/ Bests, =2D- Heiko From nobody Mon Aug 26 00:19:29 2019 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 E7B69120829 for ; Mon, 26 Aug 2019 00:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 C1_D20OvwaRr for ; Mon, 26 Aug 2019 00:19:23 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 30403120830 for ; Mon, 26 Aug 2019 00:19:22 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7Q7JCsX031124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Aug 2019 03:19:16 -0400 Date: Mon, 26 Aug 2019 02:19:12 -0500 From: Benjamin Kaduk To: Daniel Kahn Gillmor Cc: openpgp@ietf.org Message-ID: <20190826071911.GE84368@kduck.mit.edu> References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8736hsdfm4.fsf@fifthhorseman.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 07:19:25 -0000 On Thu, Aug 22, 2019 at 06:01:23PM -0400, Daniel Kahn Gillmor wrote: > On Thu 2019-08-22 17:08:44 -0400, Daniel Kahn Gillmor wrote: > > * introduce augmentation to TPK for third-party certification revocation > > distribution > > This bit is likely to be the most-controversial part of this update, so > i wanted to explain it more. Sorry that this note is so long. > [...] > There are two downsides to this approach: > > A) it violates the definition of a transferable public key in RFC4880 > (clients aren't expecting these packets) > > B) It's not obvious to to match up these revocation certificates with > the certifications they revoke > > (A) isn't really a problem -- we can just update the spec; legacy > clients will ignore the trailing "CRL" and discard it anyway. > > (B) requires a bit more engineering, but not much. Clients that know > about this CRL can keep an index of all third-party certifications based > on the SHA256 digest of the certifications. If all revocations have one > or more "Target Signature" subpackets that use SHA256, to point to the > certification(s) that they revoke, then an indexed keystore can find > them and revoke them without much trouble. > > Note that this only works if there is a well-established convention > about what digest algorithm to use. I don't want to keep a SHA256 and a > SHA512 and a blake2b index of all the certifications i know about. Note > also that SHA256 isn't used here for strong cryptographic purposes -- > it's just a hash table indexer. This sounds an awful lot like (my understanding of) what PHB's UDF [1] (uniform data fingerprint) is supposed to be. Sadly, I've not had time yet to give it a proper read... -Ben [1] https://tools.ietf.org/html/draft-hallambaker-mesh-udf From nobody Mon Aug 26 11:43:25 2019 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 45D361200FF for ; Mon, 26 Aug 2019 11:43:24 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=BBQpov7s; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=gLV/jn7m 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 RKyR6qcOjTk7 for ; Mon, 26 Aug 2019 11:43:21 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519A1120C47 for ; Mon, 26 Aug 2019 11:43:21 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1566845000; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=Hj3UNKFYw2U3dMGpXMGgG0OJYQ9NgQQp7m4Rm4lBDcc=; b=BBQpov7suNZ1DC4vXCiwYYfex4jCt9Vyw3WWHnoCf/x0yYRwOqJ4oRS8 r2WRWpgL3cMVPGmkOEFjm5to+TdiAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1566845000; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=Hj3UNKFYw2U3dMGpXMGgG0OJYQ9NgQQp7m4Rm4lBDcc=; b=gLV/jn7m5Z/6/9TiwBSpQOzuqW6nHHb5/dCbmeBDmomzMzPVyS9jl7lv HB7fV0LB359Ed59RKwfAjGHYRzl8HcCAHUVv5DYOY7HQoaugK3csFgt7pt ePeuQX6BdzSHLm/sa2ay99MdUv3S0TCSYakSTJLvSI24fLOYSgYt1Bn/AF U41H+O/8SnZb3Ko3PdNkSEYoSKh5lUhv1HsLzbUi8NBJX5I5qw/loY4R2+ PweQi8o7eI42/Z4YO6krTEad0QupnoK6axhWO03rJDv/h/y6S9PJIwTtRy us+SQRwLyef8g4pyckdcMe4LYlmJIbCNsr16kXaKbXedhylFrVJJKw== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:c41:39ff:fef3:974f]) (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 F3B87F99D; Mon, 26 Aug 2019 14:43:19 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2915020299; Mon, 26 Aug 2019 14:43:16 -0400 (EDT) From: Daniel Kahn Gillmor To: Benjamin Kaduk Cc: openpgp@ietf.org In-Reply-To: <20190826071911.GE84368@kduck.mit.edu> References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> <20190826071911.GE84368@kduck.mit.edu> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Mon, 26 Aug 2019 14:43:15 -0400 Message-ID: <87blwbbwe4.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 18:43:24 -0000 --=-=-= Content-Type: text/plain On Mon 2019-08-26 02:19:12 -0500, Benjamin Kaduk wrote: > On Thu, Aug 22, 2019 at 06:01:23PM -0400, Daniel Kahn Gillmor wrote: >> Note that this only works if there is a well-established convention >> about what digest algorithm to use. I don't want to keep a SHA256 and a >> SHA512 and a blake2b index of all the certifications i know about. Note >> also that SHA256 isn't used here for strong cryptographic purposes -- >> it's just a hash table indexer. > > This sounds an awful lot like (my understanding of) what PHB's UDF [1] > (uniform data fingerprint) is supposed to be. Sadly, I've not had time > yet to give it a proper read... > > [1] https://tools.ietf.org/html/draft-hallambaker-mesh-udf I don't think that this is the same thing as i'm proposing above -- my understanding is that PHB's UDF is intended to have some level of cryptographic resilience -- to collisions at least, and maybe to pre-images in some contexts. In the scheme i've proposed above, the digest is simply used to find a certification in an index. It could conceivably be non-unique, even, since the verification is expected to be done over the full underlying certification data. (i.e. it's an index to a non-keyed hashtable) To avoid malicious attacks against the efficiency of the non-keyed hashtable (e.g. if we used CRC32, an adversary could flood the user with certifications that produce identical checksums, reducing them to linear search), we probably *do* want it to be collision-resistant, but it's not going to need the same level of cryptographic rigor that we'd need for a fingerprint, where the fingerprint itself is used to prove identity of data. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXWQoQwAKCRB2GBllKa5f +FpEAQDHbLj+CqsJKPV0xAZ8c/CSDEl5ChuCFARiMZpxJk+A7AD/Q5/aNKmlQPCq 1gz0PbgmmguX5UjOvYqj51hYkLVAOwE= =C25i -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 27 12:44:53 2019 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 BA10D120130 for ; Tue, 27 Aug 2019 12:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 gIo2gdfLMpV1 for ; Tue, 27 Aug 2019 12:44:50 -0700 (PDT) Received: from mr85p00im-zteg06021501.me.com (mr85p00im-zteg06021501.me.com [17.58.23.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40774120113 for ; Tue, 27 Aug 2019 12:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1566935089; bh=VaQauppkxo7u8xTAhy3A3dhoUJnrWyBD/pMn1EX2XJ0=; h=Content-Type:Subject:From:Date:Message-Id:To; b=xWUnDdh8AzJzJ+DX//E84/dDUeSQEjNWco4R4Snp63ZTz5I+LpWxktQjICcn5+QGy oDeqfFDTSv0ppoyDKot8fjoTcf5jqrHWjlf7znYmpw2YmMz94Xfys+IHlJGUtpFbxG JnPFCAz9kApp2J5pYdqi9CKHMQKonAaXIg4pUPltPU5SFubjOZvUO9GYCq9qL3XQ2a QRNg2R5oZW8Ml6VaWBEoGzCJSfq5lIlJG1Fa74jhpUZ3qtdLLGrKKHTvvwtBZo6QEu mhFIi33rhMCRMExEjcIRbByZnbYG1Cxtk9I/JQ/wndSKk/w0S8X0pTov0fL92P6ZoM qGpiUTbsu3ouQ== Received: from [10.125.12.108] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-zteg06021501.me.com (Postfix) with ESMTPSA id 9E180380CDE; Tue, 27 Aug 2019 19:44:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Jon Callas In-Reply-To: <5409.1566583500@dooku.sandelman.ca> Date: Tue, 27 Aug 2019 12:44:48 -0700 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1AEEDBA4-B3D8-4356-8904-E1407C7AA4EA@icloud.com> References: <5409.1566583500@dooku.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-27_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=874 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1908270187 Archived-At: Subject: Re: [openpgp] email death certificates X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:44:52 -0000 > On Aug 23, 2019, at 11:05 AM, Michael Richardson = wrote: >=20 > Has anyone given any thought to this? >=20 > I suppose it might also apply to "does not work here anymore" Yes, as others have said, designated revokers and reason-for-revocation = are part of this, as would be even human-readable notations.=20 In PGP, we had key-splitting and those one could with that product = key-split a revoker key. It was an obvious use case for us, even. Jon From nobody Tue Aug 27 13:05:41 2019 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 C76E21200FF for ; Tue, 27 Aug 2019 13:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 PvhppeEwmSD3 for ; Tue, 27 Aug 2019 13:05:36 -0700 (PDT) Received: from mr85p00im-ztdg06011801.me.com (mr85p00im-ztdg06011801.me.com [17.58.23.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C6E1200DE for ; Tue, 27 Aug 2019 13:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1566936336; bh=/cYZYw27K4wtzf9HNdwpRUDG9NnLX96dETnIsJd8esw=; h=Content-Type:Subject:From:Date:Message-Id:To; b=bpG++Yk28dGb7DczCFj2GQkgLR+r/uYo4fv8a9qwHNsiozzA7dvCykUeDpnKN533k RDM1ZSCrRthIyZ9wOT2oEBCRHXoMygCYK5UWEl6xAlRkVS/ZP7kF6VZEA7afza2Hgb Ca/UTI70xLrOtDvLNedoLBkjqKAIFSktxeLrcE1z/0Jz9AbGZTf82TA0mJ/8UyLGk8 ihJDVTPwtRxkq65r0494opJR2LS4VphjWIOP/mLmOGd3zwC1D8VPwk3f2FbEg87opz 5wi3Y0WSAmcTsF5UC7Syszg8pAloJfqnI12/TTDyoJhr4SleW7+S5rpswByaiwHjnN JovE0GAQzh1lA== Received: from [10.125.12.108] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-ztdg06011801.me.com (Postfix) with ESMTPSA id 1D416C10C5; Tue, 27 Aug 2019 20:05:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Jon Callas In-Reply-To: <8736hsdfm4.fsf@fifthhorseman.net> Date: Tue, 27 Aug 2019 13:05:35 -0700 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-27_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1908270190 Archived-At: Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 20:05:39 -0000 > On Aug 22, 2019, at 3:01 PM, Daniel Kahn Gillmor = wrote: >=20 > The "first-party sovereignty" idea is that the certificate-holder (and > *only* the certificate-holder) gets to decide what gets shipped with > their certificate. But that makes for trouble when the first party > appears to want to distribute a third-party certification, but the > keystore is aware of a revocation from the third-party. Thank you, thank you for "first-party sovereignty" even if I'd say = "ownership." This might be relevant below. In 4880, 5.2.3.17 and the no-modify flag is there intentionally to = provide an affirmation that the owner wants sovereignty. [...] >=20 > My first instinct option is for the keystore to just slap the = revocation > onto Bob's certificate directly. This is how SKS and other > non-abuse-resistant keystores have done it in the past. That's also mine. Of course there is more to it than that, there always = is. >=20 > This has a few problems: >=20 > * It violates the "first-party sovereignty" idea. Bob doesn't get to > decide whether this revocation is attached to his certificate or = not. Yes, but it's Alice's certification. I think I can argue that she has a = right to revoke her signature, that her signature does not transfer over = to Bob. If this is false, then there's a lot of reason never to sign anyone = else's key, because it's therefore irrevocable. >=20 > * It's open to abuse. What if Alice makes an abusively large > revocation signature, or a revocation signature that contains toxic > data? I think that can be taken care of. If Alice did that, I, the key server = might decide that my sovereignty overrides hers, and I'm not going to be = a party to her abusing Bob. >=20 > * What if Bob then revokes his attestation over Alice's third-party > certification, so that the keystore won't ship it? Then presumably > the keystore won't ship the revocation as well. But then clients > that already know about Alice's certification don't get the > revocation. Well, this is why "sovereignty" might be the wrong term. In my idealized way that I think a key server should work, it should = defer to the rules of the game, and one of those rules is that it's = Bob's key, and another is that it's Alice's signature.=20 A resolution that shipped neither Alice's certification nor her = revocation of same is to me an adequate compromise. >=20 > All this is unsatisfactory, so there needs to be another approach. >=20 > The approach i'm proposing in this draft is that revocations of > third-party certifications are shipped with the *revoker*'s = certificate > (Alice, in the example above), not with the targeted certificate. >=20 > This has some nice properties: >=20 > * "Sovereignty" still holds: Alice still controls what's attached to > her certificate, because she can avoid making a revocation if she > doesn't want it to be visible there. >=20 > * it's abuse-resistant, because Alice has a strong incentive not to > make the revocation abusively large or toxic. >=20 > * A user who cares about Alice's certifications should be regularly > refreshing Alice's certificate anyway. Users who don't care about > Alice's certifications don't need to care about her revocations > either. >=20 > You can see this as the keystore performing a CRL-like distribution > service for each certificate that they distribute. That is, each > OpenPGP certificate is followed by a "CRL" of zero or more = certification > revocation signature packets, issued by that certificate's > certification-capable primary key. Yeah. I just cringed and said, "Oh, dear me, you just invented CRLs and = we *know* those don't work. [...] >=20 > Anyway, i'm thinking that this "CRL" extension to the Transferable > Public Key might belong in RFC4880bis. I will propose it as a = separate > patch to that draft, but i wanted to give some motivation behind why i > think it's important and useful. >=20 > I welcome feedback, I think that it's better to keep things more or less the way we've done = them. Alice's revocation attaches to her prior certification, and they travel = together. They could both be dropped, but not only one. (Even though I = can't really imagine the case of no certification, but only a = revocation, in completeness.) If Alice isn't a good citizen and makes an abusive revocation, the = server can and should drop it. If Bob wants to just drop Alice's = certification along with her revocation, that's fine too. Jon From nobody Tue Aug 27 16:24:21 2019 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 C876212025D for ; Tue, 27 Aug 2019 16:24:19 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=KUWG/F7L; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=E9wOhSTS 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 iHKIXjMBw9wT for ; Tue, 27 Aug 2019 16:24:17 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DAA12001A for ; Tue, 27 Aug 2019 16:24:17 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1566948256; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=XKIPXhfxKSusE8erT9+9Rce4Ik/PxpKg9cIBrD90Bh0=; b=KUWG/F7LCIBCzCuhnHfpSH4PUWNQTzxtmfyg2DJoAkZ3NVyLPZNMLG6R w4ZNnLoiVZLcgKP6Sni3WvcKkqvUCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1566948256; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=XKIPXhfxKSusE8erT9+9Rce4Ik/PxpKg9cIBrD90Bh0=; b=E9wOhSTSgUnoO4N5FaEIhiBZzuPmUgt3Eman1YuKf/IoB/E0b+PZRX14 rHoqyTjOeImsQxVd50IeKck98GhoqveXscNda1I3/spojV1RKIySjsiutr VjWtKwlqMK5J20wsZU2UGv2ivJQ4/BCgHFK7TUgZV/Q4SmY7JcceTCHF+Z UtTFa4Y+ub4RGy96h+KZbTbRnrFLBeyFeDFCmnTCGDgD0XbdozY4Lt1/xW gERWjrlDZXUB3f/9F9PacnoVMlmGXHbiWaRv4dsCJAoFCjn6xL/bZpsWdM TPmxONh4jmPRLH8uIMAf98k26s2qPod1rcgnHBgLLdZXRUYvX5qaCA== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (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 683B3F99D; Tue, 27 Aug 2019 19:24:15 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3130D202A8; Tue, 27 Aug 2019 18:43:45 -0400 (EDT) From: Daniel Kahn Gillmor To: Jon Callas , openpgp@ietf.org In-Reply-To: References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Tue, 27 Aug 2019 18:43:44 -0400 Message-ID: <87zhju9qlb.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 23:24:20 -0000 --=-=-= Content-Type: text/plain On Tue 2019-08-27 13:05:35 -0700, Jon Callas wrote: > Yeah. I just cringed and said, "Oh, dear me, you just invented CRLs > and we *know* those don't work. haha, sigh -- the way that CRLs "don't work" is roughly the same way that HKP-style keyservers "don't work". In particular, most users don't check CRLs, and they don't refresh keys from keyservers. One of the reasons that they don't check CRLs is because the relevant time for the check is often a low-latency situation (e.g. TLS session establishment) and the implementation doesn't want to block. Additionally, the user might not want to leak metadata about their activity to the CRL operator. Both of these reasons are also why OpenPGP signature verifiers have a hard time collecting revocation information about the signature-issuing certificates. In either case (X.509 or PGP), though, if we're willing to accept a delay (i.e., we don't support low-latency requirements), and we can do scheduled/backgrounded onion-routed updates to our certificate stores to obscure the metadata patterns, we can mitigate some of those concerns. But an additional concern for OpenPGP certificates (which X.509 doesn't have) is that the common keyservers are vulnerable to flooding attacks, as outlined in the draft under discussion here. So while this discussion isn't aiming to fix the low-latency or metadata leakage concerns, it is trying to address the abuse concerns. Maybe we can focus on that? > I think that it's better to keep things more or less the way we've > done them. The way we've done them in OpenPGP up to now is vulnerable to abuse, as we've seen. I'm hoping we can concretely specify what we need to do to avoid leaving the door open to that abuse. > Alice's revocation attaches to her prior certification, and they > travel together. They could both be dropped, but not only one. (Even > though I can't really imagine the case of no certification, but only a > revocation, in completeness.) The case of an omitted certification but included revocation seems sensible to me. If the keystore knows that a given certification is revoked, it might very sensibly want to refrain from redistributing it. At the same time, it knows that the certification is out there, some people might have a copy of it, and those people need to know that a revocation has been issued. > If Alice isn't a good citizen and makes an abusive revocation, the > server can and should drop it. How would you define "abusive revocation" in this context? Is it a universal view of "abuse", or might different people have different perspectives? For example, if we define abuse as being simply "too large", then perhaps we can fix a byte limit on what a "redistributable" revocation looks lke. And if Bob attests to Alice's certification, he is implicitly willing to accept her (as yet unseen) revocation as well. This gets thornier if we look at arbitrary data in the revocation. For example, if Alice's certification revocation contains a Reason for Revocation subpacket with a text string that says "the King is an imbecile" (and Bob needs his certificate to be distributable in a place where it's illegal to insult the King) or it says "Joe Smith was born on 1957-03-25" (and Bob lives needs his certificate to be distributable somwhere it's illegal to distribute "personal information" without the person's consent), then that would make Bob's certificate difficult to redistribute where he needs it to be. This is where i get uncomfortable about the idea that there is some universally-applicable view of what an "abusive" revocation is, and why i think that Bob's sovereignty over his own certificate makes it really important. Perhaps we could say that the most narrowly-tailored third-party certification revocation signature is acceptable -- the only three subpackets allowed: * Issuer Fingerprint * Signature Creation Time * Reason For Revocation -- only with a code, and string MUST be empty And of course the abuse-resistant keystore would have to cryptographically verify the certification revocation signature. But does that mean that *any* revocation is freely attachable to any certificate? What if Bob doesn't ask for a distribution of Alice's certification in the first place? Is Alice allowed to slap a revocation onto Bob's certificate? This brings us to this case: > If Bob wants to just drop Alice's certification along with her > revocation, that's fine too. So let's say Mallory gets ahold of Bob's secret key, and Bob's certificate has a certification from Alice, which Mallory likes. Alice learns that Bob's secret key has been compromised, and she wants to revoke her certification of Bob. But Mallory (masquerading as Bob) indicates "actually, do not distribute Alice's certification". Then Mallory can hide Alice's revocation. I don't think that's an acceptable outcome. Furthermore, it's possible that Bob has *never* attested to (requested redistribution of) Alice's certification, though Alice's certification is known to some other party, let's say "Carol". How should Carol be confident that she will learn of Alice's revocation, if it is created and published? Something like a CRL seems to still be required. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXWWyIAAKCRB2GBllKa5f +HXMAP0agTiCWVoa7c+0wZOtuOtLpNl/FfaImQ28auZ8AY4P5wEA6RiIZBnuj8xX be7XJ8nCeMiY/BHAQqxJcAk/m2s50w0= =iHAm -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 27 17:29:30 2019 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 C5F4B120026 for ; Tue, 27 Aug 2019 17:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 xGXLq8LcPyYT for ; Tue, 27 Aug 2019 17:29:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0577D12009E for ; Tue, 27 Aug 2019 17:29:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 069AE3818C; Tue, 27 Aug 2019 20:28:16 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 274D889; Tue, 27 Aug 2019 20:29:24 -0400 (EDT) From: Michael Richardson To: Jon Callas cc: openpgp@ietf.org In-Reply-To: <1AEEDBA4-B3D8-4356-8904-E1407C7AA4EA@icloud.com> References: <5409.1566583500@dooku.sandelman.ca> <1AEEDBA4-B3D8-4356-8904-E1407C7AA4EA@icloud.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] email death certificates X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 00:29:28 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Jon Callas wrote: >> On Aug 23, 2019, at 11:05 AM, Michael Richardson wrote: >>=20 >> Has anyone given any thought to this? >>=20 >> I suppose it might also apply to "does not work here anymore" > Yes, as others have said, designated revokers and reason-for-revocati= on > are part of this, as would be even human-readable notations.=20=20 > In PGP, we had key-splitting and those one could with that product > key-split a revoker key. It was an obvious use case for us, even. The designated revoker seems to require advance planning, as does the key-splitting. People rarely do advance planing on accidential death, nor on getting fired. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1lyuMACgkQgItw+93Q 3WW1VggAt/YJfJHWhceHrZsexJhM++7bhyghReeXzB+VuynuRBpazSUYLc1SQFep e0wfVTr4Oc67ZKP7WWMlZ1w040UJUtCnbxa+jaIjYymNMzYYdGtSe6J20xbCIbqQ O+p18WNZlUN/XgyRRPG2bu4SONvi2JlK6Lhp/3V2xzg0nShL1+2ONZ3c/PzqTwAS /D3s830d7uPYj4owGmAR8iBU3i9t0FqOLPGWbC6Z6cHU8+dXbIOw3nJOp/ha8gDY rSrUQNHbqiYNBLqKMvAb8t3/2Oa7r/He+O5m5Req7OfG0rTQY23AKlmpFSTnZB0S 1nBGLHHy1+KOfW2dKWxoeagklryhbQ== =TMqK -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 27 22:31:54 2019 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 0889012081D for ; Tue, 27 Aug 2019 22:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=wonWNemK; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=kzRUgqZT 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 AZH2T8kSvhUs for ; Tue, 27 Aug 2019 22:31:49 -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 8360512083C for ; Tue, 27 Aug 2019 22:31:49 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1566970308; h=from : to : cc : subject : date : message-id : mime-version : content-type : from; bh=Of3IylW9yYMOzaAW9teWg0J2dYFCyb8wBM23+dsEins=; b=wonWNemKuX1chfvWmvsGCIzOB5AN6N/jrWz7d4T1OJy1gOOXub56Bi7j HYV3B0ty0F/K/pPjHfkVs/ElD40nCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1566970308; h=from : to : cc : subject : date : message-id : mime-version : content-type : from; bh=Of3IylW9yYMOzaAW9teWg0J2dYFCyb8wBM23+dsEins=; b=kzRUgqZTOlceo3IKrxe/GcbBooenzhFTYwGD1dvPPWaf04ydyO0WhdU7 rvN9/CtOIAJk0y9J2jBM3lpCPaDCK0j6un9x4R7tv3qg+9ejiOPXf0j7ax +JTyom+7mrY8SPq+fWjQ3PoC/tv2hDengB8co/Q6uvNa6KedTYOTGBLBvF S6dG+HxRQmPF74F5FG+1cXPYCX8gwielPZQHsdFofDp13Bri2/9uflxlBB rVGF+hDsT7lsw+NXyDXxGGtohs7CUwxvFpvvbIqtgHgt+TH4B0Szn/n+pj pU7dSDWusaiZKQO86EXTLgor3u51O9ypa9sdorYP2eatEqFO4LWMvg== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (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 B2774F99D; Wed, 28 Aug 2019 01:31:47 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8B4F6202A6; Wed, 28 Aug 2019 01:31:43 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org Cc: Heiko Stamer Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Wed, 28 Aug 2019 01:31:42 -0400 Message-ID: <87tva1am9t.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 05:31:52 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Hi OpenPGP folks-- The "No-modify" flag for Key Server Preferences has never been particularly actionable, because the keyserver has no way to tell whether the certificate-holder intends for third-party certifications to be redistributed or not. After a few discussions with other implementers offlist [0], i'm proposing a new, simple way that the certificate holder (the "first party") can attest to some number of specific third-party certifications, to indicate that they're redistributable. [0] https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore/issues/1 and several discussions on #hagrid on IRC The shorthand for this "first-party attestation of third-party certifications" is 1PA3PC. The abuse-resistant keystores draft makes clear that such an attestation is necessary to be able to distribute third-party certifications while retaining first-party sovereignty over the certificate. But that draft (up through version -04) proposes a more-complicated mechanism using third-party confirmation signatures embedded in unhashed subpackets. The new mechanism i'm proposing here is just a list of digests over third-party certifications, stored in a hashed subpacket in the self-sig. This has two major advantages over the more complex proposal: * it's simpler to specify and to implement. * the first party can pretty easily change their mind about their preferred attestations for a given User ID by issuing a new self-sig; no need for juggling/redistributing explicit revocations of the attestations from the first party, which made the abuse-resistant keystore draft much uglier. There are two downsides as i see it, neither of them particularly bad: * there is an overall space limitation in the hashed subpackets (64KiB tops, probably less given other overhead), so the keyholder can't attest to arbitrarily many third-party certifications. However, even when using SHA512 (64B per attested certification), with even tighter constraints (like autocrypt, where the whole cert must be < 10KiB), there is still room for attestation of dozens of third-party certifications. That's more than enough for reasonable use. * It encourages/requires certificate holders to issue new self-sigs when they want to change their attestations. If a certificate store that doesn't prune superseded self-sigs encounters a rapidly-changing set of attestations, this might cause a bit of bloat. But the certificate store can just start pruning to fix that problem. This new proposal (diff for RFC 4880bis attached) claims subpacket codepoint 37 for shipping these attestations. I've also put this proposal as a merge request here: https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20 1PA3PC test vector and example ------------------------------ Below is an example of this form of 1PA3PC, using ed25519. The third-party certifier: -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEXWYJVBYJKwYBBAHaRw8BAQdAFa8edTtqPPjjMVwac8Z+LCTbQLJv8zE7YI/8 TB8Wo7vNJkNlcnRpZmljYXRlIEF1dGhvcml0eSA8Y2FAZXhhbXBsZS5jb20+wm0E ExYIABUFAl1l0RQCGwECFQgCF4ACGQECHgEACgkQCzDFEKWiYTfSTgEAr5HQLoxx JLEYiEwLfixmGj5O0egfuQ8w/j+TovDvacMA/iUe9H8oyxqGKFoTn5hj0abG72mL BWGh2++7J+BpUI8A =W+bG -----END PGP PUBLIC KEY BLOCK----- The end user certificate, with the third-party certification and a self-sig that attests to it: -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEXWYJVBYJKwYBBAHaRw8BAQdA3RPxU734ifWKfZMLChBCYYCD3Pq6mV1RFyhh H4vSq77NHFRlc3QgVXNlciA8dGVzdEBleGFtcGxlLmNvbT7CXgQQFggABgUCXWXR HgAKCRALMMUQpaJhN3V/AQD8tnvWlpuXEjPDX4jxJ9COhobYS3UG8Id4i0Mhe/4c wAD8DehW+aDn7+Nv0qPJrUuyDeODHj7/MCvvEaxltrgjkQ/CjwQTFggANwUCXWXR KAIbAQIVCAIXgAIZAQIeASElZykynZ95I3ov66EDuDZE1g6By2V0gE0Z0RlkE1DT CsQACgkQ1NdAbG04n/QVxwEAgZ812nc7lqISocouns7Z7Zi7LHj8RyI9JrpmmDio fXkA+wRUUxgsQ63nyWfOJDvMl5Z57IKQOvlWJrtmSZ9ORGwG =ApYY -----END PGP PUBLIC KEY BLOCK----- I'd be happy to hear any feedback, both about the proposed patch to the spec, and about the test vector i've included here. --dkg --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Describe-Attested-Certifications-subpacket.patch Content-Transfer-Encoding: quoted-printable From=20eedb828e08d48e3749757035e4b114d7ea2b6650 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Wed, 28 Aug 2019 00:01:07 -0400 Subject: [RFC4880bis PATCH] Describe "Attested Certifications" subpacket The "no-modify" flag in the Key Server Preferences subpacket has never had a clear indication of how a keyserver can effectively respect it. This changeset describes an "Attested Certifications" subpacket that makes "no-modify" actionable by a keyserver. A keyserver that respects this flag will only redistribute third-party certifications that have been attested to by the certificate owner. Signed-off-by: Daniel Kahn Gillmor =2D-- middle.mkd | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 66 insertions(+), 3 deletions(-) diff --git a/middle.mkd b/middle.mkd index 51f71a6..222f6ca 100644 =2D-- a/middle.mkd +++ b/middle.mkd @@ -1058,6 +1058,7 @@ The value of the subpacket type octet may be: 32 Embedded Signature 33 Issuer Fingerprint 34 Preferred AEAD Algorithms + 37 Attested Certifications 100 to 110 Private or experimental =20 An implementation SHOULD ignore any subpacket of a type that it does @@ -1451,9 +1452,15 @@ This is a list of one-bit flags that indicate prefer= ences that the key holder has about how the key is handled on a key server. All undefined flags MUST be zero. =20 =2DFirst octet: 0x80 =3D No-modify the key holder requests that this key =2Donly be modified or updated by the key holder or an administrator of =2Dthe key server. +First octet: 0x80 =3D No-modify + + The key holder requests that this key only be modified or updated + by the key holder or an administrator of the key server. + + If No-modify is set on the most recent self-sig over a user ID, + then a keyserver should only redistribute those third-party + certifications over that user ID that have been attested to within + the self-sig (see "Attested Certifications" below). =20 This is found only on a self-signature. =20 @@ -1675,6 +1682,62 @@ signature, the key ID of the Issuer subpacket MUST m= atch the low Note that the length N of the fingerprint for a version 4 key is 20 octets; for a version 5 key N is 32. =20 +#### Attested Certifications + +(N octets of certification digests) + +This subpacket only appears in a self-signature as a hashed subpacket, +attesting to a set of third-party certifications over the same +underlying data that the self-signature is made. This subpacket +enables the holder of an OpenPGP primary key to mark specific +third-party certifications over their User ID as re-distributable with +the rest of the transferable public key (see the "No-modify" flag in +"Key Server Preferences", above). Implementations SHOULD include at +most one Attested Certification subpacket in any generated self-sig. + +The contents of the subpacket consists of an ordered series of digests +using the same hash algorithm used by the signature itself. Each +digest is made over one third-party signature (a Certification, of +signature type 0x10-0x13) that covers the same Primary Key and User ID +(or User Attribute). For example, a self-signature made by key X over +user ID U using hash algorithm SHA512 might contain an Attested +Certifications subpacket of 192 octets (3*64 octets) covering three +third-party certification Signatures over . They MUST be ordered +by binary hash value, so a hash with hexadecimal value +037a... precedes a hash with value 0392..., etc. The length of this +subpacket MUST be an integer multiple of the length of the hash +algorithm used for the signature. + +The listed digests MUST be calculated over the third-party +certification Signature packet as described in the "Computing +Signatures" section, but without a trailer: the hash data starts with +the octet 0x88, followed by the four-octet length of the Signature, +and then the body of the Signature packet. (Note that this is an +old-style packet header for a Signature packet with the +length-of-length field set to zero.) The unhashed subpacket data of +the Signature packet being hashed is not included in the hash, and the +unhashed subpacket data length value is set to zero. + +If an implementation encounters more than one such subpacket in a +self-sig, it MUST treat it as a self-sig with a single Attested +Certifications subpacket containing the union of all hashes. + +As with other subpackets, The Attested Certifications subpacket in the +most recent self-sig over a given user ID supersedes all Attested +Certifications subpackets from any previous self-sig. + +If a keyholder Alice has already attested to third-party +certifications from Bob and Carol and she wants to add an attestation +to a certification from David, she should issue a new self-sig (with a +more recent Signature Creation timestamp) that contains an Attested +Certifications subpacket covering all three third-party +certifications. + +If she later decides that she does not want Carol's certification to be +redistributed with her certificate, she can issue a new self-sig +(again, with a more recent Signature Creation timestamp) that contains +an Attested Certifications subpacket covering only the certifications +from Bob and David. =20 ### Computing Signatures =20 =2D-=20 2.23.0.rc1 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXWYRvgAKCRB2GBllKa5f +LYwAPsEX4YeF44BQw8pGjNZkeFvu+ZpgyENX2sT7eNVMet0IQEAovsGcCVsp8+o mV/z/klNw9VDQ+OVd6o6f3tFQVcaLAg= =r2Q+ -----END PGP SIGNATURE----- --==-=-=-- From nobody Tue Aug 27 23:28:31 2019 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 72165120855 for ; Tue, 27 Aug 2019 23:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 NQV9UarcyG9B for ; Tue, 27 Aug 2019 23:28:28 -0700 (PDT) Received: from mr85p00im-hyfv06011301.me.com (mr85p00im-hyfv06011301.me.com [17.58.23.184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012F6120817 for ; Tue, 27 Aug 2019 23:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1566973706; bh=oUDYJ68gRqQZW2TjuSytS56/QeIzCtvVdxGSJsakEJc=; h=Content-Type:Subject:From:Date:Message-Id:To; b=SyylfkFTu696muvdUNacpmZTL7xZt630s7QG3hhldViLq+RbDaScow5Fdr7Vb293m EBvzQcHdrERChN03zJtsAee0sunlN73r96OegeFumc2TePEcCbbvWxPAZciQMOvdRf ySoerQOFzQ3uCs4w1g7Oem4ywKpuYhG5zibsMUbyk0q59Xs9YYuVadPkaGGJtmcK0v S40421XEqKnisShvfOjNrpvQwsGoTymgo+PsjOSJ07n/MhasIuL6AAs0BbBi1q9zyP 85W1YEdDuV+JSVItVlaG5IrwRtcb+5wz2+5sm+1RRmGoSKQnH37l3vgdYd5dBLms75 s+dPth9gbRHyg== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-hyfv06011301.me.com (Postfix) with ESMTPSA id 8CFAC580CD8; Wed, 28 Aug 2019 06:28:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Jon Callas In-Reply-To: <21145.1566952164@localhost> Date: Tue, 27 Aug 2019 23:28:25 -0700 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5409.1566583500@dooku.sandelman.ca> <1AEEDBA4-B3D8-4356-8904-E1407C7AA4EA@icloud.com> <21145.1566952164@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-28_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=877 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1908280068 Archived-At: Subject: Re: [openpgp] email death certificates X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 06:28:30 -0000 > On Aug 27, 2019, at 5:29 PM, Michael Richardson = wrote: >=20 >=20 > Jon Callas wrote: >>> On Aug 23, 2019, at 11:05 AM, Michael Richardson = wrote: >>>=20 >>> Has anyone given any thought to this? >>>=20 >>> I suppose it might also apply to "does not work here anymore" >=20 >> Yes, as others have said, designated revokers and = reason-for-revocation >> are part of this, as would be even human-readable notations. =20 >=20 >> In PGP, we had key-splitting and those one could with that product >> key-split a revoker key. It was an obvious use case for us, even. >=20 > The designated revoker seems to require advance planning, as does the > key-splitting. People rarely do advance planing on accidential = death, nor > on getting fired. You are, of course correct.=20 The same issue applies to wills and inheritance, and I'm not sure = there's a better solution, at least not until we get time machines. Then = if you die, you can go back in time to when you were alive and set = everything up then. Or so it says in the manual. Jon From nobody Wed Aug 28 00:29:10 2019 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 922F31200A4 for ; Wed, 28 Aug 2019 00:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 67tRz0ZG5L4b for ; Wed, 28 Aug 2019 00:29:06 -0700 (PDT) Received: from mr85p00im-zteg06012001.me.com (mr85p00im-zteg06012001.me.com [17.58.23.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D13E1200C4 for ; Wed, 28 Aug 2019 00:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1566977345; bh=EkP5RB+iAPYkNlv8Q88gsXZiHz1hEbPxSypN0wiGXcg=; h=Content-Type:Subject:From:Date:Message-Id:To; b=jEkxwoT30NrZnmfEyim62m5C3hewJPgG5yavZLP3Oe7OzULwbJTFT7Hcsx9vJi0nK KNM9fXCdawm4pxhr5OV8avUgB2lqPRKLvsNmZsu3KPD0n52JefoF2Xpx03zQEXby/1 4sOGml7A1jNNmnq9l8NoJYvtA9OAOGNmvKY3/K0CHohbK9KBx39BSa4nlKLKDnNQ9g vAN/Gbmy+gCQYTcvwMpvb/hUqKDq4XyAL/v9A7iPjPjRVzo9NlAqGu5gM0AzSHDS5+ QcjJznsH1GWEBOIuT5Wq8+ufxIyU61LaiJDpHsfuc5VnEmAaUHjRS1FBikXpKefsLE 3qhPp5Yq9PgqQ== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-zteg06012001.me.com (Postfix) with ESMTPSA id 46AC9A00D07; Wed, 28 Aug 2019 07:29:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Jon Callas In-Reply-To: <87zhju9qlb.fsf@fifthhorseman.net> Date: Wed, 28 Aug 2019 00:29:04 -0700 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6057F53D-2251-4B92-997B-EF241C2F4EF3@icloud.com> References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> <87zhju9qlb.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-28_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1908280078 Archived-At: Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 07:29:10 -0000 > On Aug 27, 2019, at 3:43 PM, Daniel Kahn Gillmor = wrote: >=20 > On Tue 2019-08-27 13:05:35 -0700, Jon Callas wrote: >> Yeah. I just cringed and said, "Oh, dear me, you just invented CRLs >> and we *know* those don't work. >=20 > haha, sigh -- the way that CRLs "don't work" is roughly the same way > that HKP-style keyservers "don't work". In particular, most users = don't > check CRLs, and they don't refresh keys from keyservers. >=20 > One of the reasons that they don't check CRLs is because the relevant > time for the check is often a low-latency situation (e.g. TLS session > establishment) and the implementation doesn't want to block. > Additionally, the user might not want to leak metadata about their > activity to the CRL operator. Both of these reasons are also why > OpenPGP signature verifiers have a hard time collecting revocation > information about the signature-issuing certificates. Yup, this is pretty much what we said about CRLs back in the mid-90s. = It's possible this is required at some level, and if it is, let's just = skip ahead to an analogue of OCSP stapling (which could be done by a key = server) and Certificate Transparency, 'cause the whole ontogeny = recapitulates phylogeny thing is predictable. The underlying issue is that revocation doesn't work. The reason = revocation doesn't work comes from the first law of data-driven = programming, which is that a datum having been emitted cannot be = recalled. A revocation is kinda an anti-cert that we send out on a = mission to find the cert, and then they mutually evaporate into raw = energy. If we willing to accept that there will always be copies of the old, = unrevoked cert hanging around and things will happen because of that, = then we reduced it to a solvable subset. I believe an example of a reasonable thing to do would be to have the = key server put a certification on the certificate that includes a URI = back to it, and appropriate metadata (timestamps, TTLs, whatever else) = and then we had a protocol by which the user of the cert would look at = the key server certification and if it's in an untenable state (like the = time has expired, or whatever else you want) that the user gets a fresh = copy of that cert -- then we have a first approximation of a distributed = CRLish thing and a working protocol. I say distributed because the = information isn't in a list, it's on the cert itself.=20 Nonetheless, even here there are edge conditions where the answer when = the inevitable thing goes wrong is, "Don't do that, you'll hurt = yourself."=20 >=20 > In either case (X.509 or PGP), though, if we're willing to accept a > delay (i.e., we don't support low-latency requirements), and we can do > scheduled/backgrounded onion-routed updates to our certificate stores = to > obscure the metadata patterns, we can mitigate some of those concerns. >=20 > But an additional concern for OpenPGP certificates (which X.509 = doesn't > have) is that the common keyservers are vulnerable to flooding = attacks, > as outlined in the draft under discussion here. >=20 > So while this discussion isn't aiming to fix the low-latency or = metadata > leakage concerns, it is trying to address the abuse concerns. Maybe = we > can focus on that? Sure. The abuse problem has been around, as well, and I'm glad you're = taking up the cause. >=20 >> I think that it's better to keep things more or less the way we've >> done them. >=20 > The way we've done them in OpenPGP up to now is vulnerable to abuse, = as > we've seen. I'm hoping we can concretely specify what we need to do = to > avoid leaving the door open to that abuse. I said more or less, not exactly. Look, I agree it's a problem worth = solving. I'm the one who calls all those key servers "The La Brea Tar = Pits" and I don't mean it as a compliment. >=20 >> Alice's revocation attaches to her prior certification, and they >> travel together. They could both be dropped, but not only one. (Even >> though I can't really imagine the case of no certification, but only = a >> revocation, in completeness.) >=20 > The case of an omitted certification but included revocation seems > sensible to me. If the keystore knows that a given certification is > revoked, it might very sensibly want to refrain from redistributing = it. >=20 > At the same time, it knows that the certification is out there, some > people might have a copy of it, and those people need to know that a > revocation has been issued. Yeah. An issue with OpenPGP certificates is that they are ultimately a = list of statements, and those statements can be rewritten with impunity. = Overall, I think it's far more of a feature than a bug, because an = alternative would make it so no one would be able to do anything without = the key owner's permission, and that would disrupt things like key = signings. >=20 >> If Alice isn't a good citizen and makes an abusive revocation, the >> server can and should drop it. >=20 > How would you define "abusive revocation" in this context? Is it a > universal view of "abuse", or might different people have different > perspectives? I define it the way it's defined. An abusive revocation is something = we'll learn over time, and it's something that the key server decides.=20= >=20 > For example, if we define abuse as being simply "too large", then > perhaps we can fix a byte limit on what a "redistributable" revocation > looks lke. And if Bob attests to Alice's certification, he is > implicitly willing to accept her (as yet unseen) revocation as well. Why not both? Why not all? Right now, we're dealing with abuse in the form of "too large." In the = paragraphs below, you have other things that could also be abuse worth = solving.=20 >=20 > This gets thornier if we look at arbitrary data in the revocation. = For > example, if Alice's certification revocation contains a Reason for > Revocation subpacket with a text string that says "the King is an > imbecile" (and Bob needs his certificate to be distributable in a = place > where it's illegal to insult the King) or it says "Joe Smith was born = on > 1957-03-25" (and Bob lives needs his certificate to be distributable > somwhere it's illegal to distribute "personal information" without the > person's consent), then that would make Bob's certificate difficult to > redistribute where he needs it to be. This is where i get = uncomfortable > about the idea that there is some universally-applicable view of what = an > "abusive" revocation is, and why i think that Bob's sovereignty over = his > own certificate makes it really important. This is why I declined to define it. It doesn't matter what it is at = this point and we *will* be faced with abuse that is so clever we didn't = think of it ahead of time. Update the server and roll. >=20 > Perhaps we could say that the most narrowly-tailored third-party > certification revocation signature is acceptable -- the only three > subpackets allowed: >=20 > * Issuer Fingerprint > * Signature Creation Time > * Reason For Revocation -- only with a code, and string MUST be empty >=20 > And of course the abuse-resistant keystore would have to > cryptographically verify the certification revocation signature. That works. I don't think it has to be that narrow, but that would work. >=20 > But does that mean that *any* revocation is freely attachable to any > certificate? What if Bob doesn't ask for a distribution of Alice's > certification in the first place? Is Alice allowed to slap a = revocation > onto Bob's certificate? Yes. Alice is revoking *her* certification of Bob's key. Bob owns Bob's = key, but Alice owns her certification of Bob's key. Bob can freely = discard the certification or the certification+revocation, but he should = not be allowed to keep Alice's certification without its matching = revocation. Part of my prologue of revocation not working is that Bob can always go = do key surgery. To some extent, anyone can do key surgery. Bob can go in = with a hex editor and pull off Alice's revocation, but general tools = shouldn't allow it. Moreover, a key server shouldn't allow it. If Bob = uploads a new copy of his key without Alice's mention at all, that's = fine. The key server MUST not allow the revocation to be vanished alone. We have not seen the abuse problem of certificates being nonsensical, = but that could really happen. I am sure that if you did something like = take the first part of Bob's key, threw in one of Aice's user ids along = with all its certifications, and some subways and other things from = Charlie's key, that some implementation's going to barf in amusing ways = -- or worse, just accept it. >=20 > This brings us to this case: >=20 >> If Bob wants to just drop Alice's certification along with her >> revocation, that's fine too. >=20 > So let's say Mallory gets ahold of Bob's secret key, and Bob's > certificate has a certification from Alice, which Mallory likes. = Alice > learns that Bob's secret key has been compromised, and she wants to > revoke her certification of Bob. But Mallory (masquerading as Bob) > indicates "actually, do not distribute Alice's certification". Then > Mallory can hide Alice's revocation. I don't think that's an = acceptable > outcome. Any problem that starts with "Mallory gets ahold of Bob's secret key" = and then goes on, is kinda like discussing an operating system exploit = that starts with, "okay, the attacker is in kernel mode." In general, = the attacker can have much more fun than whatever's described. Yes, yes, = if Malloy has Bob's secret key, Mallory can do anything. However, this is part of why we have designated revokers. The whole = problem if an adversary having a copy of the key has to be solved with = something irrevocable pointing to a third party. (This is preparing for = death, too, and sadly it has to be done in advance.) If you have a = designated revoker listed on the key server, then that entity can revoke = even if the key is compromised. There isn't a way to solve this if the = only actor is that one key. The biggest fly in the ointment, though is that not only can Mallory = masquerade as Bob, but Mallory can also make a "new" key (add in new = user ids, delete the old ones) that points somewhere else but has the = same key as Bob's. Mallory has the private key and so can do *anything* = not just masquerade. >=20 > Furthermore, it's possible that Bob has *never* attested to (requested > redistribution of) Alice's certification, though Alice's certification > is known to some other party, let's say "Carol". How should Carol be > confident that she will learn of Alice's revocation, if it is created > and published? See first paragraph. This is part of why I say revocation does not and = cannot work. A subset can. Perhaps a key server ought to be a designated revoker itself in some but = not all cases. Perhaps even the default one. Of course, I'm handwaving = away things like accounts on that server, authentication, takeover = policies, and lots of other things that will be fun for someone else. The PGP key server used expiry time for this rather than a special = signature. It just went and resigned things regularly. >=20 > Something like a CRL seems to still be required. Or a signature on the key that's made by the key server itself that has = a timeout and a lot of policy coded in it. Jon From nobody Wed Aug 28 00:55:14 2019 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 EAE25120124 for ; Wed, 28 Aug 2019 00:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 Vlkc9XyDwmyc for ; Wed, 28 Aug 2019 00:55:10 -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 9FFC01200A4 for ; Wed, 28 Aug 2019 00:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=iJae0fFCq379T/N+71d7VTyxqBX4dCz6EB/k01UGTy0=; b=e+Xq5UwtwFxbytIGP5YpwceDIa adfiU/dk6/+u+OaDzhJ3CD7WH7VmLbQUouvPVOiA2s8F0NGbYUDMt9MnBgGRpHlpcd1Kjvqti5SHu okHRnU7/F/Bz+and/qVDO2jDU9ex13YdgPBkm6Dj0vK4TnqrQTYhle2H+hhphXmhLKSA=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1i2snN-000075-1h for ; Wed, 28 Aug 2019 09:55:09 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1i2slw-00055M-8t; Wed, 28 Aug 2019 09:53:40 +0200 From: Werner Koch To: Daniel Kahn Gillmor Cc: openpgp@ietf.org, Heiko Stamer References: <87tva1am9t.fsf@fifthhorseman.net> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Daniel Kahn Gillmor , openpgp@ietf.org, Heiko Stamer Date: Wed, 28 Aug 2019 09:53:39 +0200 In-Reply-To: <87tva1am9t.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 28 Aug 2019 01:31:42 -0400") Message-ID: <87blw94tfg.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=SGI_Emergency_e-bomb_S/Key_Recce_SAR_chameleon_man_dedicated_denial_"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 07:55:13 -0000 --=SGI_Emergency_e-bomb_S/Key_Recce_SAR_chameleon_man_dedicated_denial_ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, your idea is similar to what I had in mind and recently talked about with Kristian. I have some remarks so: Putting this into a standard-self signature is troublesome because this requires to update and distribute the self-signature as soon as one uploads to a keyserver. We need to have a way do include more key signatures. This can easily be done with several of such self-signatures using the same creation date or another mechanism to connect them. An upper limit on the number of such self-signatures may be suggested in the implementation nits. The requirement to sort the hashes is not really helpful because that requires that the implementation must check the order and decide what to do if they are not sorted. In practice the implementation will sort them anyway (in particular if several self-signatures are required). It should also be up to the implementation on how to match them. To accomplish this a new signature-class can be used just for this purpose. The subpacket definition should include a version number or digest algorithm to be future prove. We should of course use SHA-256 and not SHA-512. | #### Attested Certifications |=20 | (1 octet with version number, | N octets of certification digests) |=20 | The version octet MUST be 1 and the certification digests consists of | an array of 32 octets of a SHA-256 digest, each. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=SGI_Emergency_e-bomb_S/Key_Recce_SAR_chameleon_man_dedicated_denial_ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXWYzBAAKCRD/gK6dHew1 jXfBAP96y3inaYh7Rm+mzyjgsxeBTeUWA29Az4VGkHWRYUyWmQD/cC/lELoaFQuO iV9cT2TTOo9nfOcE2p9eiNegEK9g7g8= =DCye -----END PGP SIGNATURE----- --=SGI_Emergency_e-bomb_S/Key_Recce_SAR_chameleon_man_dedicated_denial_-- From nobody Wed Aug 28 09:28:44 2019 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 9B91312088D for ; Wed, 28 Aug 2019 09:28:41 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 xXXVjgvLDFX4 for ; Wed, 28 Aug 2019 09:28:40 -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 CE53D120836 for ; Wed, 28 Aug 2019 09:28:39 -0700 (PDT) Received: from localhost (p2E5DC69E.dip0.t-ipconnect.de [46.93.198.158]) by mail.mugenguild.com (Postfix) with ESMTPSA id 67DEC5FB71; Wed, 28 Aug 2019 18:28:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1567009717; bh=97Niy7HmkslThUDKuXm1LENxqV79r4A3H264Udw/xq4=; h=Date:From:To:Subject:Autocrypt:From; b=UbRGZeHdnIDp6laEJqftH+XT9iTP72cErFwu3R53ZANvbBMnkRzdxyTkBsp8W5XsS pUKVm4B2z1e7VHWfQ7LY1i8VdJyj0NRPL/nNfOg0uk9FFsVllfBd4KoRMSBeJVyO1h vpHERpCaG1D3qVAu7KOgh5w35UVTmbfJPlTV4Atw= Message-Id: <1ZTOJUW5WAINU.3HYIYUHGVZ588@my.amazin.horse> In-Reply-To: <87blw94tfg.fsf@wheatstone.g10code.de> References: <87blw94tfg.fsf@wheatstone.g10code.de> <87tva1am9t.fsf@fifthhorseman.net> Date: Wed, 28 Aug 2019 18:28:29 +0200 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: Werner Koch Cc: Daniel Kahn Gillmor , Heiko Stamer , openpgp@ietf.org 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= Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no- X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 16:28:43 -0000 > Putting this into a standard-self signature is troublesome because this > requires to update and distribute the self-signature as soon as one > uploads to a keyserver. I also have reservations about how this interacts with certification self-sigs, simply because there are already a lot of implicit expectations and behaviors around these. > We need to have a way do include more key signatures. This can easily be done > with several of such self-signatures using the same creation date or another > mechanism to connect them. Sounds good. > The requirement to sort the hashes is not really helpful because that > requires that the implementation must check the order and decide what to > do if they are not sorted. In practice the implementation will sort them > anyway (in particular if several self-signatures are required). Agreed. > To accomplish this a new signature-class can be used just for this > purpose. The subpacket definition should include a version number or > digest algorithm to be future prove. Sounds good. > We should of course use SHA-256 and not SHA-512. Yup. - V From nobody Wed Aug 28 09:59:11 2019 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 EFA681200B2 for ; Wed, 28 Aug 2019 09:59:09 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 K7SU6UI8nKLC for ; Wed, 28 Aug 2019 09:59:08 -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 141AD120232 for ; Wed, 28 Aug 2019 09:59:05 -0700 (PDT) Received: from localhost (p2E5DC69E.dip0.t-ipconnect.de [46.93.198.158]) by mail.mugenguild.com (Postfix) with ESMTPSA id 49CAD5FB71; Wed, 28 Aug 2019 18:59:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1567011543; bh=0EbbmJfRbnxad9D60c5EsevksPRrukUm/uGJMSil6YI=; h=Date:From:To:Subject:Autocrypt:From; b=J5ud/CJmHfOkspXvW3d9DvRBxcg5NWwzTNvxCROoRLmC79Z985nMGRUwF1FwC7BTe u3GCm8VHG9xYQ2HgsWC6weGXJsGgsakydJ/64WI1pV0jQZ72F7Ex1slLt5+UbIdMhG zxg3awdL8HDgfPdMzMaU/rzUcgJEHi8UKfU6uQ6k= Message-Id: <2OU83SV4JQGEF.3PZQ4MUSGX4JI@my.amazin.horse> In-Reply-To: <1ZTOJUW5WAINU.3HYIYUHGVZ588@my.amazin.horse> References: <1ZTOJUW5WAINU.3HYIYUHGVZ588@my.amazin.horse> <87blw94tfg.fsf@wheatstone.g10code.de> <87tva1am9t.fsf@fifthhorseman.net> Date: Wed, 28 Aug 2019 18:59:02 +0200 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: Vincent Breitmoser Cc: Werner Koch , Daniel Kahn Gillmor , Heiko Stamer , openpgp@ietf.org 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= Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no- X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 16:59:10 -0000 Ah, I'll revise one bit: > The subpacket definition should include a version number or digest algorithm > to be future prove. If there are new and different semantics in a subpacket, I see no benefit to artificially conflating them with the old. If we ever really need that, we might as well introduce a new subpacket type, it's not like we're running out of namespace. This is also not common practice in other subpackets types. - V From nobody Wed Aug 28 16:30:19 2019 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 1308B120130 for ; Wed, 28 Aug 2019 16:30:18 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=SSVzKOUj; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=0otdpTSx 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 10qf9zbjrWsD for ; Wed, 28 Aug 2019 16:30:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC551201AA for ; Wed, 28 Aug 2019 16:30:15 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1567035014; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=us02xfeVWkgF7+c+UxYTPaT/YG5Tq0/AKEtV3WGf81o=; b=SSVzKOUjwnMuur4WahX/n2oClY85mMy3E5auTIfJA8DA+kGdzv+WkwKS MH2rwff4BOgJLHe7KSm5alAI4GNHCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1567035014; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=us02xfeVWkgF7+c+UxYTPaT/YG5Tq0/AKEtV3WGf81o=; b=0otdpTSxhCm+TXqkFxWNq0DyCYUHylA+VqMPSG0MbW8c8r4S+zS474XD WdioAfqEtNMNq8QpXWhBHwrZrYaQ2rcRs7jTUjc2/v3e1uax5w18Gkhi1d WQsxeFxaXEzk8pZ+FYu3F047dpXesWAgESMBheKMRJ/UFKG2OKcv8QjCjI A6wWFTRIIF/bRS3BJljP+zV5oXnJ49Qf3T+jz58Vk2jCbjZb4e3nQ/Qsax xOdJaWKR5FNTxFZDFqh1FfnjVqJMjJhPqUgpXH0M6Phj+ZmpxvvvXpOgzP XarR6Z0ZhR0dleVO4bcUZB6rwCBDR8PpF9jPokNSlUTqklbGBMh0Pw== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (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 98343F99D; Wed, 28 Aug 2019 19:30:13 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 47D2F2024E; Wed, 28 Aug 2019 18:22:45 -0400 (EDT) From: Daniel Kahn Gillmor To: Jon Callas , openpgp@ietf.org In-Reply-To: <6057F53D-2251-4B92-997B-EF241C2F4EF3@icloud.com> References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> <87zhju9qlb.fsf@fifthhorseman.net> <6057F53D-2251-4B92-997B-EF241C2F4EF3@icloud.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Wed, 28 Aug 2019 18:22:44 -0400 Message-ID: <87imqh9bgr.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 23:30:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jon-- Thanks for the feedback! I'm trying to distill it to concrete guidance we can use to make OpenPGP certificate redistribution more robust=E2=80=A6 On Wed 2019-08-28 00:29:04 -0700, Jon Callas wrote: > Yeah. An issue with OpenPGP certificates is that they are ultimately a > list of statements, and those statements can be rewritten with > impunity. Overall, I think it's far more of a feature than a bug, > because an alternative would make it so no one would be able to do > anything without the key owner's permission, and that would disrupt > things like key signings. I agree that we want people to be able to compose OpenPGP certificates. It is definitely a feature of the format, but it's a tricky one, and one that keystores have had difficulty in managing without opening themselves to abuse. > I define it the way it's defined. An abusive revocation is something > we'll learn over time, and it's something that the key server decides. This isn't sufficient, unfortunately, because what's abusive for one keyserver might not be abusive for some of its clients, and vice versa :( >> Perhaps we could say that the most narrowly-tailored third-party >> certification revocation signature is acceptable -- the only three >> subpackets allowed: >>=20 >> * Issuer Fingerprint >> * Signature Creation Time >> * Reason For Revocation -- only with a code, and string MUST be empty >>=20 >> And of course the abuse-resistant keystore would have to >> cryptographically verify the certification revocation signature. > > That works. I don't think it has to be that narrow, but that would work. So this sounds like useful concrete guidance that we can offer in the abuse-resistant keystores draft. I'll include it in the next revision. thanks! > Yes. Alice is revoking *her* certification of Bob's key. Bob owns > Bob's key, but Alice owns her certification of Bob's key. Bob can > freely discard the certification or the certification+revocation, but > he should not be allowed to keep Alice's certification without its > matching revocation. Alice doesn't "own" her certification of Bob's certificate -- we're=20 > Part of my prologue of revocation not working is that Bob can always > go do key surgery. To some extent, anyone can do key surgery. Bob can > go in with a hex editor and pull off Alice's revocation, but general > tools shouldn't allow it. I start this from the assumption that the (ab)user has powerful, flexible client-side tools, and their only limitation is that they don't have access to (certain) secret keys. This is Kerckchoff's principle, basically. > Moreover, a key server shouldn't allow it. If Bob uploads a new copy > of his key without Alice's mention at all, that's fine. The key server > MUST not allow the revocation to be vanished alone. But if the keystore allows the revocation to be vanished in any way on its own terms, it has not solved the problem for the client that does merge-based updates but already knows of Alice's certification? Or, are you suggesting that a client of the keystore which knows of Alice's certification, but receives Bob's certificate without it from the keystore, should themselves *drop* Alice's certification just because the keystore doesn't report it? That would be a pretty radical change to how most OpenPGP keystore clients work today. > We have not seen the abuse problem of certificates being nonsensical, > but that could really happen. I am sure that if you did something like > take the first part of Bob's key, threw in one of Aice's user ids > along with all its certifications, and some subways and other things > from Charlie's key, that some implementation's going to barf in > amusing ways -- or worse, just accept it. these are straight up bugs. If you see them in any OpenPGP implementation -- client or keystore or wherever -- please report them and get them fixed. > Any problem that starts with "Mallory gets ahold of Bob's secret key" > and then goes on, is kinda like discussing an operating system exploit > that starts with, "okay, the attacker is in kernel mode." In general, > the attacker can have much more fun than whatever's described. Yes, > yes, if Malloy has Bob's secret key, Mallory can do anything. No, that's not true in this situation. We're talking here about how to get control of the key back from Mallory, or how to stop Mallory from decrypting messages already encrypted to the key, or anything like that. We're talking about how Alice can reliably publish her revocation of her certification even in the face of Bob being impaired, intransigent, or compromised. > However, this is part of why we have designated revokers. Designated Revokers need to be set up ahead of time. If you've done that, and your designated revoker isn't asleep at the switch, then all's well. but most people haven't, and it would be nice to handle that case. > Perhaps a key server ought to be a designated revoker itself in some > but not all cases. Perhaps even the default one. Of course, I'm > handwaving away things like accounts on that server, authentication, > takeover policies, and lots of other things that will be fun for > someone else. I'm looking for concrete guidance that we can offer to operators of keystores and clients of keystores today. Keystore operators have traditionally not wanted to be in the role of certificate authority, or of designated revoker (i can confirm this as a past and present keystore operator, but it's not just me). They're looking for a reliable set of guidelines they can follow to ensure that (a) the ecosystem is healthy, =20 (b) clients with different trust models and trusted introducers can find what they need, (c) the keystore can operate efficiently in terms of bandwidth and computational resources, and=20 (d) the keystore operator themselves is at minimal technical and legal risk. > Or a signature on the key that's made by the key server itself that > has a timeout and a lot of policy coded in it. How does this help in redistributing Alice's certifications? I am wary about trying to "code a lot of policy" -- the devil is in the details there, and i'd like to be clear about what those details are. Do you have something specific you're trying to propose here? The CRL-like mechanism that launched this thread is concrete, implementable, and has a set of functional properties that seem better than the status quo (though i think it can be improved too). If you've got specific text that you want to propose to improve it, or a counterproposal that makes it unnecessary, i'd be happy to see it. Thanks for thinking this through here, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXWb+tAAKCRB2GBllKa5f +EDdAQDkBoew6mINrSiUIOEuW6PGrMAQFKLj8HJGKuzZfCuIdAEA/Sb7d0rpSgpx Pwm/2hqKF9OJDrXNsT7YS4TSvJellgg= =2z/5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 28 18:57:56 2019 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 DC06312024E for ; Wed, 28 Aug 2019 18:57:54 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=HZDNX5at; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=iFbkTpwj 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 kgz1ZMwfxRaH for ; Wed, 28 Aug 2019 18:57:52 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20848120013 for ; Wed, 28 Aug 2019 18:57:52 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1567043871; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=Ntvo9ICktoNeuHAA6iWDVHFK3uribh9huil5UsgzYXI=; b=HZDNX5athNIrVqhCAg4Oq0ZjLnotAIsgN8gZBcEvOZGGsbhLpreHWSkN 7cEmaO9tI6EdIIqQBX6EXyYrwz7DAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1567043871; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=Ntvo9ICktoNeuHAA6iWDVHFK3uribh9huil5UsgzYXI=; b=iFbkTpwjv5LmN74e7gpMFyVK1hz04+XL3MoMWcMMYWJLquwQODcLriLu eDLS2Lf5YOfVkbbyf5WrWl/2/x34i17x0/bwL/DBVDpREVbLuI/PuUxrZJ I0IAEDj2iT+4X9VgiUOmnwxY1jPBbcmb3AnVWbuVydNx/eL/Nxxxvqbrz1 /cha+lfl7cdsyMNLVoKNUubBvQwHyduLfgju/6nuuULPSoW5ZuBKowN3DO Pr19r+SCmcDuTfacrQvqt7HdLvcSsps+Oo07OBNAJ6DOXGYiLxJhYRFvpy 409cIEnywlCtn6BjLZnQVdFS1gYbYhjIgee/0fTFOSg0gHUt1y9HDg== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:c41:39ff:fef3:974f]) (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 33498F99D; Wed, 28 Aug 2019 21:57:50 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 18F0F2024E; Wed, 28 Aug 2019 21:57:39 -0400 (EDT) From: Daniel Kahn Gillmor To: Werner Koch Cc: openpgp@ietf.org, Heiko Stamer In-Reply-To: <87blw94tfg.fsf@wheatstone.g10code.de> References: <87tva1am9t.fsf@fifthhorseman.net> <87blw94tfg.fsf@wheatstone.g10code.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Wed, 28 Aug 2019 21:57:38 -0400 Message-ID: <87h860ag31.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 01:57:55 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Hi Werner-- Thanks for the prompt feedback. I've updated the merge request to account for these suggestions. I've pushed my changes to gitlab, i'd be happy for any review, either on the merge request or here. The overall patch is also attached below, along with some discussion. On Wed 2019-08-28 09:53:39 +0200, Werner Koch wrote: > Putting this into a standard-self signature is troublesome because this > requires to update and distribute the self-signature as soon as one > uploads to a keyserver. I agree with you that moving it to its own, dedicated signature class helps to keep the concepts and updates separate, and that's a win. In particular, it allows the keyholder to make a distinct set of attestations without having to worry that some legacy implementation that updates the traditional self-sigs (e.g. updating the expiration date) will accidentally drop the attestations in the meantime. It also lets clients update their self-sigs and their attestations in a different cadence. In my revised merge request, i've added a dedicated signature class (0x16: Attestation Key Signature) which is the only thing that holds the Attested Certifications subpacket. > We need to have a way do include more key signatures. This can easily > be done with several of such self-signatures using the same creation > date or another mechanism to connect them. An upper limit on the number > of such self-signatures may be suggested in the implementation nits. I am not convinced that anyone has a meaningful need to attest to more than two thousand third-party certifications (a 64K-octet subpacket containing 2K 32-octet SHA256 digests), but you're right that we can use this "matching creation timestamp" approach to extend such a mechanism to arbitrary numbers of attestations. I've included those semantics in my revision. > The requirement to sort the hashes is not really helpful because that > requires that the implementation must check the order and decide what to > do if they are not sorted. In practice the implementation will sort them > anyway (in particular if several self-signatures are required). You're right that this MUST was too strict, and that implementations will end up sorting them anyway. I've reduced it to a SHOULD because it can be handy, but obviously things shouldn't break if they're not sorted. Thanks for catching this. > It should also be up to the implementation on how to match them. I'm not sure what you mean by this -- it seems very important to me that there is a clear and unambiguous way to match an attestation to a third-party certification. These attestations are not merely pointers to certifications, they are cryptographic assertions about them. > The subpacket definition should include a version number or digest > algorithm to be future prove. I think that including a version number in the subpacket is premature optimization. If we decide to do something different in the future, we can use a new subpacket definition, and just deprecate this one. We have lots of room to spare, and making something simple and fixed is better. If we start running out of subpacket identifiers, we can designate one last remaining subpacket identifier to be a multiplexer into a new space of subpacket IDs, but i don't want every existing subpacket to itself be multiplexed internally. > We should of course use SHA-256 and not SHA-512. I agree with you that we want the choice of digest fixed in the subpacket -- and all attestations in the signature should use the same digest. And i don't want to include any sort of explicit digest field identifier in the subpacket, because i don't want consumers of these things to have to reason about "is it going to be OK to have a signature made over blake2b covering a series of MD5-based attestations". But rather than hard-code SHA-256 (or SHA-512 or something else), I've bound the digest used in the Attested Certifications subpacket to the digest used in the Attestation Key Signature itself. This means: * we don't have to get into any arguments about the relative strength of a digest in one place or another. if you're ok with it for the signature, you should be ok with it as the attestation. * if the certficate holder is uncomfortable with the properties of any particular digest (or they're deploying in a highly-opinionated or constrained environment), they can just choose to make their Attestation Key Signature with a digest that meets their needs. Their certificate as a whole can depend on one specific digest, without having accidentally introduced a hard-coded dependency. FWIW, i agree that SHA256 sense to use today, but if someone wants to make a certificate that is entirely free of SHA256, this lets them do it, without providing enough rope to get tangled up in. I've made some new demonstration certificates with this new approach (and my example does use SHA256): The signer's certificate (the "third party"): -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEXWcuXBYJKwYBBAHaRw8BAQdAIjn6AW4wgrQ7hI66BZkaCzL2X/bRX+yf1tm8 4OxSkULNJkNlcnRpZmljYXRlIEF1dGhvcml0eSA8Y2FAZXhhbXBsZS5jb20+woQE ExYIACwFAl1m9hwCGwECFQgCF4ACGQECHgEWIQTBvMlvJO6/G++jDVQ953dEaeBc DQAKCRA953dEaeBcDc8hAP9it7GkIgG1Sisa8e46SJIZRfWAcT1vzAmv8k57jY/P HAEAizCu8jGLKp5AHWLNIU2ah9tEEEch5q4GI7tqMbu5IQU= =rn/T -----END PGP PUBLIC KEY BLOCK----- The first party, along with a standard self-sig, a third-party certification, and an Attestation Key Signature attesting to the third-party certification: -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEXWcuXBYJKwYBBAHaRw8BAQdAPeDThwKKsiEAR8GwQBzv94FnDhyc9+NtXoH+ 4LGxhh7NHFRlc3QgVXNlciA8dGVzdEBleGFtcGxlLmNvbT7ChAQTFggALAUCXWb2 HAIbAQIVCAIXgAIZAQIeARYhBHZ7/PJBbYUZS/wOEE/bnIu8dqmjAAoJEE/bnIu8 dqmjYvcA+wbxprn1NQfP6uY19plBu/WRPnCAj6Tnte4KUThl48dMAQCuIURYGmK4 znKmav/bnDgp+bLSrfo/4tE1SK1/fudRAMJ1BBAWCAAdBQJdZvYmFiEEwbzJbyTu vxvvow1UPed3RGngXA0ACgkQPed3RGngXA3pGAEAzyIb8BtrLb6Oi1eY/JLje/i/ lmWO46EoWe0Rh8J8gC8BAPV6/txR65Qa4DaMw26GyHk8uGTzxiRyH6q62Xpwcx8K wpcEFhYIAD8FAl1m9jAhJTA+FEO+y68KkjvvIGaLNBfj/pHb2IeYj2/C6ecXEJgy FiEEdnv88kFthRlL/A4QT9uci7x2qaMACgkQT9uci7x2qaOxNwD/SLpQxMKZX4ys nmjuV2+VwpwOhlBBAZsX+eRkqDlPUicBAI9EZo/fmuzXzG3D6FrUB0rfgVdiDTy6 EB6DaIpVWGQJ =FDhV -----END PGP PUBLIC KEY BLOCK----- Please let me know what you think! --dkg --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=attested-certifications-v2.patch Content-Transfer-Encoding: quoted-printable diff --git a/middle.mkd b/middle.mkd index 51f71a6..275f5b5 100644 =2D-- a/middle.mkd +++ b/middle.mkd @@ -735,6 +735,20 @@ These meanings are as follows: certifications. Some implementations can issue 0x11-0x13 certifications, but few differentiate between the types. =20 +0x16 + : Attestion Key Signature. This signature is issued by the primary + key over itself and its user ID (or user attribute). It MUST + contain an "Attested Certifications" subpacket and a "Signature + Creation Time" subpacket. This type of key signature does not + replace or override any standard certification (0x10-0x13). + + Only the most recent Attestation Key Signature is valid for any + given pair. If more than one Certification + Attestation Key Signature is present with the same Signature + Creation Time, the set of attestations should be treated as the + union of all "Attested Certifications" subpackets from all such + signatures with the same timestamp. + 0x18 : Subkey Binding Signature. This signature is a statement by the top-level signing key that indicates that it owns the @@ -1058,6 +1072,7 @@ The value of the subpacket type octet may be: 32 Embedded Signature 33 Issuer Fingerprint 34 Preferred AEAD Algorithms + 37 Attested Certifications 100 to 110 Private or experimental =20 An implementation SHOULD ignore any subpacket of a type that it does @@ -1451,9 +1466,16 @@ This is a list of one-bit flags that indicate prefer= ences that the key holder has about how the key is handled on a key server. All undefined flags MUST be zero. =20 =2DFirst octet: 0x80 =3D No-modify the key holder requests that this key =2Donly be modified or updated by the key holder or an administrator of =2Dthe key server. +First octet: 0x80 =3D No-modify + + The key holder requests that this key only be modified or updated + by the key holder or an administrator of the key server. + + If No-modify is set on the most recent self-sig over a user ID, + then a keyserver should only redistribute those third-party + certifications over that user ID that have been attested to in the + most recent Attestation Key Signature packet (see "Attested + Certifications" below). =20 This is found only on a self-signature. =20 @@ -1675,6 +1697,75 @@ signature, the key ID of the Issuer subpacket MUST m= atch the low Note that the length N of the fingerprint for a version 4 key is 20 octets; for a version 5 key N is 32. =20 +#### Attested Certifications + +(N octets of certification digests) + +This subpacket MUST only appear as a hashed subpacket of an +Attestation Key Signature. It has no meaning in any other signature +type. It is used by the primary key to attest to a set of third-party +certifications over the associated User ID or User Attribute. This +enables the holder of an OpenPGP primary key to mark specific +third-party certifications as re-distributable with the rest of the +Transferable Public Key (see the "No-modify" flag in "Key Server +Preferences", above). Implementations MUST include exactly one +Attested Certification subpacket in any generated Attestation Key +Signature. + +The contents of the subpacket consists of a series of digests using +the same hash algorithm used by the signature itself. Each digest is +made over one third-party signature (any Certification, i.e., +signature type 0x10-0x13) that covers the same Primary Key and User ID +(or User Attribute). For example, an Attestation Key Signature made +by key X over user ID U using hash algorithm SHA256 might contain an +Attested Certifications subpacket of 192 octets (6*32 octets) covering +six third-party certification Signatures over . They SHOULD be +ordered by binary hash value from low to high (e.g., a hash with +hexadecimal value 037a... precedes a hash with value 0392..., etc). +The length of this subpacket MUST be an integer multiple of the length +of the hash algorithm used for the enclosing Attestation Key +Signature. + +The listed digests MUST be calculated over the third-party +certification's Signature packet as described in the "Computing +Signatures" section, but without a trailer: the hash data starts with +the octet 0x88, followed by the four-octet length of the Signature, +and then the body of the Signature packet. (Note that this is an +old-style packet header for a Signature packet with the +length-of-length field set to zero.) The unhashed subpacket data of +the Signature packet being hashed is not included in the hash, and the +unhashed subpacket data length value is set to zero. + +If an implementation encounters more than one such subpacket in an +Attestation Key Signature, it MUST treat it as a single Attested +Certifications subpacket containing the union of all hashes. + +The Attested Certifications subpacket in the most recent Attestation +Key Signature over a given user ID supersedes all Attested +Certifications subpackets from any previous Attestation Key Signature. +However, note that if more than one Attestation Key Signatures has the +same (most recent) Signature Creation Time subpacket, implementations +MUST consider the union of the attestations of all Attestation Key +Signatures (this allows the keyholder to attest to more third-party +certifications than could fit in a single Attestation Key Signature). + +If a keyholder Alice has already attested to third-party +certifications from Bob and Carol and she wants to add an attestation +to a certification from David, she should issue a new Attestation Key +Signature (with a more recent Signature Creation timestamp) that +contains an Attested Certifications subpacket covering all three +third-party certifications. + +If she later decides that she does not want Carol's certification to +be redistributed with her certificate, she can issue a new Attestation +Key Signature (again, with a more recent Signature Creation timestamp) +that contains an Attested Certifications subpacket covering only the +certifications from Bob and David. + +Note that Certification Revocation Signatures are not relevant for +Attestation Key Signatures. To rescind all attestations, the primary +key holder needs only to publish a more recent Attestation Key +Signature with an empty Attested Certifications subpacket. =20 ### Computing Signatures =20 @@ -1707,6 +1798,10 @@ Attribute certifications, followed by a four-octet n= umber giving the length of the User ID or User Attribute data, and then the User ID or User Attribute data. =20 +An Attestation Key Signature (0x16) hashes the same data boy that a +standard certification signature does: primary key, followed by User +ID or User Attribute. + When a signature is made over a Signature packet (type 0x50, "Third-Party Confirmation signature"), the hash data starts with the octet 0x88, followed by the four-octet length of the signature, and @@ -3646,12 +3741,12 @@ transferable public key are as follows: - Zero or more User ID packets =20 - After each User ID packet, zero or more Signature packets =2D (certifications) + (certifications and attestation key signatures) =20 - Zero or more User Attribute packets =20 - After each User Attribute packet, zero or more Signature packets =2D (certifications) + (certifications and attestation key signatures) =20 - Zero or more Subkey packets =20 @@ -3671,6 +3766,10 @@ immediately preceding User ID packet and the initial= Public-Key packet. The signature serves to certify the corresponding public key and User ID. In effect, the signer is testifying to his or her belief that this public key belongs to the user identified by this User ID. +Intermixed with these certifications may be Attestation Key Signature +packets issued by the primary key over the same User ID and Public Key +packet. The most recent of these is used to attest to third-party +certifications over the associated User ID. =20 Within the same section as the User ID packets, there are zero or more User Attribute packets. Like the User ID packets, a User Attribute --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXWcxEgAKCRB2GBllKa5f +FbcAP9Dxe2MdfuoP99T3GvMyBqycXtKeOhQigkkIfAajh1UnAD9EchklaBMsiVi WbXhb3ikYJmwCwWiNkr436ycyC2/eAA= =8GEV -----END PGP SIGNATURE----- --==-=-=-- From nobody Thu Aug 29 05:07:11 2019 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 D9EE11200F1 for ; Thu, 29 Aug 2019 05:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 OoqvG1FYJhnb for ; Thu, 29 Aug 2019 05:07:07 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 0F0FC1200D5 for ; Thu, 29 Aug 2019 05:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1567080427; x=1598616427; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LdXdb/CZUcK1a+mYUECjjle6zkkCM4eSPH+Skw3B9LI=; b=p3TBxLXbJKkeNSbbEiJW3Af2iz/cFjFHvl5nla6YcSlBwRyOBbDuL4hu BeIeWH/PdUoR8KkvAaqax7CK6eTnqk3m6T7agUZ4pPsLB+j4sAOxbBCL1 bjS0pNtc+CdSBLJT7AnmCUtrH9aSlZFubhRav0pk2OMft0lA0IanCNXYk slhNIBz9oGKEtgQjpHzJr5bxxKUdY/xiZ1GME7mmEfVvr5xPTSfHFyv0M aZNy/mS6a6PEEhRHeBiEGRBkjuO9ZLs56IAj8y4psYuG2KOYjvSUKYUft 3ziA4qTcCTmOm71o8nfuJ0z1i481mzEuDeD2kO/TXMSGL25L/5cFKY4PF A==; X-IronPort-AV: E=Sophos;i="5.64,442,1559476800"; d="scan'208";a="79254181" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Aug 2019 00:07:03 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 30 Aug 2019 00:07:02 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 30 Aug 2019 00:07:02 +1200 From: Peter Gutmann To: Daniel Kahn Gillmor , Jon Callas , "openpgp@ietf.org" Thread-Topic: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] Thread-Index: AQHVWTV/erbesUqyBEGgz5pu3ZR1aqcOqf2AgAAsMACAAJLHAIAA+bAAgAGu20k= Date: Thu, 29 Aug 2019 12:07:01 +0000 Message-ID: <1567080406573.66529@cs.auckland.ac.nz> References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> <87zhju9qlb.fsf@fifthhorseman.net> <6057F53D-2251-4B92-997B-EF241C2F4EF3@icloud.com>, <87imqh9bgr.fsf@fifthhorseman.net> In-Reply-To: <87imqh9bgr.fsf@fifthhorseman.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 12:07:10 -0000 Daniel Kahn Gillmor writes:=0A= =0A= >I'm looking for concrete guidance that we can offer to operators of keysto= res=0A= >and clients of keystores today.=0A= =0A= Maybe we can look at X.509 for an example. During the interminable X.509= =0A= standardisation process, there was an equally interminable debate about=0A= whether to make revocations easy (the emergency handbrake model) or hard (t= he=0A= DoS-resistance model). The DoS resistance guys won out protocol-wise, and = CAs=0A= won out business-wise because it costs money to deal with revocations so=0A= discouraging them as much as possible cuts back on expenses.=0A= =0A= In the 20-25 years since then, there have, to the best of my knowledge, bee= n=0A= zero malicious revocations. I counted them, twice. There have however bee= n=0A= vast numbers of certs not revoked that should have been, or revoked far too= =0A= late to do any good, typically for malware-signing, phishing, or just=0A= lost/password forgotten/eaten by the cat/whatever where there's no proof of= =0A= malicious use but they should still have been declared invalid for general= =0A= hygiene reasons.=0A= =0A= So at least for X.509 the emergency-handbrake model should have been the on= e=0A= to use but, typically for X.509, they went with the wrong option. When a b= us=0A= is about to crash, you need to stop it promptly, not argue about who is and= =0A= isn't authorised to hit the brakes.=0A= =0A= Peter.=0A= From christian.t.weissmann@campus.tu-berlin.de Thu Aug 29 07:15:21 2019 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 1089712007C for ; Thu, 29 Aug 2019 07:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=campus.tu-berlin.de 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 TnjgAunARQtn for ; Thu, 29 Aug 2019 07:15:18 -0700 (PDT) Received: from exchange.tu-berlin.de (exchange.tu-berlin.de [130.149.7.70]) (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 5508212004A for ; Thu, 29 Aug 2019 07:15:18 -0700 (PDT) Received: from SPMA-01.tubit.win.tu-berlin.de (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 191427E07F7_D67DDF4B for ; Thu, 29 Aug 2019 14:15:16 +0000 (GMT) Received: from exchange.tu-berlin.de (exchange.tu-berlin.de [130.149.7.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "exchange.tu-berlin.de", Issuer "DFN-Verein Global Issuing CA" (not verified)) by SPMA-01.tubit.win.tu-berlin.de (Sophos Email Appliance) with ESMTPS id AC1FB8327A9_D67DDF3F for ; Thu, 29 Aug 2019 14:15:15 +0000 (GMT) Received: from EX-MBX06.tubit.win.tu-berlin.de (172.26.35.176) by EX-MBX-01.tubit.win.tu-berlin.de (172.26.35.171) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 29 Aug 2019 16:15:14 +0200 Received: from EX-MBX06.tubit.win.tu-berlin.de ([172.26.35.176]) by EX-MBX06.tubit.win.tu-berlin.de ([172.26.35.176]) with mapi id 15.00.1395.000; Thu, 29 Aug 2019 16:15:14 +0200 From: =?utf-8?B?V2Vpw59tYW5uLCBDaHJpc3RpYW4gVGplcms=?= To: "openpgp@ietf.org" Thread-Topic: Private key backup on-boarding prototype survey Thread-Index: AQHVXnQseKwK8Gh6Mkybv0d1h9+9DA== Date: Thu, 29 Aug 2019 14:15:14 +0000 Message-ID: <8C3A31B7-67C7-4DA6-8A7B-AE5A17BCAE78@campus.tu-berlin.de> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [5.28.115.110] x-pmwin-version: 4.0.1, Antivirus-Engine: 3.74.1, Antivirus-Data: 5.67 x-puremessage: [Scanned] Content-Type: multipart/signed; boundary="Apple-Mail=_8326CF88-FFAE-48D9-8ABA-9DC20709F75E"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=campus.tu-berlin.de; h=from:to:subject:date:message-id:content-type:mime-version; s=dkim-tub; bh=n1K872UD1KLTQpwBNrvlRfX5gcxAgxpQT1iLp5DZva8=; b=cii4XEL9tySnbRzJeSgm3gm4da99XhyKaCaUY1qfrZdtXfCjig0v1GMCxVsmuommJp/Q77UPH/vHPIZd0e5jL9690AKucKW8vEfQw8MbH7ZDkWN5XUpSWZIW01BhHqPyrUTlLkNttfxvB9yyOh9HKWvPZW3Qs4vzXs81bI9Wvcw= Archived-At: Subject: [openpgp] Private key backup on-boarding prototype survey X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 14:16:45 -0000 --Apple-Mail=_8326CF88-FFAE-48D9-8ABA-9DC20709F75E Content-Type: multipart/alternative; boundary="Apple-Mail=_00B941DC-314F-4D19-A9D2-BC1B23773A68" --Apple-Mail=_00B941DC-314F-4D19-A9D2-BC1B23773A68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi PGP community, My name is Chris and I am currently writing my master's thesis at the TU = Berlin in co-operation with the FU Berlin. My goal is to research how to = remove hurdles that discourage people from using PGP to encrypt their = email. Currently I am looking into introducing a secret sharing scheme that = helps with secure distributed backups of the private key. If you don=E2=80= =99t know what secret sharing is, no worries, that=E2=80=99s what I am = trying to explain. Therefore I created a small on-boarding prototype for = this feature that I would love your feedback on. Below the prototype you = can see the link to the survey which has around 10 mostly = multiple-choice questions about the topic and some demographics at the = end. Of course the input is anonymized and used only within my research = purpose. For the start I would implement the feature in the PGP supporting email = client which is being developed by the Freie Universit=C3=A4t Berlin. In case you are interested in what this idea develops into, there is the = option to add your email to a list that I will update about my findings = at the end of the project. To find the prototype click the following link: = https://letterbox-app.org/survey/backup/ = Best regards, Christian Wei=C3=9Fmann --Apple-Mail=_00B941DC-314F-4D19-A9D2-BC1B23773A68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi PGP = community,

My name is Chris and I am currently writing my master's = thesis at the TU Berlin in co-operation with the FU Berlin. My goal is = to research how to remove hurdles that discourage people from using PGP = to encrypt their email. 

Currently I am = looking into introducing a secret sharing scheme that helps with secure = distributed backups of the private key. If you don=E2=80=99t know what = secret sharing is, no worries, that=E2=80=99s what I am trying to = explain. Therefore I created a small on-boarding prototype for this = feature that I would love your feedback on. Below the prototype you can = see the link to the survey which has around 10 mostly multiple-choice = questions about the topic and some demographics at the end. Of course = the input is anonymized and used only within my research = purpose. 

For the start I would implement the feature in the PGP = supporting email client which is being developed by the Freie = Universit=C3=A4t Berlin.

In case you are interested in what this idea develops into, = there is the option to add your email to a list that I will update about = my findings at the end of the project.

To find the prototype click the following = link: https://letterbox-app.org/survey/backup/

Best regards,
Christian Wei=C3=9Fmann 

= --Apple-Mail=_00B941DC-314F-4D19-A9D2-BC1B23773A68-- --Apple-Mail=_8326CF88-FFAE-48D9-8ABA-9DC20709F75E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEv115z8jp3bnDs3DvVewg73BoHp0FAl1n3fEACgkQVewg73Bo Hp2ZuhAAuNEtIff5PyZGMpn6SRi5lV3NY8df199NMK61XI7hYSY1HGCmKfQ4ENPu 66+1tQb99KkOxNM0SzvOe+WRf43OZc3pCIupQt/DBq3MdnbLaWki5ENlkzixjKZg 2WsSRuqfk/z6EEFlTrGmsgOInXMSE0fhdWot8egSIeESzE0X0lmfmn8TsH7dDtem ytRcZE4Nn8mAOJ857tkzo5FnjAv/VV0ZKInXz+8eihTgitKlhJ2m7vu5Z9qdv4Er +bZQJjzs0wVDdtlhRAZ7t/awZ/2mhDskgFEhmVyiC5xM/XOcVcK7SeWRfisR92sM bGstR0pawdadJhT76xvqTfZT660WCbRxjBg7o3MZX52kO6aGXge+m/ZChIQge4CM wnRbichYJJiwuHtX2RI/7qeaXPSx1Sn+DI22sISoqdj1sDbknwyHMzWZA50MzNhh 5jRPYSfBZoFhBoPV5mGyzmyA4K3cpB7+i2urk2kDlxPAcNz/64dBrYABajWBj6o4 qZiVOmZk+VRCofuti1cTg52hYA1KFXgmmJG5a+/viQpk9VuQVUlDa/Ht2Uph3isB NKnwDoJ6Cfd1rlL22evgidWox1vgghSRMudMuqXoW9fa/cj6Sr2CkwuGM8nii6qK ynreotuh7TZACAA1mV+7qQh4FJ+9SX7moCkeMiiJp3pq3/TTGtM= =oBEy -----END PGP SIGNATURE----- --Apple-Mail=_8326CF88-FFAE-48D9-8ABA-9DC20709F75E-- From nobody Thu Aug 29 09:59:58 2019 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 96635120A39 for ; Thu, 29 Aug 2019 09:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=xb+u3TD6; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=2OHdLIRw 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 ayBgIh11PQnN for ; Thu, 29 Aug 2019 09:59:54 -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 D2F98120A38 for ; Thu, 29 Aug 2019 09:59:53 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1567097992; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=ifsVZ3YLGQOOoQe0rrArrNewbQ3Q6fpa7ut4oyB1C0Y=; b=xb+u3TD66/+3opbTwcHn0chhkKhS+trtNkpbSG3YzYyE44gEBxqHpcCn 8zutcXnZZAazZUTGRBSXQpSruZseDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1567097992; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=ifsVZ3YLGQOOoQe0rrArrNewbQ3Q6fpa7ut4oyB1C0Y=; b=2OHdLIRwM8uSTNmuVXersiUJj2cPJB7LrFP/ng5Upu3aWdj6yddtoXya D7dPLnpY2kZocarpQQiI2iamyceKUxD8j/q6zeJqB9HGL4sAdgiAvEjEav MGANah73pimzDWLeFdOohyfCAane/MFUwCkC9000+SGpY339Ewbsm2P8Ms 6j0I/SX+S/DTXCPRVRg9BB/bVypOv5QmBxIUBeflujaiJlutIiC1sQ8VUK hkleVmffY3+0/yG2EmRzNk9OjwzAJXblLyK3nZQS4jUu7muY91GR28vxWm rnm4PU1b0MG7FxGqwxGG5/L3t3iB739SDTYlZMAkNgbDpGpd0YJIOQ== 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 E30DEF99D; Thu, 29 Aug 2019 12:59:51 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 262682025E; Thu, 29 Aug 2019 12:59:49 -0400 (EDT) From: Daniel Kahn Gillmor To: Werner Koch Cc: Heiko Stamer , openpgp@ietf.org In-Reply-To: <87h860ag31.fsf@fifthhorseman.net> References: <87tva1am9t.fsf@fifthhorseman.net> <87blw94tfg.fsf@wheatstone.g10code.de> <87h860ag31.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Thu, 29 Aug 2019 12:59:48 -0400 Message-ID: <8736hjaovv.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 16:59:57 -0000 --=-=-= Content-Type: text/plain On Wed 2019-08-28 21:57:38 -0400, Daniel Kahn Gillmor wrote: > I've made some new demonstration certificates with this new approach > (and my example does use SHA256): > > The signer's certificate (the "third party"): > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > xjMEXWcuXBYJKwYBBAHaRw8BAQdAIjn6AW4wgrQ7hI66BZkaCzL2X/bRX+yf1tm8 > 4OxSkULNJkNlcnRpZmljYXRlIEF1dGhvcml0eSA8Y2FAZXhhbXBsZS5jb20+woQE > ExYIACwFAl1m9hwCGwECFQgCF4ACGQECHgEWIQTBvMlvJO6/G++jDVQ953dEaeBc > DQAKCRA953dEaeBcDc8hAP9it7GkIgG1Sisa8e46SJIZRfWAcT1vzAmv8k57jY/P > HAEAizCu8jGLKp5AHWLNIU2ah9tEEEch5q4GI7tqMbu5IQU= > =rn/T > -----END PGP PUBLIC KEY BLOCK----- > > The first party, along with a standard self-sig, a third-party > certification, and an Attestation Key Signature attesting to the > third-party certification: > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > xjMEXWcuXBYJKwYBBAHaRw8BAQdAPeDThwKKsiEAR8GwQBzv94FnDhyc9+NtXoH+ > 4LGxhh7NHFRlc3QgVXNlciA8dGVzdEBleGFtcGxlLmNvbT7ChAQTFggALAUCXWb2 > HAIbAQIVCAIXgAIZAQIeARYhBHZ7/PJBbYUZS/wOEE/bnIu8dqmjAAoJEE/bnIu8 > dqmjYvcA+wbxprn1NQfP6uY19plBu/WRPnCAj6Tnte4KUThl48dMAQCuIURYGmK4 > znKmav/bnDgp+bLSrfo/4tE1SK1/fudRAMJ1BBAWCAAdBQJdZvYmFiEEwbzJbyTu > vxvvow1UPed3RGngXA0ACgkQPed3RGngXA3pGAEAzyIb8BtrLb6Oi1eY/JLje/i/ > lmWO46EoWe0Rh8J8gC8BAPV6/txR65Qa4DaMw26GyHk8uGTzxiRyH6q62Xpwcx8K > wpcEFhYIAD8FAl1m9jAhJTA+FEO+y68KkjvvIGaLNBfj/pHb2IeYj2/C6ecXEJgy > FiEEdnv88kFthRlL/A4QT9uci7x2qaMACgkQT9uci7x2qaOxNwD/SLpQxMKZX4ys > nmjuV2+VwpwOhlBBAZsX+eRkqDlPUicBAI9EZo/fmuzXzG3D6FrUB0rfgVdiDTy6 > EB6DaIpVWGQJ > =FDhV > -----END PGP PUBLIC KEY BLOCK----- The above examples had some silly timestamp issues due to a confusion in my generation toolchain between localtime and UTC. I've fixed that problem now. Here is an improved example: The signer's certificate (the "third party"): -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEXWgC1BYJKwYBBAHaRw8BAQdA847Q7k21jU2Io+IZ6ltc4zSxZp8ttgOZZDeG iySNTOPNJkNlcnRpZmljYXRlIEF1dGhvcml0eSA8Y2FAZXhhbXBsZS5jb20+woQE ExYIACwFAl1oAtQCGwECFQgCF4ACGQECHgEWIQQfVCvVCBoTud0bdgbSKXzdeDUV twAKCRDSKXzdeDUVt2PHAP0YiwR2ZRrfJbzH46U6eB2AOtdSpIqfTcNnHLQH2bFC 5QD8CC8Jr0Ym5Ai+qAD9GxkDJtsRkFBXq983oq52DJRJJA0= =taR1 -----END PGP PUBLIC KEY BLOCK----- The first party, along with a standard self-sig, a third-party certification, and an Attestation Key Signature attesting to the third-party certification: -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEXWgC1BYJKwYBBAHaRw8BAQdA/V1P+p5pp8EloIYF1sqeu5hobtj+BLpEn7zO XJKZtznNHFRlc3QgVXNlciA8dGVzdEBleGFtcGxlLmNvbT7ChAQTFggALAUCXWgC 1AIbAQIVCAIXgAIZAQIeARYhBBVqOHIbKPae6A3uusaUcjoTcOqxAAoJEMaUcjoT cOqxTYUA/1ypaVgyqz8KiMtz7sOhbXuS7RJ1gb0RGrtMpL8TaAsuAP4hWDFkLgKy huz4Aky8l2xJHq/bnzwO9ChDwPxccy/dA8J1BBAWCAAdBQJdaALeFiEEH1Qr1Qga E7ndG3YG0il83Xg1FbcACgkQ0il83Xg1FbfACwEA72frsa6cbvfwF3gt7TyCWN5f +U3vxv/PksT5to5PfggA/RHrasr4bWtkvTFiPTLZzsPlJ7JU3JY7S1Zfa+3oY60P wpcEFhYIAD8FAl1oAughJaeUxunM/i80xn4H94lPu9FZD/rmajysr/7YbfFNGJeU FiEEFWo4chso9p7oDe66xpRyOhNw6rEACgkQxpRyOhNw6rH/DAEA1rISPgumTkpx +eKpjV+qyb0FnlM4wOFrh6b3+lpgV6IBAIx35b6rr4yAR1P/gooCQpMfkdV1fbh9 jrjOspJMP8cG =HMMo -----END PGP PUBLIC KEY BLOCK----- Importing these with gpg 2.2.17 yields the following warning messages: gpg: key D2297CDD783515B7: public key "Certificate Authority " imported gpg: key C694723A1370EAB1: 1 bad signature gpg: sig issued by C694723A1370EAB1 with class 22 (digest: ff 0c) is not valid over a user id or a key id, ignoring. gpg: key C694723A1370EAB1: public key "Test User " imported gpg: Total number processed: 2 gpg: imported: 2 This is noise from the new signature class is what i would expect, but the result is that the attestation signature itself is simply discarded by GnuPG. Works for me -- that seems like a sensible response from a legacy client that doesn't know about attestations. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXWgEhAAKCRB2GBllKa5f +IxoAP4hJYq+1OtQQrlbvry9WTAMY7msY49NpvVqFhMc8rxBQgEAlmthyjVMcpfB C3KjDt19hvDsISh5n/yEulKPTgZdvgo= =g2yE -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 29 19:39:11 2019 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 0981A1200E5 for ; Thu, 29 Aug 2019 19:39:10 -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, SPF_NONE=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 2ubYp0328FTJ for ; Thu, 29 Aug 2019 19:39:08 -0700 (PDT) Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E38D120113 for ; Thu, 29 Aug 2019 19:39:08 -0700 (PDT) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1i3Woc-0006nn-Su for openpgp@ietf.org; Fri, 30 Aug 2019 04:39:07 +0200 Message-ID: <1567132742.1695.16.camel@16bits.net> From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Fri, 30 Aug 2019 04:39:02 +0200 In-Reply-To: <8736hjaovv.fsf@fifthhorseman.net> References: <87tva1am9t.fsf@fifthhorseman.net> <87blw94tfg.fsf@wheatstone.g10code.de> <87h860ag31.fsf@fifthhorseman.net> <8736hjaovv.fsf@fifthhorseman.net> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 02:39:10 -0000 It may not have been clear the way to work with the no-modify flag, but I feel you are changing its meaning now. By making it mean "do not redistribute third-party certifications", the result is having old clients that yet the no.modify flag yet are unable to make the needed attestations. I think this should be a new keyserver preferences flag. Eg. it could be called attested-certifications-only or drop-unattested-certifications. Kind regards From nobody Thu Aug 29 21:44:01 2019 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 4B2AB120CD4 for ; Thu, 29 Aug 2019 21:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 unWxa-jmDRhn for ; Thu, 29 Aug 2019 21:43:39 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 089EC120CAF for ; Thu, 29 Aug 2019 21:43:38 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7U4hUGb011639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Aug 2019 00:43:34 -0400 Date: Thu, 29 Aug 2019 23:43:30 -0500 From: Benjamin Kaduk To: Daniel Kahn Gillmor Cc: openpgp@ietf.org Message-ID: <20190830044304.GL84368@kduck.mit.edu> References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> <20190826071911.GE84368@kduck.mit.edu> <87blwbbwe4.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87blwbbwe4.fsf@fifthhorseman.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 04:43:44 -0000 On Mon, Aug 26, 2019 at 02:43:15PM -0400, Daniel Kahn Gillmor wrote: > On Mon 2019-08-26 02:19:12 -0500, Benjamin Kaduk wrote: > > On Thu, Aug 22, 2019 at 06:01:23PM -0400, Daniel Kahn Gillmor wrote: > >> Note that this only works if there is a well-established convention > >> about what digest algorithm to use. I don't want to keep a SHA256 and a > >> SHA512 and a blake2b index of all the certifications i know about. Note > >> also that SHA256 isn't used here for strong cryptographic purposes -- > >> it's just a hash table indexer. > > > > This sounds an awful lot like (my understanding of) what PHB's UDF [1] > > (uniform data fingerprint) is supposed to be. Sadly, I've not had time > > yet to give it a proper read... > > > > [1] https://tools.ietf.org/html/draft-hallambaker-mesh-udf > > I don't think that this is the same thing as i'm proposing above -- my > understanding is that PHB's UDF is intended to have some level of > cryptographic resilience -- to collisions at least, and maybe to > pre-images in some contexts. That's my understanding as well, but with the related property that a single index will encompass all fingerprint-generating algorithms, which is what I was focusing on. It does not really get you the property that if you have one fingerprint you can look up the entry for the object with that fingerprint, though (IIUC), since the entry might only be in the index under a different "name". Sorry for not thinking it through more, Ben > In the scheme i've proposed above, the digest is simply used to find a > certification in an index. It could conceivably be non-unique, even, > since the verification is expected to be done over the full underlying > certification data. (i.e. it's an index to a non-keyed hashtable) > > To avoid malicious attacks against the efficiency of the non-keyed > hashtable (e.g. if we used CRC32, an adversary could flood the user with > certifications that produce identical checksums, reducing them to linear > search), we probably *do* want it to be collision-resistant, but it's > not going to need the same level of cryptographic rigor that we'd need > for a fingerprint, where the fingerprint itself is used to prove > identity of data. > > --dkg From nobody Thu Aug 29 22:16:01 2019 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 DCD571200FA for ; Thu, 29 Aug 2019 22:15:59 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=kVHdD6pH; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=ew/dXDXl 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 9ZrGVDCaIK7v for ; Thu, 29 Aug 2019 22:15:58 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C866D1200E3 for ; Thu, 29 Aug 2019 22:15:57 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1567142156; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=1wLbO6H4+2tcxHciDI2sdHJT7sl5HhpcH9iyOPTtbdI=; b=kVHdD6pHmBdUx4itHa7evmP8u0rM7gIB5QCBFnb0Z42sHiGRklLCy6i6 nckKX/OOb1qdQnpnYaWHaz4uN+W6CQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1567142156; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=1wLbO6H4+2tcxHciDI2sdHJT7sl5HhpcH9iyOPTtbdI=; b=ew/dXDXlhAuCqN+kX8FZ5CSGgaMsu28MXPPCaxg0Up2lwRcDYM6Fu+7p bTGnX9miz44oic4SM3YUWdbXBc6GpW04iNrBgWhjUKWBK+CbXe84tHy6ik EuDjXioemu+3FtS4a+ZdZ05IrKDuTwMJ07Jj5xLx9L6Tqla//tpo3SbZf6 2zc38GsfuGfXeuZpIt16mn+jmGpZul6sxfsMVWlPOd4Qr+uItGG3uGpJbG 8Gkh8uYRjGDosAatSgjU0w8Ury8YRqVMUqem9aht6QBkJNvf77fwjhL34S wo8VZY/K9RNtCryHHynw1o+ZJJZldlNXDWc4jhz80pZ4viQjD8sg5g== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:c41:39ff:fef3:974f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 057A6F9A6; Fri, 30 Aug 2019 01:15:55 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A3A5A2025E; Fri, 30 Aug 2019 01:15:40 -0400 (EDT) From: Daniel Kahn Gillmor To: =?utf-8?Q?=C3=81ngel?= , openpgp@ietf.org In-Reply-To: <1567132742.1695.16.camel@16bits.net> References: <87tva1am9t.fsf@fifthhorseman.net> <87blw94tfg.fsf@wheatstone.g10code.de> <87h860ag31.fsf@fifthhorseman.net> <8736hjaovv.fsf@fifthhorseman.net> <1567132742.1695.16.camel@16bits.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 30 Aug 2019 01:15:40 -0400 Message-ID: <87lfvb8c8z.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 05:16:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri 2019-08-30 04:39:02 +0200, =C3=81ngel wrote: > It may not have been clear the way to work with the no-modify flag, but > I feel you are changing its meaning now. By making it mean "do not > redistribute third-party certifications", the result is having old > clients that yet the no.modify flag yet are unable to make the needed > attestations. > I think this should be a new keyserver preferences flag. Eg. it could be > called attested-certifications-only or drop-unattested-certifications. In practice, nearly every modern existing certificate has the keyserver-no-modify flag set on it. and also in practice, there are *no* keyservers in play that do anything with that flag that i'm aware of. The other thing to note is that abuse-resistant keystores are essentially forced to require something like this, even if the certificates don't ask for it, or else they're open to arbitrary certificate flooding attacks of the kind that SKS is basically collapsing under. See the discussion in the abuse-resistant-keystore draft about various comparable proposals for more details. So i'm not too worried about (at last) providing actionable followup for this long-claimed-but-unactionable flag. If anything, my bigger concern would be what happens for certificates where the user deliberately *clears* that flag, and they can't find any keystore willing to accept unattested third-party certifications anyway :) If there's a broader consensus on the list that we shouldn't explicitly associate no-modify with a 1PA3PC mechanism, then i can drop that part of the changes. But i don't know that i would bother creating a new keyserver preferences flag for it, since that would imply that all existing certificates want to be floodable. That doesn't seem like a great outcome. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXWiw/AAKCRB2GBllKa5f +AVUAP9EnbFbx8VsfLVhiPtxWIYNzDOVJ/DSN5QZJX0pASK3rwEAq52QYvAq1gOQ +K5FH78vhNsppgxS36gyw6+/rkp2xww= =NPWU -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 30 00:30:23 2019 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 4B622120CB8 for ; Fri, 30 Aug 2019 00:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 gCFEpT5zBjR6 for ; Fri, 30 Aug 2019 00:30:11 -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 0EE3D120C94 for ; Fri, 30 Aug 2019 00:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0SzmqdWRHSpvAruyRF+l+at8tEXyPLXri5fHMXwT72k=; b=hBmoFn468E/GNJBmV6Rq+1mIKZ ZDdNtmuCwKMQT3ZjpRH/wt/eREC9Pe1HqNKFKZIYXQd3dk5/StnDB4oFtmYZACph5GvdJXKRGnEix IBDEhdTl1c4B394Pfda2LYdBm853UHG1LORWGLX1FnGdTGQpzplQHFbm+sXctONhq3AE=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1i3bMH-0008Qb-Aj for ; Fri, 30 Aug 2019 09:30:09 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1i3bL0-0006Md-BG; Fri, 30 Aug 2019 09:28:50 +0200 From: Werner Koch To: Daniel Kahn Gillmor Cc: =?utf-8?Q?=C3=81ngel?= , openpgp@ietf.org References: <87tva1am9t.fsf@fifthhorseman.net> <87blw94tfg.fsf@wheatstone.g10code.de> <87h860ag31.fsf@fifthhorseman.net> <8736hjaovv.fsf@fifthhorseman.net> <1567132742.1695.16.camel@16bits.net> <87lfvb8c8z.fsf@fifthhorseman.net> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Daniel Kahn Gillmor , =?utf-8?Q?=C3=81ngel?= , openpgp@ietf.org Date: Fri, 30 Aug 2019 09:28:49 +0200 In-Reply-To: <87lfvb8c8z.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 30 Aug 2019 01:15:40 -0400") Message-ID: <87ef13xgb2.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Nigeria_S_Key_radar_IB_Pipe_bomb_Authorities_Narco_banners_Brush_fir"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 07:30:22 -0000 --=Nigeria_S_Key_radar_IB_Pipe_bomb_Authorities_Narco_banners_Brush_fir Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 30 Aug 2019 01:15, dkg@fifthhorseman.net said: > So i'm not too worried about (at last) providing actionable followup for > this long-claimed-but-unactionable flag. I fully agree. It has always been a fixme which was never done due to the lack of a protocol change with the keyservers. However, the intention has always been to not allow an upload. > If there's a broader consensus on the list that we shouldn't explicitly > associate no-modify with a 1PA3PC mechanism, then i can drop that part I can't yet decide on this because I have no clear vision on how to implement the workflow to create the new attestation. Probably they should be handled like a local signature and only exported when needed. Older versions need to be dropped to avoid cluttering the keyblock with lots of old and useless attestations. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Nigeria_S_Key_radar_IB_Pipe_bomb_Authorities_Narco_banners_Brush_fir Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXWjQMgAKCRD/gK6dHew1 jUufAQC9cWPYD1FNr00fvlq4tyuxSeHvDMKQa4wVKv61P+5wJwD+JQt65BVe5i9E ZBZUJy/e9b89WxgowNHKoktns8qgCAU= =pFEq -----END PGP SIGNATURE----- --=Nigeria_S_Key_radar_IB_Pipe_bomb_Authorities_Narco_banners_Brush_fir-- From nobody Fri Aug 30 10:48:19 2019 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 E820912095D for ; Fri, 30 Aug 2019 10:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=y6cbLwwE; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=1NIJLidi 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 lRlHWQqOVCFV for ; Fri, 30 Aug 2019 10:48:16 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB171200F6 for ; Fri, 30 Aug 2019 10:48:16 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1567187295; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=2dxmh3j867qHol4JsFIGOKkwf8UCe184B1RkYKddDuo=; b=y6cbLwwEvtOwNvvFyVWPn22dgHOJXWBvwjdTVuHk0TMYmWq4S/XAKoPj VONeBDxfc55qP1QKn8j1a73a02TsBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1567187295; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=2dxmh3j867qHol4JsFIGOKkwf8UCe184B1RkYKddDuo=; b=1NIJLididkLI8bI8k3p/NzA+YZiZERvwVEqThxDMRRDojPQ++v6Uxx3z lziS2FjOJP1ml3B+3eHgYfi3juVrAhiaA8M2AW7TybB5TCYGEb1X8lvVGr zn/L1qnUQDEJNDaogzWnr5UrRnvzORIo8ami/A5LqaIIUfoo5/PWsJhmtX M8U78E4+Td8/HHElX/5xUKJcsni9nAtYaNHH+kHfMLFZ2Z/kvwkxhyXuah NTL3BN0GvfP+VJeBgD1fG3RzYEPTglUNvsHlvMfSWbyZYDwMClyN8R3VgO qZKNc1RPNzn+yfvYkrk3zDhQMNmj35HfpNKcIurp/q83DjH0xN3/3Q== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:c41:39ff:fef3:974f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 3C354F9A6; Fri, 30 Aug 2019 13:48:14 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7B3132036F; Fri, 30 Aug 2019 13:47:58 -0400 (EDT) From: Daniel Kahn Gillmor To: Werner Koch Cc: =?utf-8?Q?=C3=81ngel?= , openpgp@ietf.org In-Reply-To: <87ef13xgb2.fsf@wheatstone.g10code.de> References: <87tva1am9t.fsf@fifthhorseman.net> <87blw94tfg.fsf@wheatstone.g10code.de> <87h860ag31.fsf@fifthhorseman.net> <8736hjaovv.fsf@fifthhorseman.net> <1567132742.1695.16.camel@16bits.net> <87lfvb8c8z.fsf@fifthhorseman.net> <87ef13xgb2.fsf@wheatstone.g10code.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 30 Aug 2019 13:47:57 -0400 Message-ID: <87imqe8rzm.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 17:48:18 -0000 --=-=-= Content-Type: text/plain On Fri 2019-08-30 09:28:49 +0200, Werner Koch wrote: > On Fri, 30 Aug 2019 01:15, dkg@fifthhorseman.net said: >> If there's a broader consensus on the list that we shouldn't explicitly >> associate no-modify with a 1PA3PC mechanism, then i can drop that part > > I can't yet decide on this because I have no clear vision on how to > implement the workflow to create the new attestation. Probably they > should be handled like a local signature and only exported when needed. > Older versions need to be dropped to avoid cluttering the keyblock with > lots of old and useless attestations. I agree that any OpenPGP keystore (local keyring, keyserver, whatever) should be able to legitimately discard all superseded Attestation Key Signatures, keeping only the most recent one. I think this is true regardless of whether we explicitly tie keyserver-prefs no-modify to this mechanism. [ Digging into the weird corner cases: there is a question about what to do when one receives an Attestation Key Signature with a Signature Creation Time that is in the future. I think it is acceptable to drop/discard these objects (perhaps with some window of allowance for possible clock skew) ] If you're generally ok with the protocol mechanism for attestations proposed here, i'd be happy to share my notes for what i think a initial interface for managing attestations with GnuPG might look like -- i can do that on https://dev.gnupg.org/, or on gnupg-devel@gnupg.org, wherever you prefer. All the best, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXWlhTgAKCRB2GBllKa5f +HxWAQDTEoi9zBIa6Pr8rHtXOKuXOmgvMiqZAjFCbiBf19JPjQD/e6Qhjniqy2rI AbW1jeQsRgCR/uKg9nH5mhZey/7NKQ0= =YiYS -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 30 17:04:13 2019 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 E31211208FB for ; Fri, 30 Aug 2019 17:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 O01zMavKDMxN for ; Fri, 30 Aug 2019 17:04:08 -0700 (PDT) Received: from mr85p00im-ztdg06011101.me.com (mr85p00im-ztdg06011101.me.com [17.58.23.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C093B1200F7 for ; Fri, 30 Aug 2019 17:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1567209848; bh=I/dENcZS+SXDCqus/ewq++QedZEArvz+grAvB78WjKM=; h=Content-Type:Subject:From:Date:Message-Id:To; b=FhjBWqmXXQrt3wl9cZhY+IHXB0dtOi4FgYYwn0YSyiJ9KnRGLEG6d/Njy+715dNHX w1Hio4LJTFS/2qPc/k7mERFE8EirvqMYQeonzaDQnCohqmQqyNJIBeMvHjZpxPwplh LL9PgLdwPvcPVq5APhMEGxQmT6y0RDZ2xhbpiW44u6sWq5IXwI8v6RPcvBEsFPMQpF 5+hSFXXwK+GLTcn9DC9Dzy7nl+mVUfaNIonzwR//3VwWSzxVjXZlCEKIkZntyxSe9u xgHUPuU3BNtAxkk6bg8HT6sQjt7FNVPBD4956Xxiww6Yn4XxhJ79ccOhXeRXuIspVo lFPTEdWVGqByg== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-ztdg06011101.me.com (Postfix) with ESMTPSA id 10E054A0981; Sat, 31 Aug 2019 00:04:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Jon Callas In-Reply-To: <87imqh9bgr.fsf@fifthhorseman.net> Date: Fri, 30 Aug 2019 17:04:07 -0700 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1AF6DE59-F071-4DA9-AF69-1C21A202D181@icloud.com> References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> <87zhju9qlb.fsf@fifthhorseman.net> <6057F53D-2251-4B92-997B-EF241C2F4EF3@icloud.com> <87imqh9bgr.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-30_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1908300237 Archived-At: Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt] X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 00:04:11 -0000 Thanks for the comments as well, and I'm really glad you're taking this = task on. It's been one of my peeves for a long time. I know you've been = dealing with it at least in part because the issues have been inflicted = upon you, too. I want to pull back and take a number of the discussion points in text = paragraphs, too. I think we're mostly in violent agreement. One way that I think about this is that the server is an actor in the = interactions, and I'd encourage a server to have opinions and policies. = We tend to look at the security actors as Alice and Bob, but the server = is also an actor and should consider both Alice and Bob as potential = adversaries. There's two broad classes of abuse that we have to deal with. I'm going = to call them syntactic abuse and semantic abuse. Syntactic abuse is = something that is often relatively easy to discuss and solve. For = example, if Alice puts a 1GB signature or revocation on Bob's key, we = can solve that easily. Discussions we have had are pretty = non-controversial and I like your suggestion about minimal revocations.=20= There are other forms of syntactic abuse that's similar -- for example, = if someone put a million certifications on a key, that would suck. The = server could guard against with a policy like stripping certifications = from a key that's not on the server. The obvious workaround for the = abuser is to upload that million keys first. I still think that a policy = (possibly per user?) of stripping certifications from keys not on that = server is not a bad idea. I can imagine others, like not allowing Alice = to submit certifications other than her own. Nonetheless, there's a lot = of potential issues here and I agree with you that some of the things we = discuss aren't sufficient, but I'll bet that a few (like syntactic = parsing and size limits) are necessary. One part of abuse protection is going to be to have a cleaner function = that will do things like take the submitted certification and return a = clean version of it. I'd include in that some hygiene functions like = stripping expired certifications (except self-sigs), and so on. Semantic abuse is different and much of that's going to be in the eye of = the beholder. I think one might argue that something like many = certifications as a form of spamming is actually semantic. Much of = that's going to be in the eye of the beholder. In many cases, the only = one who can tell us if Alice is being abusive to Bob is Bob. You gave the use case of Alice revoking her certification of Bob's key = because she believes he's suffered a key compromise. Fair enough, but = what if she thinks that for some legitimate, but eccentric reason. Oh, = let's suppose Bob says he keeps his passphrase in a password manager and = Alice is horrified, and thus wants nothing more to do with Bob's key?=20 Here's a case where I think that we're more or less in violent agreement = on "ownership." I think it's Bob's key and if he wants to delete Alice's = certification+revocation, fine. Let him, it's his key. The place where I = think we agree on concept but perhaps not on the word "own" is her = certification. Certainly, we shouldn't be seeing Alice's certification = re-appear without its revocation. Whatever term we want to use to = describe that is fine with me. As long as we are ending up with the idea = that the revocation sticks to the certification and can't be removed, = we're on the same page. You noted that we're probably going to need to have a way to tombstone a = certification. I agree. If Bob deletes Alice's certification, we don't = want it to reappear. My hand wave back in 2440 days was the flag that = says "let me manage this key, myself" which yes is a large hammer, but = it works. If Bob's key is groomed the way Bob wants it, it's not abusive = -- given that we agree that Bob owns his key. (There are people I know = who disagree with this, but let's ignore them for now.) If I were writing a server, I'd implement the tombstones with a = non-exportable signature made by a key that the server itself owns. I'd = write the tombstone details in a notation. This leaves dangling the = issue of how it gets propagated, as you noted, and I'm willing to leave = that as an exercise for the future. I'll state the problem though: Bob = deletes Alice's certification from his key; how does Charlie find that = out? Let's rewind, though and come back to Alice's revocation. Let's consider = the case where Alice really is trying to make Bob mad. Alice can even = create a certification just to revoke it with a reason that's insulting. = That's really just the certification-spamming abuse with frosting and = sprinkles, but it's still an issue. Summing up, you said: >=20 > I'm looking for concrete guidance that we can offer to operators of > keystores and clients of keystores today. >=20 > Keystore operators have traditionally not wanted to be in the role of > certificate authority, or of designated revoker (i can confirm this as = a > past and present keystore operator, but it's not just me). They're > looking for a reliable set of guidelines they can follow to ensure = that That's great, I agree completely. Key servers shouldn't (and likely = can't) be CAs. Heck, if there's anything we know from X.509 it's that = being a CA is hard. However, they can't just be a key store, if a store = is a database with a web interface that allows anyone to put something = into it. A key server has to have policy that it runs. It has to solve a number = of problems including abuse, but also including things like Bob being = able to get rid of a key that they don't control. One of the oldest = problems in the ecosystem is the new person who creates a key and then = forgets their passphrase. No one yet has done the automated abuse of = submitting keys for other people, but it's bound to happen, especially = now that I mentioned it. Key servers need to run code to be a fair = arbiter of cryptographic information. Jon From nobody Fri Aug 30 23:04:35 2019 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 619B9120091 for ; Fri, 30 Aug 2019 23:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 HxTfRPbVXwrq for ; Fri, 30 Aug 2019 23:04:30 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B19CD120059 for ; Fri, 30 Aug 2019 23:04:30 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7V64K6e012868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 31 Aug 2019 02:04:23 -0400 Date: Sat, 31 Aug 2019 01:04:19 -0500 From: Benjamin Kaduk To: Daniel Kahn Gillmor Cc: openpgp@ietf.org, Heiko Stamer Message-ID: <20190831060419.GV84368@kduck.mit.edu> References: <87tva1am9t.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87tva1am9t.fsf@fifthhorseman.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 06:04:34 -0000 On Wed, Aug 28, 2019 at 01:31:42AM -0400, Daniel Kahn Gillmor wrote: > > This new proposal (diff for RFC 4880bis attached) claims subpacket > codepoint 37 for shipping these attestations. I've also put this > proposal as a merge request here: > https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20 It looks like this is in an "IETF Review" registry; please please please consider making a request for an RFC 7120 early allocation. I know the risk is probably less of conflicting codepoint squatting in openpgp than in TLS, but in TLS we managed to have *three* different extensions squatting on the same codepoint, and it is pretty unpleasant to resolve. -Ben