When we refer to the ASF CA we're actually talking more about a process than a single server or application. This document is intended to provide an overview of that process and explain how all the pieces fit together. It should also eventually detail who is responsible for the various elements, but to date that hasn't been decided.
Elements
The certification process involves two basic elements:
- Registration Authority - this "entity" is responsible for controlling who may have a certiifcate and who can control the group membership.
- Certificate Authority - the actual server that issues and manages the certificates. Users have no direct interaction with this service.
Registration Authority
The Registration Authority (RA) is the group who decide whether your request is valid. They are the group that you communicate with.
The ASF RA has not yet been decided, but will likely involve a small number of people to spread the workload. Exactly how they will check validity has also net yet been decided, though several options have been discussed.
Each PMC will be asked to control their own group membership, so some of the RA function will actually be delegated. PMCs will NOT be able to authorise certificates to be issued, but will be able to modify permissions contained within them.
Certificate Authority
The Certificate Authority (CA) is basically a server that processes the requests it is sent. It will reject any request that does not arrive signed by an approved PGP key. The only interaction a user will have with this server is when it emails them a certificate.
The operation of these two bodies is described in the Certification Practice Statement.
Output
When the entire process has been completed the person who requested a certificate will be sent an X509 v3 certificate. This is a simple text file and by itself isn't very useful. To use the certificate it must be combined with the private portion of the key pair that was used to create the request, so sending it via unencrypted email isn't a security problem.