impl-openca.htm

The Open–source PKI Book Version 2.4.6 Edition Copyright &copy 1999, 2000 by Symeon (Simos) Xenite

	    as it is sometimes called, the Root CA Certificate.
	    Copies of this Certificate should be given to the public.</P
></LI
></UL
>
	</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="CA-REQUESTS"
>Requests</A
></H3
><P
>	<P
></P
><UL
><LI
><P
>Import requests</P
><P
>This imports requests (CSRs) for signing to the CA.
	    The RAServer Administrator has used the <I
CLASS="EMPHASIS"
>Export requests
	    </I
> command to export the Certificate Signing Requests to, possibly, a removable
	    medium. With this command, the CAServer Administrator will 
	    retrieve them for signing.
	    </P
></LI
><LI
><P
>Pending requests</P
><P
>This shows the pending requests that reside on the CA.
	    We should note that as <I
CLASS="EMPHASIS"
>request</I
> we describe
	    the Certificate Signing Request. Pending requests are the requests that have been
	    uploaded to the Certification Authority and wait to be signed.
	    </P
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="90%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="stylesheet-images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>	      The same terminology, <I
CLASS="EMPHASIS"
>pending requests</I
> is
	      used on the Registration Authority with a different meaning. On the Registration Authority, a pending
	      request is a Certificate Signing Request that remains to be approved by the Registration Authority
	      Administrator and be sent over to the Certification Authority.
	    </P
></TD
></TR
></TABLE
></DIV
></LI
><LI
><P
>Deleted Requests</P
><P
>This shows the deleted requests to the CA.
	    A Certificate Signing Request that has been uploaded to the Certification Authority may not be finally
	    granted permission and be signed.
	    With the current layout of the relationship of the CAServer and
	    the RAServer, the RAServer signs each Certificate Signing Request with its own private
	    key. The CAServer checks the signature and if it is verified, 
	    it creates the Certificate. Otherwise it deletes it and it is
	    shown here.
	    </P
></LI
><LI
><P
>Remove Deleted Requests</P
><P
>This removes the deleted requests from the CA.
	    It means that the requests are physically removed from the
	    file system of the CAServer.
	    </P
></LI
></UL
>  
	</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="CA-CERTIFICATES"
>Certificates</A
></H3
><P
>	<P
></P
><UL
><LI
><P
>Issued Certificates</P
><P
>This shows all Certificates ever issued by the Certification Authority.</P
></LI
><LI
><P
>Export Certificates</P
><P
>This exports the Certificates to a removable media in order
	    to be delivered to the RAServer. It is the responsibility of the
	    RAServer to distribute the Certificates to the individual owner.</P
></LI
></UL
>
	</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="CA-CRL"
>Certificate Revocation List <SPAN
CLASS="ACRONYM"
>CRL</SPAN
></A
></H3
><P
>	<P
></P
><UL
><LI
><P
>Export <SPAN
CLASS="ACRONYM"
>CRL</SPAN
></P
><P
>This exports the Certificate Revocation List
	    to the RAServer. The RAServer has the responsibility to make the
	    Certificate Revocation List known and available to the individual users.
	    </P
></LI
></UL
>
	</P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="FUNCTIONALITYRA"
>Functionality of the RA Server <I
CLASS="EMPHASIS"
>(RAServer)</I
></A
></H2
><P
>	
	This is the functionality of the Registration Authority (<SPAN
CLASS="ACRONYM"
>RAServer</SPAN
>) 
	Server. The various local Registration Authority Operators communicate 
	with this intermediary on behalf of the users' requests, in order 
	to have access to the CA. No user communicates directly with the RA 
	server. The RA server should be placed at a very high security level 
	to prevent unauthorized access.
	The RA Server is administered by the Registration Authority 
	Administrator. The actions available are listed next.
    </P
><P
>	
	While perusing the source code, you will see the principal Registration Authority
	Server to be described as <I
CLASS="EMPHASIS"
>RAServer</I
>.
    </P
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="stylesheet-images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>    The content of this section is subject to change in the future.
    </P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="RA-REQUESTS"
>Requests</A
></H3
><P
>	  <P
></P
><UL
><LI
><P
>Export Requests</P
><P
>	      Export the approved requests to the CAServer.
	      </P
></LI
><LI
><P
>Pending Requests</P
><P
>	      Show Certificate Signing Requests waiting for approval by the RAServer Administrator.
	      Approval can be based to Identification Documents or other
	      credentials.
	      </P
></LI
><LI
><P
>Approved Requests</P
><P
>	      Show Certificate Signing Requests that have already been approved by the RAServer
	      Administrator. These Certificate Signing Requests will be sent to the CAServer
	      using the <I
CLASS="EMPHASIS"
>Export requests</I
> function.
	      </P
></LI
><LI
><P
>Remove Exported Requests</P
><P
>	      The approved requests, once they are exported to the CAServer,
	      can be removed with this option.
	      </P
