[openpgp] Signatures with in-band subkeys

Julian Andres Klode <jak@debian.org> Tue, 20 August 2024 10:32 UTC

Return-Path: <julian.klode@gmail.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 7CEA7C14F713 for <openpgp@ietfa.amsl.com>; Tue, 20 Aug 2024 03:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.754
X-Spam-Level:
X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 n7Tkj9G21C4S for <openpgp@ietfa.amsl.com>; Tue, 20 Aug 2024 03:32:21 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678A8C151531 for <openpgp@ietf.org>; Tue, 20 Aug 2024 03:32:21 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5bef295a429so2730783a12.2 for <openpgp@ietf.org>; Tue, 20 Aug 2024 03:32:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724149939; x=1724754739; darn=ietf.org; h=content-disposition:mime-version:accept-language:message-id:subject :to:from:date:sender:from:to:cc:subject:date:message-id:reply-to; bh=ibnDj0b99JJpu7sGjGgYeL/3yECo0JicYZw3Lvu7KJs=; b=LjLM60wp2XLbtsX3WQdUR+Y8L3Pp0z2+gfXvZ+BlYynMVaLN0xolKwx0gH24sH6iPM EJxM0LKzVCBpKLXlne7S11LJgjvIbUH0Ypip+e7olUxm1qprAIFuShdy+nxOq3xXfEOz T5FjPf9+Wq2KUk0MLCk9AiImaH+hvIwz3/ifg23McypPjFjWSSMpW0DZPH3z2nHsOkRr MaPqyMlhfQkqG4LFmW6rneUgQ5koY84LBYV3OUJVEwncph8H8EDwqNxdBWrNliiHxwLE yyxJeSktHYnKPFZcaX3DWFQqmYMvtkM2frWhsRfRn7Uu3aHwlAF8+S2Kt1XlPkgAKGZV hRSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724149939; x=1724754739; h=content-disposition:mime-version:accept-language:message-id:subject :to:from:date:sender:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ibnDj0b99JJpu7sGjGgYeL/3yECo0JicYZw3Lvu7KJs=; b=kPJlO7agBgSLrT5ir04hZ7xyiv0Ve7Wb/e5mLS4f/JYwyTob/ZlsE+Dgoyfenw0ePt nrVQMABUhy+MQ9qfAlCARBnDfy3IzML0CkTg3bp9mg6phHAtGttWV56+Q/vBnjkq+Y47 mRGqyLfFehg8MsPw3NCfbUZK1bCprz5zD4oXDk3BC9oTmdA4KFnNDHTAdDdzD0OTntdg xr/xp3iG1gnHnQvADJfpcrQrCyDlk7Jilk3wyyysgrRpm9baIfbeNAZQyCIJsoIqCiDH fNbHusc/63rmLH2KKppjvwxhPRt7Ur8bxrFL2F+Fij37q4jb2Bv0216eNTd4oh/ilIuW hScw==
X-Gm-Message-State: AOJu0YwkE99zyXvnard0bWS4FE5ZoElgGmNqsbWWaTwFAruxafAzYBd6 QAidlroZJijQywRQrVanBYNSIG46WC2gSrHcP1abxep/lAqAo8Z0aIGUsQ==
X-Google-Smtp-Source: AGHT+IGG/758dgMPcjWO+lJoY0Hb4E4hNDA1OsDI0DwueDBHIBDVhjQ2G1gvzKcN+xHiT3A6DbTwCQ==
X-Received: by 2002:a05:6402:34c7:b0:5a1:369b:bb61 with SMTP id 4fb4d7f45d1cf-5bf0d2cf10cmr1325282a12.36.1724149938965; Tue, 20 Aug 2024 03:32:18 -0700 (PDT)
Received: from jak-t14-g3 ([2a02:908:2812:7d20::941a]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5beded0cce8sm3901984a12.17.2024.08.20.03.32.18 for <openpgp@ietf.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Aug 2024 03:32:18 -0700 (PDT)
Sender: Julian Andres Klode <julian.klode@gmail.com>
Date: Tue, 20 Aug 2024 12:32:16 +0200
From: Julian Andres Klode <jak@debian.org>
To: openpgp@ietf.org
Message-ID: <sskamp4234s7zrz5fvbyysskjlivb3tyouqpp3bij2f5p4zdlq@fjqds4wzf2fr>
Accept-Language: de-DE, de, en-GB, en-US, en
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Message-ID-Hash: VHURT5APLNK7EUHRQQTWXYWRT4EXZT3Y
X-Message-ID-Hash: VHURT5APLNK7EUHRQQTWXYWRT4EXZT3Y
X-MailFrom: julian.klode@gmail.com
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.9rc4
Precedence: list
Subject: [openpgp] Signatures with in-band subkeys
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/1DvNnIuWCX0WcY4b_phsJk-jAA0>
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 OpenPGP folks!

as some of you know I maintain APT, the Debian/Ubuntu package
manager.

One topic of concern for package management is the ability to
have online signing keys and an offline primary key that they
are chained too, as you want your repositories to work automatically.

I've been drafting a new signing scheme for APT repositories
a couple years back that hasn't been implemented, so far at
least, we are still using OpenPGP.

Now one of the ideas there is that instead of having to know
the online subkey a-priori, we instead ship the online subkey
alongside the signature.

In case your online subkey gets compromised you can just create
a new subkey and sign your data with that and the client trusts
it.

I also added a generation number: We only trust a new subkey
if its generation is higher. This means that once a client
sees a signature from a new in-band subkey, it won't ever
trust a previous in-band subkey again.

You can have multiple subkeys with the same generation on
a technical level, which is why I did not call it a serial
number.

This works reasonably well for the native apt-sign scheme:

1. We read the previous signed metadata and get a list of 
   (primary key id, generation)
2. We read the new signed metadata and check that the subkeys
   in there are >= the generation in the old one

Alternative means are to keep the mapping in a global state file.

I'm curious to hear if this is something of interest to the
OpenPGP community.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en