[openpgp] Signing-only primary keys

Wiktor Kwapisiewicz <wiktor@metacode.biz> Wed, 23 April 2025 10:04 UTC

Return-Path: <wiktor@metacode.biz>
X-Original-To: openpgp@mail2.ietf.org
Delivered-To: openpgp@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5FFA41FE553E for <openpgp@mail2.ietf.org>; Wed, 23 Apr 2025 03:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=metacode.biz
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwTq6SRbkoKE for <openpgp@mail2.ietf.org>; Wed, 23 Apr 2025 03:04:38 -0700 (PDT)
Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com [IPv6:2001:41d0:203:375::b5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 54B2E1FE5539 for <openpgp@ietf.org>; Wed, 23 Apr 2025 03:04:38 -0700 (PDT)
Message-ID: <7d94d70b-fd18-4a0f-b656-d2936aa09578@metacode.biz>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=key1; t=1745402676; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=W3V+NdKno4q8v0dwsATsybV0AJTIErXpq01VebPJctg=; b=ScZjEzlVD6MVAQK2jchzqlC5cgz2FvQ4joFSy9aqATRquAk+dgtsIIibzLlepJhOpAxh7M ASJQxD5KGUNq29c7eLtkOzYbV4cVHtb3yyrMNw/JIWvqq8J6D+1BiZLBVweKZglbuJamiF xUxWKzaYXEBTKD0GoNEn2QE4KjYmoSw=
Date: Wed, 23 Apr 2025 12:04:29 +0200
MIME-Version: 1.0
Content-Language: en-US, pl-PL
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Wiktor Kwapisiewicz <wiktor@metacode.biz>
Organization: Metacode
To: "openpgp@ietf.org" <openpgp@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Migadu-Flow: FLOW_OUT
Message-ID-Hash: VIXZH4PCK37UMOL2UP5JWZWZUVIXCCBJ
X-Message-ID-Hash: VIXZH4PCK37UMOL2UP5JWZWZUVIXCCBJ
X-MailFrom: wiktor@metacode.biz
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-openpgp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [openpgp] Signing-only primary keys
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/RD0CORpKEdLM9R4f92s802O3KjI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>

Hi folks,

I've got a question about using signing-only primary keys.

In our project we're creating certificates that will be used only for 
signing artifacts (for example packages). They are not meant to issue 
third-party certifications and I thought that, following the principle 
of least privilege, it would be good to drop the Certification flag from 
the primary key altogether and leave only the Signing key flag.

Our initial tests seem to indicate that signing-only-primary-key 
certificates don't cause any problems (tested implementations: gpg, 
rsop, sqop). Inspecting the certificate in GnuPG revealed that it adds 
the "C" flag anyway :)

I didn't see any further tests at https://tests.sequoia-pgp.org/ but 
maybe I overlooked it.

I've browsed https://www.rfc-editor.org/rfc/rfc9580#name-key-flags and 
https://www.rfc-editor.org/rfc/rfc4880#section-5.2.3.21 and the key flag 
0x01 is clearly marked as concerning "other keys" which we don't want in 
this use-case.

Is my reasoning valid that dropping the "C" key flag is okay or is 
anyone aware of practical issues with it?

Thanks for your time!

Kind regards,
Wiktor

P.S. The MR dropping the flag is at 
https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/206