Date: Thu, 22 Aug 2024 12:29:05 +0000
To: Julian Andres Klode <jak@debian.org>
From: Bart Butler <bart+ietf@pm.me>
Message-ID: 
 <EIkxLyhtm4p8rZgxBYtunyJYYoIDzRxtzHUYKB12_R_Nv8sD57HngvsdGzcSDhdXrcn3HrtEPezhdRWI2iuJYbJxfKdnVmZxc4_CfoCRDGY=@pm.me>
In-Reply-To: <sskamp4234s7zrz5fvbyysskjlivb3tyouqpp3bij2f5p4zdlq@fjqds4wzf2fr>
References: <sskamp4234s7zrz5fvbyysskjlivb3tyouqpp3bij2f5p4zdlq@fjqds4wzf2fr>
Feedback-ID: 5683226:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha512;
 boundary="------3ac30898130aeb5f2882498361d6636c753b85b6b23eeaf06d2e27eebec3cf71";
 charset=utf-8
Message-ID-Hash: MKT4LJQUDVYZFLMRG2NXBHEVZ57J3FM2
CC: openpgp@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bopenpgp=5D_Re=3A_Signatures_with_in-band_subkeys?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/openpgp/cLr_nu3jVDUxwjIzW_Nxg4ZYNO8>

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------3ac30898130aeb5f2882498361d6636c753b85b6b23eeaf06d2e27eebec3cf71
Content-Type: multipart/mixed;boundary=---------------------efaf3e07f2c36f32208e3b761b3aa02c

-----------------------efaf3e07f2c36f32208e3b761b3aa02c
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Hi Julian,

Sounds interesting, and I see why the online subkey scheme would be attrac=
tive to you.

I suspect you could also do something like this within OpenPGP out-of-the =
box.

The first and I think nicest way would be to have your trusted master offl=
ine signing key as the primary key of your certificate and generate signin=
g subkeys for use online. Your build system would have the signing subkey =
private key information but not the private key information for the primar=
y certificate signing key. =



You could ship the public-key only variant of this certificate with your s=
ignatures easily, as it's all OpenPGP packet structure, so they can just b=
e serialized together with your signature or data packets if you desire as=
 long as your tooling can pick it up (a solvable problem if it exists I th=
ink). If you want to revoke a signing subkey, you can simply ship the subk=
ey revocation with the embedded key, and OpenPGP tooling should persist th=
at revocation as long as the client sees it once. The client trusts the su=
bkeys via the binding signature from the (offline) primary signing key.

You can also pre-generate a revocation certificate for the primary key as =
a sort of break-glass emergency measure and deliver that to clients via yo=
ur key delivery mechanism as well if you ever worry that the entire chain =
has been compromised. All this you could get "for free" (read, modulo mayb=
e some tooling work) from existing OpenPGP stuff.

This kind of scheme might also be possible using a separate certificate hi=
erarchy and certifications but I think the tooling problems there could be=
 worse and I find it less elegant and more complex.

Cheers,

Bart Butler


On Tuesday, August 20th, 2024 at 12:32 PM, Julian Andres Klode <jak@debian=
.org> wrote:

> =


> =


> 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 >=3D 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
> =


> _______________________________________________
> openpgp mailing list -- openpgp@ietf.org
> To unsubscribe send an email to openpgp-leave@ietf.org
-----------------------efaf3e07f2c36f32208e3b761b3aa02c--

--------3ac30898130aeb5f2882498361d6636c753b85b6b23eeaf06d2e27eebec3cf71
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmbHLwAJkJkFRGXvMx5ERRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmdZQwboYL1q3fqu6eITbdg/6itfsPcFoPZwE4Cy
6OE/hBYhBDwVkTeBh+6myif6rJkFRGXvMx5EAAD1yAEAyL90z6RzQOWYSwJ5
tpclGHyZiUOPIOsIAR7ALG2AhWABAJfLcnLnxpd8vcFTETFhlNqDSw6v4jUe
hDHdO+8MJWgK
=Y8I+
-----END PGP SIGNATURE-----


--------3ac30898130aeb5f2882498361d6636c753b85b6b23eeaf06d2e27eebec3cf71--