During the Dublin camp, we discussed the way in which our gpg key is used and talked about various scenarios where it's less than ideal. It's not currently easy to change the key or revoke the key. It's also difficult to securely pass the key from person to person (a different angle on the revocation problem). To mitigate against this, we came up with a few ideas that should improve on all areas of our key handling PKI.
The first idea is that we'll distribute the public portions of our keys and and revocation certificates as a package. We can use scripts or CAS to automatically merge new keys, revoke old ones, etc. Additionally, we'll do all of this in a private gpg directory so that any non-csw use of gpg at the user sites will not be impacted by our keys. A proof of concept for this is already implemented and available in the experimental catalog
The second stage of the plan is to completely recreate our handling of keys and certificates. While the details are still preliminary, we're bascially going to create a certificate authority (CA) for OpenCSW and issue sub-certificates from it. We can transition from one key to another with revocation certs (CRL) and signing new keys with old. The proposed implementation is thus:
- A root CA and associated CRL.
- A Role CA (signed by the root CA) and associated CRL.
- A People CA (signed by the root CA) and associated CRL.
- A per-person release manager certificate signed by the Role CA. Each release manager will then have a unique cert.
- A per-maintainer cerficiate signed by the People CA. A release manager would have a separate key for use as a maintainer and as a release manager.
Everything will be based on OpenSSL certificates until the actual certs that people use. These will be converted from X.509 to gpg format for everyday use.
If possible, we would like to have our Root CA signed by a third party CA. GoDaddy offers certificates for open source projects so we may be able to get our key signed that way.