Certifier 5.2.3 ProductDescription

7/23/2019 Certifier 5.2.3 ProductDescription

http://slidepdf.com/reader/full/certifier-523-productdescription 1/73

www.insta.fi

Insta Certifier 5.2.3

Product Description



Insta Certifier : Product Description

Version 5.2.3

Date 16 September 2013

© 2011 Insta DefSec Oy. This software is protected by international copyright laws. Allrights 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 data-base, 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.

THERE IS NO WARRANTY OF ANY KIND FOR THE ACCURACY OR USEFUL-NESS OF THIS INFORMATION EXCEPT AS REQUIRED BY APPLICABLE LAW OREXPRESSLY AGREED IN WRITING.

Insta DefSec OySarankulmankatu 20P.O.Box 80FIN-33901 TampereFinland

http://www.insta.fi/

Tel: +358 600 97801 (Support HelpDesk)Tel: +358 20 771 7111 (Insta DefSec)Fax: +358 20 771 7122 (Insta DefSec)



Table of Contents


Table of ContentsAbout 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



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



Chapter 1: About This Document

Insta Certifier : Product Description 1

Chapter 1

About This Document

Insta Certifier is a complete solution for providing certification services in an X.509Public-Key Infrastructure (PKIX). This document introduces you to the concept of PKIand 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

glossary

Styles and Conventions

The following conventions are used in this document:

Convention Usage Example

Bold GUI elements, variables, emphasis Click System Configuration

Monospace Filenames, commands, directories Configuration file engine.conf

Italics Terms and references Certification Authority

Command lines and configuration file contents are shown as in this example:

# chkconfig --list certifier



Chapter 2: Introduction


Chapter 2

Introduction

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

2.1 Public-Key Infrastructure

Public-key infrastructure (PKI) gives means for performing authentication reliably andsecurely, ensuring message integrity, and providing non-repudiation of transactions inan 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 cryp-

tography, messages are encrypted and decrypted with different keys. This means thateach participating entity (person or device) of the PKI has a set of two keys, a publickey and a private key.

Private keys are secret and known only to their owners. Private keys are used forsigning and decrypting messages. A common way to ensure the safety of a privatekey is to store it on a separate piece of hardware (a security token such as a smartcard).

Public keys are, as the name implies, public and can be published, for example, in apublic directory or on a web server. Public keys are used for validating signatures andencrypting messages. The two keys are mathematically dependent but the private keycannot 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 bereceived 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 eachpublic key could be verified and trust established by using out-of-band methods (forexample, telephone calls). But when the number of entities grows and the entities arenot known to each other, this would soon become impossible. PKI provides a solutionby using trusted third parties for mediating the trust, and certificates for distributing thekeys.

Certificates are digital documents that are used for secure authentication of the com-

municating parties. A certificate binds identity information about an entity to the enti-ty’s public key for a certain validity period. A certificate is digitally signed by a trust edthird party (TTP) who has verified that the key pair actually belongs to the entity. Cer-





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

When authentication is required, the entity presents a signature it has generated fromauthentication 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 con-tained in the certificate. Next the receiving entity must verify the certificate itself bychecking the validity time of the certificate and the signature of the trusted party in thecertificate. If the signature is valid and the receiving entity trusts the TTP, the first enti-ty has been authenticated successfully.

To enable wide usage of certificates and interoperable implementations from multiplevendors, certificates must be based on standards. The most advanced and wide-spread certificate specifications at the moment are defined by the PKIX WorkingGroup of the Internet Engineering Task Force (IETF). PKIX stands for Public-Key In-frastructure (X.509), as the work of the group is based on the ITU-T recommendationX.509.

2.1.2 PKI - Distributing Trust

The following concepts are critical for understanding how a public-key infrastructureworks:

End Entity

End entities are individual users, devices, or software applications that transact witheach 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 certi-fication authority (CA). Certification authorities can be thought of as being analogousto 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 endentities. 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 assome 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-entitycertification requests with its RA private key.

Because the CA has delegated the task of end-entity identification to the RA, the RAsignature in the request gives the CA a guarantee of the right for end-entity certifica-tion. This allows the CA to operate automatically in online interaction while the local

RAs perform the required out-of-band interaction with end entities.





Using local RAs a large geographically or operationally distributed PKI can work in ascalable 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 re-quest or not. The policy decision and the approval/denial can be automatic, or the op-erator of the CA may have to approve the requests manually. If the request is ap-proved, a signed certificate will be issued and delivered to the end entity and possiblyalso published in a (public) directory.

Certificate Revocation

Certificates have pre-defined lifetimes, lasting from a couple of weeks to severalyears. If a private key of an end entity is compromised or the right to authenticate witha certificate is lost before the expiration date, the CA must revoke the certificate andinform all PKI users about this. Certificate revocation lists can be used for this pur-pose.

A certificate revocation list (CRL) is a list identifying the revoked certificates and it issigned by the CA that originally issued the certificates. Each CA publishes CRLs on aregular basis. The publishing interval may vary from a couple of minutes to severalhours, depending on the security policy of the CA. Verification of a certificate has toinclude the retrieval of the latest CRL to check that the certificate has not been re-voked.

As the certificate revocation lists are updated on a periodic basis, they do not providereal-time status information. If stricter security is required, online certificate status ser-vices can be used. In Online Certificate Status Protocol (OCSP), a dedicated OCSPresponder entity responds to status requests made by end entities. This kind of func-tion is required for example in a PKI where high-value business transactions are digi-tally 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 anLDAP directory or a web server as a PKI repository. The Lightweight Directory AccessProtocol (LDAP) has become the de facto standard procedure for CRL and certificatedistribution.

2.2 Insta Certifier

Insta Certifier is a public-key infrastructure (PKI) platform for issuing and managingdigital certificates both for users and machines. It enables strong, two-factor authenti-cation 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 verylarge PKI environments by introducing centralized management of authentication keyswith support for scalable revocation and key updates.





This section introduces Insta Certifier.

2.2.1 Basic Components

Insta Certifier has a fully open, standards-based architecture together with flexibilityfor configuring certificate policies and publishing practices. Insta Certifier adapts to ex-isting corporate security policy instead of introducing constraints, and is easily inte-grated into complex and heterogeneous environments, where support for multiplethird-party security applications is also needed. Therefore, the same authenticationplatform is used for authenticating users and machines, independent of the specificaccess method. In addition to improving security and manageability of large deploy-ments, Insta Certifier provides IPSec-based remote access VPNs and web browserswith strong, two-factor authentication capabilities.

The architecture of Insta Certifier is fully modular, thus facilitating scalability and relia-bility for large deployments. It supports virtual certification authorities (CAs), logicallyindependent CAs running on a single system and database, and makes it possible tocost-effectively operate complex trust hierarchies needed to separate user identitiesinto different jurisdictions within the corporation. Insta Certifier also includes a com-mercial database as an embedded internal data storage enabling reliable data backupand recovery practices.

Figure 2 –1 presents an overview of the functional architecture of Insta Certifier. Thereare two main components: Certifier Engine and Certifier Server .

The Certifier Engine and the Certifier Server may be run on different machines, andthere may be several Servers connected to one Engine. The Engine connects to theinternal 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 servicesare 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 en-

rollment 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 Sim-

ple Certificate Enrollment Protocol (SCEP).

CMP Service provides certificate life-cycle management services using the Cer-

tificate Management Protocol (CMP).

Web Enrollment Service provides enrollment pages for popular browsers, in-

cluding 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 ondifferent machines - or all the services can be run on the same Certifier Server. Thecommunication between the Servers and the Engine is protected with the TransportLayer Security (TLS) protocol, provided as a part of both Certifier Server and CertifierEngine.





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

Figure 2 –1: Architecture of Insta Certifier

2.2.2 Directory

Directory may be used as a public repository for certificates and certificate revocationlists in a PKI. Insta Certifier uses the Lightweight Directory Access Protocol (LDAP) forpublishing certificates and CRLs in a directory. The use of the standard LDAP protocolenables 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 certifi-cate revocation lists can be published on a web server with HTTP.



Chapter 3: Features


Chapter 3

Features

Insta Certifier offers a set of CA/RA features and functionalities that fully caters for theneeds 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 certificationauthority or a registration authority.

Online certificate lifecycle management

The main purpose of a CA is to provide certification services to end entities. Insta Cer-tifier provides flexible and reliable end-entity certification functionalities that can beeasily configured to fit the needs of different services and environments.

Various third-party VPN devices, remote access clients, and web browsers can beused for enrolling certificates via Insta Certifier. Costs are saved since Insta Certifierdoes not require the installation of proprietary desktop components.

Web-based self-enrollment

Insta Certifier offers different deployment options including web-based self-enrollmentand the use of registration authority (RA) for rolling out PKI-based two-factor authenti-cation. Thanks to the standards-based approach, a wide variety of authentication to-ken and smart card products can be used with Insta Certifier for secure storage of us-

er private keys.

Registration authority (RA) features with token personalization option

A registration authority (RA) is an instance that performs the identification of the pro-spective certificate holders, and vouches that the certificate to be issued and the iden-tity of the subject match. An RA entity is very similar to a CA entity. It has a certificatepolicy, 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, anRA signs certification requests that it sends to a CA. A significant difference betweenthe two is that RAs do not sign CRLs.

Having the RA component available in a PKI product adds flexibility and eases thedistribution and handling of large organizations and their user base. The RA acts as



Chapter 3: Features


an intermediate between the end entity and the CA by assuming some of the CA’stasks.

In a geographically distributed PKI it makes sense to use some kind of on-site end-entity authentication. Usually this means that the RA administrator identifies the certi f-