></LI
></UL
>
	</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="RA-CERTIFICATES"
>Certificates</A
></H3
><P
>	<P
></P
><UL
><LI
><P
>Import CA Certificate</P
><P
>	    This imports the Certification Authority Certificate and saves it on the local filesystem.
	    This copy of the Certificate will be published using the adjacent 
	    commands to the interested parties.
	    </P
></LI
><LI
><P
>Import New Certificates</P
><P
>	    This imports the newly signed Certificates from the CAServer.
	    The Certificates are copied to the local file system.
	    </P
></LI
><LI
><P
>Export Certificates onto <SPAN
CLASS="ACRONYM"
>LDAP</SPAN
></P
><P
>	    This command exports the Certificates to the specified 
	    <SPAN
CLASS="ACRONYM"
>LDAP</SPAN
> server. The users will retrieve their
	    Certificate by accessing the <SPAN
CLASS="ACRONYM"
>LDAP</SPAN
> server, rather
	    then contacting directly the RAServer.
	    </P
></LI
></UL
>
	</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="RA-CRL"
>Certificate Revocation List <SPAN
CLASS="ACRONYM"
>CRL</SPAN
></A
></H3
><P
>	  <P
></P
><UL
><LI
><P
>Import CRL</P
><P
>	    This imports the Certificate Signing Request from the Certification Authority so that it can be published.
	    </P
></LI
><LI
><P
>Export Certificate Revocation Requests</P
><P
>	    This command exports approved Revocation Requests to 
	    the CAServer. Then, the CAServer revokes these Certificates.
	    </P
></LI
></UL
>
	</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="RA-MISC"
>Miscellaneous Utilities</A
></H3
><P
>	  <P
></P
><UL
><LI
><P
>Send e&#8211;mail to users for newly&#8211;issued 
	            certificates</P
><P
>	      This informs the users that the Certificate has been prepared
	      and that they should follow the indicated
	      procedure to collect it.
	      </P
></LI
><LI
><P
>Delete Temp files (After importing certificates).</P
><P
>This is a clean&#8211;up command. With the current 
	      implementation of OpenCA, when the users are being sent
	      a notification, temporary files are created to indicate
	      the e&#8211;mail to be sent. If these files are not deleted,
	      then, on the next batch mailing, users who have already
	      received a notification are notified again.
	      </P
></LI
></UL
>
	</P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="FUNCTIONALITYLOCALRA"
>Functionality of the RA Operators <I
CLASS="EMPHASIS"
>(RAOperators)</I
></A
></H2
><P
>	The Public Servers, &#8211;&#8211; the servers that the users actually have 
	access to &#8211;&#8211; are securely&#8211;configured servers that ask 
	for Certificates, deliver them, and so on.
	This is the only entry point to the CA infrastructure from the
	Internet.
    </P
><P
>	The source code describes the local Secure RA servers 
	as <I
CLASS="EMPHASIS"
>RAOperators</I
>.
    </P
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="stylesheet-images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>    The content of this section is subject to change in the future.
    </P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="RAO-GET-CA-CERTIFICATE"
>Get Root CA Certificate</A
></H3
><P
>This allows the user to import the root Certificate of the Certification Authority into
	the browser. This is a basic and important procedure.  It
	takes place once in the life&#8211;time of the
	Certification Authority Certificate.  Other documentation describes this Certificate
	as the <I
CLASS="EMPHASIS"
>Root Certificate</I
>. It is the
	starting point to enable the client to communicate
	securely with the Certification Authority.
	</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="RAO-CRL"
>Certificate Revocation Lists</A
></H3
><P
>This brings up the Certificate Revocation List page.
	Here the Certificate Revocation List, produced by the Certification Authority is imported into the
	browser or other application.</P
><P
>	    <P
></P
><UL
><LI
><P
>OpenCA's Certificate Revocation List (DER format)</P
><P
>With this option, a browser&#8211;importable Certificate 
		Revocation List is generated to be automaticaly included 
		in the CRL list of the browser. The CRL is in the DER format.
		</P
></LI
><LI
><P
>OpenCA's Certificate Revocation List (PEM format)</P
><P
>With this option, the Certificate Revocation List 
		is generated into the PEM format. Similar to above.</P
></LI
><LI
><P
>OpenCA's Certificate Revocation List (TXT format)</P
><P
>With this option, the Certificate Revocation List 
		is generated into text format. The file generated by this 
		command can be very big.</P
></LI
></UL
>  
	</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="RAO-REQUEST-CERTIFICATE"
>Request a Certificate</A
></H3
><P
>Initiate the procedure to request a certificate.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN1065"
>Get Requested Certificate</A
></H3
><P
>This allows the user to retrieve the issued certificate 
	and subsequently import it to the application.
	The user has received the notification e&#8211;mail from 
	the Registration Authority and is prompted with intructions to retrieve the Certificate.
	In the e&#8211;mail, there is a serial number of the Certificate that
	has to be presented to the RAOperator in order to retrieve the Certificate.
	The serial number serves as an identification as to which Certificate
	will be retrieved. It is not used for authentication purposes.
	</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN1068"
