Re: [openpgp] Version 1 image header bits that MUST be 0

Derek Atkins <derek@ihtfp.com> Mon, 29 May 2023 13:12 UTC

Return-Path: <derek@ihtfp.com>
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 EE50AC151544 for <openpgp@ietfa.amsl.com>; Mon, 29 May 2023 06:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com
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 5FAZPwUWpL0N for <openpgp@ietfa.amsl.com>; Mon, 29 May 2023 06:12:55 -0700 (PDT)
Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) (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 E281BC1516E3 for <openpgp@ietf.org>; Mon, 29 May 2023 06:12:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.ihtfp.org (Postfix) with ESMTP id E80B6806C243; Mon, 29 May 2023 09:12:51 -0400 (EDT)
Received: from mail.ihtfp.org ([127.0.0.1]) by localhost (mail.ihtfp.org [127.0.0.1]) (maiad, port 10024) with LMTP id 2481487-10; Mon, 29 May 2023 09:12:51 -0400 (EDT)
Received: by mail.ihtfp.org (Postfix, from userid 48) id CEC9A806C248; Mon, 29 May 2023 09:12:51 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ihtfp.org CEC9A806C248
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1685365971; bh=DSVzGYjpTj6XcT8D3xY40hIV60ofDO8VoeyQHIQbllc=; h=In-Reply-To:References:Date:Subject:From:To:Cc:From; b=ljNuNFppMcgUnfoQvWwzfu4XJuZkiKDoRmc/OH6pEpzVM1gpBy3T6vWdkhqOc9Glo w6BLFdA6vnm935YeqA/TMu4OlhMKQWdOt/4vqAX9U8V2qFh8wwOkr2GiOWKYm0EkXj 7ZtUx+WrL6wGurycYWA9zsOGbrWe26ZbyBjnnTL8=
Received: from 192.168.248.239 (SquirrelMail authenticated user warlord) by mail.ihtfp.org with HTTP; Mon, 29 May 2023 09:12:51 -0400
Message-ID: <1a0385074512290ef8fc902acd070d2c.squirrel@mail.ihtfp.org>
In-Reply-To: <6D291C82-0F6F-4905-88DF-60A49674C76B@andrewg.com>
References: <8211a864-3ce5-bb60-2aa8-6e73e82213ef@nohats.ca> <87lehy95ba.fsf@fifthhorseman.net> <6D291C82-0F6F-4905-88DF-60A49674C76B@andrewg.com>
Date: Mon, 29 May 2023 09:12:51 -0400
From: Derek Atkins <derek@ihtfp.com>
To: Andrew Gallagher <andrewg=40andrewg.com@dmarc.ietf.org>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Paul Wouters <paul@nohats.ca>, "openpgp@ietf.org" <openpgp@ietf.org>
User-Agent: SquirrelMail/1.4.23 [SVN]-6.fc34.20190710
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/dUZq_kvFYnNxnZs_503vQp28-qc>
Subject: Re: [openpgp] Version 1 image header bits that MUST be 0
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: Mon, 29 May 2023 13:12:59 -0000


On Mon, May 29, 2023 5:06 am, Andrew Gallagher wrote:
> On 8 May 2023, at 17:05, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
> wrote:
>>
>> As an alternate approach, i expect it would be more straightforward to
>> deprecate these bits (and much of this flexibility) entirely.  The root
>> of the issue is that there is too much unused extensibility here.  A
>> simplifying approach might be:
>>
>> - drop the Image Attribute Version registry
>>
>> - drop the Image Attribute Encoding Format registry
>
> - drop Image Attribute types
>
> - deprecate User Attribute packets
>
> I see no concrete use for them other than to bloat keys, frustrate
> distribution, and abuse keyservers for anonymous file sharing. Anything
> else can be achieved in a more straightforward manner by signing a
> document.

Please do not remove these Attribute packets.

We use these attributes for device keys in embedded devices, in order to
put device attributes into the key/cert for authentication purposes, to
provide authenticated metadata about the device integrated into the
device's certificate.

To get the same level of binding in a separate document, you need,
effectively, to replicate much of the data that's already in the
certificate to ensure it cannot be replaced.  Also, in this case, we want
the data signed by the device's manufacturer, so now they have to sign
multiple data and install multiple files, instead of just installing the
cert.

> A

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant