Introduction

Introduction

This Guide is intended to provide general information on the basic concepts, design, deployment and use of the Digi-CA™ Public Key Infrastructure [PKI] system. It is assumed that the audience and readers of this guide have a basic understanding of the concepts of information technology, PKI and the use of X.509 digital public key certificates.

If you are planning to deploy Digi-CA™ inside your organisation, ensure your read this document first, before attempting to perform a new standalone or distributed installation of this system.

General Information

In cryptography, a Certificate Authority or Certification Authority [CA] is an entity that issues digital certificates for use by other parties. It is an example of a trusted third party. A CA issues digital certificates that contain a public key and the identity of the public key owner. The matching private key is not similarly made available publicly, but kept secret by the end user who owns the key pair. The certificate is also an attestation by the CA that the public key contained in the certificate belongs to the person, organization, software or hardware device or other entity noted in the certificate. A CA's obligation in such schemes is to verify an applicant's credentials, so that users and relying parties can trust the information in the CA's certificates.

Deployment Introduction

Introduction

Digi-CA™is the complete Certificate Authority system for organisations that would like to have their own CA, like to own and manage a PKI for digital certificates inside the organisation or over the Internet. Digi-CA™generates and manages digital Public Key Certificates that are used for a variety of different purposes, most commonly for electronic signatures, natural person or device authentication and secure email.

The Digi-CA™system can create multiple instances of independent Certification Authorities in a single Digi-CA™system deployment. The Digi-CA™model imposes delegation of trust downwards from Root CAs to their Subordinate CAs that meets the concepts of layered hierarchy. The same Digi-CA™system also enables a CA to be cross signed by an external third party CA. As a result of this design principal, the Digi-CA™model for trust levels increases towards the highest authority. This type of arrangement facilitates easy deployment and scalability of any PKI requirement from the smallest to the largest.

Digi-CA™can be delivered as an installed Software CA, or as a Managed CA service. Uniquely, both the Managed Digi-CA™Service and the installed Digi-CA™Server software use the same common, core technology. This is important because in selecting Digi-CA™it is possible to begin with Digi-CA™Service and migrate to Digi-CA™Server with ease.

It is possible to use the distributed architectural design of Digi-CA™to implement the concept of a Shared CA where different modules of the system are hosted and managed in separate locations.

services

Digi-CA™

The Digi-CA™System provides a full scale of services necessary for the management of X.509 certificates. An overview of these services is presented in the table below.

Digi-CA™ service overview
End Entity registration		Time-Stamping
Certificate issuance		Online Certificate Status Protocol
Certificate re-signing		Multi-CA system engine
Certificate renewal		Cross-Certification management
Certificate dissemination		CRL generation
Certificate revocation		CRL distribution and dissemination
Certificate suspension		Entity based multi-key management
Certificate de-suspension		Certificate Profile management
Certificate Expiration Notification		Certificate Enrolment Policy Management
Event logging and auditing service		Support for Hardware Cryptographic Module devices
Hierarchical CA operations		Support for Smart Cards and USB Tokens

In principle and in compliance with internationally recognised PKI standards, Digi-CA™offers the following core Certification Authority services:

• End Entity Registration Service
• Certificate Generation Service
• Certificate Dissemination Service
• Revocation Management Service
• Revocation Status Service

As an addition, Digi-CA™offers the following supplementary services:

• Time-stamping Service

Software

General Information

At its core, Digi-CA™ software was designed for Unix and Linux operating systems that provide a robust and stable operating environment. The simplicity of the architectural design of the complete Digi-CA™ system means that the same software can be deployed on a single server device and later scaled for enterprise or Internet PKI use with minimum or no disruption.

Typically, scaling may start from a 'handful' of servers acting in a basic
fail-over mode. Such basic setup can be later extended to reach greater capacity and performance by introducing additional servers as required. This scaling of the capacity can occur almost without, or completely without, interrupting the operation of the existing production environment. This is a critical component when deciding on a CA that may scale considerably over time and allows organisations to carefully plan their investment costs, whilst also achieving all functional goals.