>Issued Certificates List</A
></H3
><P
>This option presents a list of the issued certificates 
	of this Certification Authority.</P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="OPENCA-STATUS"
>Status of the OpenCA Project</A
></H2
><P
>The OpenCA Project is evolving quickly. 
  The current version at the time of writing (May, 2000) is 0.2.0. 
  Latest release information can be found at the
  <A
HREF="http://www.openca.org/docs/releases/"
TARGET="_top"
>OpenCA Status</A
> page.
  </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="OPENCA-FUTURE-WORK"
>Future OpenCA work</A
></H2
><P
>  This section describes the future work needed for OpenCA.
  </P
><P
>  <P
></P
><UL
><LI
><P
>	  The current layout of OpenCA (see <A
HREF="impl-openca.htm#OPENCA-LAYOUT"
>Figure 7-1</A
>)
	  is not yet scalable to support multiple CAServers or RAServers.
	  Currently this is not a high&#8211;priority issue as it is more
	  important to come up with a simple, secure, and clean
	  implementation of a CA.
      </P
></LI
><LI
><P
>	  Do more work on the <SPAN
CLASS="ACRONYM"
>LDAP</SPAN
> support.
      </P
></LI
><LI
><P
>	  Also, there are scalability issues with high usage
	  of OpenCA. The current implementation uses Perl <SPAN
CLASS="ACRONYM"
>CGI
	  </SPAN
> scripts. These scripts invoke
	  the <SPAN
CLASS="APPLICATION"
>openssl</SPAN
> application.
	  The overhead of invoking these two big executables
	  (<SPAN
CLASS="APPLICATION"
>perl</SPAN
> and 
	  <SPAN
CLASS="APPLICATION"
>openssl</SPAN
>) is considerable.
	  Depending on the hardware configuration,
	  there is a limit where the physical memory becomes
	  exhausted. The system starts swapping heavily
	  and the load goes high.
	</P
><P
>	  Possible solutions here would be to make use of <SPAN
CLASS="APPLICATION"
>	  mod-perl</SPAN
> for the Apache WWW Server. This adds
	  a new component that needs to
	  be included in a future security review.
	</P
><P
>	  Calling the OpenSSL library would be much more efficient than
	  invoking the <SPAN
CLASS="APPLICATION"
>openssl</SPAN
> application.
	  Both Perl and C support library function invocation.
	</P
></LI
><LI
><P
>	  In the current OpenCA layout (see <A
HREF="impl-openca.htm#OPENCA-LAYOUT"
>Figure 7-1</A
>)
	  the CAServer is shown to not be networked.  It communicates
	  with the RAServer using removable media.
	  There could be a solution that allows
	  a networked configuration and maintains a high degree
	  of security.
	</P
></LI
><LI
><P
>	  A test&#8211;suite is needed to test the installation
	  for correctness and provide an estimation of thoughput
	  capabilities. For the current implementation of OpenCA
	  applications like <SPAN
CLASS="APPLICATION"
>cURL</SPAN
> could
	  be used to write a test&#8211;suite. cURL supports SSL/TLS
	  connections.  It is an open&#8211;source command&#8211;line 
	  application. It is found at
	  <A
HREF="http://curl.haxx.nu/"
TARGET="_top"
>cURL - Client to fetch URLs
	  </A
> link.
	</P
></LI
><LI
><P
>	  OpenCA software and its components require a security review.
	</P
></LI
><LI
><P
>	  Smart cards could be used in The OpenCA Project.
	  <SPAN
CLASS="TRADEMARK"
>Linux</SPAN
>&reg; supports
	  smart cards. Information is at
	  <A
HREF="http://www.linuxnet.com/"
TARGET="_top"
>MUSCLE Smartcard
	  Home Page</A
>. MUSCLE supports <SPAN
CLASS="ACRONYM"
>PC/SC</SPAN
> and 
	  <SPAN
CLASS="ACRONYM"
>OCF</SPAN
> (through <SPAN
CLASS="ACRONYM"
>JNI</SPAN
>).
	  The <SPAN
CLASS="ACRONYM"
>PC/SC</SPAN
> support is more complete
	  and could provide the necessary performance needed.
	  Also, it can be accessed through Perl and C.
	</P
></LI
><LI
><P
>	  OpenCA could be implemented in various other
	  languages. The decision for this should be the weighing
	  of the benefits and the source&#8211;code fork problem.
	</P
></LI
><LI
><P
>	  Internationalisation of OpenCA. This could be accomplished
	  with the gettext support that perl has.
	  However, this should wait until the software has been stabilised.
	</P
></LI
></UL
>
    </P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="implementations.htm"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="ospki-book.htm"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="impl-oscar.htm"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Open-Source Implementations</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="implementations.htm"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>The Oscar Public Key Infrastructure Project</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>