icate applicant face-to-face and then signs the certification request with the RA privatekey and sends the request to the actual CA. An example of this could be the depart-mental IT support personnel of a large corporation functioning as RAs between thedepartments they serve and the corporate CAs. Another example is a certificationservice provider that distributes RA functions and software to its customers while per-forming as a central CA to all customer RAs.

The CA and RA components of Insta Certifier use the Certificate Management Proto-col (CMP) for communication between them.

As an optional component, the Insta Certifier includes the Insta Token Master applica-tion. Smart cards and USB tokens provide a safe way to store private keys of end en-

tities. Insta Token Master adds smart card and token personalization and registrationfunctionality to a PKI. It allows generating private keys in a smart card, creating a PKIprofile in the card, and enrolling user certificates. Insta Token Master can be used inboth RA and end-entity mode.

Flexible certificate issuing policies

Insta Certifier adapts to the real-life business processes of both service providers andenterprises. It provides freedom to define certification practices without technical re-strictions.

Manual and online cross-certification

In a situation in which independent PKIs are inter-connected, a need for cross-certification arises. Current PKIs do not offer much in the way of interoperability sup-port, and it is likely that crosscertification must be done manually.

Insta Certifier provides a way for online cross-certification (CMP) between two Certifi-er deployments. Also manual cross-certification (PKCS #10) can be done to providesupport 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 pairto the CA in a CMPv2 message. Insta Token Master is an example of a client-sideapplication 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. Ifthis key is compromised, the security of the whole PKI must be considered compro-mised. 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 ashardware-stored private keys are easier to protect from being compromised than keys



Chapter 3: Features


that are stored in software. Insta Certifier supports the use of a third-party hardwaresecurity module (HSM).

CA/RA private key storage in secure software environment

Insta Certifier features the possibility to use password protection for an encryptedCA/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 smart-card-based logon to a Windows 2000/XP domain.

3.2 Revocation Features

Insta Certifier provides several options for distributing the revocation information in thePKI.

Periodic CRL publishing

Revoked entities can be included in certificate revocation lists (CRLs) signed by theCAs that have issued the revoked certificates.

Per-revocation CRL publishing

A new CRL can be published after each revocation, which can in certain situationsadd to the security of the PKI system. Although OCSP is the ideal solution for provid-ing real-time certificate status information, currently there are not many clients thatsupport it. This feature of Insta Certifier can bring OCSP-like functionality to the PKIwithout 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 theirown 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 re-quest.

Built-in OCSP Responder Service

Certificate revocation lists (CRLs) are usually published periodically. In some PKI ap-plication fields, however, this method is unacceptable as real-time information aboutthe validity of certificates is required (for example banking and e-commerce). The useof CRLs in large-scale PKIs may be problematic as the CRLs may grow very large ifall the revoked entries are situated in a single list.

RFC 2560 describes the Online Certificate Status Protocol (OCSP) that overcomesthe issue of realtime certificate validity information.





Chapter 3: Features


Secure communication between Certifier components

Some components of the Insta Certifier can be separated from each other. The sepa-ration can be used to make the system structure modular and to better utilize the po-

tential of the employed hardware. In a typical Insta Certifier deployment, for example,enrollment services may need to reside outside firewalls for end-entity access whilethe Certifier Engine is fully protected from the rest of the network.

To enable secure communication between separated system modules Insta Certifieruses the TLS protocol that utilizes certificate-based authentication. TLS certificates forthe different components of Insta Certifier are created during system installation andupdated 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 time-consuming.

Insta Certifier automates these TLS-related tasks and hides them from the administra-tor. All TLS certificates for internal communications of the Insta Certifier are updatedautomatically 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 bequite short without adding a lot of administrative overhead.

3.4 Directory Integration

Insta Certifier uses the Lightweight Directory Access Protocol (LDAP) for publishingcertificates and CRLs in a directory. The use of the standard LDAP protocol enablesthe 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 publishedin 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 otheruser data. IT management becomes easier since there is no need to maintain dupli-cate data.

Insta Certifier also supports LDAPv3, which allows the use of international alphabetsin directory publishing.



Chapter 3: Features


Support for Microsoft Active Directory

Insta Certifier works smoothly in the Microsoft Windows environment and supportspublishing 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 ap-proach, as the CA should be well protected and located in premises with strict accesscontrol. In actual PKI implementations it may be feasible to have different instancesresponsible for the actual CA and the directory services.

The physical separation of certification and publishing services means that secureconnections are required between the CA and the directory. Insta Certifier employs

the TLS protocol to secure internal communications of the PKI system. Using TLS en-sures that the LDAP directory password is not exposed to the public. Using TLS withclient authentication can eliminate the need for a directory password altogether.

3.5 Administration

Insta Certifier provides advanced possibilities for managing the access rights of thePKI administrators.

Administrators can be restricted to specific CAs

Insta Certifier allows restricting the administrators’ read-access to the CAs so thatthey 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 PKIadministration. Different tasks from user management to system configuration can al-so be given to different administrators.

Insta Certifier now features the powerful option of requiring any amount of operatorsfor system changes to take effect. With this option the CA can make sure that no oneoperator, even with superuser access rights, can tamper with the configurations setforth by the certificate policy.

Event logging and audit trail

The need for auditing usually comes from specific regulations. For example, certainquality certificate statements require that the system which issues these quality certifi-cates 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.



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 Elec-

tronic Signatures.

Customizable web enrollment pages for easier branding

The Insta Certifier operator can easily customize the web enrollment pages to includeonly those fields and options that are relevant in the specific use scenario. With thisfeature, a service provider can create the web enrollment pages according to the cus-tomers’ requirements.

Insta Certifier supports extensively the use of UTF-8 character encoding, whichmakes the product especially suitable for deployment in various Asian countries. Alluser interfaces of Insta Certifier are browser-based, which allows using the advancedUTF-8 features of modern browsers for both data input and output. Also, thanks to theLDAPv3 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 electronicsignatures) may require the use of RFC 3039 qualified extensions.

Note, however, that using Insta Certifier does not automatically imply compliance withthe ETSI requirements related to this EU directive, but there may be additional re-quirements depending on the national implementation of the directive.



Chapter 4: Architecture


Chapter 4

Architecture

The architecture of Insta Certifier is modular. The two main components of Insta Certi-fier are the Certifier Engine and the Certifier Server . The Certifier Engine performs allCA and RA private-key operations and certificate policy decisions. The Engine usesan internal Certifier Database, to which the connection is established over Open Da-tabase Connectivity (ODBC). Insta Certifier ships with an embedded database, SQL Anywhere from Sybase Inc. that is used by default as the internal database. Optional-ly, 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 re-quired to provide the frontend Certifier Services such as enrollment, publishing, andadministration. 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. Thedistribution of services allows for the PKI deployment to be flexible in picking the re-quired services. For example, if the OCSP Responder and CMP Services are notsupported by the end-entity applications, they do not need to be used in the CertifierServer.

Different services require different levels of accessibility and security. Enrollment Ser-

vices 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 in-stances, they can be situated on separate host computers (for example, EnrollmentServices outside the corporate firewall and the Administration Service in a tightly se-cured network). Using multiple Certifier Server instances to distribute the PKI servicesprovides more flexibility in the PKI deployment.

Another major benefit of the Certifier Servers with a customizable service set is thepossibility to add system redundancy. In a worst-case scenario, the unavailability of asingle service may prevent the use of the whole PKI. By duplicating critical services tomultiple Certifier Server instances, a degree of redundancy can be achieved in thesystem. Duplicating services for redundancy purposes requires careful analysis on the

need and function of the deployed services.







Figure 4 –

1: Relationships between Certifier components