The following table presents a minimum software and hardware requirement to deploy a standard Digi-CA™ on a single server device.

Component		Minimum Requirements Specification
Server OS Platform		Unix®, Linux® [x86 / x86-64 / ia64]
Operating System		Red Hat Enterprise Linux® 4.x, 5.x ; FreeBSD® 5.x, 6.x, 7.x, 8.x
RAM Memory		1GB RAM
Hard Disk Device		15GB ATA/SCSI/SAS
CPU		Intel® Pentium® IV 2.4 MHz
Network Interface Card		Intel® compatible 10/100 Megabits NIC
Database server software		MySQL Community Server 5.0.45

Modular Architecture

Digi-CA™ software is a multi-application component based system for generating and managing cryptographic keys, digital X.509 public key certificates and providing supplementary PKI services. In this model, each application component, referred to as a "Service Module", provides a series of both cryptographic and non-cryptographic functionalities to other application components within the system’s infrastructure.

Modules

Digi- CA™

The following table presents a list of Service Modules currently available within Digi-CA™.

Component	Code	Minimum Requirements Specification
Cryptographic Service Provider	CSP	Certificate & CRL Generation Services
Time-Stamping Gateway	TSG	Digital Time-Stamping Service
OCSP Gateway	OCSPG	Real time Revocation Status Service
CA Application Service	CAAS	TSG and OCSPG gateway services connector
CA Management Console	CAMC	Web based Certification Authority management
RA Management Console	RAMC	Web based Registration Authority management
Entity Registration Service	EERS	Web based End Entity Registration management
Content Dissemination Service	CCDS	Certificate and CRL dissemination management

The modular design of Digi-CA™allows its seamless deployment in almost every scenario:

	a	where it is required to centralise all Module Services on a single dedicated server to reduce costs and where large certificate volumes are not a demand;
	b	in a most complex environment, for very high volume certificate processing and where all Module Services are distributed separately to a number of server devices, most often in combination with network hardware load balancing, database data replication as well as hardware and software fail-over that combine to form the so called ‘High Availability’ model.

This unique feature of Digi-CA™software provides not only a flexible range of possible configuration variations but allows organisations to slowly build their own PKI infrastructure from a very small environment and carefully control their expenditure related to purchasing and maintenance of hardware devices.

Models

Deployment models

When considering a centralised or distributed deployment model of Digi-CA™, one must consider the fact, that Digi-CA™requires a pre-established network infrastructure that is a key objective to a successful deployment of this system. Although Digi-CA™does not require, or rely on, a specific network design, careful network architecture planning is strongly recommended prior to the deployment of this system. Diagrams below – as an example only - illustrate two most common deployment methodologies, one with all Service Modules centralised on a single server and the other with distributed services as an alternative.

Diagram 1.0: Digi-CA™with centralised Service Modules

Diagram 2.0: Digi-CA™with distributed Service Modules

Summary

Digi-CA™Summary

Digi-CA™replaces older Legacy CA systems using the latest in CA and PKI technologies and benefits from combining commercial and open source software initiatives. With Digi-CA™, all of the complexities and onerous technical overhead that were required by Legacy CAs have been simplified to a ‘user-friendly’ and usable level.

The Digi-CAST™ Team combine consulting and professional services with the functions provided by Digi-CA™and can bring an organisation to a highly professional PKI level whilst meeting the criteria for internationally recognised accreditation standards such as WebTrust® and ISO 27001 certifications.

Diagram 1.0: Digi-CA™with centralised Service Modules

Service Modules : Public Key Cryptography : Digi-Sign.com

Digi-CA™Service Modules explained

This section of the Guide provides general information on the functional concepts for each Digi-CA™Service Module. More detailed information as well as usage instructions for these modules are available in the following associated documents:

• Digi-CA™Administrator Guide
• Digi-CA™RA Operation Guide

Cryptographic Service Provider

The Cryptographic Service Provider [CSP] Service Module is a software application that ultimately provides the most of cryptographic operations to the system and is effectively responsible for generating all public key certificates. Due to the high severity for the security of this module, it is not accessible through any network communications protocol. This design imposes an asynchronous certificate generation and distribution model.

