============================================================================
       Open Certification Authority - Open Source Project
        (c) 1999 by Massimiliano Pala and OpenCA Group
                      All Rights Reserved
============================================================================


1. General Structure Overview
=============================

As the structure is thought layered, it's not so simple to understand the
role of every Server.

A simple overview can be this:

       _______                                 _______
      |       |  (a)                          |       |
      |   1   |========||                     |   2   |
      |_______| __                            |_______|
       /  |       \
      /   |   ...  \  (b)
     /    |         \
   _/_   ___        _\_
  |   | |   | ...  |   | 
  | 1'| | 2'| ...  | N'|
  |___| |___|      |___|

 
Legend:
	(1) Registration Authority Server;
	(2) Certifiction Authority (Stand Alone Computer);

	(a) Connection to the Internet;
	(b) Connection Client/Server (RAs/RA Server (1));

	(1',2', ... ,N') Registration Authorities (RAs)


2. The Servers
==============

Here it is how it works. The CA (2) Computer is the most important:
on it it is istalled the ca software and the CA SECRET KEY. Because
of it's security needs, we think it must be left disconnected by any
network (this is the only way to protect a computer from network
attacks(!!!)) and file tranfers (Requests/Certificates/CRLs/etc...)
with other computers get executed via removable support
( i.e. floppy/rw/etc...).

The RA Server is a bit more complicated. It has a secure (with client
auth turned on) apache server installed. Services offered only to RAs
permit to approve/reject requests BEFORE they get signed by the CA.
On the RA Server there is also an LDAP server (for certificates
availability).

There is another Web server (Secure Server) that is used by the normal
users to make certificate requests, import CA Certificate, import requested
certificates and import other users' certs. You can activate this server
on the same machine of the RA Server: this can save a litte work and is the
currently adopted choice. 


3. What are those RAs ?
=======================

An RA is a coputer connected to the Network with a Netscape installed:
to correctly communicate with the RAServer, you also need a certificate
in the .p12 format.

RAs have the task to verify the identity of the subject in the Cert
Request (by examinating ID card when the subject comes to RAs for
identifying himself) and get them ready for export to the CA (by
removable support... ). All communications betweens RAs and RA
Server are set trought Secure Web Session (Apache+mod_ssl)(b). You
can have as many RAs as you want, just issue the needed RAs certs
for the RA operators: one CA can serve, in this way a wide local
area. (NOTE that (b) connections can be made over the internet).
(NOTE2: racertificates are issued through scrips in the bin/ dir
reqcert.bin and racert.bin => generated certs are in .p12 format
and can be imported directly into the RA's Netscape).

4. Why this structure ?
=======================

This is because we needed a CA structure that is able to issue certs
surely asserting that the subject is the one who declares himself to
be and that should have less security risks as possible.


5. How does it works ?
======================

When a user request a certificate, he connects with Netscape to the
Secure Server (Web with no client authentication for simple users) and
sends the request that is stored on the server. Then the user have
to identify himself to one of the RAs across the region (the one
he likes best) and that RA will process the Request getting it ready
for Signing by the CA (connecting to the RA Server with Netscape).

Now an operator exports on a removable support the requests, goes
to the CA ( use this computer only to do CA functions, it must
be ULTRA-SECURED, so it's not a bad idea to keep it in a access-
logged room) imports on it the requests and uses the developed
tools (again a simple apache server (local) and Netscape are
the interfaces while Perl programs and OpenSSL do the hard work)
to issue/revoke certs, issue CRLs, and so on... Done all the
issuing operations, he than export the issued certs on the
removable media and (after havnig shut the CA down...) goes
to the RA Server.

Now the RA Server imports the new certificates from the removable
media and put them on LDAP, ecc...

============================================================================
       Title: OpenCA Structure		Refer to: www.openca.org
      Author: Massimiliano Pala		e-mail: madwolf@openca.org
     Version: 0.2.1

 Last Modify: 21 Aug 1999		OpenCA Project Documentation
============================================================================
