[openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt]
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 22 August 2019 22:03 UTC
Return-Path: <dkg@fifthhorseman.net>
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 <openpgp@ietfa.amsl.com>; 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 <openpgp@ietfa.amsl.com>; 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 <openpgp@ietf.org>; 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 <openpgp@ietf.org>; 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 <dkg@fifthhorseman.net>
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: <https://mailarchive.ietf.org/arch/msg/openpgp/MwDLqyGqooy_K2SEvXFvP6o6w4c>
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." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2019 22:03:32 -0000
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
- [openpgp] [internet-drafts@ietf.org] New Version … Daniel Kahn Gillmor
- [openpgp] Revocations of third-party certificatio… Daniel Kahn Gillmor
- Re: [openpgp] Revocations of third-party certific… vedaal
- Re: [openpgp] Revocations of third-party certific… Daniel Kahn Gillmor
- Re: [openpgp] Revocations of third-party certific… Benjamin Kaduk
- Re: [openpgp] Revocations of third-party certific… Daniel Kahn Gillmor
- Re: [openpgp] Revocations of third-party certific… Jon Callas
- Re: [openpgp] Revocations of third-party certific… Daniel Kahn Gillmor
- Re: [openpgp] Revocations of third-party certific… Jon Callas
- Re: [openpgp] Revocations of third-party certific… Daniel Kahn Gillmor
- Re: [openpgp] Revocations of third-party certific… Peter Gutmann
- Re: [openpgp] Revocations of third-party certific… Benjamin Kaduk
- Re: [openpgp] Revocations of third-party certific… Jon Callas