Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key <distribution-key@intevation.de>"

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 08 August 2019 13:02 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 54AEC1200C3 for <openpgp@ietfa.amsl.com>; 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 <openpgp@ietfa.amsl.com>; 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 <openpgp@ietf.org>; 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 <dkg@fifthhorseman.net>
To: Thomas Arendsen Hein <thomas@intevation.de>, Bernhard Reiter <bernhard@intevation.de>
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: <https://mailarchive.ietf.org/arch/msg/openpgp/Udps3Q60YajU1kAEucX3MZGbJxc>
Subject: Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key <distribution-key@intevation.de>"
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, 08 Aug 2019 13:02:26 -0000

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 

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 <bernhard@intevation.de> [20190807 09:53]:
>> Getting other active pubkeys or old pubkeys can be handled by the public 
>> 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