IETF Logo Mail Archive

Re: [openpgp] Transporting certificates in messages [was: Re: Transport public keys inside the message body]

Bart Butler <bart+ietf@pm.me> Fri, 16 February 2024 01:52 UTC

Return-Path: <bart+ietf@pm.me>
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 64083C09C22D for <openpgp@ietfa.amsl.com>; Thu, 15 Feb 2024 17:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pm.me
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CkarGy5e-1H for <openpgp@ietfa.amsl.com>; Thu, 15 Feb 2024 17:52:16 -0800 (PST)
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03924C14CE42 for <openpgp@ietf.org>; Thu, 15 Feb 2024 17:52:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1708048333; x=1708307533; bh=yTmYqxM++tjwEfIbxfELVCp3Iu/Y9bsYb0ym88v3DTE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=SUOI2JkO8tZRR7/YXV2n4mn9oHG5KOT6cZI5P1XLs26UaKnD6AQMTeW8j4OI0wHeu 1ppWxgKk1T05rJhcqL4K0JciF+WoPcHnDqjreM25UereFqTY7itlV0U3MFU273fPKJ xD1Kps0OOKrNXf0rOWEMk3+GYXuJdY7a8PfXqZ0krr6rubDHOXOz0M2XvgAbSkxpKY zw34/DKmXkf/aeMYC/02CQuGUlu7rTgPqKakfPRt4ZedUH/zEgdHKtCABOA6QNVg7y MAQkozJk+S+wwxxeb86lLfRcoegvf4rNceG8lG3eGwFBT9BgAzE0OtV88LjlWzn176 lBn1OwTKpnd5A==
Date: Fri, 16 Feb 2024 01:51:53 +0000
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
From: Bart Butler <bart+ietf@pm.me>
Cc: Kai Engert <kaie@kuix.de>, "openpgp@ietf.org" <openpgp@ietf.org>
Message-ID: <EPzWExr7pyKD5EQbdjr-Bq1-Lv4wUBpiQx0oIquwIxwuz483fovxMcbPCqPFTmGDWlDGnCDXLV91gfdtt5lHj1Ijj_8gKdlts5pmBmVkztM=@pm.me>
In-Reply-To: <87jzn52s5z.fsf@fifthhorseman.net>
References: <33b847dd-2dfc-4741-a415-d4636642fef1@kuix.de> <87jzn52s5z.fsf@fifthhorseman.net>
Feedback-ID: 5683226:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="------23453bdc56486ba78e74f137f1afbc311953ad18be4061c19603bc57881af020"; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/62aSUiOLjHgPQItL3WvIC4LrLRY>
Subject: Re: [openpgp] Transporting certificates in messages [was: Re: Transport public keys inside the message body]
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 16 Feb 2024 01:52:20 -0000

Hi dkg,

A note on 4): one could allow data URLs with this idea as well. This would essentially reduce to Autocrypt in that limit (maybe with a some additional fields, like freshness) with the receiver MUA being able to decide whether they want to fetch remote content for keys or not, or only trust KOO, etc, and give the sender the flexibility to inline or not the key depending on size or other factors.

-Bart

On Friday, February 16th, 2024 at 1:01 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:

> 4) in an arbitrary external URL, accompanied by a fingerprint -- as
> specified, this looks to me like it violates constraints (g) and (h).
> Maybe there's a way to constrain or operationalize it further so that
> it passes one or both of those constraints?
>

v2.46.0 | Report a Bug | By Email | System Status