The only allowed control mechanism for this software module is manual, through the use of Operating System console command line interface [CLI]. CLI control options are limited to start, stop, key activation and general module configuration operations.

CSP in the overview of the CA core services acts as the Certificate Generation Service.

From an Operating System perspective, CSP is executed as a software daemon being also a client to the CA database server and Content Distributing Service. It sustains a persistent connection to the database from where cryptographic operation requests are loaded and subsequently served. The following table presents a general overview of the cryptographic functionality the CSP module is designed to provide.

CSP functionality overview
CA Key Pair generation		End Entity Key Pair generation
Root CA public key certification		End Entity public key certification
Subordinate CA public key certification		Certificate Revocation List certification
CA Public Key Cross-Certification		CA Private Key Storage in Software Security Module
Table 3.0

Certified (digitally signed by the CA private key) public key certificates are instantly stored in a CA database and where immediate certificate dissemination is required, a Content Distributing Service is optionally called through an Uniform Resource Identifier [URI], further resulting in a certificate being distributed to the End Entity and, if necessary, published in a certificate LDAP directory.

CSP makes regular use of CA private keys and associated public key certificates and therefore it must have uninterrupted access to these keys at all times. Private keys used by CAs to certify public key certificates are by nature security sensitive. A CA must therefore provide sufficient security mechanisms and procedures to protect the CA private key from an illegitimate use by others.

CSP is designed to meet the highest security demands and simultaneously support two different types of Security Modules for secure private key access and storage:

• Software Security Module [SSM]
• Hardware Security Module [HSM]

The SSM is a CSP’s built-in cryptographic hardware-less feature. SSM uses PKCS#8 (Public Key Cryptography Standard) format to store private keys on a local file system in an encrypted manner. Private key encryption is accomplished by the use of encryption algorithm sets as defined in PKCS#5 standard.

Access to private keys in SSM is protected by a key activation password, which is used by the CSP to derive a "secret" further used to effectively encrypt CA private key information. Although a System Administrator or Security Officer may be aware of the SSM activation password, direct access to raw private key information is not likely possible, unless a successful attempt is made to reverse engineer the CSP source code in order to establish the precise secret derivation algorithms in use.

Once an instance of a CSP is launched, all private keys residing in the SSM private key repository configured for activation are loaded and remain in computer RAM memory until the CSP process is purposefully or unexpectedly terminated. Upon successful shutdown of the CSP process, the RAM memory area designated for private key storage is programmatically zeroed.

The SSM option for CA private key storage is designed to provide a cost-effective way of CA private key storage for small organisations, that intend to deploy Digi-CA™only for private use and where corporate security policies are actively maintained and followed by IT personnel and finally where the organisation has full control of the use of public key certificates.

Where greater CA private key protection mechanisms are a security demand, SSM option is strongly NOT recommended and this is where CSP offers a simultaneous use of hardware based cryptographic devices - HSMs - for secure private key storage and access.

HSMs introduce a very high level for private key protection and provide enhanced performance for cryptographic operations with the use of private keys, for example in the process of creating digital signatures.

There are two general types of HSM devices: host-attached and network-attached. The CSP supports both types of HSMs. A host-attached HSM device can be a device connected directly to a host server through a PCI, USB or SCSI interface. A network-attached HSM is a device connected to the host server over network using a Network Interface Card [NIC] attached to the server. Both types of HSM devices provide enhanced private key protection and meet the highest security criteria demand such as certification to FIPS 140-2 level 4 and/or Common Criteria EAL4+.

CSP communicates with the HSM device using a software library API, provided by the device vendor. When using HSM devices, private keys are physically stored and protected inside a hardware device and are never accessible as plain text. In fact, CSP has no real control over private keys stored on an HSM device as it merely makes the use of the hardware device layer to perform cryptographic operations.

HSM devices are therefore strongly recommended typically everywhere, where organisations intend to provide CA services to the public community or where the use of public key certificates is outside of the organisation’s exclusive control.

The table below presents example HSM models, that have been successfully tested with the CSP Service Module.

