Anda di halaman 1dari 73

Insta Certifier 5.2.

Product Description




16 September 2013

2011 Insta DefSec Oy. This software is protected by international copyright laws. All
rights reserved.
All other names and marks are property of their respective owners.
No part of this publication may be reproduced, published, stored in an electronic database, or transmitted, in any form or by any means, electronic, mechanical, recording,
or otherwise, for any purpose, without the prior written permission of Insta DefSec Oy.

Insta DefSec Oy
Sarankulmankatu 20
P.O.Box 80
FIN-33901 Tampere
Tel: +358 600 97801 (Support HelpDesk)
Tel: +358 20 771 7111 (Insta DefSec)
Fax: +358 20 771 7122 (Insta DefSec)

Insta Certifier : Product Description

Table of Contents

Table of Contents
About This Document ................................................................................................................... 1
Introduction ................................................................................................................................... 2
2.1 Public-Key Infrastructure .................................................................................................... 2
2.1.1 Public-Key Cryptography, Keys, and Certificates ................................................... 2
2.1.2 PKI - Distributing Trust ........................................................................................... 3
2.2 Insta Certifier...................................................................................................................... 4
2.2.1 Basic Components ................................................................................................. 5
2.2.2 Directory ................................................................................................................ 6
Features ......................................................................................................................................... 7
3.1 Certificate Management Features ...................................................................................... 7
3.2 Revocation Features .......................................................................................................... 9
3.3 Scalable Architecture ....................................................................................................... 10
3.4 Directory Integration ......................................................................................................... 11
3.5 Administration .................................................................................................................. 12
3.6 Other Features ................................................................................................................. 13
Architecture ................................................................................................................................. 14
4.1 Communication between Processes ................................................................................ 15
4.2 Certifier Services .............................................................................................................. 16
4.2.1 Administration Service ......................................................................................... 16
4.2.2 CMP Service ........................................................................................................ 17
4.2.3 External Enrollment Client Service ....................................................................... 17
4.2.4 LDAP Authentication Service ............................................................................... 17
4.2.5 OCSP Responder Service ................................................................................... 18
4.2.6 Publishing Service ............................................................................................... 18
4.2.7 SCEP Service ...................................................................................................... 18
4.2.8 Web Enrollment Service ....................................................................................... 19
4.3 External Services ............................................................................................................. 19
4.3.1 Open Database Connectivity................................................................................ 19
4.3.2 Lightweight Directory Access Protocol ................................................................. 20
4.3.3 Hardware Security Modules ................................................................................. 20
4.4 Certification Request Processing ..................................................................................... 21
Deploying a PKI ........................................................................................................................... 24
5.1 The PKI Model ................................................................................................................. 24
5.1.1 CA Hierarchy........................................................................................................ 24
5.1.2 Delegating Duties to Registration Authorities ....................................................... 25
5.1.3 Cross-Certification ............................................................................................... 25

Insta Certifier : Product Description

Table of Contents

5.2 End-Entity Applications .................................................................................................... 26

5.3 CA Root Certificate Distribution ........................................................................................ 26
5.4 Key Backup ...................................................................................................................... 27
5.5 Revocation Services and Directory Deployment ............................................................... 28
5.5.1 Online Certificate Status Protocol (OCSP) ........................................................... 28
5.5.2 Certificate Revocation Lists (CRL) ....................................................................... 28
5.5.3 Revocation Service Implementation Issues .......................................................... 28
5.6 Certificate Policy and CPS ............................................................................................... 29
5.6.1 Certification Practice Statement (CPS)................................................................. 29
5.7 Organizational Responsibilities ........................................................................................ 29
5.8 Private Key Security Issues.............................................................................................. 30
Use Cases .................................................................................................................................... 32
6.1 Enterprise-Wide, Strong, Two-Factor Authentication ........................................................ 32
6.2 Authentication Management in a VPN .............................................................................. 33
6.2.1 IPSec and VPNs .................................................................................................. 33
6.2.2 Sample Scenario .................................................................................................. 34
6.3 Certification Service Provision .......................................................................................... 36
6.3.1 S/MIME and TLS Technology .............................................................................. 36
6.3.2 Sample Scenario .................................................................................................. 37
Product Specifications ............................................................................................................... 40
7.1 Main Features .................................................................................................................. 40
7.2 Technical Specifications ................................................................................................... 41
7.2.1 7.2.1 Supported Platforms ................................................................................... 41
7.2.2 Hardware Requirements ...................................................................................... 41
7.2.3 Software Requirements ........................................................................................ 42
7.2.4 Supported Third-Party Hardware.......................................................................... 42
7.2.5 Supported Cryptographic Algorithms, Standards, and Protocols .......................... 42
Appendix A Introduction to Cryptography and Certificates ..................................................... 44
A.1 Introduction to Cryptography............................................................................................ 44
A.1.1 Basic Terminology ............................................................................................... 44
A.1.2 Cryptographic Algorithms and Cryptographic Systems ........................................ 44
A.1.3 Strength of Cryptographic Algorithms .................................................................. 46
A.2 Introduction to Certificates ............................................................................................... 47
A.2.1 Basic Concepts.................................................................................................... 47
A.2.2 Structure of a Certificate ...................................................................................... 49
A.2.3 Certificate Revocation Lists (CRLs) ..................................................................... 51
A.2.4 Online Certificate Status Protocol (OCSP) ........................................................... 51
A.2.5 Certificate Enrollment .......................................................................................... 52
A.2.6 X.500 Directory Structure .................................................................................... 54
Appendix B Glossary .................................................................................................................. 57

Insta Certifier : Product Description

Chapter 1: About This Document

Chapter 1

About This Document

Insta Certifier is a complete solution for providing certification services in an X.509
Public-Key Infrastructure (PKIX). This document introduces you to the concept of PKI
and presents Insta Certifier by Insta DefSec Oy.
This document is intended as background material for the persons responsible for the
deployment and operation of an Insta Certifier based PKI.
This document contains the following information:

introduction to PKI and Insta Certifier

features of Insta Certifier
architecture of Insta Certifier
general instructions on deploying a PKI
sample use cases
technical specifications of Insta Certifier
introduction to cryptography and certificates

Styles and Conventions

The following conventions are used in this document:




GUI elements, variables, emphasis

Click System Configuration


Filenames, commands, directories

Configuration file engine.conf


Terms and references

Certification Authority

Command lines and configuration file contents are shown as in this example:
# chkconfig --list certifier

Insta Certifier : Product Description

Chapter 2: Introduction

Chapter 2

This chapter gives a short introduction to the concept of public-key infrastructure and
the Insta Certifier product.

2.1 Public-Key Infrastructure

Public-key infrastructure (PKI) gives means for performing authentication reliably and
securely, ensuring message integrity, and providing non-repudiation of transactions in
an online environment. PKI can be used for managing the digital IDs of users, servers,
and software applications.

2.1.1 Public-Key Cryptography, Keys, and Certificates

