(links with further content at the end) Hi ftp, security, and release teams, as far as I am aware each of you is currently maintaining some sort of OpenPGP signing key for apt repositories. As part of my apt-sign work, I'd like to gather some knowledge as to what are the needs for signing keys and whether the my current approach works or falls short. apt-sign is a bit of an on/off project, the latest v0.4 protocol from today adds some improvements and I started writing some C++ data structures. To give a high-level overview: apt-sign is a replacement for OpenPGP to sign deb822 files in a minimal way. I am currently implementing the apt-ed25519 algorithm a bit, when I get some time, but I have also reserved apt-ed448 and apt-p256 algorithms. In apt-sign, we differentiate between an offline key/primary key/CA and an online key/sub key/signing key. # shipping keys The offline key is shipped to users out-of-band, like the current debian-archive-keyring, in a file like: apt-ed25519 UYu0opBtAM8ggtsZ+OWPZVfWipY+6o1TaKQZV1iLkoPIaeOZ24lFNQ== apt-ed25519 mn6YGgMjBcPPKgUAKmWSVj3C/qyGl4QtEUFLeGV1Sgzs9ogpLziEcw== # comment The offline key only has a key ID (random 8 bytes) and the raw public key (random 32 bytes for ed25519). There are generally no names, but you can add comments. Meanwhile, whereas GPG ships subkey packets in the keyring, apt-sign ships them in the signature. Each subkey has - a signature from the offline key - the raw 32-bit public key material - a time64_t expiry - a uint64_t generation number # key rotation events Our goal here is clear: We do not have a mechanism in Debian to revoke keys out of band, by shipping the online keys in the signature packet, we can at least *rotate* them in-band: For each repository, if the new Release file is signed by an older generation of key for a given primary key than the old Release file, that signature and the repository is rejected. ## out-of-band revocation events Separately, it's easy to see how we can define an out-of-band mechanism by delivering a file with a trusted key that defines minimum generations for each primary key. The out-of-band rotation cannot revoke individual subkeys only, it will revoke all subkeys with a lower-generation for the given primary key. That distinction is important because it means you want to rotate all online keys whenever one of them is compromised and you want to revoke them out-of-band as opposed to in-band (where we do not check across repositories). Given that the new subkey will be delivered with the new signature, there is no harm done though, rotating all the keys should be fairly easy. # hardware keys We can easily support PKCS#11 modules for apt's native C++ signing process. dak could use a Python implementation with PKCS#11, OpenPGP smart card, or direct YubiKey implementation (either one would need to be written). APT's implementation can also likely store the signing key TPM-encrypted using systemd-creds. The first step would be straightforward unencrypted private keys, though. # questions - Would we want one offline key per team? - Would we want to rotate the offline key as well or just the online keys (coming from an Ubuntu perspective, the offline key replaces the master key which is never rotated in Ubuntu, and not the primary key of the GPG key) - Do we store offline keys in HSMS/smart cards or do we like want to invent a scheme to encrypt them some way else (maybe just gpg and sharding an unencrypted file?) - Do you have any questions? # further information The specification: https://wiki.debian.org/Teams/Apt/Spec/AptSign The reference implementation WIP (mostly data structure skeleton right now): https://salsa.debian.org/jak/apt/-/compare/main...pu%2Fapt-sign?from_project_id=228&straight=false The legacy reference implementation (of the 0.2 version): https://salsa.debian.org/apt-team/python-aptsign/ -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Attachment:
signature.asc
Description: PGP signature