Supported Hardware Security Modules

AEP Keyper Professional (FIPS 140-2 level 4)

AEP Keyper Enterprise (FIPS 140-2 level 4)

Thales nCipher NetHSM 500 (FIPS 140-2 level 3)

Thales nCipher NetHSM 2000(FIPS 140-2 level 3)

Thales nCipher nShield PCI (FIPS 140-2 level 3)

Configuration

Digi-CA™

Usage and configuration instructions for this module are available in the following associated documentation: Digi-CA™Administrator Guide.

CA Management Console [CAMC]

The CA Management Console [CAMC] Service Module is the central graphical user interface [GUI] for managing Certification Authorities, Registration Authorities, Service Modules and other services provided within the Digi-CA™system infrastructure.

The following table presents a general overview on the functionalities provided by CAMC.

CAMC functionality overview
Management of CA accounts		Management of internal Master CA key pair
CA Key Pair management		Management of Digi-CA™system user accounts
CA Certification and Cross-Certification management		Management of End Entity certificate policies
Service Module Registration and Management		Management of Time-Stamping Authorities
Digi-CA™main configuration		Management of OCSP Validation Authorities
Registration and management of X.509 certificate profiles		Digi-CA™system status overview
End Entity Certificate reporting		CSP cryptographic request queue reporting
Management of RA accounts		Activity Dual Control authorization
Table 5.0

The CAMC is essentially a web based application designed to work with an instance of an Apache web server.

System users, such as CA Administrators can access the console interface only by using a web browser client application such as Microsoft Internet Explorer or Mozilla Firefox.

CAMC provides support for a combination of two user authentication factors: traditional username and password and X.509 certificate based client authentication, which is a feature enabled by the use of SSL/TLS communication encryption protocol on the Apache web server. CAMC allows you to decide what authentication factor should be used to authenticate console users or whether to use both authentication factors at the same time.

The console is capable of supporting multiple language locales.

The great advantage of this module is that it allows different CA users to independently access separate CA accounts at the same time using the same console interface.

To store and retrieve information, the console uses an interface connection to the CA database. The fact it is a web based application, makes it easy to deploy and protect on a common installation of an Apache web server.

Management

Summary

Usage and configuration instructions for this module are available in the following associated documentation: Digi-CA™Administrator Guide.

RA Management Console [RAMC]

The RA Management Console [RAMC] Service Module is the central graphical user interface [GUI] for operating Registration Authorities and managing End Entity Certificates.

he following table presents a general overview on the functionalities provided by RAMC.

RAMC functionality overview
End Entity account management		Management of RA user accounts
End Entity key pair life cycle management		Management of End Entity certificate policies
End Entity certificate request registration		End Entity Validation
End Entity certificate authorization		Activity Dual Control authorization
End Entity certificate revocation		End Entity certificate reporting
End Entity certificate suspension		End Entity certificate de-suspension
End Entity certificate replacement (re-issuance)		Management of TSA clients
Table 6.0

The RAMC is essentially a web based application designed to work with an instance of an Apache web server.

System users, such as RA Administrators and RA Operators can access the console interface only by using a web browser client application such as Microsoft Internet Explorer or Mozilla Firefox.

The RAMC provides support for a combination of two user authentication factors: traditional username and password and X.509 certificate based client authentication, which is a feature enabled by the use of SSL/TLS communication encryption protocol on the Apache web server. RAMC allows you to decide what authentication factor should be used to authenticate console users or whether to use both authentication factors at the same time.

The console is capable of supporting multiple language locales.

The great advantage of this module is that it allows different RA users to independently access separate RA accounts at the same time using the same console interface.

To store and retrieve information, the console uses an interface connection to the CA database. The fact it is a web based application, makes it easy to deploy and protect on a common installation of an Apache web server.

Entity Registration

Summary

Usage and configuration instructions for this module are available in the following associated documentation: Digi-CA™RA Operation Guide.

End Entity Registration Service [EERS]

The Entity Registration Service [EERS] Service Module is the central graphical user interface [GUI] provided to End Entities for user account and certificate related activity registration purposes.