It is usually a good idea to use more restrictive firewall settings for the AdministrationService and allow operators to log in only from inside the local network. If a more re-laxed policy is desired, at least the Administration Service configuration should bechecked 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 pro-cesses 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 interfacefor performing the PKI management operations (including request processing, certifi-cate 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 configurationactions can be performed using the graphical user interface running on a commonweb 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 com-promise of the whole PKI. Utmost care must be exercised in maintaining security ofthe connections between the web browser and Administration Service. The browserconnections that facilitate the administrators’ sessions are protected with TransportLayer Security (TLS), the de facto web-browser security protocol. The AdministrationService can be configured to require client authentication for additional security. This

method requires that the administrators possess an authorized certificate for authenti-cation when logging in.





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

4.2.2 CMP Service

The CMP Service provides the PKI certificate life-cycle management capabilities. TheCMP Service acts as a server for handling incoming CMP messages (including certifi-cation requests and revocation requests). The CMP Service can be configured to pro-vide either TCP or HTTP-based transport for the Certificate Management Protocol(CMP).

Insta Certifier uses the CMP Service for communications between RAs and CAs. Aregistration authority signs all messages with its private key, and the CA then verifiesthe 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 certi-

fication request is made, a pre-shared key is used for authentication. The Insta Certi-fier system that houses the RA must run the External Enrollment Client Service to per-form the client side of CMP, and the system that houses the CA must run the CMPService to perform the server side.

The CMP Service also provides tools for CA-to-CA interaction (including cross-certification between separate PKI domains and issuance of sub-CA certificates). Sim-ilarly to RA-CA case, the enrolling CA must run the External Enrollment Client Serviceand 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 draft-ietf-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 enroll-ment with an external CA. This is necessary when an RA requests a certificate from aCA and when a CA requests a cross-certificate or a sub-CA certificate from an exter-nal CA. The External Enrollment Client Service is needed to run these client-side op-erations using CMP. Every Insta Certifier system that has at least one RA has to havean 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 onlineCMP enrollment, the possible crosscertification request can be stored in a file andtransported to the CA by other mechanisms.

4.2.4 LDAP Authentication Service

The LDAP Authentication Service is used for LDAP-based authentication in web en-rollment and SCEP enrollment. The service can be used to authenticate users in en-rollment based on their LDAP credentials (username and password).

LDAP authentication is made by binding to the specified LDAP server with the creden-

tials given by the enrolling user. If the binding is successful, Insta Certifier will look fora matching entity in its database. If one is found, the authentication is successful.





4.2.5 OCSP Responder Service

The OCSP Responder Service provides client applications a point of control for re-trieving real-time information on the validity status of certificates using the Online Cer-

tificate Status Protocol (OCSP). The OCSP Insta Certifier Product Description Re-sponder 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 theycan validate the signed responses. It is possible to configure the system so that theOCSP Responder Service gives out information only on certificates issued by select-ed 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 cer-tificate revocation lists for public use. The most common publishing method is to use adirectory server that the certification service subscribers can use to retrieve the latestcertificates or CRLs. The most common directory access protocol used for this pur-pose is the Lightweight Directory Access Protocol (LDAP). Publishing Service configu-rations include the LDAP connection-related parameters such as directory server ad-dress, directory administration login and password (and optionally SOCKS server andpublishing retry parameters).

If there are multiple directories for publishing within a single Certifier installation, onePublishing Service has to be created for each directory access.

The Publishing Service can also be used to store certificates and certificate revocationlists in a file and to run external scripts that perform the publishing. Using externalpublishing mechanisms provides an easy means to use publishing methods such ase-mail or FTP.

The Publishing Service supports both LDAPv2 and LDAPv3. LDAPv3 is recommend-ed for its better security and compatibility between different implementations.

When there is a need to secure the LDAP connections to prevent eavesdropping of di-rectory administrator passwords, TLS can be used (given that the directory includes aTLS server).

Operational requirements for LDAPv2 in a PKI are described in RFC 2559. The mini-

mum LDAPv2 schema set including object class and attribute definitions for commonPKI 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 clientsthat support this protocol. SCEP is a protocol that defines the procedure for a client torequest certification from a CA. SCEP is widely used in IPSec gateways and IPSechost applications.

There are two parts in SCEP. First the CA certificate is fetched from the SCEP Ser-

vice by using an HTTP GET operation and identifying the CA whose certificate isfetched. Once the CA cer tificate has been received, certificate for the end entity’s own





private key can be enrolled. Pre-shared key can be used to authenticate the end entityand to automate the process.

A client can send a certification request directly to the CA or the certification can bedone 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. Theend entity needs both certificates as the CA certificate is needed after the enrollmentwhen validating the signature of the end entity’s 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 enroll-ment clients that use the certificates issued by Insta Certifier. This service requires anetwork 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 cus-tomized to include scripts that initiate private key and certification request generationin a web browser. Also PKCS#10 certification requests, generated by other applica-tions, can be submitted via the enrollment form of the Web Enrollment Service. Thisallows support for applications that do not provide other online enrollment mecha-nisms.

Other functions of the Web Enrollment Service are CA certificate and CRL download-ing. The Web Enrollment Service can be run both in TLS-protected and non-TLSmode depending on the requirements.

4.3 External Services

Insta Certifier utilizes an internal Database for data storage and typically also a direc-tory for certificate and CRL publishing. Optionally a third-party cryptographic devicecan be used for handling private-key operations of the CAs.

ODBC is used as the API for database connectivity. With the embedded database ofInsta 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 pub-

lishing protocol. This allows the use of any standard compliant directory server prod-uct together with Insta Certifier. A directory server can be added to the Insta Certifierenvironment also after the initial installation, as the LDAP publishing configuration canbe 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. Thedatabase is installed during the Insta Certifier installation.





Open Database Connectivity (ODBC) provides both an API and a database-independent driver layer between the Certifier Engine and the actual database backend. The Certifier Engine is linked with a generic ODBC driver manager which loads adatabase-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 directoryserver supporting LDAP. Since most of the directories include LDAP support and ithas become a standard especially for PKI publishing purposes, third-party directoryservers can be used freely in a PKI based on Insta Certifier.

Publishing operations require privileged login to enable directory modification. Directo-ry administrator username and password are used in LDAP to authenticate the LDAPclient. To provide confidentiality and authentication, TLS can be used to protect thepublishing if the directory server supports TLS on the server side.

End entities need LDAP services typically when they are fetching the latest CRL orsearching for encryption or sub-CA certificates. Especially certificate searching is typi-cally a challenging task for the end entity, since the end entity may not have any priorinformation of the certificate location in the directory tree. Therefore, it is important toplan 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 publishedthere. Adding redundancy can be used to manage directory-related risks. Directoryreplication can be used on the directory side to balance the load. Insta Certifier itselfprovides 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 provid-ing the PKI objects available for each end entity. However, a directory server is an op-tional component and may not be needed in each PKI. For example in several appli-cations there is no need to search certificates from external databases since they aresent between peers in the security protocol. CRLs can also be published by using aweb 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 ahigh 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 isnot required if only software CA keys are used.

For more information, see http://www.thales-esecurity.com/.





4.4 Certification Request Processing

To add a new end entity to a public-key infrastructure (PKI), the end entity has to cre-ate a key pair, and a certification authority (CA) has to certify the key pair. This pro-

cess 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 com-munication between end entities, RAs, and CAs. These include updating keys, re-questing new certificates for existing keys, requesting revocation for compromisedkeys, performing key escrow for encryption keys, and so on. This wider concept canbe called certificate life-cycle management, and certificate enrollment is only a subsetof it.

In a large-scale PKI most of these operations should preferably be automated onlineprocesses. In some systems it may be enough that only the initial certificate enroll-ment is an online process.

Because of the strict security requirements and the online environment, there have tobe standard ways to perform certificate enrollment and certificate life-cycle manage-ment that enable an interoperable multi-vendor PKI system. Insta Certifier supportsthe most common certificate enrollment and certificate life-cycle management proto-cols to achieve interoperability with the various end-entity applications. Several exam-ples of enrolling for a certificate in a PKI based on Insta Certifier through third-partyend-entity applications are provided in Insta Certifier Interoperability Guide.

In Insta Certifier, all end-entity-to-CA interaction is performed via Enrollment Servicesrunning on Certifier Server instance(s). These services perform the message-transport-related server-side functionality of certificate enrollment or certificate life-cycle 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 beparsed (and understood), the Service forwards this request to Certifier Engine to beresolved and processed according to the defined policies. Malformed requests are

dropped immediately by the Service. As the Enrollment Services do not possess theCA or RA private keys, they cannot decrypt any encrypted messages arriving to theCA or RA.

A certification request is processed as illustrated in Figure 4 –2.









Chapter 5: Deploying a PKI


Chapter 5

Deploying a PKI

This chapter outlines some of the major issues that need to be addressed when de-ploying 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 ofa PKI and the sharing of responsibilities within the PKI. The standard allows construct-ing complex CA hierarchies for distributing the certification services between multipleCAs and delegating user identification and other tasks to RAs. On the other hand, ac-cording 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 carefullyconsidered. An efficient and secure trust model and PKI architecture should be draft-ed 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 hierarchyand roles are considered.

5.1.1 CA Hierarchy

One of the essential concepts of PKI is the distribution of trust between the CAs - achain of trust that binds different CAs together in a CA hierarchy. In every PKI there isa root CA that the end entities ultimately trust. By creating sub-CAs whose certificatesare signed by the root CA, the trust can be derived automatically to these new sub-

CAs.

CA Private Key Security

The security requirements of the root CA private key are very strict. If the private keyof 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 shouldbe strictly limited to the minimum necessary personnel. This may mean that there isno 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 sub-

CAs for end-entity certification and using offline root CA just to issue sub-CA certifi-cates, both of these requirements can be satisfied.





Extra security can be added by using a hardware security module (HSM) to protectthe CA private key.

Dividing Certification Responsibility to sub-CAs

Typically in a PKI there is a need to provide various different certificates for differentpurposes within a single PKI. A company might want to use certificates to encrypt e-mail and to authenticate users in secure web sessions. While it would be possible toissue certificates for both of these purposes with a single CA, it may prove to be moreconvenient to create two sub-CAs under a single trusted root CA. One of the sub-CAswould then issue e-mail certificates and the other TLS certificates. Both of the sub-CAs would have separate certificate policies that define the applicability of the issuedcertificates.

When separate sub-CAs are used, as in the example above, the individual securityconsiderations 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 toissuing the certificate. This identification is performed as a part of the certificationpractice that the CA (that issues the certificate) employs, and forms the basis for thetrustworthiness of the whole system.

To make sure that the user is identified correctly, the identification process typicallyinvolves some out-of-band interaction between the authority and the user (end entity).

The most common method is naturally face-to-face communication and identificationat the time of registration. In a (geographically or organizationally) distributed PKIthese identification tasks can be delegated to Registration Authorities (RAs). The useof RAs increases the scalability of the PKI system considerably.

Use of RAs always involves costs because of the required RA administrators and sys-tem maintenance. RAs should, therefore, be used only in the system if the costs of thecentrally managed user identification costs exceed the costs of the RA maintenance.

If the PKI deployment involves setting up a certification service provider system wherethe service provider acts as a trusted third party, some RA systems could be providedfor the customers. This way an enterprisescale customer of a certification service pro-

vider may take care of the employee identification by dedicating an RA administratorfor that task.

5.1.3 Cross-Certification

When enterprises deploy their internal PKIs with their own internal root CAs, it resultsin multiple independent PKI domains. When two such independent PKIs need to beconnected, this connection can be achieved by having the root CAs of each domaincross-certify each other. This means that end entities in both domains may trust thecertificates of the other PKI because the CA of their ”home” PKI has issued a CA cer-tificate 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 tobe able to perform transactions with each other. Sometimes PKI deployment may in-clude cross-certification with one or more PKIs.





If the need for cross-certification is known in the deployment phase, there are someimportant issues that must be taken into account. Two important criteria for a success-ful cross-certification are the technical CA-to-CA interoperability as well as the con-sistency of the certificate policies and certification practices of the separate PKIs. Ifthe separate PKI systems are provided by different vendors, it is important to make

sure that the PKI systems interoperate together. If certification paths containing certifi-cates issued by CA systems from two different vendors cannot be verified by the endentities, the PKI is useless.

Another important issue in cross-certification is the compatibility of the certificationpractices of the two PKIs. Cases in which the certification practices of the cross-certified PKIs differ very much may prove to be problematic. For example, if one of thePKIs follows a loose identification process and does not recommend using certificatesto secure mission-critical data, while the other maintains extremely strict practices toissue certificates for high-value transaction signing, confusion and problems mayarise. In this kind of cross-certified environment, the end entities of the latter PKIshould not rely to the other PKI’s certificates to the same extent as their own certifi-

cates. In practice this kind of distinction is very hard to implement and should beavoided. Painless cross-certification requires that the two cross-certified PKIs functionwith roughly similar certificate policies.

5.2 End-Entity Applications

A PKI deployment should always proceed from a clear need for specific end-entityapplications that are enabled by the PKI. A typical mistake in deploying a PKI is tobuild a PKI without a plan for the end-entity applications that use the certificates. End-entity 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 anddevices, 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 beenchosen otherwise, and a browser may have a fixed trusted root CA set that is not ac-cepted by the policy employed in the PKI. Before the actual deployment, it is importantto consider carefully which end-entity applications will be used. If the installation ofnew desktop software is to be avoided or the end-entity application vendors have al-ready been chosen, the limitations and supported PKI features of the applicationsneed 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 dis-tributed to all end entities. This distribution is an essential and important part of thePKI deployment project. Because there is no prior trust relationship between the CAand the end entities, the root certificate distribution cannot be an automatic onlineprocess 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.





Out-of-band transfer

In this method, the CA certificate is distributed to users face-to-face, or it is sent intraditional 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 applica-tion. 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 certificatecan be checked by comparing the fingerprint (a hash value of the certificate) to thegenuine one. For example, a phone call to the CA operator can be used to get thegenuine fingerprint of the root CA certificate. This method is used typically when enrol-ling 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 endentities. In this case, the root CA certificate can be embedded in the installation pack-age. As the software that has access to the users’ private keys must be trusted, tightsecurity requirements apply for both the root certificate installation and the applicationsoftware installation. If smart cards or other cryptographic tokens are used for storingthe private keys of end-entities, the root CA certificate can also be stored in the sametoken. In this case the root key distribution is easy, as the smart cards must be re-ceived 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 keysof the users. Without backup the loss of the private key might result in permanent lossof confidential data. For example, if you lost your private key you would no longerhave access to your encrypted e-mails.

Key backup may be considered only for encryption keys, and there should never be aneed to back up authentication or signature keys. Non-repudiation of transactionscannot 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 end-entity application, there must be support for private key export in the application. If thekeys are generated by an RA on behalf of the user (which is a typical method withkeys stored on smart cards), the RA may back up the private key.

In Insta Token Master, the private encryption keys can be generated outside smartcards and then backed up for possible future key escrow. This backup can be madeeither locally to the Token Master database or online to the CA database.





5.5 Revocation Services and Directory Deployment

While PKI is an effective way to reduce and manage risks in an online world wherewrongful authentication may result in considerable losses, there is a certain amount of

risks involved. The risks center around the Insta Certifier Product Description event ofPKI compromise which could be due to, for example, private keys or smart cards witheasy-to-guess PIN codes being stolen. A PKI must always provide some mechanismto revoke certificates in the case of compromise. There must also be effective meansby 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 val-ue of the transactions signed define the requirements for revocation. In online bankingand commerce the requirements for real-time revocation of certificates are higherthan, 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, OnlineCertificate Status Protocol (OCSP) is the appropriate way to publish revocation infor-mation. The OCSP Responder Service that runs on a Certifier Server provides the cli-ent applications information on the revocation status of certificates.

If rather recent (but not real-time) revocation information is acceptable, periodicallypublished certificate revocation lists (CRLs) will suffice.

5.5.2 Certificate Revocation Lists (CRL)

Periodically published CRLs contain information on certificates that have been re-voked before their natural expiration.

When CRLs are used, the CA needs to publish CRLs in a public repository such as aweb server or a directory server. Whether or not to deploy a directory server is one ofthe 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 directoryserver deployment is not generally justified. In this case the CRLs can be published toa web server using HTTP protocol. However, if the organization already has a directo-ry 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 orCRLs repository) must be carefully considered and implemented. Regardless of thechosen publishing method, these services are a potential single point of failure in thesystem.

