Hello there, I have read a little on this discussion and feel like sharing my thoughts. I think the current lacking procedures are number 3 and 4 from my summarization based on the current standards adopted for PKI: 1) Chain of trust from developer, [intermediaries,] to root CA. 2) Ensure multiple signing of packages at the above layers (intermediaries, root).
|__This allows for a buffer for key revocation whether by user choice or the other party holding the authority (intermediaries, root). 3) Use 'password enabled key store' to prevent unauthorized access to digital keys. 4) Use 'password enabled signing' to prevent unauthorized usage of digital keys. The use of number 3 and 4 are the steps for developers to upload application packages as part of the verification process by Google for the 'Play store' used in Android OS devices. I am not sure about the others like Apple, Windows, Amazon etc, but they all probably have the same process. Nothing new is being invented here and none being reinvented to complicate matters. The existing security framework is quite simple yet sophisticated which is probably good. Cheers, Simon khng On Tue, Feb 6, 2024 at 1:12 AM Stephan Verbücheln <verbuech...@posteo.de> wrote: > Your work is valuable. Many of the things have probably evolved over > time and could use some analysis based on modern cryptography and > security practices. I just wanted to point out that there are subtle > but important differences outside of the key and signature formats. > > The most important distinction is probably the one of personal keys on > the one hand which purpose is to identify a developer and the Release > keys which are stored on some build servers to create Release files. > > You cannot only have PGP keys signing each other (like CAs and leaf > certificates in X.509 PKI). PGP has subkeys and they could be used in > the release process to mitigate risks. > > Example: > 1. Debian creates a PGP key for releases. > 2. The public key is installed in Debian to verify releases. > 3. The release team creates subkeys for signing. > 4. The main private key is stored in a restricted place. > 5. The build server only uses the subkeys to sign releases. > > The subkeys could be expired and rotated all the time without changing > the PGP fingerprint and therefore without changing the trusted key ring > in the Debian installations. I do not know whether Debian actually > makes use of this, or it has been discussed before. > > Regards > Stephan >