The following table presents a general overview on the functionalities provided by EERS.

EERS functionality overview
End Entity initial account registration		End Entity certificate status reporting
End Entity certificate request registration		End Entity certificate collection
End Entity certificate revocation requests		End Entity certificate replacement (re-issuance) requests
End Entity certificate suspension requests		End Entity certificate de-suspension requests
TSA client token reporting
Table 7.0

The EERS is essentially a web based application designed to work with an instance of an Apache web server.

End Entity users, such as Public Key Certificate subscribers or TSA Clients can access the module interface only by using a web browser client application, such as Microsoft Internet Explorer or Mozilla Firefox.

EERS provides support for traditional username and password based authentication. The console is capable of supporting multiple language locales.

To store and retrieve information, the module uses an interface connection to the CA database. The fact it is a web based application, makes it easy to deploy and protect on a common installation of an Apache web server.

CRL Dissemination

Summary

Usage and configuration instructions for this module are available in the following associated documentation: Digi-CA™RA Operation Guide.

Certificate & CRL Dissemination Services [CCDS]

The Certificate & CRL Dissemination Services [CCDS] Module is a software application that ultimately provides dissemination service for End Entity Public Key Certificates, Key Pairs and Certificate Revocation Lists.

The CCDS, in the overview of the CA core services, acts as the Dissemination Service.

From an Operating System perspective, the CCDS is a client application to the CA database server. It sustains a persistent connection to the database from where dissemination requests are loaded and subsequently served. The following table presents a general overview of the functionality the CCDS module is designed to provide.

CSP functionality overview
End Entity public key publication in LDAP directory		CRL publication in web repository
End Entity public key distribution		CRL distribution
End Entity certificate expiration notification		TSA Client notifications
Table 8.0

Public Key Certificates generated by the CSP Service Module are stored in a CA database and CCDS is responsible for distributing the certificates to End Entities and if necessary, publishing these in a certificate LDAP directory.

For distribution, CCDS primarily uses Internet mail messaging [email], where public key certificates are attached to email messages. Another common method is to notify End Entities of a specific certificate collection web access point where End Entities can collect certificates by using a web browser, which is provided as part of the Entity Registration Service.

Time Stamp

Summary

Usage and configuration instructions for this module are available in the following associated documentation: Digi-CA™Administrator Guide.

TimeStamp Authority Gateway [TSAG]

The TimeStamp Authority Gateway [TSAG] Service Module is intended to provide digital Time-Stamping network based services in compliance with RFC 3161 standard, Internet X.509 Public Key Infrastructure Time-Stamp Protocol [TSP].

The Time-Stamp Protocol, or TSP, is a cryptographic protocol for certifying time-stamp tokens using X.509 public key certificates and public key infrastructure. The time-stamp token is the signer's assertion that a piece of electronic data existed at, or before, a particular time. Time-Stamp tokens are effectively used to provide evidence data in the process of validating long-term electronic signatures applied to digital communication or payment transactions and electronic documents such as Adobe® Acrobat® PDF.<,/

TSAG, in the overview of the CA supplementary services, acts as the Timestamping Service.

The term "Gateway" in the module name is purposely used to describe what the TSAG really does. It is essentially a network gateway between the TSP Client and TSP Server. The design concept for this Service Module arose from the results of security assessments applied to RFC 3161 standard.

A typical implementation model for a TSP Server allows that server to directly access the Timestamp Authority’s [TSA] Private Key designated for certifying TimeStamp tokens. Due to the fact that the TSP Server is very likely to be exposed for public use, the likelihood of the TSA’s private key accidental exposure to an illegitimate party is relatively high, regardless whether the TSA’s private key is stored in a Software or Hardware Security Module. The TSA forms a key party in the process of validating electronic signatures and non-repudiation and therefore an illegitimate exposure of the TSA’s private key in any form could lead to a potential risk of TSA signature forger that would further result in invalidation of any previously certified Time-Stamp tokens and further invalidation of any electronic signatures that these tokens would provide an evidence of.