If, for example, the only directory where the CRLs are published is not available, thewhole PKI may not be able to operate. This risk can be lowered by adding redundan-

cy. 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





in multiple directories. Whether additional redundancy is required for the revocationshould 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 acertificate to a particular community and/or class of application with common securityrequirements.

It is the responsibility of the CA to define the exact policy that defines the applicabilityof the certificates it issues. If there is no well-defined certificate policy, it is up to theend 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 purposesits 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 thecertificate itself may reduce end entities’ risks as it enables the end users to avoid un-intended use of the certificates.

5.6.1 Certification Practice Statement (CPS)

Certification practice statement (CPS) details the practices that the CA employs in is-suing certificates. CPS provides information for a relying party who is making deci-sions based on a certificate that has been issued according to certain certificationpractices.

Every commercial CA (such as a certification service provider) should have a pub-lished CPS that defines the procedures, operating policy, security controls, and envi-ronment according to which the certificates are issued. A link to the CPS documentcan 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 certificationservice provider and the customer. While the CA normally has a single CPS describ-ing the certification practices in detail, it may have multiple certificate policies. Thismay be the case if the CA issues different certificates for different purposes.

For more information on the certificate policies and certification practice statements aswell as the standard template for policies, see RFC 2527 (Certificate Policy and Certi-fication Practices Framework).

5.7 Organizational Responsibilities

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

System administration

CA administration

RA administration





System Administrators

System administration duties include the administration of Certifier Engine and thevarious Certifier Servers that make up the Insta Certifier system. The configuration

and maintenance of the Enrollment and Publishing services are also duties taken careof by the system administrators.

RA/CA Administrators

RA and CA administration duties include certificate request processing, entity man-agement, user authentication, and certificate revocation. In a large-scale PKI it mayalso 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 specialadministrators, while everyday request processing can be handled by normal opera-tors. 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 thesystem 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 ofthe PKI. The security of a PKI system depends heavily on the safe storage of the pri-vate keys. In most cases today, the end-entity private keys are stored on software, ei-ther in plain-text form or in encrypted form protected with passwords. This may be suf-

ficient if the access to these keys is limited (no outsider access), but in systems thatare 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 andthe key must be regenerated. The revocation can be done easily for any end-entitykey. However, strong authentication and non-repudiation are problematic in cases inwhich the keys have been stored on software, because it is not possible to guaranteethat no copies of the keys exist. Cryptographic tokens such as smart cards are idealfor achieving strong user authentication and non-repudiation. The decision betweensoftware storage and token storage of keys is a major pre-deployment decision. Inaddition to providing stringent security, smart cards and other cryptographic tokensgive the user the possibility for mobility.

The revocation of a CA key is different from the revocation of an end-entity key. Whileend-entity keys are usually easy to revoke and re-generate, the compromise of a CAprivate key involves much more work. Certificates of sub-CAs can be revoked, but thismeans that all certificates issued by the CA are also revoked and need to be re-issued. A catastrophe scenario for the PKI is the compromise of the root CA privatekey. Update of a compromised root CA involves the redistribution of the root CA certif-icate 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 bestored in tamper-resistant cryptographic devices, or at the minimum, the access to theroot CA private key should be strictly restricted. While smart cards provide a cost-

effective tamper-resistant environment for end-entity private keys, they are suitable forCA private key storage only in very small-scale PKIs. The CA is often required to donumerous signing operations in a short time span and smart cards are not designed to





handle this. Specific hardware security modules (HSM) that have optimized private-key operations and secure key storage should be considered for larger-scale PKI de-ployments.

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 enter-prise-wide small PKI deployment for managing a virtual private network (VPN), soft-ware keys in a room with restricted access may be sufficient but for a legally bindingPKI involved in financial operations, a tamper-proof high-security storage is the onlyoption.





Chapter 6: Use Cases