PKI is based on the use of public-key (asymmetric) cryptography. In public-key cryptography, messages are encrypted and decrypted with different keys. This means that
each participating entity (person or device) of the PKI has a set of two keys, a public
key and a private key.
Private keys are secret and known only to their owners. Private keys are used for
signing and decrypting messages. A common way to ensure the safety of a private
key is to store it on a separate piece of hardware (a security token such as a smart
Public keys are, as the name implies, public and can be published, for example, in a
public directory or on a web server. Public keys are used for validating signatures and
encrypting messages. The two keys are mathematically dependent but the private key
cannot be derived from the public key. Furthermore, the two keys possess a distinct
quality: what the public key encrypts can only be decrypted by the private key.
Before public-key operations can be made, the public key of the other entity has to be
received securely, so that no one can substitute the genuine key with a tampered one.
If there are only a few entities communicating with each other, the validity of each
public key could be verified and trust established by using out-of-band methods (for
example, telephone calls). But when the number of entities grows and the entities are
not known to each other, this would soon become impossible. PKI provides a solution
by using trusted third parties for mediating the trust, and certificates for distributing the
Certificates are digital documents that are used for secure authentication of the communicating parties. A certificate binds identity information about an entity to the entitys public key for a certain validity period. A certificate is digitally signed by a trusted
third party (TTP) who has verified that the key pair actually belongs to the entity. CerInsta Certifier : Product Description

Chapter 2: Introduction

tificates can be thought of as analogous to passports that guarantee the identity of

their bearers.
When authentication is required, the entity presents a signature it has generated from
authentication data using its private key, and a certificate corresponding to that key.
The receiving entity can verify the signature with the public key of the sender contained in the certificate. Next the receiving entity must verify the certificate itself by
checking the validity time of the certificate and the signature of the trusted party in the
certificate. If the signature is valid and the receiving entity trusts the TTP, the first entity has been authenticated successfully.
To enable wide usage of certificates and interoperable implementations from multiple
vendors, certificates must be based on standards. The most advanced and widespread certificate specifications at the moment are defined by the PKIX Working
Group of the Internet Engineering Task Force (IETF). PKIX stands for Public-Key Infrastructure (X.509), as the work of the group is based on the ITU-T recommendation

2.1.2 PKI - Distributing Trust

The following concepts are critical for understanding how a public-key infrastructure
End Entity
End entities are individual users, devices, or software applications that transact with
each other. End entities do not necessarily know each other and they need a way of
finding out whether the other party of a transaction is trustworthy.
Certification Authority (CA)
The trusted party who issues certificates to the identified end entities is called a certification authority (CA). Certification authorities can be thought of as being analogous
to governments issuing passports for their citizens.
A certification authority can be operated by an external certification service provider,
or even by a government, or the CA can belong to the same organization as the end
entities. CAs can also issue certificates to other (sub-)CAs. This leads to a tree-like
certification hierarchy. The highest trusted CA in the tree is called a root CA.
Registration Authority (RA)
In some cases, a CA can delegate the actual identification of end entities as well as
some other administrative tasks to a separate entity, the registration authority (RA).
The RA performs the identification of the end entities and then signs the end-entity
certification requests with its RA private key.
Because the CA has delegated the task of end-entity identification to the RA, the RA
signature in the request gives the CA a guarantee of the right for end-entity certification. This allows the CA to operate automatically in online interaction while the local
RAs perform the required out-of-band interaction with end entities.

Insta Certifier : Product Description

Chapter 2: Introduction

Using local RAs a large geographically or operationally distributed PKI can work in a
scalable way, even when the actual certificate issuing is centralized.
Certificate Enrollment
Certificate enrollment is an action in which a CA certifies a public key.
End entities can use standard request formats for requesting certificates from a CA.
The CA uses the underlying certificate policy to decide whether to approve the request or not. The policy decision and the approval/denial can be automatic, or the operator of the CA may have to approve the requests manually. If the request is approved, a signed certificate will be issued and delivered to the end entity and possibly
also published in a (public) directory.
Certificate Revocation
Certificates have pre-defined lifetimes, lasting from a couple of weeks to several
years. If a private key of an end entity is compromised or the right to authenticate with
a certificate is lost before the expiration date, the CA must revoke the certificate and
inform all PKI users about this. Certificate revocation lists can be used for this purpose.
A certificate revocation list (CRL) is a list identifying the revoked certificates and it is
signed by the CA that originally issued the certificates. Each CA publishes CRLs on a
regular basis. The publishing interval may vary from a couple of minutes to several
hours, depending on the security policy of the CA. Verification of a certificate has to
include the retrieval of the latest CRL to check that the certificate has not been revoked.
As the certificate revocation lists are updated on a periodic basis, they do not provide
real-time status information. If stricter security is required, online certificate status services can be used. In Online Certificate Status Protocol (OCSP), a dedicated OCSP
responder entity responds to status requests made by end entities. This kind of function is required for example in a PKI where high-value business transactions are digitally signed.
PKI Repository
Certificates and CRLs need to be publicly available for the end entities that perform
validation and encryption. A typical solution for publishing certificates is to use an
LDAP directory or a web server as a PKI repository. The Lightweight Directory Access
Protocol (LDAP) has become the de facto standard procedure for CRL and certificate

2.2 Insta Certifier

Insta Certifier is a public-key infrastructure (PKI) platform for issuing and managing
digital certificates both for users and machines. It enables strong, two-factor authentication based on smart cards and USB security tokens for storing the user private keys
in a tamper-resistant and portable environment. It provides manageability for very
large PKI environments by introducing centralized management of authentication keys
with support for scalable revocation and key updates.
Insta Certifier : Product Description

Chapter 2: Introduction

This section introduces Insta Certifier.

2.2.1 Basic Components

Insta Certifier has a fully open, standards-based architecture together with flexibility
for configuring certificate policies and publishing practices. Insta Certifier adapts to existing corporate security policy instead of introducing constraints, and is easily integrated into complex and heterogeneous environments, where support for multiple
third-party security applications is also needed. Therefore, the same authentication
platform is used for authenticating users and machines, independent of the specific
access method. In addition to improving security and manageability of large deployments, Insta Certifier provides IPSec-based remote access VPNs and web browsers
with strong, two-factor authentication capabilities.
The architecture of Insta Certifier is fully modular, thus facilitating scalability and reliability for large deployments. It supports virtual certification authorities (CAs), logically
independent CAs running on a single system and database, and makes it possible to
cost-effectively operate complex trust hierarchies needed to separate user identities
into different jurisdictions within the corporation. Insta Certifier also includes a commercial database as an embedded internal data storage enabling reliable data backup
and recovery practices.
Figure 21 presents an overview of the functional architecture of Insta Certifier. There
are two main components: Certifier Engine and Certifier Server.
The Certifier Engine and the Certifier Server may be run on different machines, and
there may be several Servers connected to one Engine. The Engine connects to the
internal database of Insta Certifier and performs all CA/RA private-key operations.
The Engine also implements the certificate policy, and serves the Certifier Servers.
The Certifier Servers can have one or more front-end services running. The services
are the following:

External Enrollment Client Service provides means of communication between

RA and CA components, and cross-certification.
LDAP Authentication Service provides LDAP-based authentication in web enrollment and SCEP enrollment.
Administration Service provides web-based CA/RA administration access to
the Certifier Engine.
SCEP Service provides enrollment services for VPN applications using the Simple Certificate Enrollment Protocol (SCEP).
CMP Service provides certificate life-cycle management services using the Certificate Management Protocol (CMP).
Web Enrollment Service provides enrollment pages for popular browsers, including PKCS #10 enrollment.
OCSP Responder Service provides online certificate status services.
Publishing Service publishes certificates and certificate revocation lists (CRLs)
in a directory, a web site, or other repository.

The different services can be divided between multiple Certifier Servers running on
different machines - or all the services can be run on the same Certifier Server. The
communication between the Servers and the Engine is protected with the Transport
Layer Security (TLS) protocol, provided as a part of both Certifier Server and Certifier

Insta Certifier : Product Description

Chapter 2: Introduction

The optional hardware security module (HSM) is a third-party cryptographic device for
storing the private keys of CAs. This device is not part of the standard Insta Certifier
solution but is an optional supported component. For more information on supported
HSM products, see Section 4.3.3 (Hardware Security Modules).

Figure 21: Architecture of Insta Certifier

2.2.2 Directory
Directory may be used as a public repository for certificates and certificate revocation
lists in a PKI. Insta Certifier uses the Lightweight Directory Access Protocol (LDAP) for
publishing certificates and CRLs in a directory. The use of the standard LDAP protocol
enables the customer to use any third-party LDAPcompliant directory server.
Use of an LDAP directory is not mandatory, and if the customer so prefers, the certificate revocation lists can be published on a web server with HTTP.

Insta Certifier : Product Description

Chapter 3: Features

Chapter 3

Insta Certifier offers a set of CA/RA features and functionalities that fully caters for the
needs of a certification service provider or an enterprise deploying an internal PKI.
This chapter lists the most important features and functionalities of Insta Certifier.

3.1 Certificate Management Features

Insta Certifier contains all basic features that are needed for operating a certification
authority or a registration authority.
Online certificate lifecycle management
The main purpose of a CA is to provide certification services to end entities. Insta Certifier provides flexible and reliable end-entity certification functionalities that can be
easily configured to fit the needs of different services and environments.
Various third-party VPN devices, remote access clients, and web browsers can be
used for enrolling certificates via Insta Certifier. Costs are saved since Insta Certifier
does not require the installation of proprietary desktop components.
Web-based self-enrollment
Insta Certifier offers different deployment options including web-based self-enrollment
and the use of registration authority (RA) for rolling out PKI-based two-factor authentication. Thanks to the standards-based approach, a wide variety of authentication token and smart card products can be used with Insta Certifier for secure storage of user private keys.
Registration authority (RA) features with token personalization option
A registration authority (RA) is an instance that performs the identification of the prospective certificate holders, and vouches that the certificate to be issued and the identity of the subject match. An RA entity is very similar to a CA entity. It has a certificate
policy, it may perform publishing, and it has authorized operators that manage the RA.
The main difference between a CA and an RA is that instead of issuing certificates, an
RA signs certification requests that it sends to a CA. A significant difference between
the two is that RAs do not sign CRLs.
Having the RA component available in a PKI product adds flexibility and eases the
distribution and handling of large organizations and their user base. The RA acts as

Insta Certifier : Product Description

Chapter 3: Features

an intermediate between the end entity and the CA by assuming some of the CAs
In a geographically distributed PKI it makes sense to use some kind of on-site endentity authentication. Usually this means that the RA administrator identifies the certificate applicant face-to-face and then signs the certification request with the RA private
key and sends the request to the actual CA. An example of this could be the departmental IT support personnel of a large corporation functioning as RAs between the
departments they serve and the corporate CAs. Another example is a certification
service provider that distributes RA functions and software to its customers while performing as a central CA to all customer RAs.
The CA and RA components of Insta Certifier use the Certificate Management Protocol (CMP) for communication between them.
As an optional component, the Insta Certifier includes the Insta Token Master application. Smart cards and USB tokens provide a safe way to store private keys of end entities. Insta Token Master adds smart card and token personalization and registration
functionality to a PKI. It allows generating private keys in a smart card, creating a PKI
profile in the card, and enrolling user certificates. Insta Token Master can be used in
both RA and end-entity mode.
Flexible certificate issuing policies
Insta Certifier adapts to the real-life business processes of both service providers and
enterprises. It provides freedom to define certification practices without technical restrictions.
Manual and online cross-certification
In a situation in which independent PKIs are inter-connected, a need for crosscertification arises. Current PKIs do not offer much in the way of interoperability support, and it is likely that crosscertification must be done manually.
Insta Certifier provides a way for online cross-certification (CMP) between two Certifier deployments. Also manual cross-certification (PKCS #10) can be done to provide
support for cross-certification with third-party CAs.
Online private key backup and recovery (CMPv2)
This feature enables online key backup, in which the CMPv2 client sends its key pair
to the CA in a CMPv2 message. Insta Token Master is an example of a client-side
application that supports CMP key backup.
CA private key storage in a hardware security module (HSM)
The private key of the CA is the most critical piece in the security setup of the PKI. If
this key is compromised, the security of the whole PKI must be considered compromised. The requirements for secure storage of this key are extremely strict.
Insta Certifier features the possibility to store the private keys of CAs in hardware.
This feature makes the PKI implementation more resistant to physical attacks as
hardware-stored private keys are easier to protect from being compromised than keys

Insta Certifier : Product Description

Chapter 3: Features

that are stored in software. Insta Certifier supports the use of a third-party hardware
security module (HSM).
CA/RA private key storage in secure software environment
Insta Certifier features the possibility to use password protection for an encrypted
CA/RA private key, if a hardware-based storage is not available.
MicrosoftWindows 2000/XP logon certificate issuance
Insta Certifier can be used to issue and store certificates on tokens to allow smartcard-based logon to a Windows 2000/XP domain.

3.2 Revocation Features

Insta Certifier provides several options for distributing the revocation information in the
Periodic CRL publishing
Revoked entities can be included in certificate revocation lists (CRLs) signed by the
CAs that have issued the revoked certificates.
Per-revocation CRL publishing
A new CRL can be published after each revocation, which can in certain situations
add to the security of the PKI system. Although OCSP is the ideal solution for providing real-time certificate status information, currently there are not many clients that
support it. This feature of Insta Certifier can bring OCSP-like functionality to the PKI
without the need to invest in separate OCSP components on the client side.
Self-revocation based on pre-shared key (PSK)
In environments where the PKI security policy allows it, the end users can revoke their
own certificates via the web enrollment pages, helping to reduce the workload of the
PKI administrators. A pre-shared key (PSK) is used to authenticate the revocation request.
Built-in OCSP Responder Service
Certificate revocation lists (CRLs) are usually published periodically. In some PKI application fields, however, this method is unacceptable as real-time information about
the validity of certificates is required (for example banking and e-commerce). The use
of CRLs in large-scale PKIs may be problematic as the CRLs may grow very large if
all the revoked entries are situated in a single list.
RFC 2560 describes the Online Certificate Status Protocol (OCSP) that overcomes
the issue of realtime certificate validity information.

Insta Certifier : Product Description

Chapter 3: Features

The OCSP Responder Service of Insta Certifier can be enabled and configured
through the Administrator Service of Insta Certifier. The OCSP Responder Service
provides accurate information on the status of a requested certificate to the OCSP client (end entity) in real-time.

3.3 Scalable Architecture

The architecture of Insta Certifier is fully modular, which allows scalability and reliability for large deployments.
A back-end Certifier Engine and front-end Certifier Services
Different front-end PKI services and the Certifier Engine can be distributed on dedicated hosts in large-scale deployments for added availability, redundancy, and security. Services such as enrollment, administration, and publishing can all run on separate
machines if needed. The whole Insta Certifier system can be configured centrally
through the Administration Service with no need for local service management. Wellplanned deployment allows scaling up the system as the business grows.
On some platforms, installing and configuring databases requires time and expertise.
To ease the installation, Insta Certifier includes a commercial relational database
(Sybase Adaptive Server Anywhere).
The database can be installed automatically along with Insta Certifier and no additional configuration is required. The whole installation process is over in minutes.
Also, the use of a commercial database allows easy implementation of backup procedures to ensure quick recovery in case of disk failure.
Adding the flexibility for the customer to choose over the embedded Sybase database,
Insta Certifier now supports also Oracle on Windows platforms through ODBC drivers.
Multi-platform support for all Certifier components
Both the Certifier Engine and the front-end Certifier Servers can be installed either on
HP-UX, Linux, Solaris, or Windows.
Support for duplicating Certifier Servers and Services for higher availability
Redundancy can be added to the system, for example, by setting up several Publishing Services.
Multiple Virtual CAs/RAs within the same installation
New Virtual CAs with their own set of certificate policies and configurations can easily
be created by a superuser administrator via the administration GUI without the need
to invest in additional hardware. This powerful feature makes Insta Certifier an ideal
platform for hosting a managed multi-CA service environment.

Insta Certifier : Product Description


Chapter 3: Features

Secure communication between Certifier components

Some components of the Insta Certifier can be separated from each other. The separation can be used to make the system structure modular and to better utilize the potential of the employed hardware. In a typical Insta Certifier deployment, for example,
enrollment services may need to reside outside firewalls for end-entity access while
the Certifier Engine is fully protected from the rest of the network.
To enable secure communication between separated system modules Insta Certifier
uses the TLS protocol that utilizes certificate-based authentication. TLS certificates for
the different components of Insta Certifier are created during system installation and
updated periodically.
Automated handling of internal system certificates
When the connections between PKI components are secured with TLS, there is a risk
that the maintenance and administration of these secure connections will be timeconsuming.
Insta Certifier automates these TLS-related tasks and hides them from the administrator. All TLS certificates for internal communications of the Insta Certifier are updated
automatically before they expire (unless, of course, they are revoked or suspended).
This feature allows the administrator to set the validity period for TLS certificates to be
quite short without adding a lot of administrative overhead.

3.4 Directory Integration

Insta Certifier uses the Lightweight Directory Access Protocol (LDAP) for publishing
certificates and CRLs in a directory. The use of the standard LDAP protocol enables
the customer to use any LDAP-compliant directory server.
Certificate and CRL publishing to standard LDAP directories
To make revocation information available for all end entities, CRLs can be published
in a public directory server using LDAP.
Flexible publishing schemas
Insta Certifier can use LDAP directories freely regardless of the directory schema.
Thus, existing enterprise directories can be used for publishing certificates and other
user data. IT management becomes easier since there is no need to maintain duplicate data.
Insta Certifier also supports LDAPv3, which allows the use of international alphabets
in directory publishing.

Insta Certifier : Product Description


Chapter 3: Features

Support for Microsoft Active Directory

Insta Certifier works smoothly in the Microsoft Windows environment and supports
publishing certificates and CRLs to Microsoft Active Directory. Insta Certifier can also
be used to issue certificates for Windows Smart Card Logon.
Out-of-the-box TLS protection of LDAP publishing
It is quite common that the directory services of the PKI are somewhat separated
(physically and organizationally) from the actual CA. This is also a reasonable approach, as the CA should be well protected and located in premises with strict access
control. In actual PKI implementations it may be feasible to have different instances
responsible for the actual CA and the directory services.
The physical separation of certification and publishing services means that secure
connections are required between the CA and the directory. Insta Certifier employs
the TLS protocol to secure internal communications of the PKI system. Using TLS ensures that the LDAP directory password is not exposed to the public. Using TLS with
client authentication can eliminate the need for a directory password altogether.

3.5 Administration
Insta Certifier provides advanced possibilities for managing the access rights of the
PKI administrators.
Administrators can be restricted to specific CAs
Insta Certifier allows restricting the administrators read-access to the CAs so that
they see only those CAs they have access to.
Dual control and fine-grained separation of duties
The security of the system can be improved by defining access control rules for PKI
administration. Different tasks from user management to system configuration can also be given to different administrators.
Insta Certifier now features the powerful option of requiring any amount of operators
for system changes to take effect. With this option the CA can make sure that no one
operator, even with superuser access rights, can tamper with the configurations set
forth by the certificate policy.
Event logging and audit trail
The need for auditing usually comes from specific regulations. For example, certain
quality certificate statements require that the system which issues these quality certificates must be auditable. Insta Certifier provides now advanced auditing functionality.
All configuration changes through the administration web interface leave a visible trail,
which can be verified afterwards.

Insta Certifier : Product Description


Chapter 3: Features

3.6 Other Features

Insta Certifier provides several other advanced features, including easy customization,
support for international character sets, and compliance with the EU Directive on Electronic Signatures.
Customizable web enrollment pages for easier branding
The Insta Certifier operator can easily customize the web enrollment pages to include
only those fields and options that are relevant in the specific use scenario. With this
feature, a service provider can create the web enrollment pages according to the customers requirements.
Insta Certifier supports extensively the use of UTF-8 character encoding, which
makes the product especially suitable for deployment in various Asian countries. All
user interfaces of Insta Certifier are browser-based, which allows using the advanced
UTF-8 features of modern browsers for both data input and output. Also, thanks to the
LDAPv3 support, Insta Certifier can publish UTF-8 content in the directory.
Compliant with the EU Directive on Electronic Signatures (1999/93/EC)
In Europe, the compliance with the EU Directive 1999/93/EC (framework for electronic
signatures) may require the use of RFC 3039 qualified extensions.
Note, however, that using Insta Certifier does not automatically imply compliance with
the ETSI requirements related to this EU directive, but there may be additional requirements depending on the national implementation of the directive.

Insta Certifier : Product Description


Chapter 4: Architecture

Chapter 4

The architecture of Insta Certifier is modular. The two main components of Insta Certifier are the Certifier Engine and the Certifier Server. The Certifier Engine performs all
CA and RA private-key operations and certificate policy decisions. The Engine uses
an internal Certifier Database, to which the connection is established over Open Database Connectivity (ODBC). Insta Certifier ships with an embedded database, SQL
Anywhere from Sybase Inc. that is used by default as the internal database. Optionally, an Oracle database can be used to replace the embedded database.
In addition to the Certifier Engine, one or more instances of Certifier Servers are required to provide the frontend Certifier Services such as enrollment, publishing, and
administration. The services that can be provided by the Certifier Server(s) are:

Administration Service
CMP Service
External Enrollment Client Service
LDAP Authentication Service
OCSP Responder Service
Publishing Service
SCEP Service
Web Enrollment Service

The distributed service concept of Insta Certifier brings added system scalability. The
distribution of services allows for the PKI deployment to be flexible in picking the required services. For example, if the OCSP Responder and CMP Services are not
supported by the end-entity applications, they do not need to be used in the Certifier
Different services require different levels of accessibility and security. Enrollment Services typically need to be available for a wider part of the network than, for example,
the Administration Service. By running these services on separate Certifier Server instances, they can be situated on separate host computers (for example, Enrollment
Services outside the corporate firewall and the Administration Service in a tightly secured network). Using multiple Certifier Server instances to distribute the PKI services
provides more flexibility in the PKI deployment.
Another major benefit of the Certifier Servers with a customizable service set is the
possibility to add system redundancy. In a worst-case scenario, the unavailability of a
single service may prevent the use of the whole PKI. By duplicating critical services to
multiple Certifier Server instances, a degree of redundancy can be achieved in the
system. Duplicating services for redundancy purposes requires careful analysis on the
need and function of the deployed services.

Insta Certifier : Product Description


Chapter 4: Architecture

Insta Certifier requires typically also an LDAP directory, where the CRLs, certificates
and other user data can be published. Almost any third-party LDAP-compliant directory server can be used as a PKI repository with Insta Certifier.
In addition to the Certifier Engine, its internal Database, Certifier Server(s), and the
optional publishing directory, also end-entity applications are required for the PKI. By
providing multiple enrollment protocol and publishing options, Insta Certifier provides
support for a wide variety of third-party applications. See Insta Certifier Interoperability
Guide for more detailed information and instructions on how third-party endentity applications can be used with Insta Certifier.

4.1 Communication between Processes

The Certifier Servers communicate with the Certifier Engine using a TCP-based
communication protocol. The data that is being transmitted between processes is represented as association lists (ASL).
When the Certifier Server(s) are situated on different hosts in the network than the
Certifier Engine (a typical case), the communication has to be secure to prevent possible eavesdropping or active attacks against the Certifier Engine. Eavesdropping on
the communications could be used to catch sensitive data such as directory administrator passwords, and active attacks could be used to attempt to crash the Certifier
Engine itself. Transport Layer Security (TLS) with certificate-based authentication is
used to protect internal communications of the components in Insta Certifier. First TLS
certificates are created for the Engine and Server during the system installation, and
keys are automatically updated and new certificates enrolled before the expiration of
the old certificates.
Directory administrator passwords are used by the Publishing Service as a basis for
directory access control.
TLS can also be used to provide confidentiality and server authentication in the LDAP
Figure 41 shows an example setup where Certifier Services are distributed between
three Certifier Servers. An Administration Service is running on one server instance,
enrollment and OCSP services are running on the second server instance, and a Publishing Service on the third server instance.

Insta Certifier : Product Description


Chapter 4: Architecture

Figure 41: Relationships between Certifier components

It is usually a good idea to use more restrictive firewall settings for the Administration
Service and allow operators to log in only from inside the local network. If a more relaxed policy is desired, at least the Administration Service configuration should be
checked to ensure that only TLS-protected (with both client and server authentication)
connections are allowed.

4.2 Certifier Services

This section describes the different services that provide the functionalities and processes that are necessary for the operation of a PKI based on Insta Certifier.

4.2.1 Administration Service

The Administration Service provides CA and RA operators a graphical user interface
for performing the PKI management operations (including request processing, certificate revocation, and entity management).
For system administrators, the Administration Service provides access to reviewing,
testing, and modifying the configuration of the Certifier system. The Administration
Service is accessed over an HTTP connection, and all management and configuration
actions can be performed using the graphical user interface running on a common
web browser.
The administrators remote access to the Administration Service must be protected,
even if the remote login is done within a corporate network. In a worst-case scenario,
a compromised administrative connection with super-user login may lead to the compromise of the whole PKI. Utmost care must be exercised in maintaining security of
the connections between the web browser and Administration Service. The browser
connections that facilitate the administrators sessions are protected with Transport
Layer Security (TLS), the de facto web-browser security protocol. The Administration
Service can be configured to require client authentication for additional security. This
method requires that the administrators possess an authorized certificate for authentication when logging in.

Insta Certifier : Product Description


Chapter 4: Architecture

The Administration Service itself should run on a machine that is tightly secured, and
has no other vital services running.

4.2.2 CMP Service

The CMP Service provides the PKI certificate life-cycle management capabilities. The
CMP Service acts as a server for handling incoming CMP messages (including certification requests and revocation requests). The CMP Service can be configured to provide either TCP or HTTP-based transport for the Certificate Management Protocol
Insta Certifier uses the CMP Service for communications between RAs and CAs. A
registration authority signs all messages with its private key, and the CA then verifies
the origin of the requests (since it has issued the RA certificate that is used).
The initial enrollment of the RA is also performed by using CMP. When the initial certification request is made, a pre-shared key is used for authentication. The Insta Certifier system that houses the RA must run the External Enrollment Client Service to perform the client side of CMP, and the system that houses the CA must run the CMP
Service to perform the server side.
The CMP Service also provides tools for CA-to-CA interaction (including crosscertification between separate PKI domains and issuance of sub-CA certificates). Similarly to RA-CA case, the enrolling CA must run the External Enrollment Client Service
and the issuing CA must run the CMP Service to process the CA certification request.
The CMP implementation of Insta Certifier is based on Internet-Draft documents draftietf-pkix-rfc2510bis and draft-ietf-pkix-rfc2511bis, also known as CMPv2.

4.2.3 External Enrollment Client Service

In certain cases, Insta Certifier needs to act as an enrollment client initiating enrollment with an external CA. This is necessary when an RA requests a certificate from a
CA and when a CA requests a cross-certificate or a sub-CA certificate from an external CA. The External Enrollment Client Service is needed to run these client-side operations using CMP. Every Insta Certifier system that has at least one RA has to have
an External Enrollment Client Service running on a Certifier Server instance.
When the external CA is not online, certification requests can be stored in a file by the
External Enrollment Client Service. Also, if a third-party CA does not support online
CMP enrollment, the possible crosscertification request can be stored in a file and
transported to the CA by other mechanisms.

4.2.4 LDAP Authentication Service

The LDAP Authentication Service is used for LDAP-based authentication in web enrollment and SCEP enrollment. The service can be used to authenticate users in enrollment based on their LDAP credentials (username and password).
LDAP authentication is made by binding to the specified LDAP server with the credentials given by the enrolling user. If the binding is successful, Insta Certifier will look for
a matching entity in its database. If one is found, the authentication is successful.

Insta Certifier : Product Description


Chapter 4: Architecture

4.2.5 OCSP Responder Service

The OCSP Responder Service provides client applications a point of control for retrieving real-time information on the validity status of certificates using the Online Certificate Status Protocol (OCSP). The OCSP Insta Certifier Product Description Responder Service has a certificate that has been issued by one of the Certifier CAs.
The end-entity applications that use OCSP need to trust the issuing CA, so that they
can validate the signed responses. It is possible to configure the system so that the
OCSP Responder Service gives out information only on certificates issued by selected CAs.
For more information on OCSP, see RFC 2560.

4.2.6 Publishing Service

The Publishing Service provides the means to publish the issued certificates and certificate revocation lists for public use. The most common publishing method is to use a
directory server that the certification service subscribers can use to retrieve the latest
certificates or CRLs. The most common directory access protocol used for this purpose is the Lightweight Directory Access Protocol (LDAP). Publishing Service configurations include the LDAP connection-related parameters such as directory server address, directory administration login and password (and optionally SOCKS server and
publishing retry parameters).
If there are multiple directories for publishing within a single Certifier installation, one
Publishing Service has to be created for each directory access.
The Publishing Service can also be used to store certificates and certificate revocation
lists in a file and to run external scripts that perform the publishing. Using external
publishing mechanisms provides an easy means to use publishing methods such as
e-mail or FTP.
The Publishing Service supports both LDAPv2 and LDAPv3. LDAPv3 is recommended for its better security and compatibility between different implementations.
When there is a need to secure the LDAP connections to prevent eavesdropping of directory administrator passwords, TLS can be used (given that the directory includes a
TLS server).
Operational requirements for LDAPv2 in a PKI are described in RFC 2559. The minimum LDAPv2 schema set including object class and attribute definitions for common
PKI objects can be found in RFC 2587. LDAPv3 is described in RFC 3377.

4.2.7 SCEP Service

The SCEP Service provides Simple Certificate Enrollment Protocol services for clients
that support this protocol. SCEP is a protocol that defines the procedure for a client to
request certification from a CA. SCEP is widely used in IPSec gateways and IPSec
host applications.
There are two parts in SCEP. First the CA certificate is fetched from the SCEP Service by using an HTTP GET operation and identifying the CA whose certificate is
fetched. Once the CA certificate has been received, certificate for the end entitys own

Insta Certifier : Product Description


Chapter 4: Architecture

private key can be enrolled. Pre-shared key can be used to authenticate the end entity
and to automate the process.
A client can send a certification request directly to the CA or the certification can be
done via an RA. When an end entity requests the RA certificate using the RA name to
identify it, both the CA and RA certificates are given out by the SCEP Service. The
end entity needs both certificates as the CA certificate is needed after the enrollment
when validating the signature of the end entitys own certificate.
The SCEP protocol is described in the Internet-Draft document draft-nourse-scep.

4.2.8 Web Enrollment Service

TheWeb Enrollment Service provides a point of connection for the web-based enrollment clients that use the certificates issued by Insta Certifier. This service requires a
network connection to the same network that the clients of the CA use.
The main function of theWeb Enrollment Service is to offer web pages that are customized to include scripts that initiate private key and certification request generation
in a web browser. Also PKCS#10 certification requests, generated by other applications, can be submitted via the enrollment form of the Web Enrollment Service. This
allows support for applications that do not provide other online enrollment mechanisms.
Other functions of the Web Enrollment Service are CA certificate and CRL downloading. The Web Enrollment Service can be run both in TLS-protected and non-TLS
mode depending on the requirements.

4.3 External Services

Insta Certifier utilizes an internal Database for data storage and typically also a directory for certificate and CRL publishing. Optionally a third-party cryptographic device
can be used for handling private-key operations of the CAs.
ODBC is used as the API for database connectivity. With the embedded database of
Insta Certifier, there is no need for additional drivers. With the optional Oracle support,
separate ODBC drivers are required (not provided with Insta Certifier).
Insta Certifier supports standards-based directory publishing using LDAP as a publishing protocol. This allows the use of any standard compliant directory server product together with Insta Certifier. A directory server can be added to the Insta Certifier
environment also after the initial installation, as the LDAP publishing configuration can
be defined by using the web-based Administration Service.
The following sections briefly describe the external services available (ODBC, LDAP,
and hardware security modules).

4.3.1 Open Database Connectivity

Insta Certifier includes the Adaptive Server Anywhere database from Sybase Inc. The
database is installed during the Insta Certifier installation.

Insta Certifier : Product Description


Chapter 4: Architecture

Open Database Connectivity (ODBC) provides both an API and a databaseindependent driver layer between the Certifier Engine and the actual database back
end. The Certifier Engine is linked with a generic ODBC driver manager which loads a
database-specific driver according to its configuration at runtime.

4.3.2 Lightweight Directory Access Protocol

Another external service typically required by Insta Certifier deployment is a directory
server supporting LDAP. Since most of the directories include LDAP support and it
has become a standard especially for PKI publishing purposes, third-party directory
servers can be used freely in a PKI based on Insta Certifier.
Publishing operations require privileged login to enable directory modification. Directory administrator username and password are used in LDAP to authenticate the LDAP
client. To provide confidentiality and authentication, TLS can be used to protect the
publishing if the directory server supports TLS on the server side.
End entities need LDAP services typically when they are fetching the latest CRL or
searching for encryption or sub-CA certificates. Especially certificate searching is typically a challenging task for the end entity, since the end entity may not have any prior
information of the certificate location in the directory tree. Therefore, it is important to
plan carefully how the PKI data is organized in the directory.
In a large-scale PKI, the directory is typically the most heavily used part of the system.
On the other hand, it is also the single point of failure, especially if CRLs are published
there. Adding redundancy can be used to manage directory-related risks. Directory
replication can be used on the directory side to balance the load. Insta Certifier itself
provides a simple and cost-effective way to distribute certificates and CRLs in multiple
directories. Multiple Publishing Services can be associated to a single CA to publish,
for example, CRLs in multiple directories.
The directory server provides a powerful system for organizing user data and providing the PKI objects available for each end entity. However, a directory server is an optional component and may not be needed in each PKI. For example in several applications there is no need to search certificates from external databases since they are
sent between peers in the security protocol. CRLs can also be published by using a
web server (HTTP).

4.3.3 Hardware Security Modules

A hardware security module (HSM) is a way to store the private keys of the CA in a
high security hardware device to prevent CA compromise through stolen keys.
Insta Certifier provides support for HSM modules through the PKCS #11 interface.
HSMs by Thales have been tested. HSM is an optional external component, and it is
not required if only software CA keys are used.
For more information, see

Insta Certifier : Product Description


Chapter 4: Architecture

4.4 Certification Request Processing

To add a new end entity to a public-key infrastructure (PKI), the end entity has to create a key pair, and a certification authority (CA) has to certify the key pair. This process of an end entity enrolling to a PKI is commonly known as certificate enrollment.
In addition to certificate enrollment, there are also other operations that involve communication between end entities, RAs, and CAs. These include updating keys, requesting new certificates for existing keys, requesting revocation for compromised
keys, performing key escrow for encryption keys, and so on. This wider concept can
be called certificate life-cycle management, and certificate enrollment is only a subset
of it.
In a large-scale PKI most of these operations should preferably be automated online
processes. In some systems it may be enough that only the initial certificate enrollment is an online process.
Because of the strict security requirements and the online environment, there have to
be standard ways to perform certificate enrollment and certificate life-cycle management that enable an interoperable multi-vendor PKI system. Insta Certifier supports
the most common certificate enrollment and certificate life-cycle management protocols to achieve interoperability with the various end-entity applications. Several examples of enrolling for a certificate in a PKI based on Insta Certifier through third-party
end-entity applications are provided in Insta Certifier Interoperability Guide.
In Insta Certifier, all end-entity-to-CA interaction is performed via Enrollment Services
running on Certifier Server instance(s). These services perform the messagetransport-related server-side functionality of certificate enrollment or certificate lifecycle management.
There is a dedicated Certifier Service for each protocol:

SCEP Service for enrollment services for VPN applications such as routers and
software clients.
CMP Service acting as a certificate life-cycle management server.
Web Enrollment Service for a web-based enrollment interface.

Each of these Certifier Services check all the incoming messages from end entities.
RA-signed requests are processed by the CMP Service. If the message can be
parsed (and understood), the Service forwards this request to Certifier Engine to be
resolved and processed according to the defined policies. Malformed requests are
dropped immediately by the Service. As the Enrollment Services do not possess the
CA or RA private keys, they cannot decrypt any encrypted messages arriving to the
CA or RA.
A certification request is processed as illustrated in Figure 42.

Insta Certifier : Product Description


Chapter 4: Architecture

Insta Certifier : Product Description


Chapter 4: Architecture

Figure 42: Processing a certification request


An end entity (an end user, a device, or an application) or an RA makes the certification request to the CA (or RA).


CMP, SCEP, or Web Enrollment service of Insta Certifier receives the request.
The request is decoded. Malformed requests are dropped.


The request arrives to the Certifier Engine and is pre-processed.



Protocol dispatching: further processing depends on the used enrollment

Verification: the integrity of the request is checked. If the request fails this
check, it is dropped.
Assigning to CA: The request is assigned to a CA (or an RA).
Decryption (SCEP only): The request is decrypted.
Mapping: The request is mapped to an entity, if an entity has been created
beforehand and the request contains a valid shared secret. The mapping
can also be done via an RA, either based on an already existing RA signature, or based on an existing valid key.
POP: Proof-of-possession check is made to the request. If the check fails,
the request is dropped.

A certificate template is created based on the request and the template is processed in Certifier Engine according to the CA policy. The policy processing consists of four policy chains. After each chain, the certificate template can be either
accepted or rejected.


The Receive request policy chain is applied. Based on policy and end entity mapping, further processing can be either automatic or manual. If automatic processing is applied, the template is passed directly to the Accept
request policy chain. If manual processing is applied, a message about
this is sent to the client. The client can poll the request status later.
The View request policy chain is applied when the CA operator views the
The Update request policy chain is applied when the CA operator updates
the request.
Finally the Accept request policy chain is applied.


If the policy chains end in acceptance, the certificate template is now signed with
the CA private key. In case of an RA, the request is signed with the RA private
key and forwarded to the CA. Note. If CMP is used, it is possible to skip the POP
check at step 3f and establish POP but now. The processing will not continue before POP has been established.


The certificate is published in the Directory according to the publishing rules. If

the client has the enrollment session still open, the certificate is sent to the client
via the enrollment service. Otherwise, the client can poll the certificate later.

Insta Certifier : Product Description


Chapter 5: Deploying a PKI

Chapter 5

Deploying a PKI
This chapter outlines some of the major issues that need to be addressed when deploying a public-key infrastructure (PKI) solution.

5.1 The PKI Model

The PKIX specifications allow a great deal of flexibility in designing the trust model of
a PKI and the sharing of responsibilities within the PKI. The standard allows constructing complex CA hierarchies for distributing the certification services between multiple
CAs and delegating user identification and other tasks to RAs. On the other hand, according to the standard, it is also possible to create a PKI with a single CA with no RA
a set-up that may best suit small-scale PKI deployments.
Before the actual deployment phase, the model and setup of the PKI must be carefully
considered. An efficient and secure trust model and PKI architecture should be drafted by analyzing the needs of the organization and the requirements of the situation.
The planning done in this phase is critical to the success of the PKI deployment.
The following sections present some issues that are important when the PKI hierarchy
and roles are considered.

5.1.1 CA Hierarchy
One of the essential concepts of PKI is the distribution of trust between the CAs - a
chain of trust that binds different CAs together in a CA hierarchy. In every PKI there is
a root CA that the end entities ultimately trust. By creating sub-CAs whose certificates
are signed by the root CA, the trust can be derived automatically to these new subCAs.
CA Private Key Security
The security requirements of the root CA private key are very strict. If the private key
of the root CA is compromised, the security of the whole PKI is compromised.
To maximize the security of the root key, access to the root private key storage should
be strictly limited to the minimum necessary personnel. This may mean that there is
no online connection to the Certifier Engine which is running the root CA. However,
online connection is a requirement for smooth end-entity enrollment. By creating subCAs for end-entity certification and using offline root CA just to issue sub-CA certificates, both of these requirements can be satisfied.

Insta Certifier : Product Description


Chapter 5: Deploying a PKI

Extra security can be added by using a hardware security module (HSM) to protect
the CA private key.
Dividing Certification Responsibility to sub-CAs
Typically in a PKI there is a need to provide various different certificates for different
purposes within a single PKI. A company might want to use certificates to encrypt email and to authenticate users in secure web sessions. While it would be possible to
issue certificates for both of these purposes with a single CA, it may prove to be more
convenient to create two sub-CAs under a single trusted root CA. One of the sub-CAs
would then issue e-mail certificates and the other TLS certificates. Both of the subCAs would have separate certificate policies that define the applicability of the issued
When separate sub-CAs are used, as in the example above, the individual security
considerations of each certification service can be taken into account in the CA private
key length and key storage environment.

5.1.2 Delegating Duties to Registration Authorities

The registration of users into a PKI always includes identification of the user prior to
issuing the certificate. This identification is performed as a part of the certification
practice that the CA (that issues the certificate) employs, and forms the basis for the
trustworthiness of the whole system.
To make sure that the user is identified correctly, the identification process typically
involves some out-of-band interaction between the authority and the user (end entity).
The most common method is naturally face-to-face communication and identification
at the time of registration. In a (geographically or organizationally) distributed PKI
these identification tasks can be delegated to Registration Authorities (RAs). The use
of RAs increases the scalability of the PKI system considerably.
Use of RAs always involves costs because of the required RA administrators and system maintenance. RAs should, therefore, be used only in the system if the costs of the
centrally managed user identification costs exceed the costs of the RA maintenance.
If the PKI deployment involves setting up a certification service provider system where
the service provider acts as a trusted third party, some RA systems could be provided
for the customers. This way an enterprisescale customer of a certification service provider may take care of the employee identification by dedicating an RA administrator
for that task.

5.1.3 Cross-Certification
When enterprises deploy their internal PKIs with their own internal root CAs, it results
in multiple independent PKI domains. When two such independent PKIs need to be
connected, this connection can be achieved by having the root CAs of each domain
cross-certify each other. This means that end entities in both domains may trust the
certificates of the other PKI because the CA of their home PKI has issued a CA certificate for the root CA of the other domain. Cross-certification is considered when two
independent PKI systems need to get interconnected in order for their end entities to
be able to perform transactions with each other. Sometimes PKI deployment may include cross-certification with one or more PKIs.
Insta Certifier : Product Description


Chapter 5: Deploying a PKI

If the need for cross-certification is known in the deployment phase, there are some
important issues that must be taken into account. Two important criteria for a successful cross-certification are the technical CA-to-CA interoperability as well as the consistency of the certificate policies and certification practices of the separate PKIs. If
the separate PKI systems are provided by different vendors, it is important to make
sure that the PKI systems interoperate together. If certification paths containing certificates issued by CA systems from two different vendors cannot be verified by the end
entities, the PKI is useless.
Another important issue in cross-certification is the compatibility of the certification
practices of the two PKIs. Cases in which the certification practices of the crosscertified PKIs differ very much may prove to be problematic. For example, if one of the
PKIs follows a loose identification process and does not recommend using certificates
to secure mission-critical data, while the other maintains extremely strict practices to
issue certificates for high-value transaction signing, confusion and problems may
arise. In this kind of cross-certified environment, the end entities of the latter PKI
should not rely to the other PKIs certificates to the same extent as their own certificates. In practice this kind of distinction is very hard to implement and should be
avoided. Painless cross-certification requires that the two cross-certified PKIs function
with roughly similar certificate policies.

5.2 End-Entity Applications

A PKI deployment should always proceed from a clear need for specific end-entity
applications that are enabled by the PKI. A typical mistake in deploying a PKI is to
build a PKI without a plan for the end-entity applications that use the certificates. Endentity applications create the need for the PKI; the PKI in itself should not be the goal
of the deployment. Common end-entity applications in a PKI include VPN clients and
devices, web browsers, and e-mail clients.
The end-entity applications may restrict the use of PKI in many ways. For example,
popular applications may not support the revocation mechanism that would have been
chosen otherwise, and a browser may have a fixed trusted root CA set that is not accepted by the policy employed in the PKI. Before the actual deployment, it is important
to consider carefully which end-entity applications will be used. If the installation of
new desktop software is to be avoided or the end-entity application vendors have already been chosen, the limitations and supported PKI features of the applications
need to be taken into account in the PKI planning.

5.3 CA Root Certificate Distribution

Before a newly established PKI can start operation, the CA root key needs to be distributed to all end entities. This distribution is an essential and important part of the
PKI deployment project. Because there is no prior trust relationship between the CA
and the end entities, the root certificate distribution cannot be an automatic online
process with no user intervention. Three common alternatives for the distribution are:

out-of-band transfer
online fetching with fingerprint checking
embedding the root CA certificate in the client software or a smart card.

Insta Certifier : Product Description


Chapter 5: Deploying a PKI

Out-of-band transfer
In this method, the CA certificate is distributed to users face-to-face, or it is sent in
traditional mail, which may (or may not) be seen secure enough for the purpose.
Online fetching with fingerprint checking
In this method the CA certificate may be fetched with a browser or another application. However, as there is no security because the trust has not yet been established,
the integrity of the CA certificate needs to be checked. The integrity of the certificate
can be checked by comparing the fingerprint (a hash value of the certificate) to the
genuine one. For example, a phone call to the CA operator can be used to get the
genuine fingerprint of the root CA certificate. This method is used typically when enrolling certificates to VPN devices.
Embedding the root CA certificate in the client software or smart card
The PKI deployment may involve the installation of PKI-enabled applications for end
entities. In this case, the root CA certificate can be embedded in the installation package. As the software that has access to the users private keys must be trusted, tight
security requirements apply for both the root certificate installation and the application
software installation. If smart cards or other cryptographic tokens are used for storing
the private keys of end-entities, the root CA certificate can also be stored in the same
token. In this case the root key distribution is easy, as the smart cards must be received personally (or in another secure way) in any case.

5.4 Key Backup

When certificates are used for encryption there may be a need to back up private keys
of the users. Without backup the loss of the private key might result in permanent loss
of confidential data. For example, if you lost your private key you would no longer
have access to your encrypted e-mails.
Key backup may be considered only for encryption keys, and there should never be a
need to back up authentication or signature keys. Non-repudiation of transactions
cannot be achieved if copies of the private authentication key or signature key exist.
This also means that encryption keys should never be combined with other keys in
case that key backup is deployed.
The key backup is done after the key generation. If the key is generated by an endentity application, there must be support for private key export in the application. If the
keys are generated by an RA on behalf of the user (which is a typical method with
keys stored on smart cards), the RA may back up the private key.
In Insta Token Master, the private encryption keys can be generated outside smart
cards and then backed up for possible future key escrow. This backup can be made
either locally to the Token Master database or online to the CA database.

Insta Certifier : Product Description


Chapter 5: Deploying a PKI

5.5 Revocation Services and Directory Deployment

While PKI is an effective way to reduce and manage risks in an online world where
wrongful authentication may result in considerable losses, there is a certain amount of
risks involved. The risks center around the Insta Certifier Product Description event of
PKI compromise which could be due to, for example, private keys or smart cards with
easy-to-guess PIN codes being stolen. A PKI must always provide some mechanism
to revoke certificates in the case of compromise. There must also be effective means
by which to publish the revocation information to all end entities that rely on the PKI.
The importance of the information that is secured in a PKI system, as well as the value of the transactions signed define the requirements for revocation. In online banking
and commerce the requirements for real-time revocation of certificates are higher
than, for example, in systems providing e-mail signature and encryption certificates.

5.5.1 Online Certificate Status Protocol (OCSP)

In PKI deployment cases where real-time revocation information is required, Online
Certificate Status Protocol (OCSP) is the appropriate way to publish revocation information. The OCSP Responder Service that runs on a Certifier Server provides the client applications information on the revocation status of certificates.
If rather recent (but not real-time) revocation information is acceptable, periodically
published certificate revocation lists (CRLs) will suffice.

5.5.2 Certificate Revocation Lists (CRL)

Periodically published CRLs contain information on certificates that have been revoked before their natural expiration.
When CRLs are used, the CA needs to publish CRLs in a public repository such as a
web server or a directory server. Whether or not to deploy a directory server is one of
the major decisions that must be made in a PKI deployment.
If there is no other need for a directory server than the CRL publishing, the directory
server deployment is not generally justified. In this case the CRLs can be published to
a web server using HTTP protocol. However, if the organization already has a directory server where all the user information is stored, it might be useful to publish the user
certificates to the corresponding entries and the CRLs to a CA- specific entry.

5.5.3 Revocation Service Implementation Issues

The publishing method and location of the revocation information service (OCSP or
CRLs repository) must be carefully considered and implemented. Regardless of the
chosen publishing method, these services are a potential single point of failure in the
If, for example, the only directory where the CRLs are published is not available, the
whole PKI may not be able to operate. This risk can be lowered by adding redundancy. Insta Certifier allows multiple OCSP responders to be situated on different hosts.
When CRLs are used, Insta Certifier allows the CRLs and certificates to be published

Insta Certifier : Product Description


Chapter 5: Deploying a PKI

in multiple directories. Whether additional redundancy is required for the revocation

should be decided before deployment, because they affect the system requirements.

5.6 Certificate Policy and CPS

Certificate policy is defined as a named set of rules that indicates the applicability of a
certificate to a particular community and/or class of application with common security
It is the responsibility of the CA to define the exact policy that defines the applicability
of the certificates it issues. If there is no well-defined certificate policy, it is up to the
end entities to decide whether they rely on the certificate or not.
By defining a certificate policy and following that policy, the CA can state the purposes
its certificates can be used for. According to the standards, this information can be
embedded in a PKIX extension of a certificate itself. Including this information in the
certificate itself may reduce end entities risks as it enables the end users to avoid unintended use of the certificates.

5.6.1 Certification Practice Statement (CPS)

Certification practice statement (CPS) details the practices that the CA employs in issuing certificates. CPS provides information for a relying party who is making decisions based on a certificate that has been issued according to certain certification
Every commercial CA (such as a certification service provider) should have a published CPS that defines the procedures, operating policy, security controls, and environment according to which the certificates are issued. A link to the CPS document
can be included in the issued certificates to provide information for the certificate user.
In some cases, a CPS may be a part of the written contract between the certification
service provider and the customer. While the CA normally has a single CPS describing the certification practices in detail, it may have multiple certificate policies. This
may be the case if the CA issues different certificates for different purposes.
For more information on the certificate policies and certification practice statements as
well as the standard template for policies, see RFC 2527 (Certificate Policy and Certification Practices Framework).

5.7 Organizational Responsibilities

Running an enterprise PKI will employ several people at least part-time. The main responsibilities can be roughly divided into the following tasks:

System administration
CA administration
RA administration

Insta Certifier : Product Description


Chapter 5: Deploying a PKI

System Administrators
System administration duties include the administration of Certifier Engine and the
various Certifier Servers that make up the Insta Certifier system. The configuration
and maintenance of the Enrollment and Publishing services are also duties taken care
of by the system administrators.
RA/CA Administrators
RA and CA administration duties include certificate request processing, entity management, user authentication, and certificate revocation. In a large-scale PKI it may
also be necessary to divide CA and RA administrators further into different privileges.
Operations such as CA policy editing and CA creation can be delegated to special
administrators, while everyday request processing can be handled by normal operators. In Insta Certifier the administrator privileges can be defined flexibly to allow the
PKI deployer to decide the roles of the different administrators.
Mandatory requirements for a successful PKI deployment are resources to run the
system and skillful administrators with defined responsibilities.

5.8 Private Key Security Issues

The private keys of the PKI entities (CAs, RAs, and end entities) are critical secrets of
the PKI. The security of a PKI system depends heavily on the safe storage of the private keys. In most cases today, the end-entity private keys are stored on software, either in plain-text form or in encrypted form protected with passwords. This may be sufficient if the access to these keys is limited (no outsider access), but in systems that
are open to the outside network another method should be selected for key storage.
In case a private key is compromised, the certificate for the key must be revoked and
the key must be regenerated. The revocation can be done easily for any end-entity
key. However, strong authentication and non-repudiation are problematic in cases in
which the keys have been stored on software, because it is not possible to guarantee
that no copies of the keys exist. Cryptographic tokens such as smart cards are ideal
for achieving strong user authentication and non-repudiation. The decision between
software storage and token storage of keys is a major pre-deployment decision. In
addition to providing stringent security, smart cards and other cryptographic tokens
give the user the possibility for mobility.
The revocation of a CA key is different from the revocation of an end-entity key. While
end-entity keys are usually easy to revoke and re-generate, the compromise of a CA
private key involves much more work. Certificates of sub-CAs can be revoked, but this
means that all certificates issued by the CA are also revoked and need to be reissued. A catastrophe scenario for the PKI is the compromise of the root CA private
key. Update of a compromised root CA involves the redistribution of the root CA certificate to all end entities and the re-issuing of all certificates in the PKI.
Because of the strict security requirements of CA private keys, the keys should be
stored in tamper-resistant cryptographic devices, or at the minimum, the access to the
root CA private key should be strictly restricted. While smart cards provide a costeffective tamper-resistant environment for end-entity private keys, they are suitable for
CA private key storage only in very small-scale PKIs. The CA is often required to do
numerous signing operations in a short time span and smart cards are not designed to

Insta Certifier : Product Description


Chapter 5: Deploying a PKI

handle this. Specific hardware security modules (HSM) that have optimized privatekey operations and secure key storage should be considered for larger-scale PKI deployments.
When considering the appropriate method for private key storage, the costs of setting
up a secure environment should be balanced against the reduced risks. For an enterprise-wide small PKI deployment for managing a virtual private network (VPN), software keys in a room with restricted access may be sufficient but for a legally binding
PKI involved in financial operations, a tamper-proof high-security storage is the only

Insta Certifier : Product Description


Chapter 6: Use Cases

Chapter 6

Use Cases
This chapter presents examples of Insta Certifier deployment:

enterprise-wide, strong, two-factor authentication

authentication management in a VPN
certification service provision.

6.1 Enterprise-Wide, Strong, Two-Factor Authentication

Insta Certifier can be used to issue digital certificates for secure and scalable user and
server authentication. Because of its open and flexible architecture, the use of the certificates is not limited. Insta Certifier supports wide variety of third-party security applications.
In this use scenario digital certificates are issued for smart-card-based authentication,
IPSec VPN remote access for secure end-to-end application connections.
Certifier Server provides the administration and CMPv2 services enabling the administration operations and user enrollment. Certifier Engine, on the other hand, is stored
in a dedicated server with hardware security module (HSM) for additional security.
Figure 61 shows an example use case how Insta Certifier can be used as an enterprise-wide authentication platform.

Insta Certifier : Product Description


Chapter 6: Use Cases

Figure 61: Strong, two-factor authentication with Insta Certifier

6.2 Authentication Management in a VPN

The following sections present an example of deploying a PKI for a virtual private
network (VPN).

6.2.1 IPSec and VPNs

Internet Protocol Security (IPSec) is a standard protocol for achieving confidentiality,
authentication, and integrity in IP networks. Since IPSec operates on the level of the
Internet Protocol itself, IPSec can be used to protect all applications that are running
on top of the IP stack. Common applications of IPSec are virtual private networks
(VPNs), that securely interconnect individual networks and remote users over an insecure medium such as the Internet. VPNs are a cost-effective alternative to connecting to remote network with leased lines.
The authentication of end entities and the distribution of keys in IPSec virtual private
networks can be PKIbased. IPSec uses the Internet Key Exchange (IKE) protocol to
negotiate secure connections and to authenticate network devices and remote users.
PKIX certificates can be used to authenticate the communicating parties in IKE. PKI
provides a cost-effective and a scalable way to manage keys in a large-scale VPN

Insta Certifier : Product Description


Chapter 6: Use Cases

Insta Certifier has been designed to match the requirements of the PKI management
in a VPN environment and it can be used in a multi-vendor VPN system.

6.2.2 Sample Scenario

This section presents a sample scenario in which an imaginary Corporation X with
several regional offices and a traveling sales force implements an IPSec-based VPN
with a PKI.
When on the road, the sales people need access to several IT resources, such as the
company intranet and e-mail. There is confidential traffic between the geographically
dispersed offices. Consequently, Corporation X has decided to securely connect the
local networks of each office and to provide secure access to the same network for
employees traveling with their laptops. To save costs, Corporation X has decided to
build a VPN over the Internet instead of leasing secure lines between all offices. To
avoid manual distribution of symmetric keys and to achieve strong authentication in
the VPN, Corporation X has decided to use certificates and to deploy a PKI based on
Insta Certifier. Sofware VPN clients are selected to be used for remote access in the
sales personnels computers.
PKI Deployment
After planning the deployment carefully, Corporation X decides to proceed with an installation described in Figure 62.

Insta Certifier : Product Description


Chapter 6: Use Cases

Figure 62: Insta Certifier for VPN management

The figure presents a scenario in which offices A and B are interconnected by an IPSec VPN. For the traveling personnel the company VPN is also accessible over the
Internet with IPSec software clients. A VPN Gateway is the connecting point in each
office. The Insta Certifier CA is installed in Office A, and provides the certification and
the certificate and CRL publishing services required to operate the company VPN.
At the time of the PKI launch, Corporation X has no other plans for using certificates
than to authenticate IPSec connections, so only one self-signed root CA is created.
The CAs private key is stored on software (for the pilot project phase). A possible
hardware-based solution will be considered later.
The Insta Certifier Engine is installed in its private network, physically on the premises
with strict access control (a machine room maintained by qualified IT support personnel). A Certifier Server that runs the Administration and Publishing Services is installed on the same premises with the Engine.

Insta Certifier : Product Description


Chapter 6: Use Cases

Another Certifier Server is located in the semi-public (DMZ) network of the company,
to enable certificate enrollment over the Internet. The only service running on this outside Certifier Server is the SCEP Service used for online certificate enrollment between the PKI, VPN gateways, and software VPN clients. The communication between the Certifier Engine and the two Certifier Servers is secured with Transport
Layer Security (TLS). The support for TLS is a built-in feature of Insta Certifier and requires minimal configuration.
The directory software is installed on the same machine as the Certifier Server running the Enrollment Service. All the gateways and remote users are able to fetch the
certificate revocation lists (CRLs) from that server.
Certification Practices
In the case of Corporation X the CA policy is configured to allow automatic issuance if
the request includes a valid one-time password. IT support personnel who are working
as CA operators will create these passwords and deliver them in person to remote
users. The private key generation is done by the VPN client software and the VPN
gateways, and the certificates are enrolled online. Users are instructed to use certificates only for authenticating IPSec connections. Users are also instructed to inform IT
support immediately of any suspected unauthorized access to their personal laptops.
As the pilot project progresses, Corporation X considers using smart-card-based authentication of remote connections.
CRLs are published by the CA every two hours, overlapping period of the CRLs is
configured to be 10 minutes to avoid problems with slightly non-synchronous clocks.
Important Considerations
Not all PKI deployments are successful. To be successful in the PKI deployment presented in this example, Corporation X needs the following:

A clear business need for the PKI must exist. Corporation X has a need for strong
authentication and key management for securing mission-critical data within the
There have to be PKI-enabled applications that solve the business need. Corporation X employs PKIenabled VPN routers and VPN client software.
Required resources for running the system must be available. Corporation Xs
competent IT support personnel will take on the PKI management responsibility.
The deployment has to be planned carefully, with realistic goals and no overambitious plans in the first stage.

6.3 Certification Service Provision

This section presents an example scenario that describes how Insta Certifier can be
used as a building block for certification service provision business.

6.3.1 S/MIME and TLS Technology

The most popular applications for PKI have traditionally been secure web browsing
and secure e-mail. S/MIME (Secure/Multipurpose Internet Mail Extensions) is an IETF
Insta Certifier : Product Description


Chapter 6: Use Cases

standard for providing confidentiality and authentication in e-mail communications.

PKIX certificates are used in S/MIME to provide these. The S/MIME signature verification and encryption capabilities are already supported in most popular e-mail clients,
making them very attractive end-entity applications for a PKI.
TLS (Transport Layer Security) is an IETF standard for providing security to applications running on top of TCP/IP. The most common application of TLS is secure web
browsing, where the HTTP communication between a web server and the browser
can be encrypted and authenticated. Certificates are used for server authentication
and optionally for client authentication. TLS and especially server authentication are
currently widely deployed in the Internet. With the use of client certificates cumbersome login names and long passwords are not necessarily required, as access control can be based on the user identity defined in the certificate.
Insta Certifier can be used to issue and manage S/MIME and TLS certificates.

6.3.2 Sample Scenario

In this sample scenario, Company Y is starting up a certification service provision
business. The company is already on the security products and provision market with
information security consultancy.
In Company Ys vision the provision of PKI services is an attractive business. Many
small companies lack the resources to deploy their own internal PKIs, but still require
PKI services to secure their internal and external IT services. Company Y attempts to
seize the opportunity provided by the need of these companies, and has decided to
start in the business of certification and CA hosting services.
The goal of the deployment is to build, host, and maintain a highly secure CA and certificate creation environment on behalf of the customers. However, the idea is that
customers dedicate qualified administrators in their organization to handle the actual
user identification and registration process. This allows the customers of Company Y
to outsource most of the PKI deployment work and maintenance but yet retain full
control of the user registration and certification practices.
The target applications that the customers are looking for are secure e-mail (S/MIME)
and web server authentication (TLS). Support for most popular web browsers and email clients is provided in the service.
PKI Deployment
Support for multiple CAs with hierarchies makes Insta Certifier suitable for a CA hosting environment. Company Y has located their Certifier Engine in high security premises. The CA private key will be stored in a hardware security module (HSM). When a
new customer is being provisioned, a new CA private key and CA entity is generated
for the customer and stored in the HSM. The policies, certificate publishing and revocation mechanisms are selected in co-operation with the customer.
The issuance policy of the hosted CAs is based on RA verification. Each company
subscribing to Company Ys CA hosting services receives the Insta Certifier software
with RA functionality. When the dedicated RA administrator of the customer has done
the user verification, an RA-signed request is sent to the Insta Certifier CA maintained
by Company Y. The Certifier Engine can then automatically issue the certificate with a
corresponding customer CA private key. The CA policies allow automatic issuance of

Insta Certifier : Product Description


Chapter 6: Use Cases

RA-verified user certificates so that manual certificate request processing is not needed in the CA environment.
Company Ys service offering includes also the certificate and CRL directory (or
OCSP service) over the public Internet. Customers that do not want their certificates
to be published on the Internet are provided a certificate-based or password-based
access control to the certificate directory. The deployment is described in Figure 63.

Figure 63: Insta Certifier for a certification service provider

Certification Practices in Distributed PKIs

All users that are registered into the PKI must be reliably and securely identified prior
to the creation and enrollment of their certificates. The secure identification of users
cannot be easily done by the certification service provider. Therefore, Company Y decides to delegate the responsibility for registration and operation to the customer organization. The customer companies that subscribe to Company Ys PKI services will

Insta Certifier : Product Description


Chapter 6: Use Cases

set up internal registration authorities (RAs) for user identification duties. The CA/RA
architecture of Insta Certifier provides convenient means for this. The end user employees perform browser-based enrollment including private key generation with their
browsers using the RA server web pages that have been added to the intranets of the
customer organizations. The RA administrators have generated a one-time password
for each customer and distribute them. These passwords are used to access the enrollment web pages to enable automatic RA verification.
Once an RA-signed certification request is sent over the Internet to the CA operated
by Company Y, a certificate matching the request is automatically generated, provided
that the RA signature is found authentic.
It is important to notice that since the RA signature is a sufficient requirement for certification, the RA signature creation environment has to be secure. Company Y leases
hardware-based key storage devices for customers who require a higher level of security than software keys can provide.
In Figure 6.3 (Certification service provider), Company Y, acting as a certification service provider, serves two customer companies that both run the Insta Certifier RA installation on their premises. The CA of Company Y utilizes an LDAP directory for CRL
and certificate publishing as well as an HSM for secure hardware storage of the CA
private keys.
Important Considerations
The identification of users prior to the issuing of their initial certificates always requires
manual effort. The tasks of password creation and delivery, face-to-face registration or
other out-of-band verification cannot be omitted or entirely automated without risking
the overall security of the PKI. These identification tasks can be either centralized to
CA or distributed locally to RAs. The Insta Certifier supports both modes of operation.
An important decision in the PKI deployment planning is whether a distributed PKI architecture with RAs is used or not. While the CA administrators can have secure remote connections and operate locally, the use of RAs allows the building of a comprehensive local PKI registration system. In the example scenario presented above,
Company Y with global operations lacks the resources to perform identification of every single end user, and therefore opts for the distributed RA model. In reality, it may
also prove that customers subscribing to PKI services would not even want to delegate the user identification service to a third party. In the example case, providing onsite RA software for each customer brings Company Y significant savings in operational costs while offering the customer the possibility to manage the registration. Yet
the overall system achieves the goal of outsourcing the certificate creation and CA
operating services.
The less installation and configuration is required on the client side and the more the
existing applications can be utilized, the better the chances for a successful PKI deployment are. In this example scenario, the registration and user certificate enrollment
are provided with intranet web pages and the client applications are familiar web
browsers and e-mail clients. Extensive user training is not required and most of the
PKIspecific technical details are hidden from the end users. One of the biggest obstacles to the adoption of the PKI technology has been the complexity of the technology
from the users point of view. Therefore, all steps that can be taken to hide this technological complexity and to make the system easier to use increase the chances of

Insta Certifier : Product Description


Chapter 7: Product Specifications

Chapter 7

Product Specifications
This chapter summarizes the main features and technical specifications of Insta Certifier, including the supported standards and protocols, and the system requirements for
the software.

7.1 Main Features

Insta Certifier has the following main features:
Certificate Management Features

Online certificate life-cycle management

Web-based self-enrollment
Registration authority (RA) features with token personalization option
Flexible certificate issuing policies
Manual and online cross-certification
Online key backup and recovery
CA private key storage in a hardware security module (HSM)
CA/RA private key storage in a secure software environment
Microsoft Windows 2000/XP logon certificate issuance

Revocation Features

Periodic CRL publishing

Per-revocation CRL publishing
Self-revocation based on pre-shared key (PSK)
Built-in OCSP Responder Service

Scalable Architecture

Multi-platform support for all Certifier components

Support for duplicating Certifier servers and services for higher availability
Scalable architecture: a back-end Certifier Engine and front-end Certifier services
Multiple Virtual CAs/RAs within the same installation
Secure communication between Certifier components
Automated handling of internal system certificates

Insta Certifier : Product Description


Chapter 7: Product Specifications

Directory Integration

Certificate and CRL publishing to standard LDAP directories

Flexible publishing schemas
Support for Microsoft Active Directory
Out-of-the-box TLS protection of LDAP publishing


Web-based administration
Administrators can be restricted to specific CAs
Simplified administrator GUIs for e.g. help desks
Dual control and fine-grained separation of duties
Event logging and audit trail

Other Features

Customizable web enrollment pages for easier branding

Compliant with the EU Directive on Electronic Signatures (1999/93/EC)

7.2 Technical Specifications

This section gives the minimum system configuration required to run Insta Certifier.

7.2.1 7.2.1 Supported Platforms

One of the following operating systems is required:

Red Hat Enterprise Linux 6 ES (x86_64)

Other Linux distributions may also be supported.

7.2.2 Hardware Requirements

The following minimum hardware is required:

256 MB system RAM (1 GB recommended)

On Linux, Solaris, and HP-UX, 80 MB disk space for the full installation (Engine +
Server + Database). The Database will require more disk space as it grows.
20 MB disk space for a Certifier Server installation
CD-ROM drive
TCP/IP connection

Note: TCP/IP connection is not required in the special case where the root CA is offline.

Insta Certifier : Product Description


Chapter 7: Product Specifications

7.2.3 Software Requirements

One of the following software is required for connecting to the Administration andWeb
Enrollment Services:

Microsoft Internet Explorer 5.01 or later

7.2.4 Firefox Supported Third-Party Hardware

Insta Certifier supports the following hardware security modules:

Thales nShield models

7.2.5 Supported Cryptographic Algorithms, Standards, and Protocols

Insta Certifier includes implementations of several cryptographic algorithms and protocols in order to be interoperable with the currently existing and upcoming third-party
PKI components.
Note: Some of the listed standards may be only partially supported.
The supported public-key algorithms are:

EC (elliptic curve); supported setup is prime fields with domain parameters encoded as named curves. Point representation is expected to be uncompressed
(compressed format is not supported).

The supported hash algorithms are:


The supported symmetric ciphers used with the TLS protocol are:


The supported certificate standards and drafts are:

RFC 2437, PKCS#1: RSA Cryptography Specifications Version 2.0, B. Kaliski

and J. Staddon, October 1998.
PKCS#6: Extended-Certificate Syntax Standard Version 1.5, RSA Laboratories,
November 1993.

Insta Certifier : Product Description


Chapter 7: Product Specifications

RFC 2315, PKCS#7: Cryptographic Message Syntax Version 1.5, B. Kaliski,

March 1998.
PKCS#8: Private-Key Information Syntax Standard Version 1.2, RSA Laboratories, November 1993.
PKCS#9 v2.0: Selected Object Classes and Attribute Types, RSA Laboratories,
February 2000.
RFC 2986, PKCS#10: Certification Request Syntax Specification Version 1.7, M.
Nystrom and B. Kaliski, November 2000.
PKCS#12 v1.0: Personal Information Exchange Syntax, RSA Laboratories, June
RFC 3739, Internet X.509 Public Key Infrastructure Qualified Certificates Profile.
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile.
RFC 4210, Internet X.509 Public Key Infrastructure - Certificate Management
Protocol (CMP).
RFC 4211, Internet X.509 Public Key Infrastructure - Certificate Request Message Format (CRMF).
draft-nourse-scep-09.txt, Cisco Systems Simple Certificate Enrollment Protocol
(SCEP), X. Liu, C. Madson, D. McGrew, and A. Nourse, Dec 2003.

For certificate and CRL publishing and certificate status services, the following standards are supported:

RFC 2559, Internet X.509 Public Key Infrastructure Operational Protocols LDAPv2, S. Boeyen, T. Howes, and P. Richard, April 1999.
RFC 4511, Lightweight Directory Access Protocol (LDAP): The Protocol.
RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams,
June 1999.
RFC 2585, Internet X.509 Public Key Infrastructure Operational Protocols: FTP
and HTTP, R. Housley and P. Hoffman, May 1999.
RFC 2587, Internet X.509 Public Key Infrastructure LDAPv2 Schema, S. Boeyen,
T. Howes, and P. Richard, June 1999.
RFC 4523, Lightweight Directory Access Protocol (LDAP), Schema Definitions for
X.509 Certificates.
RFC 3377, Lightweight Directory Access Protocol (v3): Technical Specification, J.
Hodges and R. Morgan, September 2002.

The following smart-card and cryptographic-token-related standards are supported:

PKCS#11 v2.11: Cryptographic Token Interface Standard, RSA Laboratories,

November 2001.

Other supported standards and specifications are:

RFC 2246, The TLS Protocol Version 1.0, T. Dierks and C. Allen, January 1999.
ODBC v3.x (Open Database Connectivity)

Insta Certifier : Product Description


Chapter 7: Product Specifications

Appendix A Introduction to Cryptography and

This chapter describes the basic concepts of cryptography and public-key infrastructures. The X.509 certificates are described in more detail. If you are already familiar
with these subjects, you can skip this chapter.

A.1 Introduction to Cryptography

Two communicating parties - lets call them Alice and Bob - want to exchange messages securely. To ensure that nobody else can read or modify the messages, Alice
and Bob will use cryptography. Cryptography is the science used to provide confidentiality, authentication, and integrity to messages in todays electronic world.

A.1.1 Basic Terminology

In cryptographic terminology, a message is called plaintext or cleartext. Encoding the
contents of the message in such a way that hides its contents from outsiders is called
encryption. The encrypted message is called ciphertext. The process of retrieving the
plaintext from the ciphertext is called decryption. Encryption and decryption usually
make use of a key, and the coding method is such that decryption can be performed
only by knowing the proper key.
Cryptography is the art or science of keeping messages secret. Cryptanalysis is the
art of breaking ciphers, i.e. retrieving the plaintext without knowing the proper key.
Cryptography deals with all aspects of secure messaging, authentication, digital signatures, electronic money, and other applications. Cryptology is the branch of mathematics that studies the mathematical foundations of cryptographic methods.

A.1.2 Cryptographic Algorithms and Cryptographic Systems

A method of encryption and decryption is called a cipher. Some cryptographic methods rely on the secrecy of the encryption algorithms (ciphers); such algorithms are only of historical interest and are not adequate for real-world needs. All modern algorithms use a key to control encryption and decryption; a message can be decrypted
only if the key matches the encryption key.
There are two classes of key-based encryption algorithms, symmetric (or secret-key)
and asymmetric (or public-key) algorithms. The difference is that symmetric algorithms use the same key for encryption and decryption (or the decryption key is easily
derived from the encryption key), whereas asymmetric algorithms use a different key
for encryption and decryption, and the decryption key cannot be derived from the encryption key.

Insta Certifier : Product Description


Chapter 7: Product Specifications

A cryptographic system is a protocol utilizing cryptographic methods. Cryptographic

systems can be divided in two classes, according to the algorithms used, that is in secret-key systems and public-key systems.
Secret-Key (Symmetric) Cryptographic Systems
Secret-key cryptosystems use only one key that the participants of the protocol must
know. The same key is used for both encryption and decryption. For example, Alice
and Bob could use secure encrypted e-mail; Alice and Bob both know the key, so Alice can encrypt the e-mails she sends to Bob, and Bob can decrypt those e-mails. The
same is true in the opposite direction.
Symmetric (secret-key) algorithms can be divided into stream ciphers and block ciphers. Stream ciphers can encrypt a single bit of plaintext at a time, whereas block ciphers take a number of bits (typically 64 bits in modern ciphers), and encrypt them as
a single unit.
Public-Key (Asymmetric) Cryptographic Systems
In public-key cryptosystems, all the participants have two keys, a private key and a
public key. In this case, both Alice and Bob have their own private and public keys.
One half of the key pair is used for encryption, and the other half is used for decryption. The private keys are kept secret, but the public keys are distributed to all involved parties, and may even be made totally public without compromising the cryptosystem in any way.
Using the public key of Bob, Alice can encrypt her messages to Bob. The messages
can then be decrypted only by using Bobs private key. Public-key cryptosystems can
also be used for digital signatures. Using his private key, Bob can digitally sign the
message he sends to Alice. She will then use Bobs public key to verify the validity of
the signature. It is very improbable that any outsider could decode the messages or
forge the digital signatures.
In certificates, the use of digital signatures is necessary, as these are used to prove
that the issuer of the certificate really approves it. In many ways, a digital signature is
like a traditional written signature; it leaves traces of the issuers private key so that it
cannot be faked.
RSA and DSA are the two most commonly used public-key cryptosystems. Both
methods are based on mathematical problems, in which the solution is easy if the private key is known, but very difficult if only the public key is known. Newer addition is
elliptic curve cryptography (EC), which is based on point multiplication on elliptic curve
over finite fields.
In practice, public-key algorithms are not used in their plain forms. Instead, the algorithm is appended with a padding or redundancy method. For example, the input to
the RSA encryption is formatted in a special way, and the input to the signature generation is formatted in a certain way as well. The encryption and signature generation
may have different padding methods. For signature methods, the most important is to
digest the message. A long message is digested by a pseudo-random function which
produces a short message digest.
The digest is then signed. Generally used cryptographic hash functions such as SHA1, SHA-256 and MD5 can be used as the pseudo-random function.

Insta Certifier : Product Description


Chapter 7: Product Specifications

The PKIX (Public-Key Infrastructure X.509) standards define methods for SHA-1 with
RSA signatures and SHA-1 with DSA signatures. These are the most commonly used
methods, although other combinations may also be used.

A.1.3 For EC based signatures, ANS X.96-2005 defines elliptic curve

digital signature algorithm (ECDSA). Recommended SHA hash algorithm is based on used private key size.Strength of Cryptographic Algorithms
In theory, any cryptographic method with a key can be broken by trying all possible
keys in sequence. This is called a brute-force attack. If using brute force to try all keys
is the only option, the required computing power increases exponentially with the
length of the key. A 32-bit key takes 232 (about 109) steps. This is something anyone
can do on his/her home computer. A system with 40-bit keys takes 240 (about 1012)
steps - this kind of computation requires a few days on a modern home computer. A
system with 56-bit keys (such as DES) takes some effort, but is easily breakable with
special hardware. The cost of the special hardware is high, but easily within the reach
of organized criminals, companies, and governments. Keys with 64 bits are probably
breakable now by major governments, and within the reach of organized criminals,
major companies, and lesser governments. Keys with 80 bits appear good for now,
but will be breakable within the next 25 years.
Keys with 128 bits will probably remain unbreakable by brute force for the foreseeable
future. Even larger keys are sometimes used. For example, the new U.S. Advanced
Encryption Standard (AES) supports key lengths of 128, 192, and 256 bits.
However, key length is not the only relevant issue. Many ciphers can be broken without trying all possible keys. In general, it is very difficult to design ciphers that could
not be broken more effectively using other methods.
The key lengths used in public-key cryptography are usually much longer than those
used in symmetric ciphers. This is caused by the extra structure that is available to the
cryptanalyst. There the problem is not guessing the right key, but deriving the matching secret key from the public key. In the case of RSA, this could be done by factoring
a large integer that has two large prime factors. In the case of some other cryptosystems it is equivalent to computing the discrete logarithm modulo a large integer (which
is believed to be roughly comparable to factoring when the moduli is a large prime
number). There are public-key cryptosystems based on yet other problems.
To give some idea of the complexity for the RSA cryptosystem, a 256-bit modulus is
easily factored at home, and 512-bit keys can be broken by university research
groups within a few weeks. Although not provably broken, 768-bit keys cannot be
considered secure in the long term. While considered secure for now, even keys with
1024 bits could be broken in the near future by major governments using specialized
Keys of 2048 bits and more are considered by many to be secure for decades unless
major cryptographic advances are made against RSA.
EC key type gives same strength that RSA gives, but with smaller key size. Asymmetric key (like RSA) of size 3072 bits is equal to EC key of 256 bit. 7680 bit asymmetric
key is equal to 384 bit EC key and 15360 bit asymmetric key to 512 bit EC key.
EC key is defined as elliptic curve parameter. For example secp256r1, where sec
means SEC2 standard, p means prime field, 256 means that prime is 256 bit long

Insta Certifier : Product Description


Chapter 7: Product Specifications

(thus private key size is 256 bit) and r1 means variant (there are others, like k1).
Curve parameters can be defined as named curve (like secp256r1) or as explicit parameters where each curve parameter is given. Certifier supports only named curve.
It should be emphasized that the strength of a cryptographic system is equal to its
weakest link. No aspect of the system design should be overlooked, from the choice
of algorithms to the key distribution and usage policies.

A.2 Introduction to Certificates

Certificates are digital documents that are used for strong authentication of communicating parties. This section deals especially with X.509 public-key certificates.

A.2.1 Basic Concepts

Certificates are digital proofs of identity. In a trustworthy manner, they link an identity,
for example a name, with the public key that is derived from the identitys private key.
Certificates are used to provide authentication, integrity, and confidentiality in the
communication. Certificates can be used to authenticate an individual user or some
other entity (e.g. the IP address of a machine).
Such certificates are commonly called end-entity certificates. Examples of end-entity
certificates would be certificates with e-mail address as part of the identity information
or digital IDs issued by a governmental certification authority for citizens.
Certification Authority (CA)
A certification authority is a trusted entity that issues certificates to other entities. All
certificates issued by a CA are digitally signed by the CA. A valid CA signature in a
certificate attests to the identity of the certificate holder and guarantees that the certificate has not been modified by any third party.
A CA certificate is like any certificate, except that it allows the corresponding private
key to sign other certificates. If the private key of the CA is compromised, the whole
CA is also compromised.
Certification Hierarchy and Certification Paths
Certification authorities can also issue certificates to other CAs. This leads to a treelike certification hierarchy.
The highest trusted CA in the tree is called the root CA. In the hierarchy, every certificate is signed by the CA immediately above it. An exception is the root CA certificate
which is usually signed by the root CA itself. Figure A.1 (Sample certification hierarchy) illustrates the structure.
A certification path refers to a path of certificates from one certificate to another certificate, based on the relation of a CA and its children. When verifying the validity of a
certificate, we need to have the certification path from the trusted root CA certificate to
the certificate in question.

Insta Certifier : Product Description


Chapter 7: Product Specifications

Validity Period
When a CA issues a public-key certificate, it also specifies a lifetime for which the certificate is valid. The validity period can be anything from a couple of days to twenty
years, and after it is over the certificate should no longer be trusted.
Sometimes it becomes necessary to revoke a certificate before its preset expiration
date. For this purpose, the CA may publish a certificate revocation list (CRL). See
Section A.2.3 (Certificate Revocation Lists (CRLs)).
In addition to the validity period, a certificate usually has other constraints that limit its
use. A certain CA may specify that the certificate and the associated key may be used
only to sign and decrypt e-mails, for example.
Validating Certificates
Whenever a certificate is presented as a means of authentication, the recipient must
verify the validity of the certificate. This includes the following steps:

Constructing a certification path up to the trusted root CA.

Verifying the signatures and constraint fields in the certificates on the certification
path, and checking that the certificates have not expired.
Fetching the CRL for each certificate to verify that the certificates have not been
revoked (see Section A.2.3 (Certificate Revocation Lists (CRLs)).

Note that successful validation does not equal authorization. After the validation, the
recipient knows that the certificate is valid for the time period selected, and it can be
used for further security-related operations such as authorization and access control.
Authentication vs. Authorization
Certificates by themselves only provide authentication, not authorization.
After the certificate has been validated, we know that the identity of the certificate is
valid and that it is issued by a specific CA. Because the identity is given by a CA, we
must trust that the CA has somehow checked that the certificate owner actually
matches the claimed identity. For personal certificates, this means that prior to issuing
a certificate, somebody has to check that you really are the person who you claim to
be. If we trust a specific CA, we already trust that it does this. But this is not always
the case. Some online CAs, for instance, issue certificates with any identity, so we
cannot use them for identity-based authorization.
In some systems, there are special registration authorities (RAs) which verify the identities for the CAs. That is, the RAs can issue proof that a person is the owner of a certain private key.
Authorization follows authentication. When we know that the identity Bob Marley has
contacted us, we need to check if Bob has the rights to do something. We might also
do the authorization by specifying that certificates issued by a certain CA have some
specific rights no matter what their identities are. The choice is up to the application,
although the particular certificate system may impose constraints upon this.

Insta Certifier : Product Description


Chapter 7: Product Specifications

Compromised Certificates
To compromise a certificate implies that something very severe has happened; you
have actually revealed your private key to the public.
Certificates have specific lifetimes, so a compromised certificate will become invalid
after some time. Normally,
if a certificate is known to be compromised, it is revoked by the CA and placed on the
certificate revocation list (CRL) as a revoked certificate. It is not valid anymore in any
application that gets the new revocation list. See Section A.2.3 (Certificate Revocation
Lists (CRLs)).
However, there may be some delay before the actual invalidation of a certificate
comes to force. This may require specific precautions to be taken by the certification
In situations that require real-time information on the validity status of certificates, a
special protocol has been designed. The Online Certificate Status Protocol (OCSP)
provides means for querying the status of a certain certificate in real-time. See Section A.2.4 (Online Certificate Status Protocol (OCSP)).

A.2.2 Structure of a Certificate

The simplest form of a certificate contains only the public key, the identity of the certificate owner and the signature of the certificate issuer (usually CA). The owner of the
certificate also has the private key.
The private key is never encoded in the certificate itself. Only when the owner does an
operation with the certificate we can assume that the private key is present. So, for
example, when somebody is requesting you to send your certificate, you will send the
certificate, but not your private key.
Example of a certificate (pseudo certificate).
subject name = Bob Marley
// name
issuer name = CA-Name
// name
subject public key = -- public key goes here -validity = 6/2/1945
// not valid before date
= 11/5/1981
// not valid after date
signature = -- signature goes here -- // signature of the certificate

X.509 Certificates
The ITU-T X.509 standard defines one interpretation of certificates. The X.509 standard is widely used and has become de facto standard for commercial certificate technology. Different X.509 applications are further defined by the PKIX Working Group of
the IETF. The current version of the X.509 certificates is version 3 (defined in RFC
5280). From now on in this text, X.509 certificates are simply referred to as certificates. The following example is output from the Insta certificate viewer tool (sshcertview). See Insta Certifier Reference Guide for more information on the tool.
Certificate =
SubjectName = <C=FI, O=Insta, CN=Secure Shell Test CA>
IssuerName = <C=FI, O=Insta, CN=Secure Shell Test CA>
SerialNumber= 34679408

Insta Certifier : Product Description


Chapter 7: Product Specifications

SignatureAlgorithm = rsa-pkcs1-sha1
Certificate seems to be self-signed.
* Signature verification success.
Validity =
NotBefore = 2003 Dec 3rd, 08:04:27 GMT
NotAfter = 2005 Dec 2nd, 08:04:27 GMT
PublicKeyInfo =
PublicKey =
Algorithm name (SSH) : if-modn{sign{rsa-pkcs1-md5}}
Modulus n (1024 bits) :
Exponent e ( 17 bits) :
Extensions =
Available = authority key identifier, subject key identifier, key
usage(critical), basic constraints(critical), authority
information access
KeyUsage = DigitalSignature KeyEncipherment KeyCertSign CRLSign
BasicConstraints =
PathLength = 0
AuthorityKeyID =
KeyID =
SubjectKeyID =
KeyId =
AuthorityInfoAccess =
AccessMethod =
AccessLocation =
Following names detected =
URI (uniform resource indicator)
Viewing specific name types =
Fingerprints =
MD5 = c7:af:e5:3d:f6:ea:ce:da:07:93:d0:06:8d:c0:0a:f8
SHA-1 = 27:d7:19:47:7c:08:3e:1a:27:4b:68:8e:18:83:e8:f9:23:e8:29:85

As we can see from the example, this is a self-signed CA certificate.

Encoding Certificates
Certificates can be encoded in several ways. In their basic form, X.509 certificates are
ASN.1 structures encoded to DER binary. Often, the binary format is presented using
base-64 encoding (PEM), which makes it simple to store the certificate or copy and
paste it when needed. An example of a PEM-encoded X.509 v3 certificate is shown

Insta Certifier : Product Description


Chapter 7: Product Specifications

-----END X509 CERTIFICATE-----

A.2.3 Certificate Revocation Lists (CRLs)

A certificate revocation list contains the serial numbers of certificates that have been
cancelled before their expiration date. The cancellation might happen for one of several reasons. For instance, the keys in the certificate might be compromised, or the
owner of the certificate might have lost the right to authenticate with the certificate.
The latter could happen, for instance, when an employee leaves a company.
CRLs are published at certain time intervals. They are usually maintained by certification authorities that also issue the certificates. Applications check the CRLs each time
they verify certificates.
If the cancellation of the certificate does not need to be permanent, it is possible to
suspend the certificate instead of revoking it. Suspended certificates can be reactivated at a later time, whereas revoked certificates are permanently cancelled.
A CRL contains a list of revoked and suspended certificates. More precisely, it contains a unique key to identify the certificate and its revocation time. The unique key
could be the serial number of the certificate, or another identifier.
New CRLs are fetched periodically from public directories. Depending on the application, this could happen every five minutes or so. CRLs are usually stored in public directories which can be accessed by LDAP, HTTP or other protocols. Multiple CAs can
share the same CRL directory.
Every certificate may have a pointer to a specific CRL it uses. This is defined when
the certificate is created.
The pointer identifies the place where the CRL is to be fetched from. For instance,
with X.509 this could be a URL with a HTTP server, or a server address with LDAP.
However, in some cases no pointer exists and the application must have other
knowledge of the CRL distribution site.

A.2.4 Online Certificate Status Protocol (OCSP)

Online Certificate Status Protocol (OCSP) is specified in RFC 2560.
OCSP provides applications a means to query for the validity status of an identified
certificate in (almost) real-time. As CRLs are published periodically, they cannot be
used in environments where more timely validity information is required (for example
e-commerce and other financial applications).
When utilizing OCSP, the OCSP client sends the responder a request message containing information on the certificate that is queried for. While the OCSP client waits
for the response, the certificate is suspended.
When a response is received, the OCSP client acts based on the response as the client either accepts or rejects the certificate.

Insta Certifier : Product Description


Chapter 7: Product Specifications

A.2.5 Certificate Enrollment

The basic idea of a public-key infrastructure (PKI) is to have a trusted CA which, as a
trusted third party (TTP), can be used to build trust between the end entities possessing the certificates. To add a new end entity to a PKI, the end entity has to create
a key pair, and a certification authority (CA) has to certify the key pair. This process of
an end entity enrolling in a PKI is commonly known as certificate enrollment.
Certificate enrollment involves (usually) two parties, a client (an end entity) and a
server (a CA), and they need to communicate to have the certificate issued.
A typical certificate enrollment process is shown in Figure A.2 (Certificate enrollment).
It consists of the following steps:

The end entity obtains the CA certificate (this is the first step of the enrollment
process in most cases).


The end entity generates a key pair.


The end entity generates a certification request for the key pair.


The end entity sends the request to the CA.


The CA processes the request according to its policy and, if the request is approved, issues a public-key certificate.


The CA sends the certificate to the end entity and/or publishes it to a directory.

There are several security requirements in certificate enrollment. The end entity has to
be able to prove the possession of the key to the CA (this is known as PoP, proof of
possession). Usually this is achieved by signing the certificate request with the private
Additionally, the CA has to authenticate the end entity. This can be done automatically
by using pre-shared keys, or manually in an out-of-band way.
In the certification request, the end entity may define the values wanted for the certificate. The CA, however, considers the request as a wish list, and under its own policies, it can deny the request completely or modify the requested values.
The certification authorities that process the requests can be roughly divided into two
categories: manual CAs and automatic CAs. Manual CAs require a human operator to
manually approve the request, whereas automatic CAs issue the certificates automatically, for example, based on shared secrets (one-time passwords).
However, in real life, also automatic CAs need a human operator for creating and distributing the one-time passwords.
If manual actions are needed, the processing of a certification request may take some
time. The end entity has to later poll for the certificate.
Several online protocols have been developed for certificate enrollment. These protocols are described below.

Insta Certifier : Product Description


Chapter 7: Product Specifications

Certificate Management Protocol (CMP)

CMP is a certificate life-cycle management protocol developed by the PKIX Working
Group of the Internet Engineering Task Force (IETF), and it is described in documents
RFC 4210 and RFC 4211.
CMP supports PKCS #10 and Certificate Request Message Format (CRMF) as the
request message formats. These formats provide the mechanisms for proof of possession (PoP) for the private key that is being certified and they are wrapped inside
CMP messages. The CMP messages can be transported with either HTTP or TCP.
CMP is a full certificate life-cycle management protocol, and initial enrollment is only
part of it.
In CMP, an end entity needs to send an initial request when the first certificate is enrolled from a given CA. Consequent certification requests can be signed with the valid
private key to facilitate automatic key renewal. Revocation requests can be used to inform the CA about the need to revoke a certificate.
Currently CMP is not widely supported by the end-entity clients and devices, but as a
result of intensive interoperability efforts it is likely that more client-side implementations will emerge.
Simple Certificate Enrollment Protocol (SCEP)
SCEP was developed by the IPSec community to overcome the problem of enrolling
certificates for routers and other network devices. SCEP is widely supported both on
the client and the server sides. SCEP uses PKCS #10 as the certification request format and PKCS #7 as the digital envelope syntax. HTTP is used as the transport protocol.
A prerequisite for SCEP enrollment is that the end entity has to have the appropriate
CA certificate, which must have been verified using some offline method (fingerprint
check). The verification should be done to prevent man-in-the-middle attacks, in which
someone is impersonating the CA.
The initial end-entity authentication in SCEP is done either manually or by using
shared secrets. When using a shared secret scheme, the CA administrator generates
a one-time password for the entity and distributes the password to the entity in a secure way. When the entity generates the certification request, it includes the password
in the request.
After approving the request the CA issues the certificate and packs it to a PKCS #7
cryptographic packet and sends it to the end user (and possibly publishes the certificate to a directory).
Web-Based Enrollment
Many clients support web-based certificate enrollment. The end entity generates a key
pair, creates the certification request on a web browser, and submits the request to
the CA with an HTTP POST operation. After approving the request, the CA returns the
certificate to the end entity. Transport Layer Security (TLS) can be used to protect the
enrollment session.
If the certificate policy requires manual administrator approval, the user can poll the
certificate via the web pages.

Insta Certifier : Product Description


Chapter 7: Product Specifications

Most web browsers support exporting the private key and the certificate in PKCS #12
format. PKCS#12 is a portable file format for storing user credentials and many PKI
client applications, in turn, support it for importing keys and certificates.
PKCS#12 can be used to export user crendentials from one place to another securely.
The sensitive PKCS#12 file and the information it contains is protected with a passphrase. In some cases, it is also possible to download the PKCS #12 file onto a smart
PKCS #10 is the simplest form of certificate enrollment. However, it requires more
manual work than SCEP and CMP.
In this enrollment method an end entity generates a key pair and a base-64-encoded
(PEM-encoded) PKCS#10 certification request in a file. The PKCS #10 request is then
sent to the CA, usually via a web form.
If the certificate policy requires manual administrator approval, the user needs to
download the certificate later after it has been approved (download with Downloadbutton or some web browsers require user to click right button of the mouse and to select Save).

A.2.6 X.500 Directory Structure

The ITU-T/ISO X.500 standards define a directory service for storing certificates,
CRLs, and additional information.
The acronym LDAP stands for Lightweight Directory Access Protocol. It is a protocol
that defines how an X.500 Directory can be accessed by a client.
LDAP operations can be roughly separated into two categories; search and modify
operations. Client applications typically only need search operations for fetching certificates and CRLs. A certification authority also needs to add, update, and remove directory entries in order to make certificates and CRLs available for directory users. All
anonymous clients can be given access to perform searches, while only directory administrators should have the privileges to modify directory entries.
Naming of the Directory Entries
X.500 directories can be represented as logical X.500 Directory Information Trees
(DIT). Each entry in the directory hierarchy is named with a set of relative distinguished names (RDN) which form the distinguished name (DN) of the entry. The distinguished name has to uniquely define the entry within the directory. Some of the typical RDNs used in distinguished names are the following:
C Country
O Organization
OU Organizational Unit

Insta Certifier : Product Description


Chapter 7: Product Specifications

CN Common Name
For example C=US, O=Insta, OU=People, CN=Test User is a valid DN for a person
called Test User working in the People unit in the Insta DefSec office. The subject
name of an X.509 v3 certificate is also a distinguished name and so the subject name
of an issued certificate is typically used as an entry path to the object containing the
certificate in the directory.
Each directory entry consists of attributes that provide information about the entry. For
example the distinguished name of the entry, which was described above, consists of
a set of naming attributes (C, O, OU etc).
In addition to these, the entry can have several other attributes. Of specific interest
regarding PKI are the following:
Contains a binary X.509 certificate of the user.
Contains a binary X.509 certificate of the CA.
Contains a binary X.509 v2 CRL.
Object Classes
Every directory entry also has to belong to at least one object class. Object classes consist of mandatory and optional attributes and so they set restrictions to the
data that can be stored in the directory.
Below is an example definition of an object class pkiUser defined in RFC 2587 Internet X.509 PKI LDAPv2 Schema:
pkiUser OBJECT-CLASS ::= {
KIND auxiliary
MAY CONTAIN {userCertificate}
ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}

The attribute pkiUser is a subclass of the top object (the root of the object hierarchy).
It is auxiliary which means that it can be freely added to or deleted from the entry. The
only attribute which pkiUser may contain is userCertificate. The final line in the definition tells the object identifier (OID) of the object class which is
Another interesting object class is inetOrgPerson which is designed to match the requirements of a modern Internet or intranet directory service (see RFC 2798):
inetOrgPerson OBJECT-CLASS ::= {
{audio, businessCategory, carLicense, departmentNumber,
displayName, employeeNumber, employeeType, givenName,
homePhone, homePostalAddress, initials, jpegPhoto,
labeledURI, mail, manager, mobile, o, pager photo,
roomNumber, secretary, uid, userCertificate,
x500uniqueIdentifier, preferredLanguage,
userSMIMECertificate, userPKCS12}

Insta Certifier : Product Description


Chapter 7: Product Specifications

This object class is derived from organizationalPerson and is structural which means
that it determines the nature of the entry (recall auxiliary pkiUser). In addition to the
attributes of its superclasses it may also have several other attributes including userCertificate.

Insta Certifier : Product Description


Chapter 7: Product Specifications

Appendix B Glossary
This glossary contains definitions of special terms and abbreviations used in the customer documents of Insta DefSec Oy. For more information on terms related to Internet security, see RFC 2828.
Abstract Syntax Notation One (ASN.1)
Standard notation for explaining complicated data structures.
The ASN.1 is used in X.500 Directory to describe the directory objects. ASN.1 is
also used to describe X.509 certificates and CRLs. There are many ways to encode the ASN.1 described structures to binary, most common methods are BER
and DER. The ASN.1 is defined in ITU-T Recommendation X.680.
Advanced Encryption Standard (AES)
AES is the new U.S. government standard for a symmetric encryption algorithm.
AES uses the Rijndael block cipher and it is defined by the National Institute of
Standards and Technology (NIST) in FIPS 197.
Authentication is the process of verifying that the remote entity is who it claims to
Authentication is not the same as authorization (access control), since it is not
concerned with determining which rights the remote entity has. Authentication
means for example verifying that the correct password for the given user account
has been entered, but it does not mean determining what file system permissions
the user has.
Authorization is the process of determining which rights an entity has, after the
entity has been authenticated.
A security service that addresses the security concerns caused by attacks that
deny or degrade a network service.
base-64 encoding
A method of representing six-bit strings of binary data (values 0-63) using 64
ASCII characters. Base-64 encoding was originally used with Privacy Enhanced
Mail (PEM), thus it is sometimes referred to as PEM encoding.
Basic Encoding Rules (BER)
The Basic Encoding Rules define one possible way of converting structures of
ASN.1 into binary data. These objects are not necessarily unique in binary form.
BER is defined in the ITU-T X.690 recommendation. See also DER.
block cipher

Insta Certifier : Product Description


Chapter 7: Product Specifications

A representative of symmetric (secret-key) encryption algorithms that encrypts a

fixed length block of plaintext (for example, 64 bits) at a time. With a block cipher,
the same plaintext block will always encrypt to the same ciphertext block, under
the same key.
A symmetric block cipher designed by Bruce Schneier. Blowfish uses a block size
of 64 bits and a key length of 32 to 448 bits.
brute-force attack
A brute-force attack is an attempt to guess, for example, a password by trying all
possible values one by one. The determining factor for the likelihood of success of
a brute-force attack is the number of possible values. This is important for cryptographic keys, since a large key will have a much smaller chance of being broken
within a reasonable amount of time. If for example a key has a length of 128 bits,
it means that there are a total of 2128 = 3,4*1038 possible values. Even with
very large amounts of processing resources available, a key with this size is not
likely to be broken within a reasonable amount of time. A processor capable of
performing 1,000,000,000 such guesses per second would still need 3,4*1029
seconds = 1022 years to try all possible values, which is not practical.
A symmetric block cipher with a block size of 64 bits and a key length of up to 128
bits. CAST-128 is believed to be very strong. See RFC 2144 for more information.
Certificates are digital documents that are used for verifying the identity of communicating parties. In this documentation, the term certificate is commonly used
to refer to X.509 public-key certificates.
A public-key certificate binds identity information about an entity to the entitys
public key for a certain validity period.
certificate enrollment
Certificate enrollment is an action in which a public key gets certified by a certification authority (CA). In this action a client provides the CA with a public key and
some additional data in a certification request. The CA signs this key together with
additional information with its own private key and returns the signed certificate to
the client.
certificate extension
An optional field in an X.509 v3 certificate providing further information of the usage or applicability of the certificate in a certain PKI.
Certificate Management Protocol (CMP)
CMP defines online interactions between the end entities, the registration authorities, and the certification authority in a PKI. It is developed by the PKIX Working
Group of the IETF and specified in RFC 2510. An advanced version of CMP,
known as CMPv2, is currently an Internet-Draft.
certificate policy
A certificate policy is a named set of rules that indicates the applicability of a certificate to a particular community.

Insta Certifier : Product Description


Chapter 7: Product Specifications

Certificate Request Message Format (CRMF)

CRMF is used as a request format in Certificate Management Protocol (CMP).
CRMF is a PKIX specification (RFC 2511).
certificate revocation list (CRL)
A signed list containing the serial numbers of the certificates that have been revoked or suspended by the certificate issuer (the CA) before their expiration date.
The CA usually issues new CRLs at frequent intervals. Current PKIX implementation of CRLs is the X.509 version 2 CRL. See RFC 3280 for more information.
certification authority (CA)
An entity in a PKI that issues digital certificates (especially X.509 publickey certificates) and vouches for the binding between the data items in a certificate.
Certificate users (end entities) depend on the validity of information provided by a
certificate. Thus, a CA should be someone that the end entities trust, and usually
holds an official position created and granted power by a government, a corporation, or some other organization. A CA is responsible for managing the life cycle
of certificates. Depending on the type of certificate and the CPS that applies, a CA
may also be responsible for managing the life cycle of the key pair associated
with the certificate.
certification practice statement (CPS)
A statement of the practices that a certification authority employs in issuing certificates. A CPS is a published security policy that can help a certificate user to decide whether a certificate issued by a particular CA can be trusted enough to use
in a particular application. A CPS is usually more detailed and procedurally oriented than a certificate policy.
certification request
A certification request contains at least the public key and some identity information of the entity making the request, and it is signed with the private key of the
entity. Certification requests are generated by end entities or RAs and sent to the
CA. If allowed by the certificate policy of the CA, a certificate can be issued based
on the request.
certification service provider (CSP)
A CSP is an organization that acts as a trusted third party or a CA host providing
PKI services to other organizations and individuals.
Text which has been encrypted by an encryption system. The opposite is
A security service that protects data from unauthorized disclosure. Usually, unauthorized disclosure of application level data is the primary concern, but the disclosure of the external characteristics of communication can also be a concern in
some circumstances. The traffic flow confidentiality service addresses this latter
concern by concealing source and destination addresses, message length, or frequency of communication.

Insta Certifier : Product Description


Chapter 7: Product Specifications

Cross-certification is a trust model where two certification authorities (CAs) certify

each other. It allows end entities in different certificate hierarchies to verify each
others certificates.
The branch of mathematics that studies the mathematical foundations of cryptographic methods.
Data Encryption Standard (DES)
DES is a U.S. Federal Information Processing Standard (FIPS) that defines the
Data Encryption Algorithm (DEA). The term DES is also commonly used when referring to the algorithm.
The algorithm itself is a symmetric block cipher with a block size of 64 bits and a
key length of 64 bits (of which 8 are parity bits). It was created in the 1970s by
IBM assisted by the U.S. National Security Agency (NSA).
Single DES is no longer considered secure. The controversy around DES key
length and design issues has developed many variants of the original algorithm.
3DES (also known as triple-DES and Triple Data Encryption Algorithm or TDEA)
is the most accepted. Most of what is known about block ciphers is due to analysis of DES. DEA and TDEA are defined in FIPS 46-3.
denial of service (DoS)
Denotes attacks that do not cause a security violation per se, but harm the availability of a service.
dictionary attack
A dictionary attack is an attempt to guess, for example, a password by trying all
words in a given dictionary (of for example the English language) and simple
permutations of those words. Even though the number of words and simple permutations of them is large, it will be significantly smaller than trying all possible
values. For example most modern computers would be able to run through all the
words of an English dictionary in a few minutes. This makes dictionary attacks
much more feasible, and if a password is very close to a word in a dictionary, it
will not last long against a dictionary attack.
Diffie-Hellman key exchange
A method for key exchange between two parties. This method can be used to
generate an unbiased secret key over an insecure medium. The method has
many variants. A well known attack called the man-in-the-middle attack forces the
use of digital signatures or other means of authentication with the Diffie-Hellman
digital signature
By encrypting a digest of a message with the private key, authentication can later
be performed by applying the public key to an encrypted digest (digital signature)
and comparing the result to the digest of the message.
Digital Signature Algorithm (DSA)
DSA is a public-key algorithm for digital signatures. The DSA algorithm was invented by the U.S. National Security Agency (NSA) and it is defined by NIST in
FIPS 186-2. For more information, see e.g. Bruce Schneier: Applied Cryptography. See also DSS.

Insta Certifier : Product Description


Chapter 7: Product Specifications

Digital Signature Standard (DSS)

The U.S. digital signature standard defined by National Institute of Standards and
Technology (NIST). It is a standard for digital signatures using the DSA public-key
algorithm and the SHA-1 hash algorithm.
Distinguished Encoding Rules (DER)
The Distinguished Encoding Rules, defined in ITU-T X.690, describe a way of
converting structures of ASN.1 into binary data. DER is a subset of BER and
guarantees unique representation in binary for every ASN.1 structure.
distinguished name (DN)
A distinguished name belongs to the X.500 Directory terminology. It declares a
name that can be distinguished from other names in the directory. In that sense
that name does not have to be unique. Often these names are seen encoded using the LDAP format e.g.CN=John Doe, O=Some Organization, C=US, however,
the actual names are ASN.1 objects.
domain name
A domain name is a textual name for an Internet host, e.g. The
Domain Name System (DNS) infrastructure is used to map domain names to IP
addresses. See STD 13 for more information.
Dynamic Host Configuration Protocol (DHCP)
A protocol that provides a means to dynamically allocate IP addresses to computers on local area networks (LANs). The system administrator assigns a range of
IP addresses to DHCP, and each client computer on the LAN has its TCP/IP
software configured to request an IP address from the DHCP server. The request
and grant process uses a lease concept with a controllable time period. DHCP is
defined in RFC 2131.
Elliptic curve cryptography (ECC)
Public key cryptography based on elliptic curves over finite fields. ECC gives
same strength as RSA with smaller key sizes.
Elliptic curve digital signature algorithm (ECDSA)
ECDSA is digital signature algorithm variant for elliptic curve cryptography. It is
recommended (NIST 2011) that used SHA hash is equal to EC key size. For example using 256 bit EC key would use ECDSA with SHA-256.
A security mechanism used for the transformation of data from an intelligible form
(plaintext) into an unintelligible form (ciphertext), to provide confidentiality. The inverse transformation process is called decryption.
end entity
An entity in a PKI (other than a CA or an RA) to whom a certificate is issued. The
end entity has also the private key counterpart of the public key in the certificate.
An entity is a party in a security relationship. An entity could, for example, be one
of the following: user, company, program or process (server process/program, cli-

Insta Certifier : Product Description


Chapter 7: Product Specifications

ent process/program), machine (computer), hardware device (router, gateway).

An entity must be unique, and therefore it must have a unique identifier.
Depending on the entity, an identifier can be a name, e-mail address, social security number, IP address, DNS name, process ID, hardware MAC address or
something else.
In Insta Certifier, an entity is anything that can request and receive certificates
from Insta Certifier. An entity is used to bind a set of attributes describing the entity and a set of requests and certificates together. For example, a Certifier Server,
a registration authority, a Certifier operator, or an end user are entities in Insta
Federal Information Processing Standard (FIPS)
FIPS is a series of U.S. Government technical standards published by the National Institute of Standards and Technology (NIST).
A node located on the perimeter of an administrative domain that implements the
security policy of the domain. A firewall usually performs address and port-based
packet filtering and usually has proxy servers for e-mail and other services.
hardware security module (HSM)
HSM is a tamper-resistant cryptographic device used to store CA/RA private keys.
hash function
An algorithm that computes a short digest of a longer message. The digest is
usually of a fixed size. See also MD5, SHA-1 and SHA-256.
Hash Message Authentication Code (HMAC)
A secret-key authentication algorithm. Data integrity and data origin authentication
as provided by HMAC depend on the scope of the distribution of the secret key. If
only the source and destination know the HMAC key, this provides both data
origin authentication and data integrity for packets sent between the two parties. If
the HMAC is correct, this proves that it must have been added by the source. host
A host is an individual machine (computer). The term host is used for both client
and server machines.
Hypertext Transfer Protocol (HTTP)
HTTP is the protocol used to transfer web pages from a WWW server to the
browser. The HTTP client sends requests to the server, and gets some data as a
response. HTTP identifies objects on the server using URIs or URLs. For more information, see RFC 2068.
Insta Certifier
Insta Certifier is a public-key infrastructure (PKI) platform for issuing and managing digital certificates both for users and servers. It enables strong, two-factor authentication based on smart cards and USB security tokens for storing the user
private keys in a tamper-resistant and portable environment.
A security service that ensures that data modifications are detectable. Integrity
services need to match application requirements. Although authentication and in-

Insta Certifier : Product Description


Chapter 7: Product Specifications

tegrity services are often cited separately, in practice they are intimately connected and almost always offered together.
Internet Engineering Task Force (IETF)
An international standards body that has standardized the IP protocol and most of
the other successful protocols used on the Internet. The IETF web pages are
available at
Internet Protocol (IP)
The network layer for the TCP/IP protocol suite, defined in STD 5. IP is a connectionless, best-effort packet switching protocol. It provides packet routing, fragmentation, and reassembly through the data link layer.
Internet Protocol Security (IPSec)
A protocol suite for protecting IP traffic at packet level defined by the Internet Engineering Task Force (IETF). IPSec can be used for protecting the data transmitted by any service or application that is based on IP. The IPSec protocols are defined in RFC 2401.
Internet Protocol version 4 (IPv4)
This is the current version of the Internet Protocol (IP).
Internet Protocol version 6 (IPv6)
This is a new version of the Internet Protocol (IP). Among other improvements it
has an extended address space and better security. It is described in RFC 2460.
There is no version five.
IP address
In IPv4, a 32-bit number that identifies the devices using the IP protocol. An IP
address can be unicast, broadcast, or multicast. Please see STD 5 for more information.
IP packet
A self-contained, independent entity of data carrying sufficient information to be
routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network. The Internet Protocol (IP) is defined in STD 5.
Lightweight Directory Access Protocol (LDAP)
LDAP is a directory access protocol defined in RFC 2251 and RFC 1777 for accessing directories that support the X.500 Directory model, while not incurring the
resource requirements of the X.500 Directory Access Protocol (DAP). This protocol is especially targeted at management applications and browser applications
that provide read/write interactive access to directories.
The protocol is carried directly over TCP or other transport, bypassing much of
the session/presentation overhead of X.500 DAP.
Managed Service Provider (MSP)
A managed service provider (MSP) provides delivery and management of network-based services, applications, and equipment to other organizations or individuals. A CA hosting service is an example of an MSP activity.
Insta Certifier : Product Description


Chapter 7: Product Specifications

A message-digest algorithm developed by Ron Rivest of RSA Security. It computes a secure, irreversible, cryptographically strong 128-bit hash value for a document. The algorithm is documented in RFC 1321. Newer 160-bit algorithms such
as SHA-1 and 256-bit algorith such as SHA-256 are thought to be more secure
than MD5.
Microsoft Crypto API, a standard cryptographic interface in Microsoft Windows based systems.
Online Certificate Status Protocol (OCSP)
In some applications, such as banking and e-commerce, it may be necessary to
obtain certificate revocation status that is more timely than is possible with CRLs.
OCSP may be used to determine the current revocation status of a digital certificate, instead of or as a supplement to checking against a periodically published
CRL. OCSP is described in RFC 2560.
A passphrase is a string of characters. Whereas a password is used for authentication directly, a passphrase is only used to protect the actual information used
for authentication, the private key. password A password is a string of characters
such as numbers, letters and special characters, used for authenticating an entity
against another. The strength of a password is measured by its randomness,
called entropy. If a password has a high level of entropy, it is difficult to guess using dictionary attacks.
A standard for integrating smart cards and smart card readers, defined by the
PC/SC Workgroup.
perfect forward secrecy (PFS)
Refers to the notion that any single key being compromised will permit access to
only data protected by that single key. In order for PFS to exist, the key used to
protect transmission of data must not be used to derive any additional keys. If the
key used to protect transmission of data was derived from some other keying material, that material must not be used to derive any more keys. Also referred to as
public-key forward secrecy (PFS).
Personal Identification Number (PIN)
Security tokens such as smart cards usually contain one or more PIN codes that
protect the contents of the token. Different objects (private keys, data objects, and
so on) on the token may be protected by different PIN codes. A PIN code must be
given before using a protected object. If a wrong PIN code is entered several
times in a row (usually three), the object is blocked and cannot be used before the
unblocking key is given. See PUK.
Personal Unblocking Key (PUK)
Each PIN code has an associated PUK code that can be used to unblock the token if it becomes blocked as a result of entering several wrong PIN codes in a
row. PUK codes should be stored in a safe place, preferably by the operator who
has issued the security token.

Insta Certifier : Product Description


Chapter 7: Product Specifications

This standard defines the usage of RSA algorithm in encryption and digital signatures. It contains explicit suggestions for the encoding of keys and algorithm input
This standard defines the general syntax for data that may have cryptography applied to it. This data includes digital signatures and recursive digital envelope encoding for cryptographic objects.
This standard describes syntax for private-key information, including a private key
and a set of attributes. The standard also describes syntax for encrypted private
This standard defines a format for certification requests.
This standard defines CryptoKi, which is an interface for cryptographic devices
(for example, smart cards and cryptographic accelerators).
This standard defines a portable format for storing or transporting a users private
keys, certificates, and miscellaneous secrets. PKCS #12 is supported by common
web browsers for importing and exporting user private keys.
This standard defines how keys, certificates, and application-specific data may be
stored on an ISO/IEC 7816 compliant smart card.
PKIX Public-Key Infrastructure (X.509)
A collective name for an architecture and set of protocols based on X.509, drafted
by an IETF working group of the same name.
Text which has not been encrypted. The opposite is ciphertext.
Privacy Enhanced Mail (PEM)
A suite of protocols for encryption, authentication, message integrity, and key
management. For more information, see RFC 1421. PEM is commonly used to refer to an encoding method where binary objects such as certificates are converted
to a printable format using a 64-character subset of the alphabet (this is also
known as base-64 encoding).
private key
In public-key cryptography the private key is only known to the holder, and it can
be used to sign and decrypt messages.
proof of possession (PoP)
During certificate enrollment the end entity has to prove that it is in possession of
the private key corresponding to the public key for which a certificate is requested.

Insta Certifier : Product Description


Chapter 7: Product Specifications

A common way to establish PoP is for the end entity to sign a value with the private key and append the signature to the certification request.
Proxy is a cache server that acts as a firewall, protecting the local network. It allows an application inside the proxy to access resources on the global Internet.
public key
In public-key cryptography the public key, which is included in the certificate, can
be used to verify signatures and encrypt messages.
public-key cryptography
In contrast to symmetric (secret-key) cryptography with just one cipher key, in
public-key cryptography each person or host has two keys. One is the private key,
which is used for signing outgoing messages and decrypting incoming messages,
the other is the public key, which is used by others to confirm the authenticity of a
signed message coming from that person and for encrypting messages addressed to that person. The private key must not be available to anyone but its
owner, but the public key is spread via trusted channels to anyone.
Public-Key Cryptography Standards (PKCS)
The PKCS standards are a document series from RSA Laboratories. Some of the
most important PKCS standards include PKCS#1 for RSA encryption and signature formats, PKCS#7 for cryptographic message encapsulation, PKCS#10 for
certification requests, and PKCS#11 for a cryptographic token interface commonly
used with smart cards.
public-key infrastructure (PKI)
PKI consists of end entities possessing key pairs, certification authorities, certificate repositories (directories), and all the other software, components, and entities required when utilizing public-key cryptography.
A symmetric block cipher designed by Ronald Rivest for RSA Security. RC2 uses
a block size of 64 bits and a variable key length.
A symmetric stream cipher with a variable key length designed by Ronald Rivest
for RSA Security in 1987. RC4 is based on the use of random permutation and its
operations are byte-oriented.
registration authority (RA)
An optional entity in a PKI, separate from the CA(s). The functions that the RA
performs will vary from case to case but may include identity authentication and
name assignment, key generation, token distribution, and revocation reporting.
Request For Comments (RFC)
A document of the Internet Society under standardization. RFCs can be located at

Insta Certifier : Product Description


Chapter 7: Product Specifications

Designed by Joan Daemen and Vincent Rijmen, Rijndael is a symmetric block cipher with a block size of 128 bits and a variable key length of 128, 192, or 256
bits. Rijndael was chosen for the U.S. Advanced Encryption Standard (AES).
A public-key encryption and digital signature algorithm, invented by Ron Rivest,
Adi Shamir, and Leonard Adleman. For more information, see e.g. Bruce Schneier: Applied Cryptography. The RSA algorithm was patented by RSA Security,
but the patent expired in September 2000.
Secure Hash Algorithm (SHA)
A United States standard for a cryptographically strong hash algorithm designed
by National Security Agency (NSA) and defined by National Institute of Standards
and Technology (NIST). See also MD5.
security gateway (SGW)
An intermediate system that acts as the communications interface between two
networks. The internal subnetworks and hosts served by a security gateway are
presumed to be trusted because of shared local security administration.
security policy
The purpose of a security policy is to decide how an organization is going to protect itself.
The policy will generally require two parts: a general policy and specific rules (system-specific policy). The general policy sets the overall approach to security. The
rules define what is and what is not allowed. In this document the term security
policy is typically used when referring to the latter. The security policy describes
how data is protected, which traffic is allowed or denied, and who is able to use
the network resources.
SHA-1 is improved cryptographic hash function of the original Secure Hash Algorithm (SHA-0). The algorithm produces a 160-bit message digest and it is considered good. It is part of the U.S. Digital Signature Standard (DSS) and it is defined
in FIPS 180-1.
SHA-2 (SHA-224/SHA-256/SHA-384/SHA-512)
SHA-2 set of cryptographic hash functions. Functions produce 224/256/384/512bit message digest. The algorithms are defined in FIPS 180-2. Hash algorithm
from SHA-2 family should be used instead of SHA-1.
shared secret
A shared secret, also known as pre-shared key (PSK) or simply shared key, is
similar to a password in the sense that it is also used for authentication, but
shared keys are often used to authenticate both entities at the same time. If both
entities know the shared secret, they are assured of each others identities.
Shared keys can be used to give end entities the right to enroll certificates, in
which case the shared key is created by an RA or a CA and distributed to the end
entity by some out-of-band method. The end entity can then authenticate itself by
using the shared key in the certificate enrollment. In this case, the key is often limited to a certain number of uses.

Insta Certifier : Product Description


Chapter 7: Product Specifications

Simple Certificate Enrollment Protocol (SCEP)

SCEP is developed by Cisco Systems and VeriSign. It is an enrollment protocol
supported by Ciscos routers.
smart card
A smart card, or an integrated circuit card, is a device for secure identification of
users of information systems. Typically smart cards contain a processor that can
do a private-key operation using a private key on the card, some kind of a file system that can hold certificates, public keys, or other data relevant for the use of the
SOCKS is a protocol for traversing through application gateway firewalls. It allows
an application inside the firewall to access resources on the global Internet. The
protocol is defined in RFC 1928.
standard (STD)
A subseries of Request For Comments (RFC) that specify Internet standards. The
standards in the STD series also retain their RFC numbers.
stream cipher
A representative of symmetric (secret-key) encryption algorithms that encrypt a
single bit at a time. With a stream cipher, the same plaintext bit or byte will encrypt to a different bit or byte every time it is encrypted.
traffic analysis
The analysis of network traffic flow for the purpose of deducing information that is
useful to an adversary. For example, frequency of transmission, the identities of
the conversing parties, sizes of IP packets, and flow identifiers.
Transmission Control Protocol (TCP)
A widely used connection-oriented, reliable (but insecure) communications protocol. This is the standard transport protocol used on the Internet. It is defined in
STD 7 (also RFC 793).
Transport Layer Security (TLS)
Transport Layer Security is a protocol providing confidentiality, authentication, and
integrity for stream-like connections. It is typically used to secure HTTP connections. The protocol is being standardized by a working group of the IETF.
A strong and fast block cipher designed by Bruce Schneier. Twofish was one of
the five final candidates for the United States governments new cipher standard,
AES (Advanced Encryption Standard). Twofish uses a block size of 128 bits and a
key length of up to 256 bits.
Uniform Resource Identifier (URI)
URIs are supposed to identify resources or objects in the world or on the Internet.
They are defined in RFC 2396. The most commonly used form of an URI is an
Uniform Resource Locator (URL)

Insta Certifier : Product Description


Chapter 7: Product Specifications

URLs are used to describe the location of web pages, and are also used in many
other contexts. An example of an URL is They
are defined in RFC 1738 and RFC 1808. URLs are a special case of URIs.
User Datagram Protocol (UDP)
A datagram-oriented unreliable communications protocol widely used on the Internet. It is a layer over the IP protocol. UDP is defined in STD 6 (also RFC 768).
virtual private network (VPN)
Virtual private networking is the use of encryption in the lower protocol layers to
provide a secure connection through an otherwise insecure network, typically the
Internet. The encryption may be performed, for example, by firewall software, by a
router, or by a dedicated VPN security gateway.
The family of joint ITU-T/ISO standards defining the X.500 Directory. The directory can be used for many applications, such as storing certificates, or information
about people. LDAP is often used to access the X.500 Directory.
The ITU-T X.509 recommendation defines the formats for X.509 certificates and
X.509 CRLs. Different X.509 applications are further defined by the PKIX Working
Group of the IETF. These include X.509 version 3 public-key certificates and
X.509 version 2 CRLs.

Insta Certifier : Product Description