TSAG was designed to eliminate the above risks. It is a software library built to work with an instance of an Apache web server software and it can be therefore considered as an Apache software module. Its functionality is limited to the following purposes:

		a. Optionally authenticate connecting TSP Clients against a database
		b. Qualify correctly formatted TSP requests
		c. Transparently pass TSP requests to the CA Application Service [CAAS]
		d. Retrieve responses from CAAS
		e. Transparently pass responses retrieved from CAAS to TSP Clients

The TSP Clients can connect to the TSAG using standard HTTP or secure HTTPS [HTTP over SSL/TLS] protocol using a Uniform Resource Locator [URL] method. TSP requests are accepted either as HTTP POST or HTTP GET requests.

The optional Client Authentication is accomplished by the use of Simple HTTP Authentication where TSP Clients are requested to provide a username and password before their TSP request is accepted. To authenticate a TSP Client, the TSAG will transparently connect to a CA database, where End Entity account information is stored.

The TSAG module is configured and activated inside the Apache web server configuration and can be applied per site, virtual realm or per physical directory configuration. It is loaded the very moment the Apache web server is started.

Important Note: TSAG Service Module can place significant demands on your servers and IT hardware environment and should only be deployed and offered to relying parties if you have the correct infrastructure that meets the recommended model of High Availability.

Online Certificate

Summary

Usage and configuration instructions for this module are available in the following associated documentation: Digi-CA™Administrator Guide.

Online Certificate Status Protocol [OCSP]

The Online Certificate Status Protocol [OCSP] Gateway Service Module is intended to provide digital network based services in compliance with RFC 2560 standard, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP.

The OCSP is an Internet protocol used for obtaining the revocation status of an X.509 digital public key certificate. It was created as an alternative to Certificate Revocation Lists [CRL], specifically addressing certain problems associated with using CRLs in a public key infrastructure [PKI].

Messages communicated via OCSP are effectively used to provide real time certificate revocation status service in the process of validating a public key certificate. This service can greatly support the validation process of the long-term electronic signatures applied to digital communication or payment transactions and electronic documents, such as Adobe® Acrobat® PDF. OCSP, in the overview of the CA core services, acts as the Revocation Status Service.

The OCSP is provided in a Gateway mode and the term "Gateway" in the module name is purposefully used to describe what the OCSPG really does. It is essentially a network gateway between the OCSP Client and OCSP Responder. The design concept for this Service Module arose from the results of security assessments applied to RFC 2560 standard. A typical implementation model for an OCSP Responder allows that server to directly access the OCSP Validation Authority’s [VA] Private Key designated for certifying OCSP response messages. Due to the fact that the OCSP Responder is very likely to be exposed for public use, the likelihood of the VA’s private key accidental exposure to an illegitimate party is relatively high, regardless whether the VA’s private key is stored in a Software or Hardware Security Module. The VA forms a key party in the process of validating electronic signatures and non-repudiation and therefore an illegitimate exposure of the VA’s private key in any form could lead to a potential risk of VA signature forgery that would further result in invalidation of any previously certified OCSP responses and further invalidation of any electronic signatures that these responses would provide evidence of.

OCSPG was designed to eliminate the above risks. It is a software library built to work with an instance of an Apache web server software – it can be therefore considered as an Apache software module. Its functionality is limited to the following purposes:

		a. Qualify correctly formatted OCSP requests
		b. Transparently pass OCSP requests to the CA Application Service [CAAS]
		c. Retrieve responses from CAAS
		d. Transparently pass responses retrieved from CAAS to OCSP Clients

OCSP Clients can connect to OCSP Gateway using standard HTTP or secure HTTPS [HTTP over SSL/TLS] protocol using a Uniform Resource Locator [URL] method. OCSP request messages are accepted either as HTTP POST or HTTP GET requests.

OCSP Gateway module is configured and activated inside the Apache web server configuration and can be applied per site, virtual realm or per physical directory configuration basis. It is loaded the very moment the Apache web server is started.

Important Note: OCSP Gateway Service Module can place significant demands on your servers and IT hardware environment and should only be deployed and offered to relying parties if you have the correct infrastructure that meets the recommended model of High Availability.