Figure 6 –1: 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 privatenetwork (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 theInternet Protocol itself, IPSec can be used to protect all applications that are runningon top of the IP stack. Common applications of IPSec are virtual private networks(VPNs), that securely interconnect individual networks and remote users over an in-secure medium such as the Internet. VPNs are a cost-effective alternative to connect-ing to remote network with leased lines.

The authentication of end entities and the distribution of keys in IPSec virtual privatenetworks can be PKIbased. IPSec uses the Internet Key Exchange (IKE) protocol tonegotiate secure connections and to authenticate network devices and remote users.PKIX certificates can be used to authenticate the communicating parties in IKE. PKIprovides a cost-effective and a scalable way to manage keys in a large-scale VPN

environment.





Insta Certifier has been designed to match the requirements of the PKI managementin 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 withseveral regional offices and a traveling sales force implements an IPSec-based VPNwith a PKI.

When on the road, the sales people need access to several IT resources, such as thecompany intranet and e-mail. There is confidential traffic between the geographicallydispersed offices. Consequently, Corporation X has decided to securely connect thelocal networks of each office and to provide secure access to the same network foremployees traveling with their laptops. To save costs, Corporation X has decided tobuild a VPN over the Internet instead of leasing secure lines between all offices. Toavoid manual distribution of symmetric keys and to achieve strong authentication inthe VPN, Corporation X has decided to use certificates and to deploy a PKI based onInsta Certifier. Sofware VPN clients are selected to be used for remote access in thesales personnel’s computers.

PKI Deployment

After planning the deployment carefully, Corporation X decides to proceed with an in-stallation described in Figure 6 –2.







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 out-side Certifier Server is the SCEP Service used for online certificate enrollment be-tween the PKI, VPN gateways, and software VPN clients. The communication be-tween 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 re-quires minimal configuration.

The directory software is installed on the same machine as the Certifier Server run-ning the Enrollment Service. All the gateways and remote users are able to fetch thecertificate revocation lists (CRLs) from that server.

Certification Practices

In the case of Corporation X the CA policy is configured to allow automatic issuance ifthe 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 remoteusers. The private key generation is done by the VPN client software and the VPNgateways, and the certificates are enrolled online. Users are instructed to use certifi-cates only for authenticating IPSec connections. Users are also instructed to inform ITsupport immediately of any suspected unauthorized access to their personal laptops. As the pilot project progresses, Corporation X considers using smart-card-based au-thentication of remote connections.

CRLs are published by the CA every two hours, overlapping period of the CRLs isconfigured 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 pre-sented in this example, Corporation X needs the following:

A clear business need for the PKI must exist. Corporation X has a need for strongauthentication and key management for securing mission-critical data within theorganization.

There have to be PKI-enabled applications that solve the business need. Corpo-ration X employs PKIenabled VPN routers and VPN client software.

Required resources for running the system must be available. Corporation X’scompetent IT support personnel will take on the PKI management responsibility.

The deployment has to be planned carefully, with realistic goals and no over-

ambitious plans in the first stage.

6.3 Certification Service Provision

This section presents an example scenario that describes how Insta Certifier can beused 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 browsingand secure e-mail. S/MIME (Secure/Multipurpose Internet Mail Extensions) is an IETF









set up internal registration authorities (RAs) for user identification duties. The CA/RAarchitecture of Insta Certifier provides convenient means for this. The end user em-ployees perform browser-based enrollment including private key generation with theirbrowsers using the RA server web pages that have been added to the intranets of thecustomer organizations. The RA administrators have generated a one-time password

for each customer and distribute them. These passwords are used to access the en-rollment web pages to enable automatic RA verification.

Once an RA-signed certification request is sent over the Internet to the CA operatedby Company Y, a certificate matching the request is automatically generated, providedthat the RA signature is found authentic.

It is important to notice that since the RA signature is a sufficient requirement for certi-fication, the RA signature creation environment has to be secure. Company Y leaseshardware-based key storage devices for customers who require a higher level of se-curity than software keys can provide.

In Figure 6.3 (Certification service provider), Company Y, acting as a certification ser-vice provider, serves two customer companies that both run the Insta Certifier RA in-stallation on their premises. The CA of Company Y utilizes an LDAP directory for CRLand certificate publishing as well as an HSM for secure hardware storage of the CAprivate keys.

Important Considerations

The identification of users prior to the issuing of their initial certificates always requiresmanual effort. The tasks of password creation and delivery, face-to-face registration orother out-of-band verification cannot be omitted or entirely automated without riskingthe overall security of the PKI. These identification tasks can be either centralized toCA 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 ar-chitecture with RAs is used or not. While the CA administrators can have secure re-mote connections and operate locally, the use of RAs allows the building of a com-prehensive local PKI registration system. In the example scenario presented above,Company Y with global operations lacks the resources to perform identification of eve-ry single end user, and therefore opts for the distributed RA model. In reality, it mayalso prove that customers subscribing to PKI services would not even want to dele-gate the user identification service to a third party. In the example case, providing on-site RA software for each customer brings Company Y significant savings in opera-tional costs while offering the customer the possibility to manage the registration. Yetthe overall system achieves the goal of outsourcing the certificate creation and CAoperating services.

The less installation and configuration is required on the client side and the more theexisting applications can be utilized, the better the chances for a successful PKI de-ployment are. In this example scenario, the registration and user certificate enrollmentare provided with intranet web pages and the client applications are familiar webbrowsers and e-mail clients. Extensive user training is not required and most of thePKIspecific technical details are hidden from the end users. One of the biggest obsta-cles to the adoption of the PKI technology has been the complexity of the technologyfrom the users’ point of view. Therefore, all steps that can be taken to hide this tech-nological complexity and to make the system easier to use increase the chances ofsuccess.





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

Administration

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 off-line.





7.2.3 Software Requirements

One of the following software is required for connecting to the Administration andWebEnrollment 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 pro-tocols in order to be interoperable with the currently existing and upcoming third-partyPKI components.

Note: Some of the listed standards may be only partially supported.

The supported public-key algorithms are:

RSA

DSA

EC (elliptic curve); supported setup is prime fields with domain parameters en-coded as “named curves”. Point representation is expected to be uncompressed

(compressed format is not supported).

The supported hash algorithms are:

MD5

SHA-1

SHA-214

SHA-256

SHA-384

SHA-512

The supported symmetric ciphers used with the TLS protocol are:

AES

DES

3DES

RC2

RC4

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.





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 Laborato-

ries, 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

1999.

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 Mes-

sage Format (CRMF).

draft-nourse-scep-09.txt, Cisco Systems’ Simple Certificate Enrollment Pr otocol

(SCEP), X. Liu, C. Madson, D. McGrew, and A. Nourse, Dec 2003.

For certificate and CRL publishing and certificate status services, the following stand-ards 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 Pro-tocol - 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)





Appendix A Introduction to Cryptography andCertificates

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

A.1 Introduction to Cryptography

Two communicating parties - let’s call them Alice and Bob - want to exchange mes-sages securely. To ensure that nobody else can read or modify the messages, Aliceand Bob will use cryptography. Cryptography is the science used to provide confiden-tiality, authentication, and integrity to messages in today’s electronic world.

A.1.1 Basic Terminology

In cryptographic terminology, a message is called plaintext or cleartext. Encoding thecontents of the message in such a way that hides its contents from outsiders is calledencryption. The encrypted message is called ciphertext. The process of retrieving theplaintext from the ciphertext is called decryption. Encryption and decryption usuallymake use of a key, and the coding method is such that decryption can be performedonly by knowing the proper key.

Cryptography is the art or science of keeping messages secret. Cryptanalysis is theart of breaking ciphers, i.e. retrieving the plaintext without knowing the proper key.

Cryptography deals with all aspects of secure messaging, authentication, digital sig-natures, electronic money, and other applications. Cryptology is the branch of mathe-matics 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 meth-ods rely on the secrecy of the encryption algorithms (ciphers); such algorithms are on-ly of historical interest and are not adequate for real-world needs. All modern algo-rithms use a key to control encryption and decryption; a message can be decryptedonly 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 algo-rithms use the same key for encryption and decryption (or the decryption key is easilyderived from the encryption key), whereas asymmetric algorithms use a different keyfor encryption and decryption, and the decryption key cannot be derived from the en-

cryption key.





A cryptographic system is a protocol utilizing cryptographic methods. Cryptographicsystems can be divided in two classes, according to the algorithms used, that is in se-cret-key systems and public-key systems.

Secret-Key (Symmetric) Cryptographic Systems

Secret-key cryptosystems use only one key that the participants of the protocol mustknow. The same key is used for both encryption and decryption. For example, Aliceand Bob could use secure encrypted e-mail; Alice and Bob both know the key, so Al-ice can encrypt the e-mails she sends to Bob, and Bob can decrypt those e-mails. Thesame is true in the opposite direction.

Symmetric (secret-key) algorithms can be divided into stream ciphers and block ci-phers. Stream ciphers can encrypt a single bit of plaintext at a time, whereas block ci-phers take a number of bits (typically 64 bits in modern ciphers), and encrypt them asa single unit.

Public-Key (Asymmetric) Cryptographic Systems

In public-key cryptosystems, all the participants have two keys, a private key and apublic 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 decryp-tion. The private keys are kept secret, but the public keys are distributed to all in-volved parties, and may even be made totally public without compromising the cryp-tosystem in any way.

Using the public key of Bob, Alice can encrypt her messages to Bob. The messagescan then be decrypted only by using Bob’s private key. Public-key cryptosystems canalso be used for digital signatures. Using his private key, Bob can digitally sign themessage he sends to Alice. She will then use Bob’s public key to verify the validity ofthe signature. It is very improbable that any outsider could decode the messages orforge the digital signatures.

In certificates, the use of digital signatures is necessary, as these are used to provethat the issuer of the certificate really approves it. In many ways, a digital signature islike a traditional written signature; it leaves traces of the issuer’s private key so that itcannot be faked.

RSA and DSA are the two most commonly used public-key cryptosystems. Bothmethods are based on mathematical problems, in which the solution is easy if the pri-

vate key is known, but very difficult if only the public key is known. Newer addition iselliptic curve cryptography (EC), which is based on point multiplication on elliptic curveover finite fields.

In practice, public-key algorithms are not used in their plain forms. Instead, the algo-rithm is appended with a padding or redundancy method. For example, the input tothe RSA encryption is formatted in a special way, and the input to the signature gen-eration is formatted in a certain way as well. The encryption and signature generationmay have different padding methods. For signature methods, the most important is todigest the message. A long message is digested by a pseudo-random function whichproduces a short message digest.

