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
- [openpgp] Embedded TPK subpacket Justus Winter
- Re: [openpgp] Embedded TPK subpacket Marcus Brinkmann
- Re: [openpgp] Embedded TPK subpacket Justus Winter
- Re: [openpgp] Embedded TPK subpacket Vincent Breitmoser
- Re: [openpgp] Embedded TPK subpacket Marcus Brinkmann
- Re: [openpgp] Embedded TPK subpacket Neal H. Walfield
- Re: [openpgp] Embedded TPK subpacket Justus Winter
- Re: [openpgp] Embedded TPK subpacket Vincent Breitmoser