CA Application

Summary

Usage and configuration instructions for this module are available in the following associated documentation: Digi-CA™Administrator Guide.

CA Application Service [CAAS]

The CA Application Service [CAAS] Service Module is intended to provide target TSP Server and OCSP Responder services to the Time-Stamping Gateway and OCSP Gateway Service Modules.

The CA Application Service [CAAS] Service Module is intended to provide target TSP Server and OCSP Responder services to the Time-Stamping Gateway and OCSP Gateway Service Modules.

The design concept for this Service Module arose from the results of security assessments applied to RFC 3161 and RF 2560 standards and these concepts are further described in the above chapters 3.2 and 3.3.

CAAS has direct access and makes regular use of the TSA and OCSP VA Private Keys designated for certifying Time-Stamp tokens and OCSP response messages. Due to the fact that CAAS is NOT likely to be exposed for public access, the likelihood of the TSA or VA private key accidental exposure to an illegitimate party is relatively very small, regardless whether the TSA or VA private key is stored in a Software or Hardware Security Module.

CAAP was designed to remain in a protected network zone where public access is physically made impossible. It is a software library built to work with an instance of an Apache web server software – it can be therefore considered as an Apache software module. Its functionality is limited to the following purposes:

		a. Receive and serve Time-Stamp Requests
		b. Receive and serve OCSP Requests
		c. Respond to relevant requests by producing Time-Stamp tokens
		d. Respond to relevant requests by producing OCSP responses

Note: although CAAS will only accept legitimate requests from either of the Gateway Service Modules, it is still possible to setup the CAAS in combination with any of the Gateway Service Module in a traditional manner. Such a setup would allow you to install CAAS with TSG and/or OCSPG on a single server. This type of deployment is very useful in a closed private environment where volumes of requests are predictable and where corporate security policies are actively maintained and followed by IT personnel.

The CAAS uses the same private key storage and access techniques as the CSP Service Module and these techniques are described in more detail above.

Gateway Service Modules can connect to CAAS using secure HTTPS [HTTP over SSL/TLS] protocol with a Uniform Resource Locator [URL] method. Request messages are accepted as HTTP POST requests.

The CAAS module is configured and activated inside the Apache web server configuration and can be applied per site, virtual realm or per physical directory configuration basis. It is loaded the very moment the Apache web server is started.

Important Note: CAAS Service Module can place significant demands on your servers and IT hardware environment and should only be deployed and offered to relying parties if you have the correct infrastructure that meets the recommended model of High Availability.

Standalone

Summary

Usage and configuration instructions for this module are available in the following associated documentation: Digi-CA™Administrator Guide.

Performance Data

Using a standalone deployment of Digi-CA™with basic Service Modules on a mid-spec Intel® processor based computer, Digi-CA™CSP Service Module has recorded the following performance data.

CSP Performance Data
Number of Certificates	500 up to 500,000,000+
Production speed	5,000 1024-bits key signatures using SSM / hour 20,000 1024-bits key signatures using HSM / hour
Key lengths	1024-8192 bits using SSM and HSM
Signature algorithms	PKCS#1: RSA with SHA-1

Compliance to standards

Digi-CA™has been verified to comply with the following standards. For a complete and current list of standards, refer to the official Digi-Sign website URL:

www.digi-sign.com/about/compliance [3]

Digi-CA™standard compliance list
RFC 5280, RFC 3647, RFC 2587, RFC 3161, RFC 3628, RFC 3629, RFC 2560		RFC standards or standard candidates
PKCS#1, PKCS#3, PKCS#5, PKCS#7, PKCS#8, PKCS#9, PKCS#10, PKCS#11, PKCS#12		RSA Public Key Cryptography Standards
FIPS 46, FIPS 180-2, FIPS 186-2, FIPS 197, FIPS 198		US Federal Information Processing Standards
ETSI TS 102 280, ETSI TS 102 042, ETSI TS 102 040, ETSI TS 102 023, ETSI TS 101 861		European Telecommunications Standards Institute standards
CWA 14167-1		CEN Workshop Agreement standards