The digest is then signed. Generally used cryptographic hash functions such as SHA-1, SHA-256 and MD5 can be used as the pseudo-random function.











Compromised Certificates

To compromise a certificate implies that something very severe has happened; youhave actually revealed your private key to the public.

Certificates have specific lifetimes, so a compromised certificate will become invalidafter some time. Normally,

if a certificate is known to be compromised, it is revoked by the CA and placed on thecertificate revocation list (CRL) as a revoked certificate. It is not valid anymore in anyapplication that gets the new revocation list. See Section A.2.3 (Certificate RevocationLists (CRLs)).

However, there may be some delay before the actual invalidation of a certificatecomes to force. This may require specific precautions to be taken by the certificationauthority.

In situations that require real-time information on the validity status of certificates, aspecial protocol has been designed. The Online Certificate Status Protocol (OCSP)provides means for querying the status of a certain certificate in real-time. See Sec-tion 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 certif-icate owner and the signature of the certificate issuer (usually CA). The owner of thecertificate also has the private key.

The private key is never encoded in the certificate itself. Only when the owner does anoperation with the certificate we can assume that the private key is present. So, forexample, when somebody is requesting you to send your certificate, you will send thecertificate, 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 stand-ard is widely used and has become de facto standard for commercial certificate tech-nology. Different X.509 applications are further defined by the PKIX Working Group ofthe IETF. The current version of the X.509 certificates is version 3 (defined in RFC5280). From now on in this text, X.509 certificates are simply referred to as certifi-cates. The following example is output from the Insta certificate viewer tool (ssh-certview). 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





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) :

9635680922805930263476549641957998756341022541202937865240553

9374740946079473767424224071470837728840839320521621518323377

3593102350415987252300817926769968881159896955490274368606664

0759644131690750532665266218696466060377799358036735475902257

6086098562919363963470926690162744258451983124575595926849551

903

Exponent e ( 17 bits) :

65537

Extensions =

Available = authority key identifier, subject key identifier, key

usage(critical), basic constraints(critical), authority

information access

KeyUsage = DigitalSignature KeyEncipherment KeyCertSign CRLSign[CRITICAL]

BasicConstraints =

PathLength = 0

cA = TRUE

[CRITICAL]

AuthorityKeyID =

KeyID =

eb:f0:4d:b5:b2:4c:be:47:35:53:a8:37:d2:8d:c8:b2:f1:19:71:79

SubjectKeyID =

KeyId =

eb:f0:4d:b5:b2:4c:be:47:35:53:a8:37:d2:8d:c8:b2:f1:19:71:79

AuthorityInfoAccess =

AccessMethod = 1.3.6.1.5.5.7.48.1

AccessLocation =

Following names detected =URI (uniform resource indicator)

Viewing specific name types =

URI = http://pki.certificate.fi:8090/ocsp-1/

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 usingbase-64 encoding (PEM), which makes it simple to store the certificate or copy andpaste it when needed. An example of a PEM-encoded X.509 v3 certificate is shownbelow:

-----BEGIN X509 CERTIFICATE-----

MIICzDCCAjWgAwIBAgIEAhEqcDANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJGSTEpMCcGA1U

EChMgU1NIIENvbW11bmljYXRpb25zIFNlY3VyaXR5IENvcnAxHTAbBgNVBAMTFFNlY3VyZSBTaG

VsbCBUZXN0IENBMB4XDTAzMTIwMzA4MDQyN1oXDTA1MTIwMjA4MDQyN1owVzELMAkGA1UEBhMCR

kkxKTAnBgNVBAoTIFNTSCBDb21tdW5pY2F0aW9ucyBTZWN1cml0eSBDb3JwMR0wGwYDVQQDExRT

ZWN1cmUgU2hlbGwgVGVzdCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAiTd2cdvPlVx

BlHnOaBadyg3T2AT312+9WPKLcPnybIYYGARzCI9Q+XAqH8QGapHuegeVYabIrwVgfOZpfQ8Ihk

asi3oG3j87znL/gbjYBQnUApQBCQjEPcXZoOn/HNH5Qh8tJI8ES39nPBGS6x3UcCbTWOqCqZ5O5

xAUg4HXfh8CAwEAAaOBpDCBoTAfBgNVHSMEGDAWgBTr8E21sky+RzVTqDfSjciy8RlxeTAdBgNV

HQ4EFgQU6/BNtbJMvkc1U6g30o3IsvEZcXkwDgYDVR0PAQH/BAQDAgGmMBIGA1UdEwEB/wQIMAYBAf8CAQAwOwYIKwYBBQUHAQEELzAtMCsGCCsGAQUFBzABhh9odHRwOi8vcGtpLnNzaC5jb206OD

A5MC9vY3NwLTEvMA0GCSqGSIb3DQEBBQUAA4GBADKm1PniVbxZNTtExQtpm2s3eTFc+0rRM5svm





0tm8MALb36VmjWQS8NyqU2kVyJpd+q1coIYFBSzGdyEU7+WXEqoFwOH543YXX/T9QIYqkZ0y/cv

QH40H3TS5iKeNJMAPL50esw3dzUWjTXp0D5cXrl1W3ZLhNH72GX1yWLkugtM

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

A.2.3 Certificate Revocation Lists (CRLs)

A certificate revocation list contains the serial numbers of certificates that have beencancelled before their expiration date. The cancellation might happen for one of sev-eral reasons. For instance, the keys in the certificate might be compromised, or theowner 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 certifica-tion authorities that also issue the certificates. Applications check the CRLs each timethey verify certificates.

If the cancellation of the certificate does not need to be permanent, it is possible tosuspend the certificate instead of revoking it. Suspended certificates can be reactivat-ed at a later time, whereas revoked certificates are permanently cancelled.

A CRL contains a list of revoked and suspended certificates. More precisely, it con-tains a unique key to identify the certificate and its revocation time. The unique keycould be the serial number of the certificate, or another identifier.

New CRLs are fetched periodically from public directories. Depending on the applica-tion, this could happen every five minutes or so. CRLs are usually stored in public di-rectories which can be accessed by LDAP, HTTP or other protocols. Multiple CAs canshare the same CRL directory.

Every certificate may have a pointer to a specific CRL it uses. This is defined whenthe 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 otherknowledge 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 identifiedcertificate in (almost) real-time. As CRLs are published periodically, they cannot beused in environments where more timely validity information is required (for examplee-commerce and other financial applications).

When utilizing OCSP, the OCSP client sends the responder a request message con-taining information on the certificate that is queried for. While the OCSP client waitsfor the response, the certificate is suspended.

When a response is received, the OCSP client acts based on the response as the cli-ent either accepts or rejects the certificate.





A.2.5 Certificate Enrollment

The basic idea of a public-key infrastructure (PKI) is to have a trusted CA which, as atrusted third party (TTP), can be used to build trust between the end entities pos-

sessing the certificates. To add a new end entity to a PKI, the end entity has to createa key pair, and a certification authority (CA) has to certify the key pair. This process ofan end entity enrolling in a PKI is commonly known as certificate enrollment.

