BaDCA ===== BaDCA is a certificate Authority that provides the usual certificate management functions, but uses PGP as it's authentication mechanism. Using PGP in this way provides us with verification of both creator of the message and the message contents through the use of a digital signature. BaDCA is designed to be run as a daemon, though it runs as an "isolated" service as shown below. Each instance of the daemon can process requests for one "Certificate Authority" and any number of "sub Certificate Authorities". The distinction between CA and subCA is largely due to their position within the heirachy rather than the operations they perform. Objects ------- Certificate - Certifcates can be either those used by a CA/subCA or user certificates. CA/subCA certificates have a key and CRL associated with them. User certificates have a CSR associated with them. Key - Private keys generated as the basis of x509 certificates. CA/SubCA - This is the main object and a number of these will exist in a functioning instance of BaDCA. Every instance will have exactly 1 top level CA object that represents the Root Authority for that CA. This top level CA NEVER signs user certificates, but instead signs CSR's from subCA's. An instance of BaDCA should contain at least 1 subCA, but there is no upper limit. Each subCA is used to issue certificates to users. It also manages all certificates it has issued. Keyring - Every CA/subCA determines the validity of requests it receives by checking a PGP signature. Every CA/subCA has a single keyring associated with it. The key used to create the signature MUST be present in the keyring for a request to be processed. Keyrings may be stored on disk or generated at startup (yet to be decided). Request - Every request to BaDCA is stored as an XML file. This file is stored as a hashed filename and used to allow replay of the actions. CSR's contained with the request are extracted and stored seperately. Stored requests are signed by the certificate of the CA/subCA that they were intended for. This allows requests to be trusted after their receipt. Commands -------- The following commands are valid for requests to BaDCA request - process the attached CSR addkey - add the supplied key to the keyring for the CA/subCA removekey - remove the supplied key from the keyring revoke - revoke all keys for the supplied email(s) producecrl - generate a crl This list isn't meant to be definitive. Heirachy -------- Simple Example - BaDCA is configured with a Root Certificate called 'TestRoot' and a single subCA called 'TestIssuer'. ------------ --------------- | TestRoot | | Test Issuer | ------------ --------------- Files - private key - private key - csr - csr - certificate - certificate - crl - crl - rec'd csrs - rec'd csrs - TestIssuer - bloggs@apache.org - jsmith@apache.org - issued certs - issued certs - TestIssuer - bloggs@apache.org - jsmith@apache.org As can be seen there is very little difference in the generated and stored files between a CA and a subCA. Object Functionality -------------------- Private Key - generate - compare - write to disk - read from disk Certificate - create from private key + CSR - read from disk - write to disk - compare CA/subCA - generate a private key - create a CSR from a private key using information contained in it's configuration - create a valid root certificate from a generated CSR - generate future certificates as required - issue certificate from given a user CSR - revoke user certificate as required - send emails - to RA - to users - create a valid crl when required Keyrings - add fingerprint - remove fingerprint - read from disk - write to disk - check fingerprint is contained