Re: [openpgp] Embedded TPK subpacket

Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> Mon, 25 March 2019 09:46 UTC

Return-Path: <marcus.brinkmann@ruhr-uni-bochum.de>
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 4B3B5120381 for <openpgp@ietfa.amsl.com>; Mon, 25 Mar 2019 02:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.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 6a42Olj0GMZ0 for <openpgp@ietfa.amsl.com>; Mon, 25 Mar 2019 02:46:17 -0700 (PDT)
Received: from out1.mail.ruhr-uni-bochum.de (out1.mail.ruhr-uni-bochum.de [134.147.53.149]) (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 EC8E612014F for <openpgp@ietf.org>; Mon, 25 Mar 2019 02:46:16 -0700 (PDT)
Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out1.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 44STtH0C3lz4wBm for <openpgp@ietf.org>; Mon, 25 Mar 2019 10:46:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1553507191; bh=+Q0VsafAVOHav9AVzZCzr/WTzTEAoRbdOy6Ln/G0WGk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=vrL8YG7YEx3GzjJ2gRVKJ2i+C6c8w7Bso/UP6LhnL6vDQif/iocgXti0rHFkspNk2 zZ77d0c783ku6WlLnNq0qrfSHVJhSwkMh8wfr6zqwwrLJLmFcw3pj33f6IZM5w7/Tq St43n4YrFzSogI62GRpgvPw3iyFIZyI0KdBO29qA=
Received: from out1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 44STtG6Fqqz4vyd for <openpgp@ietf.org>; Mon, 25 Mar 2019 10:46:30 +0100 (CET)
X-Envelope-Sender: <marcus.brinkmann@ruhr-uni-bochum.de>
X-RUB-Notes: Internal origin=134.147.42.227
Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out1.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 44STtG5q6Pz4wBm for <openpgp@ietf.org>; Mon, 25 Mar 2019 10:46:30 +0100 (CET)
Received: from [192.168.142.139] (p4FE3F5A1.dip0.t-ipconnect.de [79.227.245.161]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 44STsw61cXzyqp for <openpgp@ietf.org>; Mon, 25 Mar 2019 10:46:12 +0100 (CET)
To: openpgp@ietf.org
References: <87ef6v71jm.fsf@europa.jade-hamburg.de>
From: Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de>
Openpgp: preference=signencrypt
Message-ID: <1e6052ec-36ba-d14d-5028-b4aac973a494@ruhr-uni-bochum.de>
Date: Mon, 25 Mar 2019 10:46:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <87ef6v71jm.fsf@europa.jade-hamburg.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/wTuRsJMJXrFnwnonH3RyBUUVE_E>
Subject: Re: [openpgp] Embedded TPK subpacket
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: Mon, 25 Mar 2019 09:46:20 -0000

Note: I am assuming TPK means transferable public key.  Some issues that
spring to mind and that you may want to consider in your proposal:

This is a bit awkward if you only want to do encryption (there is no
subpacket then).  Some think one should always encrypt and sign, but the
issue at least needs to be raised and considered.

Can you clarify what keys are allowed as embedded TPKs?  Just the
signing key for that signature, or arbitrary keys?  If the latter (for
example to allow more use cases such as key rollover), then the new
subpacket would be the first subpacket not to have any relationship to
the signature it is contained in, which would be awkward. It would also
potentially allow interesting attack vectors (injecting arbitrary
keyring data).  If only some keys are allowed, it needs to be specified
which and how they are verified.

Also, as you said, there are already some ways to transfer public keys
in email as attachment or header.  Some email readers already look in
these places and have a GUI to import these keys.  You say your proposal
requires no cooperation by the MUAs, but this seems to rely on very
narrow trust models not requiring any user interaction.  Maybe you can
expand on that topic a bit?  Are the existing mechanisms obsoleted by
it, or is it an alternative?  If the latter, can your proposal be
extended to cover existing use cases?

The embedded key can contain signatures, and these signatures can again
have embedded keys.  This would allow for arbitrary recursion, which
from experience makes for interesting bugs.  Maybe you can add some
considerations for that to your proposal?

Thanks,
Marcus

On 3/25/19 10:20 AM, Justus Winter wrote:
> Hello,
> 
> I'd like to propose a new signature subpacket that contains a TPK,
> let's call it the Embedded TPK subpacket.
> 
> I see two immediate use cases:
> 
>   - If a designated revoker creates a revocation signature, she can
>     embed her TPK in the signature, so that it is easy to verify the
>     revocation without having to hunt for her TPK.
> 
>   - Some MUAs attach TPKs to emails, pEp does so too, and Autocrypt
>     includes TPKs in mail headers.  Instead of doing that, one could
>     then transmit ones TPK (and those of others in the conversation)
>     in-band.  This has the advantage of requiring no cooperation of
>     the MUAs, and the PGP implementations can gather the TPKs when
>     parsing the signatures.
> 
> 
> Thanks,
> Justus
> 
> 
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp
> 

-- 
Dipl.-Math. Marcus Brinkmann

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
Universitätsstr. 150, Geb. ID 2/461
D-44780 Bochum

Telefon: +49 (0) 234 / 32-25030
http://www.nds.rub.de/chair/people/mbrinkmann