Certificate enrollment involves (usually) two parties, a client (an end entity) and aserver (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:

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

2. The end entity generates a key pair.

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

4. The end entity sends the request to the CA.

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

6. 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 tobe 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 privatekey.

Additionally, the CA has to authenticate the end entity. This can be done automaticallyby 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 certifi-cate. The CA, however, considers the request as a wish list, and under its own poli-cies, it can deny the request completely or modify the requested values.

The certification authorities that process the requests can be roughly divided into twocategories: manual CAs and automatic CAs. Manual CAs require a human operator tomanually approve the request, whereas automatic CAs issue the certificates automat-

ically, for example, based on shared secrets (one-time passwords).

However, in real life, also automatic CAs need a human operator for creating and dis-tributing the one-time passwords.

If manual actions are needed, the processing of a certification request may take sometime. The end entity has to later poll for the certificate.

Several online protocols have been developed for certificate enrollment. These proto-cols are described below.





Certificate Management Protocol (CMP)

CMP is a certificate life-cycle management protocol developed by the PKIX WorkingGroup 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 therequest message formats. These formats provide the mechanisms for proof of pos-session (PoP) for the private key that is being certified and they are wrapped insideCMP 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 onlypart of it.

In CMP, an end entity needs to send an initial request when the first certificate is en-rolled from a given CA. Consequent certification requests can be signed with the validprivate key to facilitate automatic key renewal. Revocation requests can be used to in-form the CA about the need to revoke a certificate.

Currently CMP is not widely supported by the end-entity clients and devices, but as aresult of intensive interoperability efforts it is likely that more client-side implementa-tions will emerge.

Simple Certificate Enrollment Protocol (SCEP)

SCEP was developed by the IPSec community to overcome the problem of enrollingcertificates for routers and other network devices. SCEP is widely supported both onthe client and the server sides. SCEP uses PKCS #10 as the certification request for-mat and PKCS #7 as the digital envelope syntax. HTTP is used as the transport pro-

tocol.

A prerequisite for SCEP enrollment is that the end entity has to have the appropriateCA certificate, which must have been verified using some offline method (fingerprintcheck). The verification should be done to prevent man-in-the-middle attacks, in whichsomeone is impersonating the CA.

The initial end-entity authentication in SCEP is done either manually or by usingshared secrets. When using a shared secret scheme, the CA administrator generatesa one-time password for the entity and distributes the password to the entity in a se-cure way. When the entity generates the certification request, it includes the passwordin the request.

After approving the request the CA issues the certificate and packs it to a PKCS #7cryptographic packet and sends it to the end user (and possibly publishes the certifi-cate to a directory).

Web-Based Enrollment

Many clients support web-based certificate enrollment. The end entity generates a keypair, creates the certification request on a web browser, and submits the request tothe CA with an HTTP POST operation. After approving the request, the CA returns thecertificate to the end entity. Transport Layer Security (TLS) can be used to protect theenrollment session.

If the certificate policy requires manual administrator approval, the user can poll thecertificate via the web pages.





Most web browsers support exporting the private key and the certificate in PKCS #12format. PKCS#12 is a portable file format for storing user credentials and many PKIclient 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 pass-phrase. In some cases, it is also possible to download the PKCS #12 file onto a smartcard.

PKCS#10

PKCS #10 is the simplest form of certificate enrollment. However, it requires moremanual 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 todownload the certificate later after it has been approved (download with Download-button or some web browsers require user to click right button of the mouse and to se-lect 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.

LDAP

The acronym LDAP stands for Lightweight Directory Access Protocol. It is a protocolthat defines how an X.500 Directory can be accessed by a client.

LDAP operations can be roughly separated into two categories; search and modifyoperations. Client applications typically only need search operations for fetching certif-icates and CRLs. A certification authority also needs to add, update, and remove di-rectory entries in order to make certificates and CRLs available for directory users. Allanonymous clients can be given access to perform searches, while only directory ad-ministrators 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 distin-guished names (RDN) which form the distinguished name (DN) of the entry. The dis-tinguished name has to uniquely define the entry within the directory. Some of the typ-ical RDNs used in distinguished names are the following:

C Country

O OrganizationOU Organizational Unit









Appendix B GlossaryThis glossary contains definitions of special terms and abbreviations used in the cus-tomer documents of Insta DefSec Oy. For more information on terms related to Inter-net 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 isalso used to describe X.509 certificates and CRLs. There are many ways to en-code 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 ofStandards and Technology (NIST) in FIPS 197.

Authentication

Authentication is the process of verifying that the remote entity is who it claims tobe.

Authentication is not the same as authorization (access control), since it is not

concerned with determining which rights the remote entity has. Authenticationmeans for example verifying that the correct password for the given user accounthas been entered, but it does not mean determining what file system permissionsthe user has.

Authorization

Authorization is the process of determining which rights an entity has, after theentity has been authenticated.

Availability

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 EnhancedMail (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





A representative of symmetric (secret-key) encryption algorithms that encrypts afixed 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, underthe same key.

Blowfish

A symmetric block cipher designed by Bruce Schneier. Blowfish uses a block sizeof 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 allpossible values one by one. The determining factor for the likelihood of success ofa brute-force attack is the number of possible values. This is important for crypto-graphic 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 2ˆ128 = 3,4*10ˆ38 possible values. Even with

very large amounts of processing resources available, a key with this size is notlikely to be broken within a reasonable amount of time. A processor capable ofperforming 1,000,000,000 such guesses per second would still need 3,4*10ˆ29 seconds = 10ˆ22 years to try all possible values, which is not practical.

CAST-128

A symmetric block cipher with a block size of 64 bits and a key length of up to 128bits. CAST-128 is believed to be very strong. See RFC 2144 for more information.

Certificate

Certificates are digital documents that are used for verifying the identity of com-municating parties. In this documentation, the term certificate is commonly usedto refer to X.509 public-key certificates.

A public-key certificate binds identity information about an entity to the entity’spublic key for a certain validity period.

certificate enrollment

Certificate enrollment is an action in which a public key gets certified by a certifi-cation authority (CA). In this action a client provides the CA with a public key andsome additional data in a certification request. The CA signs this key together withadditional information with its own private key and returns the signed certificate tothe client.

certificate extension

An optional field in an X.509 v3 certificate providing further information of the us-age or applicability of the certificate in a certain PKI.

Certificate Management Protocol (CMP)

CMP defines online interactions between the end entities, the registration authori-ties, and the certification authority in a PKI. It is developed by the PKIX WorkingGroup 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 cer-tificate to a particular community.





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 re-voked or suspended by the certificate issuer (the CA) before their expiration date.The CA usually issues new CRLs at frequent intervals. Current PKIX implementa-tion 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 certifi-cates) and vouches for the binding between the data items in a certificate.

Certificate users (end entities) depend on the validity of information provided by acertificate. 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 corpora-tion, or some other organization. A CA is responsible for managing the life cycleof certificates. Depending on the type of certificate and the CPS that applies, a CAmay also be responsible for managing the life cycle of the key pair associatedwith the certificate.

certification practice statement (CPS)

A statement of the practices that a certification authority employs in issuing certifi-cates. A CPS is a published security policy that can help a certificate user to de-cide whether a certificate issued by a particular CA can be trusted enough to usein a particular application. A CPS is usually more detailed and procedurally ori-ented than a certificate policy.

certification request

A certification request contains at least the public key and some identity infor-mation of the entity making the request, and it is signed with the private key of theentity. Certification requests are generated by end entities or RAs and sent to theCA. If allowed by the certificate policy of the CA, a certificate can be issued basedon the request.

certification service provider (CSP)

A CSP is an organization that acts as a trusted third party or a CA host providingPKI services to other organizations and individuals.

Ciphertext

Text which has been encrypted by an encryption system. The opposite isplaintext.

Confidentiality

A security service that protects data from unauthorized disclosure. Usually, unau-thorized disclosure of application level data is the primary concern, but the disclo-sure of the external characteristics of communication can also be a concern insome circumstances. The traffic flow confidentiality service addresses this latterconcern by concealing source and destination addresses, message length, or fre-quency of communication.

cross-certification





Cross-certification is a trust model where two certification authorities (CAs) certifyeach other. It allows end entities in different certificate hierarchies to verify eachother’s certificates.

Cryptology

The branch of mathematics that studies the mathematical foundations of crypto-graphic methods.

Data Encryption Standard (DES)

DES is a U.S. Federal Information Processing Standard (FIPS) that defines theData Encryption Algorithm (DEA). The term DES is also commonly used when re-ferring to the algorithm.

The algorithm itself is a symmetric block cipher with a block size of 64 bits and akey length of 64 bits (of which 8 are parity bits). It was created in the 1970s byIBM assisted by the U.S. National Security Agency (NSA).

Single DES is no longer considered secure. The controversy around DES keylength 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 analy-sis 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 availa-bility of a service.

dictionary attack

A dictionary attack is an attempt to guess, for example, a password by trying allwords in a given dictionary (of for example the English language) and simplepermutations of those words. Even though the number of words and simple per-mutations of them is large, it will be significantly smaller than trying all possiblevalues. For example most modern computers would be able to run through all thewords of an English dictionary in a few minutes. This makes dictionary attacksmuch more feasible, and if a password is very close to a word in a dictionary, itwill not last long against a dictionary attack.

Diffie-Hellman key exchange

A method for key exchange between two parties. This method can be used togenerate 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 theuse of digital signatures or other means of authentication with the Diffie-Hellmanprotocol.

digital signature

By encrypting a digest of a message with the private key, authentication can laterbe 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 in-vented by the U.S. National Security Agency (NSA) and it is defined by NIST inFIPS 186-2. For more information, see e.g. Bruce Schneier: ”Applied Cryptog-raphy”. See also DSS.





Digital Signature Standard (DSS)

The U.S. digital signature standard defined by National Institute of Standards andTechnology (NIST). It is a standard for digital signatures using the DSA public-keyalgorithm and the SHA-1 hash algorithm.

Distinguished Encoding Rules (DER)

The Distinguished Encoding Rules, defined in ITU-T X.690, describe a way ofconverting structures of ASN.1 into binary data. DER is a subset of BER andguarantees unique representation in binary for every ASN.1 structure.

distinguished name (DN)

A distinguished name belongs to the X.500 Directory terminology. It declares aname that can be distinguished from other names in the directory. In that sensethat name does not have to be unique. Often these names are seen encoded us-ing 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. www.ssh.com. TheDomain Name System (DNS) infrastructure is used to map domain names to IPaddresses. See STD 13 for more information.

Dynamic Host Configuration Protocol (DHCP)

A protocol that provides a means to dynamically allocate IP addresses to comput-ers on local area networks (LANs). The system administrator assigns a range ofIP addresses to DHCP, and each client computer on the LAN has its TCP/IPsoftware 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 isdefined in RFC 2131.

Elliptic curve cryptography (ECC)

Public key cryptography based on elliptic curves over finite fields. ECC givessame strength as RSA with smaller key sizes.

Elliptic curve digital signature algorithm (ECDSA)

ECDSA is digital signature algorithm variant for elliptic curve cryptography. It isrecommended (NIST 2011) that used SHA hash is equal to EC key size. For ex-ample using 256 bit EC key would use ECDSA with SHA-256.

Encryption

A security mechanism used for the transformation of data from an intelligible form(plaintext) into an unintelligible form (ciphertext), to provide confidentiality. The in-verse 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. Theend entity has also the private key counterpart of the public key in the certificate.

Entity

An entity is a party in a security relationship. An entity could, for example, be oneof the following: user, company, program or process (server process/program, cli-







tegrity services are often cited separately, in practice they are intimately connect-ed and almost always offered together.

Internet Engineering Task Force (IETF)

An international standards body that has standardized the IP protocol and most ofthe other successful protocols used on the Internet. The IETF web pages areavailable at http://www.ietf.org/.

Internet Protocol (IP)

The network layer for the TCP/IP protocol suite, defined in STD 5. IP is a connec-tionless, best-effort packet switching protocol. It provides packet routing, fragmen-tation, 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 En-gineering Task Force (IETF). IPSec can be used for protecting the data transmit-

ted by any service or application that is based on IP. The IPSec protocols are de-fined 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 ithas 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 IPaddress can be unicast, broadcast, or multicast. Please see STD 5 for more in-formation.

IP packet

A self-contained, independent entity of data carrying sufficient information to berouted from the source to the destination computer without reliance on earlier ex-changes between this source and destination computer and the transporting net-work. 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 ac-cessing directories that support the X.500 Directory model, while not incurring theresource requirements of the X.500 Directory Access Protocol (DAP). This proto-col is especially targeted at management applications and browser applicationsthat provide read/write interactive access to directories.

The protocol is carried directly over TCP or other transport, bypassing much ofthe session/presentation overhead of X.500 DAP.

Managed Service Provider (MSP)

A managed service provider (MSP) provides delivery and management of net-work-based services, applications, and equipment to other organizations or indi-viduals. A CA hosting service is an example of an MSP activity.

MD5





A message-digest algorithm developed by Ron Rivest of RSA Security. It com-putes a secure, irreversible, cryptographically strong 128-bit hash value for a doc-ument. The algorithm is documented in RFC 1321. Newer 160-bit algorithms suchas SHA-1 and 256-bit algorith such as SHA-256 are thought to be more securethan MD5.

MSCAPI

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 toobtain 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 certifi-cate, instead of or as a supplement to checking against a periodically publishedCRL. OCSP is described in RFC 2560.

Passphrase

A passphrase is a string of characters. Whereas a password is used for authenti-cation directly, a passphrase is only used to protect the actual information usedfor authentication, the private key. password A password is a string of characterssuch as numbers, letters and special characters, used for authenticating an entityagainst 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 us-ing dictionary attacks.

PC/SC

A standard for integrating smart cards and smart card readers, defined by thePC/SC Workgroup.

perfect forward secrecy (PFS)

Refers to the notion that any single key being compromised will permit access toonly data protected by that single key. In order for PFS to exist, the key used toprotect transmission of data must not be used to derive any additional keys. If thekey used to protect transmission of data was derived from some other keying ma-terial, that material must not be used to derive any more keys. Also referred to aspublic-key forward secrecy (PFS).

Personal Identification Number (PIN)

Security tokens such as smart cards usually contain one or more PIN codes thatprotect the contents of the token. Different objects (private keys, data objects, andso on) on the token may be protected by different PIN codes. A PIN code must begiven before using a protected object. If a wrong PIN code is entered severaltimes in a row (usually three), the object is blocked and cannot be used before theunblocking key is given. See PUK.

Personal Unblocking Key (PUK)

Each PIN code has an associated PUK code that can be used to unblock the to-ken if it becomes blocked as a result of entering several wrong PIN codes in arow. PUK codes should be stored in a safe place, preferably by the operator who

has issued the security token.PKCS#1





This standard defines the usage of RSA algorithm in encryption and digital signa-tures. It contains explicit suggestions for the encoding of keys and algorithm inputformatting.

PKCS#7

This standard defines the general syntax for data that may have cryptography ap-plied to it. This data includes digital signatures and recursive digital envelope en-coding for cryptographic objects.

PKCS#8

This standard describes syntax for private-key information, including a private keyand a set of attributes. The standard also describes syntax for encrypted privatekeys.

PKCS#10

This standard defines a format for certification requests.

PKCS#11

This standard defines CryptoKi, which is an interface for cryptographic devices(for example, smart cards and cryptographic accelerators).

PKCS#12

This standard defines a portable format for storing or transporting a user’s privatekeys, certificates, and miscellaneous secrets. PKCS #12 is supported by commonweb browsers for importing and exporting user private keys.

PKCS#15

This standard defines how keys, certificates, and application-specific data may bestored 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, draftedby an IETF working group of the same name.

Plaintext

Text which has not been encrypted. The opposite is ciphertext.

Privacy Enhanced Mail (PEM)

A suite of protocols for encryption, authentication, message integrity, and keymanagement. For more information, see RFC 1421. PEM is commonly used to re-fer to an encoding method where binary objects such as certificates are convertedto a printable format using a 64-character subset of the alphabet (this is alsoknown as base-64 encoding).

private key

In public-key cryptography the private key is only known to the holder, and it canbe 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.





A common way to establish PoP is for the end entity to sign a value with the pri-vate key and append the signature to the certification request.

Proxy

Proxy is a cache server that acts as a firewall, protecting the local network. It al-lows 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, canbe used to verify signatures and encrypt messages.

public-key cryptography

In contrast to symmetric (secret-key) cryptography with just one cipher key, inpublic-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 ad-dressed to that person. The private key must not be available to anyone but itsowner, 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 themost important PKCS standards include PKCS#1 for RSA encryption and signa-ture formats, PKCS#7 for cryptographic message encapsulation, PKCS#10 forcertification requests, and PKCS#11 for a cryptographic token interface commonlyused with smart cards.

public-key infrastructure (PKI)

PKI consists of end entities possessing key pairs, certification authorities, certifi-cate repositories (directories), and all the other software, components, and enti-ties required when utilizing public-key cryptography.

RC2

A symmetric block cipher designed by Ronald Rivest for RSA Security. RC2 usesa block size of 64 bits and a variable key length.

RC4

A symmetric stream cipher with a variable key length designed by Ronald Rivestfor RSA Security in 1987. RC4 is based on the use of random permutation and itsoperations are byte-oriented.

registration authority (RA)

An optional entity in a PKI, separate from the CA(s). The functions that the RAperforms will vary from case to case but may include identity authentication andname assignment, key generation, token distribution, and revocation reporting.

Request For Comments (RFC)

A document of the Internet Society under standardization. RFCs can be located athttp://www.ietf.org/rfc.html.

Rijndael





Designed by Joan Daemen and Vincent Rijmen, Rijndael is a symmetric block ci-pher with a block size of 128 bits and a variable key length of 128, 192, or 256bits. Rijndael was chosen for the U.S. Advanced Encryption Standard (AES).

RSA

A public-key encryption and digital signature algorithm, invented by Ron Rivest, Adi Shamir, and Leonard Adleman. For more information, see e.g. Bruce Schnei-er: ”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 designedby National Security Agency (NSA) and defined by National Institute of Standardsand Technology (NIST). See also MD5.

security gateway (SGW)

An intermediate system that acts as the communications interface between twonetworks. The internal subnetworks and hosts served by a security gateway arepresumed 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 pro-tect itself.

The policy will generally require two parts: a general policy and specific rules (sys-tem-specific policy). The general policy sets the overall approach to security. Therules define what is and what is not allowed. In this document the term securitypolicy 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 usethe network resources.

SHA-1

SHA-1 is improved cryptographic hash function of the original Secure Hash Algo-rithm (SHA-0). The algorithm produces a 160-bit message digest and it is consid-ered good. It is part of the U.S. Digital Signature Standard (DSS) and it is definedin 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/512-

bit message digest. The algorithms are defined in FIPS 180-2. Hash algorithmfrom 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, issimilar to a password in the sense that it is also used for authentication, butshared keys are often used to authenticate both entities at the same time. If bothentities 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, inwhich case the shared key is created by an RA or a CA and distributed to the endentity by some out-of-band method. The end entity can then authenticate itself byusing the shared key in the certificate enrollment. In this case, the key is often lim-ited to a certain number of uses.





Simple Certificate Enrollment Protocol (SCEP)

SCEP is developed by Cisco Systems and VeriSign. It is an enrollment protocolsupported by Cisco’s routers.

smart card

A smart card, or an integrated circuit card, is a device for secure identification ofusers of information systems. Typically smart cards contain a processor that cando a private-key operation using a private key on the card, some kind of a file sys-tem that can hold certificates, public keys, or other data relevant for the use of thecard.

SOCKS

SOCKS is a protocol for traversing through application gateway firewalls. It allowsan application inside the firewall to access resources on the global Internet. Theprotocol is defined in RFC 1928.

standard (STD)

A subseries of Request For Comments (RFC) that specify Internet standards. Thestandards in the STD series also retain their RFC numbers.

stream cipher

A representative of symmetric (secret-key) encryption algorithms that encrypt asingle bit at a time. With a stream cipher, the same plaintext bit or byte will en-crypt 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 ofthe conversing parties, sizes of IP packets, and flow identifiers.

Transmission Control Protocol (TCP)

A widely used connection-oriented, reliable (but insecure) communications proto-col. This is the standard transport protocol used on the Internet. It is defined inSTD 7 (also RFC 793).

Transport Layer Security (TLS)

Transport Layer Security is a protocol providing confidentiality, authentication, andintegrity for stream-like connections. It is typically used to secure HTTP connec-

tions. The protocol is being standardized by a working group of the IETF.

Twofish

A strong and fast block cipher designed by Bruce Schneier. Twofish was one ofthe five final candidates for the United States government’s new cipher standard, AES (Advanced Encryption Standard). Twofish uses a block size of 128 bits and akey 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 anURL.

Uniform Resource Locator (URL)




URLs are used to describe the location of web pages, and are also used in manyother contexts. An example of an URL is http://www.certificate.fi/index.html. Theyare 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 In-ternet. 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 toprovide a secure connection through an otherwise insecure network, typically theInternet. The encryption may be performed, for example, by firewall software, by arouter, or by a dedicated VPN security gateway.

X.500

The family of joint ITU-T/ISO standards defining the X.500 Directory. The directo-

ry can be used for many applications, such as storing certificates, or informationabout people. LDAP is often used to access the X.500 Directory.

X.509

The ITU-T X.509 recommendation defines the formats for X.509 certificates andX.509 CRLs. Different X.509 applications are further defined by the PKIX WorkingGroup of the IETF. These include X.509 version 3 public-key certificates andX.509 version 2 CRLs.

Documents

Certifier 5.2.3 ProductDescription