Guide

Intended Audience

The Audience of this Guide should have a basic understanding of computers, how to use office software, send and receive email and how to browse the internet.

Your Approach at Your Speed

Implementing a certificate Authority is not a ‘one size fits all’ project. Your requirement might be for a few hundred users with exceptionally high security parameters or you could be looking to authenticate several million hardware devices. The commercial organisation’s requirements are typically related to cost, benefit, risk and return whilst the government project is more concerned with statutory requirements, IT standards and compliance.

No matter how small or large your requirement, you’ll have restrictions on what your current environment can cope with; availability of staff; budgetary constraints and other parameters within which you must choose the correct CA for your organisation. You may want to be very ‘hands on’ at every stage of the project and even want to conduct some of the integration and even programming or you may decide you want us to do everything for you. Just as Digi-CA™ is totally flexible, so too is the Digi-Sign approach.

Approach

The ‘Fast Track’ Approach

‘Fast Track’ is exactly as it sounds, you want everything done as quickly as possible and you want the professionals to do it for you. This is a total ‘turn key’ approach where we take your instructions, document them and deliver the entire solution back to you in the shortest possible time. Once the Digi-CA™ is in ‘production status’, you nominate personnel within your organisation to take responsibility for it and we support them in the background.

Total Trust Management™ Approach

This is where we not only ‘Fast Track your requirements through to delivery but actually assume responsibility for the total management of your CA environment for as long as you need us too.

Total Trust Management™ [TTM™] is a unique offering from Digi-Sign (although some vendors have tried to copy it) and it means that you Trust us to Totally Manage the Digi-CA™ for you. TTM™ is much more than a dedicated telephone support line, it’s a service where Digi-Sign personnel effectively work for you. We ensure that the CA technology is introduced to the end users with the minimum of fuss. All you do is agree how you want us to operate the Digi-CA™, and we do everything for you. It’s a bit like travelling First Class.

75% of our customers use TTM™ in the first year, at least, so that they can see how we do everything and then learn by watching us.

Build-Box-Deliver Approach

For an installation of Digi-CA™ Server (see sub section 3.7.3.2), we document your requirement, you sign the documented order and then we build, box and either ship it to you for installation or, in the case of Digi-CA™ Service (see sub section 3.7.3.1) we host it for you so that it only needs to be activated.

If your requirements include integration work or customisation, this is scheduled and delivery is subject to Production scheduling and all of this is agreed in advance.

Delivery by an ARP Member

Most Digi-CA™ systems are delivered by a member of the Digi-Sign Affiliates, Resellers & Partners [ARP] Network. The ARP member will co-ordinate all aspects of the delivery, installation, configuration and setting the system to production status for you.

Benefits

Digi-CA™

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

By combining the consulting and professional services offered by Digi-CAST™ (see sub section 3.1) with the functions provided by Digi-CA™, can bring an organisation to a highly professional PKI level, meeting the criteria for internationally recognised accreditation standards such as WebTrust® and ISO 27001 certifications.

Choosing

Reasons for Choosing Digi-CA™

Compliance to international standards		Digi-CA™ follows the international industry standards for PKI and CA systems so that is can easily fit into almost any certificated IT infrastructure and work seamlessly within that environment.  This compliance to standards is important when considering current requirements and potential future requirements too
Programming language		All components of the Digi-CA™ system kernel have been developed in C on Unix and this is considered the most stable, secure and efficient language and operating system for the development of PKI & CA systems
Centralised Management		Web based ‘system management centre’ for all operated CAs, RAs & LRAs makes it ideal for operation as an installed standalone CA system or as a Managed CA
‘futureproof’		By its very design, the entire Digi-CA™ system can be in house, totally out sourced or a combination of the two and this can be decided at any stage during the life of the system. So you can purchase what it needs today, safe in the knowledge that you can easily migrate and move all or part of the system to the Managed CA alternative to meet your future demands
Ease of integration		Whether now or in the future, because it is LDAPv3 compliant, Digi-CA™ can publish X.509 certificates and certificate Revocation Lists [CRL] to other directories. This is a significant factor when considering integration with existing or future environments
Scalability		Digi-CA™ can scale, easily and with minimal/no interrupting of live operations. This is important when considering the future growth of your requirements. It is also possible to add additional hardware to expand the system capacity and services and to conduct cross certification
Continuous operation		When considering the future growth of your requirements, live production can continue uninterrupted while adding more CAs, RAs and LRAs. These capabilities ensure the CA remains operational and without interruption throughout
Customisation to your requirements		Custom multi-layer CA hierarchy, RA and LRA distribution can be modified, extended and changed at any stage and again, this can be done without affecting the operation of the live environment
‘look & feel’ customisation		The entire Digi-CA™ system interfaces and all its levels can be easily changed using Cascade Style Sheet [CSS]. This ability to completely change the ‘look and feel’ of the system eases the deployment to your end users because they know you but may not be familiar with the CA vendor.  It also helps with integrating into web sites and other online systems seamlessly
Multiple Languages		Language localisation is “plug n’ play” for displaying all interfaces in your desired language(s). This further helps the deployment to end users and reduces ‘help desk calls’ (where users are really looking for translation of help files, etc)
Custom profile, enrolment & DN capabilities supplied as standard		Certificate profiles and enrolment policies can be customised and therefore full custom certificate subject Distinguished Name [DN] attributes and certificate extensions are possible.  This is particularly important when meeting national & international standards and the cost of providing these capabilities from other systems can be considerable
CA Flexibility		Ability to operate multiple independent CA hierarchies from a single system instance without the need of installing multiple software applications on multiple server computers to run each CA hierarchy
RA Flexibility		Multiple independent Registration Authority [RA] instances from a single system without needing to install multiple applications on multiple servers to run each RA
100% browser independent		100% certificate enrolment web browser platform and operating system independency
Root CA cross certification		Digi-CA™ offers the capability of cross certification between the your Root CA and any other CA
Trusted Root capability		Also it can be cross certified by a Trusted Root CA of issuing trusted SSLs and secure, signed and/or encrypted email
Best training & knowledge transfer		With the largest online searchable PKI & CA KnowledgeBase, the extensive documentation offered, the Digi-TaSC system and the many different types of training offered, this proposal offers the most comprehensive that programme for your personnel
Overall most capable & most competitively priced		Digi-CA™ achieves the best blend of meeting your current requirements and possible future ones too. It’s highly customisable and flexible features means it will meet future demands easily, without incurring downtime, service interruption or unwieldy costs

Digital Certificates

Learn About Digital Certificates

In the ‘real world’ passports and ID cards identify people; crests or symbols identify institutions like the police or a hospital, for example; and a seal or stamp authenticates a document. In the Digital World, we use digital certificates to do the same thing.

The Basics

In the ‘digital world’ the digital certificate is used to identify the person, authority, device, website, software and/or electronic file and it is a CA that issues these digital certificates. The purpose of the CA is to provide digital identities of users, devices or files. The CA is configured and installed in accordance with the customer’s requirements and these requirements are documented in the Certificate Policy [CP] for the CA.

Every request for a digital certificate is validated and approved, or rejected, by the Registration Authority [RA]. A trained Administrator, again in accordance with the CP, can manually operate the RA or this function can be automated depending on the CA you choose. Every digital certificate issued is unique and is delivered according to the CP.

The Business Case

Any network where information is stored electronically needs to be secured. Up to now, the most common way of protecting such data has been through the use of usernames and passwords. This is no longer considered ‘secure’.

A single unsecured transaction could result in significant losses to an organisation. This alone makes a strong argument for using digital certificates. Digital certificates remove this risk completely.

However, the digital certificate is only as good as the security processes and procedures that surround the issuing of that certificate to the individual, or device. This is where the validations process, and its importance, must be understood thoroughly. If it is easy for one person to assume the identity of another and subsequently, as a result of poor policies and procedures, successfully apply for and receive another person’s certificate, then the value of that digital identification is effectively useless. On the contrary, a correctly managed Certificate Authority, can bring endless value and cost savings to countless digital and physical environments.

Even more compelling business arguments in favour of using digital certificates would include the reduction or removal of paper forms and workflow from an organisation. Paper business processes can be computerized and digital signatures replace handwritten signatures. The savings to organisations as a result of using this technology are well documented.

Two-factor authentication, Machine Readable Travel Documents [MRTD], secure email national ID cards, digital rights management, web access control, device-to-device authentication and many other business processes can benefit from significant savings by using technology smartly. Integral to all of these processes, is the requirement for digital authentication, digital identification, digital encryption, digital stamping and digital signing and being able to support these transactions with a legally binding infrastructure. This is what Digi-CA™ provides to your organisation.

Replacing CA

Replacing an Existing CA

If you are trying to migrate an existing environment from another Legacy CA Authority to Digi-CA™, there is a ready-to-go solution that works independently from the Legacy CA. The customer can provide the information manually, or use migration engines provided by the Digi-CAST™ team.

This is how it works:

A list of all existing certificates is provided, including all of the following information:
• certificate Subject Details
• Expiry Date
• certificate with public key
• certificate Issuer: Signer CA certificate with public key

The information provided by the customer is loaded into the Digi-CA™ system using the Digi-CA™ Control Centre;

Based on the information provided, the Digi-CA™ will send expiry reminder emails according to the expiry reminder policy and each email will contain a unique URL for the certificate renewal.

For client certificate migration, once the user enters the certificate renewal screen using the URL provided in the email, they will be prompted by the system to prove their identity using their existing/old certificate. If the old user certificate details match the pre-configured Digi-CA™ system data, the user will be allowed to renew their certificate.

For SSL certificates, the Digi-CA™ is preconfigured in the same way as for client certificates except that it doesn’t require the old certificates to be present. All that is needed is the expiry date so that the replacement occurs seamlessly.

This is the highly effective method used to replace older and more costly Legacy CA systems.

‘Fast Track’ Your Requirements

The success or failure of any project can normally be traced back to the start, where bad planning will be found. This poor initial planning will either be as a result of bad management and leadership and to a lesser extent, the selection of technically inexperienced personnel. That is why Digi-Sign insists that no matter how many 'issues' the project encounters en route, if it is properly planned initially, it will succeed.

Understanding Online Security

If you want to use the internet as a tool to improve communications, take advantage of on demand cloud computing, reduce costs, improve customer service and retention, or to expand your market reach, then Digi-Sign’s products, services and solutions will help you secure these environments.

These same offerings can be used in physical border control, building access, electronic signatures and any situation where truly knowing the other person/device is a necessity to securing the transaction.

Agreement

Service Level Agreement [SLA]

The Service Level Agreement [SLA] is critical to the continued success of the Digi-CA™ delivery model and central to this SLA is the Incident Management System [IMS]. The IMS is an automated system that escalates issues, without human intervention, and automatically notifies the user at each stage.

The IMS incorporates system and personnel reaction times with issue escalation times and then monitors each and every support issue to the successful completion as confirmed by the customer.

IMS Level	Description	Time Before Escalation	Time Lapsed
Level 1	Incident Logging
Level 2	Severity 1 Escalation	4 hours	4 hours
Level 3	Severity 2 Escalation	20 hours	24 hours
Level 4	Severity 3 Escalation	48 hours	72 hours
Level 5	Case Termination / Indefinite Suspension	48 hours	120 hours

The IMS automatically provides this level of service using the SLA table of IMS Escalation Levels.

The IMS system is shared between your organisation and ours so that the correct delivery of the SLA is maintained. In this instance there are two components to the SLA delivery namely: the Public Interface, then the internal Support Case responsibility delineation and the IMS escalation.

Using the workflow and case escalation contained in the IMS, every case is still managed and monitored by the system, but the case may be resolved by multiple personnel in different organisations.

Further explanation of the SLA and how it is managed is available at the following URL:

www.digi-sign.com/about/service+level+agreement [1]

This level of dedication has resulted in numerous and recurring testimonials, letters of reference and increasing number of customers and members enjoying our systems and support:

www.digi-sign.com/about [2]

Numerous Governments around the world and countless internationally recognised organisations have commented on the effectiveness of the IMS.

Application

Certificate Application

Digi-CA™ has different certificate application options for each type of digital certificate it produces. In low volume situations, such as SSL certificates, the application process is conducted manually. Alternatively, when issuing thousands of client certificates to end users, part or all of the application process can be automated.

The three application options are completely manual, completely automated or partial automation, as required.

Manual Certificate Application

There are two primary ways that the end entity certificates are delivered. Either the certificate is delivered as a package [Package Method] or it is delivered as a result of a series of steps in a process [Process Method].

Manual Certificate Approval

Xxxxxxxxxxxxxxxxxxxxxxxx /digi-ca/introduction/

Manual Certificate Application

There are two primary ways that the end entity certificates are delivered. Either the certificate is delivered as a package [Package Method] or it is delivered as a result of a series of steps in a process [Process Method].

Automated Certificate Approval

Using the

Automated Certificate Application

There are two primary ways that the end entity certificates are delivered. Either the certificate is delivered as a package [Package Method] or it is delivered as a result of a series of steps in a process [Process Method].

Authentication

Proving Identity & Authentication

In the 'real world' passports and ID cards identify people, crests or symbols identify institutions like the police or a hospital and a seal or stamp authenticates a document.

Proving Online Identity & Authentication

In the online world, a digital certificate can be used to identify a person, an authority or device like a web site and/or an electronic file or piece of software. The CA issues digital certificates that provide digital identities and/or to prove the authenticity of users, devices or files. The digital identities are proven by use of the digital certificates.

The digital certificate is the unique identifier that allows individuals and devices to be irrefutably linked to their actions, transactions and communications. In the case of an organisation or corporate body, the Digi-SSL™ acts as a seal or crest of authenticity. For an individual, the digital certificate acts as the electronic equivalent of the passport or driver's license.

Another use for the digital certificate (also called an electronic signature) is for digitally signing electronic files and data just as a person’s signature or official seal is used to authenticate paper documents. This dual functionality of both identification and authentication enables many different types of electronic transactions.

CA Software

CA Software

CA Software is a software product that is installed, either in a data centre or at the Customer site. This CA Software charges a once-off fee upfront that is based on the cost of the software, its configuration and installation and then the number of digital certificates required over the life of the product's use. The only other fee the Customer pays is an annual license fee to cover upgrades, patches and application telephone support required to keep the CA operational. Digi-CA™ Server is CA software.

The CA Software user creates and controls their own CA environment but in so doing must have reliable internet connections, hardware, hardware support, compliance documents, Administrator’s and its own technical support help desk.

The Third Type of CA - Digi-CA™ Shared

The Shared CA, Digi-CA™ Shared, is a concept and capability that is unique to Digi-CA™. It is made possible by the component design and flexibility that is at the core design of Digi-CA™ and is not available from any other CA vendor.

The concept is simple: The benefits of outsourcing the entire CA to a Trusted Third Party [TTP] as a Managed CA may meet most of your main business objectives. In a second scenario, your organisation may require total ownership of the CA in which case the Managed CA is more suitable. But there is a third scenario where you want to own the critical assets but do not wish to manage everything internally. In this case, the Digi-CA™ Shared system is the solution.

In instances where critical assets, such as the use of a Hardware Security Module [HSM], databases, key storage and other functions must be retained by your organisation and the day-to-day administration, support, help desk, ‘critical response’ and other ‘non critical’ components can be outside your organisation, then Digi-CA™ will be your choice.

Digi-CA™ Shared offers all the technical backup and support components of your CA requirements and ‘fills in any gaps’ in your current environment. The external infrastructure, the team of professionals and specialist you require and other critical resources such as Disaster Recovery, critical response and Service Level Agreement [SLA], components can be outsourced with ease. At the same time, the principal assets and integrity you wish to own and control can remain inside your organisation.

Digi-CA™ Shared can be designed and delivered to meet your precise requirements and can combine physical IT assets, personnel, help desk, internal and external networks and servers. For further details contact a member of the Digi-CAST1™ Technical Advisor Team and they will advise you accordingly.

Selecting the Correct CA for You

To decide on the best CA system for your environment, there are three key considerations you need to take into account:

• The type of user group you have
• The type of certificate this group needs
• The technical personnel you have available

CA Software

Digi-CA™ Server

Digi-CA™ Server is the CA Software that is installed on a server in a data centre or at the customer site. As explained in 2.6.3, Digi-CA™ charges a once off license fee in advance that is based on the cost of the software, its configuration and installation and then the number of certificates required over the life of the product's use. The only other fee you pay is the annual license fee to cover upgrades, patches and application telephone support (see sub section 3.14 for more details).

Digi-CA™ Shared

Digi-CA™ Shared was a concept conceived by Digi-Sign in 2006 that has only recently been acknowledged by potential customers as a real alternative in the provisioning of CA services. Although implementations of this concept CA are limited, the capability and the option are important.

Typical enquiries come from large industry or government agencies where ownership of the entire CA is not a requirement, but ownership of specific components is preferred (e.g. data files, HSMs or the requirement to have a complete, hosted disaster recovery system). When considering Digi-CA™, the availability of this concept may not be of paramount importance, but its availability may be very useful during the continued growth and expansion of the total environment.

Digi-CA™ Classes

Digi-CA™ is delivered either as CA Software or as a Managed CA and it is available in three classes:

• Digi-CA™ Xs - Entry Level CA
• Digi-CA™ Xp - Professional CA
• Digi-CA™ Xg - Trust Centre CA

Digi-CA™ Variations & Combinations

There are four principal variations of Digi-CA™ Service and each variation can be provided as a single variant and multiple combinations are also possible. The four main variants are:

• Digi-SSL™ Service - is for SSLs in bulk (5 or more)
• Digi-Access™ Service - for two factor authentication certificates
• Digi-Mail Service™ - provides secure email certificates
• Digi-ID™ Service - is for multi-use Digi-ID™ certificates

Digi-SSL™ Service

When issuing and managing multiple Digi-SSL™ certificates, the Digi-CA™ Service system is the recommended management system. Almost every Digi-SSL™ certificate is issued from a TRoot and therefore this is offered form this Managed CA service .

Digi-Access™ Service/Server

When securing with Digi-Access™ two factor authentication, we recommend using Digi-CA™ Service, because it is issued and managed by the Digi-CAST™ team and it is much faster to configure and deploy. However, the is also the option to install the Digi-CA™ Server software if there is a strong requirement and business case for it .

Digi-ID™ Service/Server

When considering multiple Digi-ID™ certificates, careful consideration to the usage, environment and overall requirement should assist you in deciding wh is the best Digi-CA™ system to choose. Seek advice from the Digi-CAST™ team before making this important selection

Digi-Mail™ Service

When issuing and managing multiple Digi-Mail™ certificates, the Digi-CA™ Service system is the recommended management system. Almost every Digi-Mail™ certificate is issued from a TRoot and therefore this is offered form this Managed CA service .

CA-systems

CA Systems

Digital certificates can be used in a variety of different security situations, however the common uses are for proving identity, digitally signing/sealing files and encrypting data. These important capabilities are integral parts of any secure environment.

As can be seen from the diagram below, digital certificates come from the certificate Engine core and it issues the various types of digital certificates.

Two Types of CA Systems

Digital certificates are issued and managed using a certificate Authority or CA. There are two different types of CA systems and, uniquely, with Digi-CA™ there is a third option:

• Managed CA
• CA Software
• Digi-CA™ Shared CA

The Managed CA is supplied as an online service from outside your organisation.
We call this Digi-CA™ Service.

The CA Software can be installed at your premises or at your data centre.
We call thisDigi-CA™ Server..

Certificate Authority

Where to get Digital Certificates

All digital certificates come from a certificate Authority [CA] that is a computer system that is capable of issuing these different types of digital certificate.

Certificate Authority [CA]

Digital certificates are issued by a Certificate Authority [CA]. Any organisation can opt to operate its own CA and typically the types of organisations that have a CA are either commercial CAs that offers their services to other organisations as an external service, or organisations that purchase the necessary systems for their own use.

The computer system that issues the different types of digital certificate does this from the central system core of the CA system and this core is called the certificate engine.

Regardless of the type of CA system or how it is operated, the certificate Engine for the system has at least one Root certificate. The certificate Engine core uses the Root certificate to sign the various types of digital certificates the CA issues.

Certificate Policy

Certificate Policy [CP]

The rules, methods and guidelines that specify how the digital certificate is distributed to the end user are documented in the Certificate Policy [CP]. The CP is the ‘Who, What, Where and How’ document that describes the principles of the digital certificate usage and how they are to be distributed. This CP is agreed before the CA is operational and all digital certificates must be deployed in accordance with the CP.

The Registration Authority [RA]

The Registration Authority [RA] decides what users are permitted to receive a certificate. The RA can be a Systems Administrator or other responsible member of the organisation, or the process can be automated using a database and a series of automated checks and controls, each one of which is designed to reduce the error possibility or the risk of deception.

Four Types of Digital Certificate

There are three main types of digital certificates, they are:

• Secure Socket Layer certificate [SSL]
• Software Signing [Code Signing certificate]
• Client Certificate
• Digital Signature

Certificate Revocation

Digi-CA™

All certificate revokations are initiated either by the user or by the Administrator. Revokations are required for a number of reasons, for example:

	1	the user has lost the PC or media where the certificate was stored.
	2	the user no longer has any affiliation with the organisation that issued the certificate
	3	the user changed position in the organisation and no longer has any right to the certificate
	4	the Administrator believes a certificate has been misused.
	5	the Administrator believes a certificate used to misrepresent the organisation that issued the certificate

The following sub sections detail how Revokation requests are made and the resulting actions and uses for this important feature.

Revokation Process

The following diagram explains the events that occur within the Digi-CA™ and how a revokation request is executed:

Certificate Storage

Digi-CA™

For end entity certificates there are two different Storage Types and several devices that need careful consideration when choosing how your certificates will be deployed. The correct selection is critical to the ease of operation combined with the level of security you need to achieve.

Certificate Storage Devices

The end entity certificates can be stored on two different types of device, one that has Cryptographic Service Provider [CSP] capabilities and the other that doesn’t. Most web browsers and specific Smart Cards [Digi-Cards™], USB Tokens [Digi-Tokens™] have CSP software installed. These devices are easily identified because the product’s specification will refer to its cryptographic capabilities.

If the end user is required to enroll for their certificate and the storage device is their PC, then the CSP within the Microsoft Internet Explorer browser will use its own CSP capabilities during the procedure.

Other types of storages device that don’t have CSP capabilities can still be used to store the certificate, just as they would any computer file. These devices can include Smart Cards and USB Tokens that don’t have CSP capabilities.

Storage Device Considerations

When selecting your storage device, you should consider its immediate intended use and also other future possible uses too. For example the end entity certificate that’s being used to access an online banking system today could also be used to sign funds transfer transactions in the future. The protection for the access to the application will not be as great as the protection required to transfer funds, so you need to decide in advance what solution will work today but also grow with the needs of tomorrow.

Then there are the issues of ‘portability’ and cost. Digi-Tokens™ are an excellent solution because the end entity certificate can be used in any PC anywhere but as the most expensive storage device, it may not be the most practical. The Digi-Card™ offers multiple functions like doubling for an ID card, but it assumes there are smart card readers available and again cost may be an issue here. The least expensive option is the user’s own PC but may not suit your requirement for complete portability.

The Digi-CAST1™ Team of professional advisors are there to assist you in making the best choice for your environment and remove the element of risk from your purchase.

Certificate Storage Types

When a CSP is used in the ‘manufacture’ of the Public and Private Key Pair that is used when generating the certificate, then there is the option to use two end entity certificate Storage Methods:

• The Export Storage type is where the Private Key can be exported from the storage device.
• The Fused Storage type means that the Private Key cannot be exported from the storage device.

Digi-CA™ offers both of these Types of Storage.

Export Storage

Export Storage means that when the Public and Private Key Pairs are generated and then signed, the entire end entity certificate package that includes the Key Pairs and the certificate can be exported from the original storage device as a PKCS#12. So the certificate is not ‘fused’ into the device.

In the most common case where the end entity certificates is stored in the certificate Store of the Desktop Profile for the user, there is a wizard for exporting the entire file so that it can be reinstalled elsewhere.

Certificate Uses

Digital Certificate Uses

Digital certificates can be used to identify a person or a device. Once identification is established, the certificate is most frequently used to prove one person’s, or device’s, identity to another person or device. Because of the RSA system, they both know each other. The digital certificate can now be used for signing and/or encrypting email or for providing two-factor strong authentication.

How Digital Certificates Work

Using the dual-key cryptography algorithm, the digital certificates allow users to exchange public keys to secure and authenticate each other.

There are two main uses for digital certificates are for:

• Secure Email
• Secure Access

And when considering using digital certificates you need to consider:

• The digital Certificate Policy
• The Registration Authority Function

Certificates

Choosing & Using Digi-Sign Digital Certificates

The Digi-CAST™ practices for digital certificates and the provisioning of Certificate Authority [CA] systems differs substantially for other Traditional CA providers. The methodology itself is unique to Digi-Sign and was conceived in 2004 after many years of examining alternative system implementations and poorly conceived projects. The principle differences are achieved by the ‘open collaboration & your active participation’ that is then supported by our extensive experience.

The four corner stones of the Digi-CAST™ approach are:

• Digi-CAST™ Methodology
• Service Approach
• Service Level Agreement
• CA Management Services

Code Signing

Digi-Code™ Certificates

Digi-Codes™ are Code Signing certificates and are used for securing and authenticating:

• Software downloads from the internet
• Executable code on a website
• Signing macros in Word®, Excel®, Access®, etc files

Digi-Codes™ are not a high volume item and most organisations only need one or two each year.

Digi-Code™ Xs

Digi-Code™ is offered in a single Class only: Digi-Code™ Xs and is used for software and code signing.

Digi-Access™ Certificates

Securing any on line system with usernames and passwords may not offer the level of protection and security your organisation needs. You improve the security by adding a 'second layer' of protection called 'two factor authentication'. This means adding another method of authenticating your users, on top of the existing username and password access.

Digi-Access™ adds this two factor authentication security and is the most popular and fastest growing certificate we provide currently.

Digi-Access™ Xs & Xp

Digi-Access™ certificates are available in the Xs and Xp Classes and are used for cloud based on demand computing, Software-as-a-Service [SaaS], secure web portals, online gaming compliance, financial service (e.g. online banking and broking), etc. In fact, anywhere where a username and password is used to gain access to any application or service using your browser.

Digi-ID™ Certificates

Digi-ID™ certificates are most commonly used for identification and digital signature and are single application certificates. A single application certificate is designed to perform a single action like providing identification on an ID card or for digitally signing a document, e.g. a PDF.

If a single Digi-ID™ is required to perform multiple functions (and this isn’t always possible), then a Digi-ID™ Xg is used because the single Digi-ID™ Xg certificate is a multi-application certificate that can be used to perform multiple actions (i.e. both identification and digital signing).

Digi-ID™ Xs, Xp & Xg

Digi-ID™ certificates are available in Xs, Xp and Xg Classes and are used for digital identification and/or electronic signatures. Digi-ID™ Xs are entry level certificates used for pilot projects, test environments or in small, single application environments only.

Digi-ID™ certificates are very popular when considering EU legislation, workflow systems or indeed anywhere that a digital signature is being used to replace paper based signatures. The reason for this is because digital identity and non-repudiation of transactions is now considered critical. Also, the demand for Machine Readable Travel Documents [MRTD], electronic invoicing and other document signing solutions have underpinned the use of Digi-ID™ certificates.

Digi-Mail™ Certificates

Digi-Mail™ certificates are available in the Xs and Xp Classes and are used for digitally signing and encrypting email. The practice of signing email is commonly used in healthcare, financial and government environments, where the authenticity of an email is of paramount importance to the organisation.

Digi-Mail™ Xs & Xp

Digi-Mail™ certificates are available in Xs and Xp Classes and are used for secure email only. Digi-Mail™ Xs are entry level certificates used for pilot projects, test environments or in small, single end users only

Digi-ID™ Xp is the most commonly used commercial certificate and it is also a single application certificate. A single application certificate is designed to perform a single action like securing email or providing two factor authentications.

Communication

Communication

User A and B exchange public keys and use the other person’s public key to encrypt messages back to each other. Only User A has the Private Key that can decrypt any the messages encrypted with User A’s matching public key.

Secure Access

In the case where a web server has a highly secure area and wishes to give restricted and controlled access to the information stored on it, then usernames and passwords do not offer sufficient protection. Adding two factor authentications to this insecure login method with a Digi-Access™ certificate solves this problem.

There are two types of Digi-Access™ authentication systems:

• SOne-to-One Authentication
• One-to-Many Authentication

Configuration

System Specification & Configuration

The Digi-CA™ system is a complete system containing all of the necessary Operating System [OS], modules, directories and engines required to operate a fully functional CA system. For the technical specifications of the software, refer to the Digi-CA™ Administrator Manual.

'Fast Track' Your Solution Design

Your complete system design, the modules that are needed, their specification and configuration and preparation for delivery can be completely delivered by the Digi-CAST1™ Team of professional advisors. After consulting with you, every aspect of the project is documented and submitted back to you for approval.

Once approved, the Digi-CAST2™ will deliver the ‘turn key’ solution as specified in by the Digi-CAST1™ documentation.

Security

Digi-CA™ has been designed by some of the foremost experts in Internet Application Security. All modules are contained in one Linux / Unix based system. Specific care has been taken in the design of Digi-CA™ to ensure that no outside intrusion can take place and that all the private Keys for the Digi-CA™ are secure (if they are not stored on a HSM).

To ensure the uniqueness of the keys in the certificates, Digi-CA™ uses its own entropy system. Digi-CA™ can create Key lengths up to 9192-bits. It can also support all key ciphers and signature algorithms.

Depending on the level of security required, Administrators must be authenticated by either a smart card [Digi-Card™], a USB Tokens [Digi-Tokens™] and/or a biometric reader.

Encryption

The entire Digi-CA™ system infrastructure is formed mainly around x.509 certificates produced with accordance to the internationally recognised RFC 2459 standard and is maintained in accordance to the same internationally recognised RFC 3647 standard.

The design of a typical x.509 certificate includes the following cryptographic algorithms that are approved for commercial use by governments and related agencies and institutions around the world.

Customisation

Digi-CA™

The Digi-CA™ is probably the most flexible and capable CA system available in the market today. Unlike the other Legacy CAs, Digi-CA™ takes advantage of the many advances in technology over the past seven years and you benefit by getting the flexible, cost effective and easily integrated CA system you need.

The Digi-CA™ still uses Unix in its certificate Engine core but by using the Open Standard Institute [OSI] initiative in other modules, Professional Services and upgrade costs are substantially less than those normally associated with the complex and costly modifications of the less flexible Unix Legacy CAs.

This section explains the design principles and also gives typical examples of previous customisations . The most important feature of Digi-CA™ is that your precise requirements can be delivered, exactly as you require.

Process Customisation

In the larger or more complex environment, the organisation may require a workflow process to control the use of the Digi-CA™ usage from a cost, security or for general management reasons. The following is an example of a customisation currently in use by a Digi-Sign customer for issuing Digi-SSLs™:

This type of customisation is not unusual but it does add to the initial cost of deploying a Digi-CA™ system.

Process Automation

Every aspect of the Digi-CA™ can be automated. Examples of this would be where the certificates are being used to replace Usernames and Passwords for login to a secure website, to replace hardware tokens like SecurID®, to issue certificates for secure email on a closed network or to replace an existing Legacy CA with Digi-CA™.

Using the MCAM™ technology and capabilities, it is possible to use existing LDAPs or other databases such as Oracle®, Active Directory® or any other SQL or flat file format to automate the certificate issuing, renewal, suspension and revokation processes.

Migration from a Legacy CA

Using the authentication and validation certificate Policies from your Legacy CA, Digi-CA™ can migrate users automatically without requiring any IT resources or Administrators’ time.

Interface Customisation

The entire Digi-CA™ system and all of the interfaces used by the Administrators and users can be completely customised on request. Typical reasons for the graphical changes are for integrating Digi-CA™ into a larger application to make a complete package or the simpler integration of the Digi-CA™ into the organisation’s web systems or extranet.

Technical Specification & Help Files

The specification of the Digi-CA™ at the time of going to print is available in Appendix IV. All specification updates and technical help files are updated using the online support section of the Digi-Sign website located at www.digi-sign.com [3].

Delivery

Certificate Delivery

Digi-CA™ has different delivery options for each digital certificate it produces. The most common use for Digi-CA™ is to deliver end entity certificates. Prior to the installation of the Digi-CA™, the CP is documented and this determines what Method of Delivery is used for issuing a digital certificate.

The two principle Methods are the Package Method and the Process Method. An end entity certificates can be issued in different ways depending on the method of delivery chosen. A single issuing process can be decided on, or a combination of processes.

Certificate Delivery Methods

There are two primary ways that the end entity certificates are delivered. Either the certificate is delivered as a package [Package Method] or it is delivered as a result of a series of steps in a process [Process Method].

Methods of Delivery:

• The Package Method is where both the public and the Private Key are generated together and delivered together.
• The Process Method means that there are several stages, or processes, in getting a Digi-ID™.

Digi-CA™ offers both of these Methods of Delivery.

Package Method Explained

Using the Package Method, the public and Private Keys are generated at the RA or Administrator’s PC. The public key is signed by the Digi-CA™ Engine and the entire end entity certificate is packaged in a single file and either sent to the end user or is installed on a Smart card, USB Token or any other suitable end entity certificates storage device. This package is also referred to as a PKCS#12, a .pxf or a .p12 Private Key Container Package.

Process Method Explained

Using suitable Digi-Cards™, Digi-Tokens™ or other suitable CSP storage device, a Private Key is generated and remains on the device and never leaves the user. When requesting an end entity certificates, the device generates the certificate Signing Request [CSR].

When the user enrolls at the web application form, the form data entered and the CSR are transferred to the Digi-CA™. The transfer occurs over a HyperText Transfer Protocol Secured [HTTPS]. On receiving the CSR, the Digi-CA™ Engine signs it and creates the x.509 certificate.

Usually, an email is then sent to the user to collect the end entity certificates. When the user clicks on the hyperlink within the email, using the TCP/IP Protocol, the certificate is installed on the user’s device.

As stated, the Digi-CA™ offers both of these Methods of Delivery.

Demonstration

Digi-CA™ Demonstration

Almost every Digi-CA™ installation has one or more customised features added to the system to meet the customer’s specific requirements. The requirements range from overall certificate management and control, to system integration, automation and/or accounting requirements.

Digi-CA™ Service as the Managed CA solution and Digi-CA™ Server as the Software CA product ‘in a box’, both use the same browser–based interfaces. To get a better understanding of how Digi-CA™ is controlled and Administered manually (much of the Administration can be automated in the Xp and Xg systems), its basic functionality, features and benefits, visit the following URL:
www.digi-sign.com/digi-ca [4]

…and see an online demonstration of how the Digi-CA™ system works.

Design Principals

Digi-CA™

Digi-CA™ is the core software that includes the interfaces, modules and applications [IP] that are common to both the Digi-CA™ Server software and the Digi-CA™ Service. The importance of this common IP is unique to Digi-CA™ and makes it possible for the Service and the Server versions of Digi-CA™ to be interchangeable. Therefore, starting with one version of Digi-CA™ and migrating to the other, as your requirements grow, will not
require a complete system replacement (as is the case with legacy CAs) and thereby saves you considerable costs, should such a requirement arise.

Digi-CA™ Design Principals

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

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

Certificate Policy

The rules, methods and guidelines that specify how the Digi-CA™ will issue its certificates and these processes and procedures are documented in the certificate Practice Statement [CPS] and certificate Policy [CP]. The CP is the ‘Who, What, Where and How’ document that describes the principles of the digital certificate usage and how they are to be distributed.

This CP is agreed before the Digi-CA™ is operational and all digital certificates must be deployed in accordance with the CP. Appendix I is a questionnaire designed to assist in creating your CP.

Types of Digi-CA™ Systems

There are three different types of Digi-CA™ system:

• Digi-CA™ Service - Managed CA
• Digi-CA™ Server - CA Software
• Digi-CA™ Shared - Dedicated CA

Digi-Access™

Service Overview

Digi-Access™ Service is the simple to deploy and manage two factor authentication secure access method that can’t be compromised. In most cases, the issuing and management of the Digi-Access™ Service is simpler than administering a database of usernames and passwords. There are no specialist skills needed to incorporate it into your system(s) as most IT
systems are x.509 compliant and are already configured to work with Digi-Access™.

Digi-Access™ uses digital certificates to authenticate individual users to the server. More than 27 different server software systems that are compatible with Digi-Access™ (including most OEM versions). Within minutes, the server can be configured without the need for any additional software or specialist programming skills. Once activated, whatever section of the network or server needs protecting, all that is required is a simple Login button.

Once this Login button is clicked, the browser automatically activates the client authentication dialog (a piece of software that is already embedded in most web browsers)

Competing Technology

Digi-Access™ competes directly with asynchronous number and One-Time Password [OTP] tokens like RSA® SecurID®, but this older technology. There have been many improvements since the original SecurID® idea, but the technology is still basically the same. In their favour, tokens are easy for the user to understand (it’s just a more powerful password) but the initial and ongoing costs are prohibitive. Tokens do provide good two factor authentication, but that’s it.

More and more organisations are moving towards digital certificates to solve their authentication issues because they are more flexible and provide additional functions (albeit they may not be needed immediately). If your Storage Type is the certificate Store within the browser, there are significant cost savings to consider.

Digi-ID™ Service

The Digi-ID™ Service is used when you require digital signatures for workflow, forms and/or digital documents. Digi-ID™ certificates are also used for ID cards and tokens. With Digi-ID™ Service, each service you require is configured according to your precise requirements and tested before activation.

Regulatory Requirements

Digital signatures are becoming a regulatory requirement when considering digital documents and workflows in specific communities (e.g. European Union, gaming industry, HIPPA, etc.). There is no substitute, either your organisation continues to operate cumbersome paper based systems, or you digitise and authenticate them with a Digi-ID™.

Within the EU in particular, there is a specific requirement to use qualified electronic signatures that are a very specific type of Digi-ID™ that must be delivered on a Secure Signature-Creation Device [SSCD]. Digi-ID™ SSCD are issued for the Digi-ID™ Service system only, unless your organisation is prepared to achieve ISO 27001 certification and is willing to invest considerable sums in creating your own dedicated Trust Centre. If your organisation wishes to achieve qualified certificate status, then Digi-CA™ Server can deliver the PKI system you need to issue your own Digi-ID™ SSCD.

Digi-CA™ Service

Digi-CA™

The Digi-CA™ Service is the Managed CA and as explained in 2.6.2, it is the service that is provided online using the Application Service Provider [ASP] or Software-as-a-Service [SaaS] delivery model. There is no hardware or software requirement at the customer site.

The Digi-CA™ Service is charged on an annual recurring fee based on the number of digital certificates issued each year and this covers all maintenance, administration and the support that is required to keep the Digi-CA™ operational.

You can choose to start with Digi-CA™ Service, migrate to Digi-CA™ Server and then further migrate back to Digi-CA™ Service with ease. This is because the Digi-CA™ Service and Digi-CA™ Server systems share a common architecture and the same Digi-CA™ certificate Engine.

No other vendor offers this high degree of flexibility; migration and integration capabilities (see sub section 3.13 for more details).

Dual Server

Dual Server Digi-CA™ Server Xp Technical Diagram

The following technical installation diagram outlines a typical network requirement to run and operate a dual server Digi-CA™ Server Xp system without a HSM. Backup server is optional.

Dual Server Digi-CA™ Server Xp & HSM Technical Diagram

The following technical installation diagram outlines the typical network requirement to run and operate a single server Digi-CA™ Server Xs system with a HSM. Backup server is optional.

End Entity Certificate

Processes used in issuing End Entity Certificate

A standard process for issuing an end entity certificate involves the following stages:

- Using the Digi-CA™ RAMC, the Administrator initiates a certificate invitation email message that is sent to the intended recipient (user)

- The recipient (user) enters the online certificate application form using the URL provided in the invitation email message;

- The user completes the online certificate application form by providing personal information such as:

• Full name;
• Email address
• Organisation (it is possible to restrict the value of the Organisation to a pre-defined read-only string)
• Organisational Unit/Department
• Locality
• Telephone
• Country (it is possible to restrict the value of the Country to a pre-defined read-only option)
• Secret Question
• Secret Answer
• Other custom values based on the customer requirements

- A key-pair (Private and public key) and a PKCS#10 certificate Signing Request [CSR] code is generated on the user PC using a local Cryptographic Service Provider [CSP] engine installed on the user’s computer. It can be either a built-in Microsoft CryptoAPI software engine or a hardware USB Token or Smart Card CSP engine;

- Using HTTP POST method over SSL/TLS all the user data is transferred securely to the RA [Registration Authority] Server;

- The system Administrator/Validations Officer verifies and validates the user application data and depending on the content of the application, it is either approved or rejected;

- If the certificate application is approved, the application data is passed to the certificate Engine core server and the CSR is signed by the Certification Authority certificate;

- The certificate Engine core server generates a unique key/PIN number and sends a certificate activation email message to the end user. The message contains a URL to activate and install the certificate;

- The recipient (user) enters the certificate activation screen from the URL provided in the certificate activation email and completes the installation of the certificate by clicking the installation button on the screen;

- The certificate is collected from directly the certificate directory via a background TCP/IP connection and installed on the user’s PC using the CSP engine chosen at the time of the certificate application;

- The user may now use the certificate.

End entity certificates are requested by using the online certificate application form or by the Administrator (on the users behalf) using the Digi-CA™ RAMC.

From the Digi-CA™ Control Centre, all certificate requests are either entered into the database on an individual basis, using a batch upload file or automatically, depending on the Class of Digi-CA™ you are using. Similarly, all requests for end entity certificates are accepted, rejected or deferred either manually or automatically, depending on the Class of Digi-CA™ you are own, using the RAMC console of the Digi-CA™.

The Digi-CA™ system automatically generates a certificate Signing Request [CSR] if the requesting party did not already supply one and then generates the end entity certificate. The generation is done in batch processes according to schedules set in crontab. The default is to run the process every hour.

After generation, the certificate is activated at the users PC or it can be delivered by email as a .p12 file. Storage of the certificate can be on the PC or any suitable media such as a Digi-Card™ or a Digi-Token™. Similarly, the Administrator can pre-install the certificate on the Digi-Card™ or Digi-Token™ prior to dispatch. This is particularly convenient where the Administrator wants ‘Zero Touch’ at the user’s location.

The method of distribution is set in the database at the time of the validation. The default is that certificates are distributed over the web, with the certificate holder getting an email containing a one-time password needed to pick it up.

If the billing module is installed, this module is updated with information and then passed on to your billing system.

Examples

Delivery & Storage Examples

As stated, these are just some issuing processes and parts of one process can be combined with parts of another to meet the CP requirements.

Fast Track

‘Fast Track’ Solution Advisor

Using the Solution Advisor Table will help you select the best solution your environment or use the interactive version available at www.digi-sign.com/advisor [5]

	Digi-SSL™ Service	Digi-Access Server™	Digi-Mail Service™	Digi-CA™	Digi-Code™
Secure Multiple Servers (Using SSL)
Secure Multiple Emails (Closed Group)
Secure Multiple Emails (Internet Public)
Multiple Email Encryption (Closed Group)
Multiple Email Encryption (Internet Public)
Two Factor Authentication (without tokens / smart cards)
Two Factor Authentication (with tokens / smart cards)
Secure Login (Web Applications)
Secure Login (Desktop Applications)
Device-to-Device Authentication (Specialist / Proprietary)
Secure Messaging (Closed Group)
Secure Messaging (Internet Public)
MRTD (e Passport / National ID)
certificate Authority (Closed Group)
certificate Authority (Accredited Trust Centre)
Digital Signature (Workflow & Business Process)
electronic signature (e Signature & Compliance)
Strong Authentication (without tokens / smart cards)
Strong Authentication (with tokens / smart cards)
Software & Code Signing (Applications, Downloads & Applets)

Groups

Open & Closed User Groups

When deciding on whether the Managed CA or the CA Software is most suited to you, you should understand the difference between an open and a closed user group. From a CA perspective, this relates to the extent of end user control you have. If the CA exercises some degree of control over the end user’s environment then it is a closed user group and if it doesn’t, it is in an open group.

The following are examples of the two types of user group:

• If you have sufficient control over your users and can ensure they all have Outlook® 2008, then this is considered a closed user group.
• If you issue all the certificates on smart cards, from a CA perspective, you control every aspect of the environment and this is a closed group.
• If you send thousands of email newsletters to a wide user group, you have no idea what email software they use, so this is an open group.
• If you have a small group of extranet users that you manage and they trust you, then this could be considered a closed user group.
• The tax payers in a country all belong to the closed group: tax payers and the tax authorities can enforce certain practices on its users
• The e Passport of the citizen from one country is still valid in another country is a closed group by conforming to international standards
• Two friends communicating over the internet but not knowing each others software is an open group because neither controls the other

It is not always immediately obvious whether a group is open or closed and it is important that this is determined accurately if your CA is to meet your precise requirements. If there is any doubt, contact the Digi-CAST™ Team and ask them to advise you.

The Correct Certificate for the Group

If the user group is closed, then you may be able to use either CA. There are two exceptions to this when you want to secure:

• a server using a Secure Socket Layer [SSL] server certificate
• email using a client certificate

In 99% of cases an SSL certificate must be Trusted and if there is any possibility that the secure email is required outside the closed group, then the Trusted certificate is required here too. In both of these special cases, the Managed CA is your only choice.

Availability of Technical Personnel

The third consideration needed to help you select the correct CA for your organisation is the availability suitably trained and experienced technical personnel required to run and operate a CA. Most organisations don’t have this type of specialist staff within their organisation and therefore are best advised to use a Managed CA to deliver the required service.

Key Management

Digi-CA™

The issue of Key Management is an important consideration when selecting any CA system. To understand the importance of this subject, you must first understand the real difference between the key-pair and the certificate. The key-pair is used to provide the authentication and the unique identity of the end user. The certificate, that is used to sign this key-pair, tells you that it is valid and ‘not out of date’. Together the key-pair and the certificate create the ‘package’ that makes up the digital certificate.

When considering whether you need (or want) Key Management, you should clearly understand the total environment that your digital certificates will be used in and, in particular, your end users. This requires that you pay special attention to the following three ‘Top Considerations’ when selecting the correct CA for you:

Three Top Considerations

• Whether your User Group is Open or Closed.
• The Delivery Method you will use.
• The Storage Type you select.

The Fourth Top Consideration

• Your choice of certificate Binding Option

What is Certificate/Key Backup

Certificate/Key Backup can be a valuable service where there is a risk that if a user looses their digital certificate, or if the certificate is corrupted for any reason, this may cause serious issues for the CA administrator, or the organisation. Typically, this concern only exists where a user certificate is being used to encrypt data. With Certificate Backup, the user can request a replacement for the lost keys that were used when their digital certificate was generated.

Certificate/Key Backup can be likened to leaving the spare key for your house with a trusted neighbour so that if anything happens to the original, you know you have a spare. This type of help from your trusted neighbour could also be referred too as key backup. Alternatively and using the same analogy, it might be just as good to have a backup key stored elsewhere. The CA equivalent of this is called the digital certificate backup.

Backing up computer data is now understood as a routine responsibility and including the user’s digital certificate backup in this routine is a simple task that your network administrator should provide for you on request.

What is Key Management

Key Management is often mistakenly linked to the Certificate/Key Backup service and should be clearly understood as a separate service that many CAs provide so that users can manage multiple key-pairs and certificates.

Key Management is only necessary when users have multiple Keys and this only occurs when the Disposable Binding Option (see sub sections 3.8.4 and 3.8.4.1) is chosen. To understand why Key Management is only needed in these certain special cases, you must first understand the x.509 elements that are used when generating the digital certificate.

How digital certificates are Generated

Understanding the principles of Dual Key Cryptography , the Public and Private Key form the key-pair that is used to authenticate the user. This key-pair is generated using the RSA algorithm and once created, the certificate signs the key-pair with the information that you see when you open the digital certificate. This singing procedure inextricably ‘binds’ the specific key-pair to the specific certificate that was used to sign it. This is what makes up the elements of the digital certificate.

Key Management Options

Certificate Key Management Options

The production of any digital certificate, from any provider, uses the same x.509 elements and the method that is used to inextricably link the key-pair to the certificate we call the ‘Binding Option’. There are two different Binding Options that can be used when generating digital certificates and each one produces an inherently different CA environment.

With Digi-CA™, you can choose what type of Binding Option you prefer once you have a clear understanding of your environment and the affect of your choice. Digi-CA™ refers to the Binding Options as Disposable or Renewable and classifies the options in two distinctly different certificates:

• Disposable Certificates
• Renewable Certificates

With Digi-CA™, you can choose the Disposable Certificate Binding Option most frequently used in Legacy CAs or you can use the more modern Binding Option that creates the Renewable Certificate.

Disposable Certificates

The Disposable Binding Option stipulates that every time you require a new certificate, you need both a new key-pair and a new certificate. Once the certificate expires, you simply dispose of it and issue a new certificate (i.e. a new key-pair and a new certificate are issued every time). The certificate that uses this type of Disposable Binding Option is referred too as a disposable certificate

Renewable Certificates

The Renewable Binding Option stipulates that you keep the original key-pair and only need a new certificate for the renewal. Once the certificate expires, you simply need a new certificate to renew it (i.e. only a new certificate is issued every time). The certificate that uses this type of Renewable Binding Option is referred too as a Renewable Certificate.

Certificate Application

The Renewable Binding Option stipulates that you keep the original key-pair and only need a new certificate for the renewal. Once the certificate expires, you simply need a new certificate to renew it (i.e. only a new certificate is issued every time). The certificate that uses this type of Renewable Binding Option is referred too as a Renewable Certificate.

Language Capabilities

Digi-CA™

As is the case with sub section 5.4, Digi-CA™ offers the capability to completely localise all interfaces, help files and user screens into your local language(s). This is particularly important to organisations where English is not used. It is also possible to have multiple interfaces with multiple languages for the same system. The following two samples show the Digi-CA™ Control Centre screen in Chinese and the user enrollment screen where users can apply for a certificate in Turkish.

The importance of the capability to produce the Digi-CA™ in the local language(s) cannot be over stated. It will result in faster training of the RA personnel and will significantly reduce the Help Desk Support calls (where users are seeking help to with translations from English rather than actual technical support related issues).

It is also possible to have a single Digi-CA™ configured in multiple languages so that different Digi-RAs™ in different countries can use the same Digi-CA™ Control Centre in their native language. Similarly, the users requesting certificates can do so from the same system but again in their native language.

To have your Digi-CA™ localized in your language, the system files and instructions are available in Appendix V.

Mail Service

Digi-Mail Service™

As a business tool, email is the easiest one to manipulate and alter. Once sent, the information is extremely easy to intercept and copy whilst en-route. The best way to protect email is with Digi-Mail™.

Digi-Mail™ is a simple solution that totally protects email information. All email can be digitally signed and the sensitive information can also be encrypted for total security.

Using the capabilities within the certificate, Digi-Mail™ works with all versions of email software without any additional configuration or specialist skills required to make it work. Digi-Mail™ can be used within an organisation or across a user group that includes suppliers, customers, advisors and employees alike.

Once deployed, all members of the user group can be assured that all communications are bona fide and have not been tampered with or intercepted. With the simple click of a button, those sensitive emails can be encrypted so that only the intended recipients can open them.

When the email arrives, it is displayed in the recipient’s inbox, clearly marked as being digitally signed. In checking the details of the certificate, the credentials of the sender and the integrity of the communication can be verified:

Digi-Mail Service™ provides the certificates designed to provide the secure email you need and as it comes from the TRoot, it will work in either a closed or an open user group.

Activation Requirements

All you require is a single internet enabled PC with Internet Explorer® 5.5+ and to decide whether to store the Digi-Access™ certificate used to access the system on a Digi-Card™, a Digi-Token™ or in the certificate Store of that PC.

Managed-CA

Managed CA

A Managed CA is a service that is provided online using the Application Service Provider [ASP] delivery model. There is no software or hardware requirement. This Managed CA is charged on an annual recurring fee, based on the number of digital certificates issued each year. The Customer pays this fee to cover all maintenance, administration and support required to keep the CA operational. The Digi-CA™ Service is a managed CA.

The Managed CA Administrator connects securely to the larger CA environment run and operated by the CA Provider or what is called the CA Trust Centre.

Managed CAs is operated by professional organisations that specialise in digital certificates and have been certified to issue trusted certificates. Managed CAs that offers trusted certificates run and operate Trust Centres.

Methodology

Digi-CAST™ Methodology

Digi-CAST™ is factual, high-quality, digital certificate and CA advice from experienced personnel that can show you how your CA should be implemented, integrated and maintained. The C-A-S-T? method was pioneered by Digi-Sign in 2004 after many years of developing and deploying CAs around the world.

The Digi-CAST™ methodology has four distinctly separate components that are adapted and designed specifically to meet your needs:

• Digi-CAST1™ - Consultation, Assessment, Security & Technical
• Digi-CAST2™ - certificate Authority Solutions Team
• Digi-CAST3™ - Compliance, Audit, Standards & Training
• Digi-CAST4™ - Continued Assessment & Security Testing

Where Digi-CAST1™ should be used on every project, CAST2™ to CAST4™ are normally used on medium to large-scale projects such as enterprise or public sector environments.

Digi-CAST1™

Just as there is no such thing as a typical IT environment, there is no such thing as a typical Digi-CAST™ service. Some Digi-CAST1™ projects (where we are assisting or advising on a project before it starts) can last only a few hours, whilst other projects have 4-6 weeks durations.

Digi-CAST1™ is concerned with project planning excellence, cause and affects planning, 'skills pool' analysis, personnel selection and management. The most important thing to remember about Digi-CAST™ is that the entire service is tailored to your specific needs.

Digi-CAST2™

Depending on the findings of Digi-CAST1™ regarding the available personnel and their skills, you might decide that you need us for some or all of the project implementation phase. As explained in the Digi-CAST1™ phase, all of this is decided at the project evaluation and planning stage.

Digi-CAST2™ is concerned with detailing the actual project as documented in Digi-CAST1™. Its concern is with personnel, availability, time lines, 'choke points' and overall project delivery. Combining your resources with ours, we begin the project and work together to a common goal.

Digi-CAST3™

Digi-CAST3™ is concerned exclusively with compliance and certification. The most common requests for certification are for ETSI 101 456, ISO 17799, ALGO and 1999/93/EC. There are many other requirements that can include accreditation in your country by the national accreditation board, the national telecom regulator or other third-party organisations.

These requirements are typical of a CA that wants to issue Digi-IDs™ for Machine Readable Travel Documents [MRTD], e Passports, National ID cards, Trust Centres or large scale certificate deployments for government, health, finance, insurance or banking.

National and international accreditation is normally based on ETSI, ISO, ANSI, ICAO or other standards. BS 7799 (Part 2) or ISO 17799, 1999/93/EC, ETSI 101 456, HIPAA, Sarbanes Oxley, SB 1386, Gramm-Leach Bliley, EAL, ETSI, CWA, ALGO, ICAO for MRTD and many others are all possible with Digi-CA™.

Digi-CAST4™

The real objective with Digi-CAST4™ is to ensure as much knowledge transfer as possible. Using the 'Train the Trainer' approach, it is expected that your organisation should be capable of maintaining your own environment and its accreditation to the highest of standards and to do this without assistance.

Multi Server

Dual Server Digi-CA™ Server Xp Technical Diagram

The following technical installation diagram outlines a typical network requirement to run and operate a dual server Digi-CA™ Server Xp system without a HSM. Backup server is optional.

Online Certificates

Online Security & Digital Certificates

The solution to the problem of online identification, authentication and privacy in computer based systems lies in the field of cryptography. Due to the non-physical nature of electronic communication, traditional methods of physically marking transactions with a seal or signature are useless. So an alternative mark must be coded into the information itself in order to identify the source and provide privacy against eavesdroppers.

One widely used tool for privacy protection is what cryptographers call a “secret key.” Log-on passwords and cash card PINs are examples of secret keys. Consumers share these secret keys only with the parties they want to communicate with, such as an online subscription service or a bank. Private information is then encrypted with this password, and it can only be decrypted by one of the parties holding that same password.

Despite its widespread use, this secret-key system has some serious limitations. As network communications proliferate, it becomes very cumbersome for users to create and remember different passwords for each situation. Moreover, the sharing of a secret key involves inherent risks. In the process of transmitting a password, it can fall into the wrong hands, or one of the sharing parties might use it maliciously and then deny all action or liability.

Digital certificate technology addresses these issues because it does not rely on the sharing of secret keys. Rather than using the same key to both encrypt and decrypt data, a digital certificate uses a matched pair of keys that are unique complements to one another. In other words, what is done by one key can only be undone by the other key in the matching pair.

Digi-CA™ generates these digital certificates using the patented Rivest, Shamir & Adelman [RSA] cryptographic algorithm. This algorithm is a mathematical formula that creates a dual key algorithm that is used to create the digital certificate.

In this type of key-pair system, the “Private Key” can only be accessed by you. Your “public key” gets widely distributed as part of the certificate. Customers, partners or employees who want to communicate privately with you can use the public key in your certificate to encrypt information, and you are then the only one who can decrypt that information. Since the public key alone does not provide access to communications, you do not need to worry about who gets hold of this Key.

Your certificate tells customers and correspondents that your public key in fact belongs to you. The certificate contains your name and identifying information, your public key and electronic signature as certification.

Performance Data

Digi-CA™

Number of certificates:		200 up to 200,000,000
Production speed:		Without HSM up to 5,000 1024-bits certificates/hour With HSM up to 10,000 1024-bits certificates/hour
Key length:		Root and Intermediate certificates 9196-1024 bits Client certificates 1024-2048 bits Symmetric Keys 56 to 256 bits
Key validity:		Root Key 1 to 25 years Intermediate Keys 1 to 10 years Client Keys 1 to 10 years (as per CP)
Key storage:		Root Key off-line and stored in several separate pieces Intermediate (signing) keys access through HSM, biometric client certificates, smart card or USB tokens
Cryptographic Ciphers:		AES, Blowfish, CAST5, DES, 3DES, IDEA, RC2, RC4, RC5 and RSA
Signature Algorithms:		MD2, MD4, MD5, MDC2, SHA1 (DSSI) and RIPEMD-160
Entropy:		2127

Authentication, Privacy & Integrity

The authentication, privacy and integrity of the digital certificates is governed by several factors:

• Security Protocols
• Root Key Ceremony
• Distribution Processes
• S/MIME Technology
• Validations

Security Protocols

SSL and TLS are protocols that are used to provide secure Web communications on intranets and the Internet. TLS is the standardized (by the Internet Engineering Task Force [IETF]) version of SSL and is also referred to as SSL version 3.1, whereas the most commonly used SSL version is 3.0. Both protocols can provide the following basic security services:

• Mutual Authentication
• Communication Privacy
• Communication Integrity

Mutual Authentication

Mutual Authentication verifies the identities of both the server and the client through the exchange and validation of their digital certificates.

Communication Privacy

Communication Privacy encrypts information exchanged between secure servers and secure clients using a secure channel.

44.2.1.3 Communication Integrity

Communication Integrity verifies the integrity of the contents of messages exchanged between the client and the server, which ensures that messages haven’t been altered en route. Digital certificates are an integral part of a total environment. Whether it is a simple case of using them to secure email or using them for authentication purposes in a larger workflow business process, in all cases, Digi-CA™ certificates are easy to deploy.

Policy Documentation

Digi-CA™

You can own and operate a Digi-CA™ system without ever putting in place any statutory documents or standards compliance and many organisations because their application is commercial and doesn’t need third part accreditation. ‘Best Practice’ means you should consider having a CP and we would recommend the following:

• Certificate field configuration (see below)
• CP certificate Policy document (see Appendix II)
• Digi-CA™ referencing the CPS (optional)

Digi-CA™ Field Configuration Control

Having specific fields added to your certificates is normally not required unless you are seeking accreditation or are issuing to millions of users and is a common practice when considering National IDs, e Passports, Health IDs, etc. At the deepest level, this may include Object ID [OID] fields and the need to register these OIDs with the Internet Assigned Numbers Authority [IANA]. Digi-CAST1™ will advise you on this should it be required and carry out this level of customisation and registration where appropriate.

	Status:		Active
	Expiry Date:		2007-02-14 00:00:00 GMT
	Serial Number:		04A80417E8B3D35AE8B480FFAFCD3274
	Invited on:		2006-02-02 17:40:17 GMT
	Invited by:		bob.smith@digi-sign.com
	Invitation Name:		Mary Brown
	Invitation Email:		mary.brown@domain.com
	Requested on:		2006-02-02 18:51:09 GMT
	Approved on:		2006-02-12 18:55:52 GMT
	Approved by:		mylissa.monton@hostname.com
	Activated on:		2006-02-13 19:00:33 GMT
	Revoked on:
	Common Name:		Bob Smith
	Email:		bob.smith@digi-sign.com
	Organisation:		Services Group
	Organisational Unit:		14029
	Locality/City:		Pompano Beach, FL
	Country:		US
	Secret Question:		Favourite pet's name?
	Secret Answer:		Johnny Cash

Certificate Policy [CP] Control

The CP for the Digi-CA™ is an important document because it clearly identifies the processes and procedures of your CA operation in a single document. It also adds to the credibility, security and acceptance when getting the people to accept and use your digital certificates. There is a standard recognised format for writing a CP but we suggest that you don’t need to follow this RFC format unless your CA requires certification or accreditation.

In sub section 2.5.7.3, the CP is the ‘Who, What, Where and How’ document that describes the principles of the Digi-CA™ usage and how they are to be distributed. This CP is agreed before the Digi-CA™ is operational and all certificates must then be deployed in accordance with the CP.

Digi-CA™ Certificate Practice Statement [CPS] Control

CPS control using your own CPS is only required if you are building a Trust Centre using Digi-CA™ Server Xg. The CPS should follow the RFC 2527 format in compliance with European Telecommunications Standards Institute [ETSI] 101 456. The Digi-CAST1™ Team will advise your legal technical teams on the best approach using these internationally recognised standards.

Creating your own CPS is a time consuming and complex process that will require several specialist consultants and may take several months to complete. Referencing an existing CPS such as the one used by Digi-Sign is probably the most practical approach. You should only consider drafting your own CPS if you are setting up a national or international Trust Centre.

Public keys

One-to-One Authentication

Public keys and Private Keys ‘recognize’ each other and because the public key can be freely distributed, the web server can store all the public keys belonging to its list of authorized users and match the Keys for users seeking access. This is called On-to-One authentication.

User A’s public key is stored on the web server. When User A attempts to gain access to the server, the server asks User A’s browser’s certificate Store to confirm that it has the matching Private Key to the public key stored on the server. If the match is confirmed, User A is granted access.

In simpler deployments, you might only need to identify groups of users in which case the One-to-Many implementation is faster to implement and easier to manage.

One-to-Many Authentication

In One-to-Many Authentication, the entire group of users or several sub-groups are formed. The server is then configured to seek the Signing certificate only, in which case, the server doesn’t need a copy of each individual’s public key.

This is easier to deploy and manage because the server doesn’t require a unique configuration for each Digi-ID™ that will be used to access it. By its simplicity, the server is configured once and any number of users can access it without any further intervention and still the individual user can be revoked so that access is denied on the individual basis as needed.

Questions

Simple Questions About Online Security

Consider the following questions carefully:

Q1.	When you visit a web site, like your Bank’s for example, how do you know that it really is their web site?
Q2.	When you download software from the Internet, how can you be sure that it really is from the original Publisher?
Q3.	If you are sending a confidential email to someone, how can you be sure that they are the only person that can open it?
Q4.	Your company has a Virtual Private Network [VPN], how can you replace password security with a stronger alternative?
Q5.	When you make a payment over the Internet using your credit card, how can you be assured a hacker won’t steal it during transmission?
Q6.	If your organisation wishes to use the internet to have business forms / documents (legally binding) signed on line, how can you do this?
Q7.	Your organisation wishes to put some or all of its systems on line for suppliers, customers, etc. How can you securely control access to them?

Digital certificates can be used in a variety of different security situations; however the most common uses are for proving identity, digitally signing/sealing files and encrypting data or two factor authentications.

This is how digital certificates answer the above questions:

A1.	If the Bank is serious about security, they will use a Digi-SSL™ Secure Web Server certificate to prove its online web site identity.
A2.	Using a Digi-Code™ Software/Code Signing certificate, a pop up dialog box assures the user of the Publisher’s identity prior to download.
A3.	If the email is first encrypted using an email certificates [Digi-Mail™], and then only the intended recipient can decrypt the email.
A4.	Passwords can be copied and misused, however, if each user has a Digi-Access™ certificate, security and identification is assured because this is strong two factor authentication.
A5.	The same Digi-SSL™ that confirms the identity of the website automatically encrypts any data that is submitted through it.
A6.	Again using the Digi-ID™, because the identity of the owner has been verified, they can use it to sign any digital file.
A7.	Using a Digi-CA™ combined with Digi-Access™, the systems can be secured and all users can be verified before offering them the correct access level.

Root Key

Root Key Ceremony

At the heart of every Digi-CA™ are at least one Root Key(s) or Root certificate(s) and one Intermediate Root certificate(s). Every Digi-CA™ certificate is made from a Public and a Private Key. A Root Key Ceremony is a procedure where a unique pair of Public and Private Root Keys is generated. Depending on the CP, the generation of the Root Keys may require notarization, legal representation, witnesses and ‘Key Holders’ to be present. This process is best explained with some examples:

Example A: Strong identification & non-repudiation for email & web access

Unless the information being accessed or transmitted is valued in terms of millions of dollars, it is probably sufficient that the Digi-CAST2™ Team conduct the Root Key Ceremony within the security of the Digi-CAST2™ Laboratory. The customer may opt to have the Root Key stored on a Luna Card or HSM, but in most cases the safe storage of the Root Key on a CD or hard disk is sufficient. The Root Key is never stored on the Digi-CA™ server.

Example B: Machine Readable Travel Document [MRTD] ID Card or e Passport

This type of environment requires much higher security than a commercial one. When conducting the Root Key Ceremony, the Government or Organization will require rigorous security checks to be conducted on all personnel in attendance. Those that are normally required to attend the Key Ceremony will include a minimum of two Administrators from the organisation, two signatories from the organisation, one lawyer, a notary and two video camera operators in addition to the Digi-CAST2™ Team.

The actual Root key-pair generation is normally conducted in a secure vault that has no communication or contact with the outside world other than a single telephone line or intercom. Once the vault is secured, all personnel present must prove their identity using at least two legally recognised forms of identification. Every person present, every transaction and every event is logged by the lawyer in a Root Key Ceremony Log Book and each page is notarized by the notary. From the moment the vault door is closed until it is re-opened, everything is also video recorded. The lawyer and the two organisation’s signatories must sign the recording and it too is then notarized.

Finally, as part of the above process, the Root Key is broken into as many as twenty-one parts and each individual part is secured in its own safe for which there is a key and a numerical lock. The keys are distributed to as many as twenty-one people and the numerical code is distributed to another twenty-one people.

Important Note: Example A and B are at opposite ends of the security spectrum and no two environments are the same. When considering the Root Key Ceremony, the Digi-CAST1™ Team of professional advisors can assist you in deciding on the most efficient level of security to reflect the level of protection required.

Root Certificate : Digi-Sign.com

Types of Root certificate

In the same way that a Grandfather can be traced back from the Grandson (and if needed the true legal identity proven using DNA analysis); a web server certificate can be traced back to its Root and by definition this relationship is tested, verifiable and cannot be compromised.

Depending on the type of CA system, the Root certificate used in by certificate Engine to sign the certificates below it can be:

• a Self-Signed Root [SSRoot]
• a Trusted Root [TRoot]

SSRoot

An SSRoot is a Root certificate that is signed by itself or is Self-Signed. This means that the Root certificate was created during the CA system installation and was not signed or cross certified by any other certificate (i.e. this certificate is the certificate at the top of the certificate chain).

TRoot

In every browser, there is a Trusted Root certificate store so that the important relationship from web server or person back to the TRoot can be checked every time the certificate is accessed.

This TRoot is used to sign all digital certificates below it. Much in the same way there is a natural Grandfather, Father and Son relationship; there is a chained relationship between a TRoot certificate, an Intermediate Root certificate and a Personal, or web server certificate.

Digital certificates signed in this way are part of the Trusted Chain and are said to offer public non-repudiation. Non-repudiation means that the validity of the certificate can be proven and that the recipient has been validated and verified in accordance with internationally recognised standards of practices and procedures for issuing Trusted certificates. This can also mean that they have legal standing in a court of law and therefore can act as a legal instrument or seal for digital transactions.

Only a Trusted Third Party [TTP] that operates a Trust Centre can issue a Trusted certificate because only a TTP has access to the TRoot certificate needed to sign the certificates they issue so that they can be trusted.

Trusted Root Restrictions

Only a certified commercial CA organisation or certified independent organisation can achieve the status necessary to own and operate the TRoot CA in a Trust Centre.

Trust Centres

Trust Centres are Commercial CAs and are usually operated by accredited TTP organisations. The TTP is an organisation that has been certified in accordance with international standards as being suitable and capable of issuing digital certificates. To attain the status of being a TTP, the organisation must have at its disposal a secure data centre that conforms to the Web Trust or similar Standards (an internationally recognised authority that certifies TTPs)

This typically includes that the data centre meets the same military standards for the physical facilities, personnel, procedures, practices, security controls and allocations used when storing nuclear missiles and is therefore highly secure. Once the TTP has been certified and its Root certificates accepted by the major browsers, they can issue Trusted certificates.

Thumbnail: 

Secure Socket

Secure Socket Layer Certificate

Secure Socket Layer [SSL] server certificates are installed on a server. This can be a server that hosts a website like www.digi-sign.com [3], a mail server, a directory or LDAP server, or any other type of server that needs to be authenticated, or that wants to send and receive encrypted data.

Code Signing Certificate

Code signing certificates are used to sign software or programmed code that is downloaded over the Internet. It is the digital equivalent of the shrink-wrap or hologram seal used in the real world to authenticate software and assure the user it is genuine and actually comes from the software publisher that it claims.

Client Certificate

Client certificates or Digital IDs are used to identify one person to another, a person to a device or gateway, or one device to another device. Client certificates are issued in their thousands and millions each year and would be the principle reason for purchasing a CA.

A person that is given access to a secure online service like a cloud service, an extranet or web portal will be authenticated to the gateway or entry point using a client certificate. This type of strong two factor authentication replaces less secure usernames and passwords currently in use on many websites.

If two routers or a Virtual Private Network [VPN] connection needs to authenticate each other, a client certificate can be used and exchanged to prove the connection is trusted. This type of client authentication occurs deep within the application and is not usually visible to the end user. This type of device-to-device authentication often uses a particular IPSec client certificate.

Also, bespoke applications and hardware seeking to utilize IP technology securely can use digital certificates to authenticate the application and/or for device-to-device authentication.

Digital Signature

Digital signatures are used to authenticate documents, files and emails and are the electronic equivalent of a handwritten signature. Digital signatures are issued in their thousands and millions each year and would be another use for a CA.

For example, two people communicating by email will used a client certificate to authenticate or digitally sign their respective communications. This digital signature will assure each person that the email is genuine and comes from the other person. And the same digital signature can be used to sign forms, PDF documents, workflow processes, etc.

Selection Guidelines

Digi-CA™ Selection Guidelines

The simplest way to select the correct Digi-CA™ for your organisation is to decide how many users you have (or in some cases the number of physical devices you need to identify). This should include employees, customers, partners or suppliers and the individual people that work in each of these areas that you wish to issue a digital certificate [Digi-ID™] too.

Another alternative is to look at the level of security that you wish to achieve. If the security is relating to corporate secrets, national security or can be regarded as critical, regardless of cost, then Digi-CA™ Xg may be the only option for you. The Digi-CAST1™ Team of professional advisors will guide you toward the optimum solution.

The most important benefit of Digi-CA™ is that every aspect of the final solution can be tailored to meet your precise user, security and policy requirements.

The following table can be used as a guide to assist in choosing the best Digi-CA™ Server for your environment.

Selecting the Correct Digi-CA™ for You

As explained in sub section 2.6.5.1, you should clearly identify if your user group is open or closed, what you want to use your certificates for and whether you have the staff required to run and operate the Digi-CA™. If, having read sub section 2.6.5 that advises you on how to select your Digi-CA™, you are still not clear, then contact the Digi-CAST1™ Team and seek their advice before proceeding further. You should also read the ‘Top Considerations’ when selecting your CA

Server Overview

Digi-CA™ Server Overview

The principal difference between Xs, Xp and Xg in each case relates to the degree of integration and customisation required. For example, Digi-CA™ Server Xs can be pre-configured and delivered to the customer for installation without any assistance from Digi-Sign whilst Digi-CA™ Server Xg projects can run for several days or a few weeks.

Important Note:If you have technical personnel that can correctly configure a network environment, install the necessary operating systems and provide secure access to the server(s), the Digi-CAST2™ installations Team may be able to conduct a large part of the installation process prior to visiting your site. In some cases, the complete installation can occur without the need for Digi-CAST2™ to visit your site at all.

Digi-CA™ Server Xs

Digi-CA™ Server Xs is CA Software for installation on a single server and comes complete with all the different sub-systems designed to run and operate efficiently on that single machine (see Appendix II).

As a software product, Digi-CA™ Server Xs only generates client certificates that can be used for email, two-factor authentication, secure web access, as electronic signatures, for use within a Virtual Private Networks [VPN] or for device-to-device authentication. Like all professional CA systems it allows the Administrator to set up policies and to manage all of the certificate life cycle services.

Even with all of the powerful functionality and capabilities that Digi-CA™ Server Xs offers, it is easy to install, configure and operate. A competent Network Engineer or qualified IT Technician could install a fully functional version of Digi-CA™ Server Xs and be fully competent in its operation within three days or less.

Digi-CA™ Server Xs can only be installed on a single Pentium® server and is typically used where high availability is not a key component of the environment. As a single server installation, there is no mirroring or synchronising of data. All records and data are protected by periodic backups only. Typical installations would be small to medium environments where high system availability is not an issue.

Digi-CA™ Server Xp

Digi-CA™ Server Xp is CA Software for installation on two servers and offers the same services as Digi-CA™ Server Xs but on a larger scale and with many additional services including certificate deployment and renewal automation (see Appendix II). The primary reason for selecting Xp instead of Xs is because Digi-CA™ Server Xp offers fail-over functionality.

Digi-CA™ Server Xp can also be configured to generate Secure Socket Layer [Digi-SSL™] web server certificates, Software & Code Signing certificates [Digi-Code™] in addition to Digi-Access™, Digi-ID™, and Digi-Mail™ certificates

The Digi-CA™ Server Xp installation must be carried out by Digi-CAST2™ professional services. This installation may require the Digi-CAST™ Team to physically conduct the installation on site, however, if a competent Network Engineer can provide a reliable connection to the correctly configured servers, then it may be possible to conduct the installation over the internet, without incurring travel and accommodation costs. The fully functional version of Digi-CA™ Server Xp can be completed in seven days or less.

Digi-CA™ Server Xp is installed on two Pentium® servers and is typically used where high availability is a component of the environment. As a dual server installation, there is mirroring and synchronising of data. All records and data are protected by this fail-over service. The Digi-CA™ Server Xp is split over two servers and gives the option to include a firewall in between. Typical installations would be large enterprise or government environments.

Digi-CA™ Server Xg

Digi-CA™ Server Xg is the CA for commercial Trust Centres. The services can be split over as many as 16 servers but a typical installation would use four servers and a single Hardware Security Module [HSM]. This CA has four levels of security including two or three levels of firewalls with fail over facilities and can incorporate hot standby, disaster recovery and a single system can operate from multiple locations.

The Digi-CA™ Server Xg installation must be carried out by Digi-CAST2™ professional services and requires the Team to physically conduct the installation on site with the associated travel and accommodation costs. Once configured, the fully functional version of Digi-CA™ Server Xg can be completed in ten days or less.

Digi-CA™ Server Xg is used where high availability and reliability are a key component of the environment. As a multi-server installation, there is mirroring and synchronising of data. All records and data are protected by this fail-over service. The Digi-CA™ Server Xg separates the CA services so that seven layers of security can be applied to the Trust Centre environment. The CA services are located in the certificate Engine core with the RA, certificate Revocation List [CRL], Light Directory Access Protocol [LDAP] and Time Stamping services located in the Outer Core (see Appendix II). Typical installations are government and commercial CA Trust Centres.

Digi-CA™ Shared Notes

Digi-CA™ Shared is where you actually purchase the Digi-CA™ Server software but we host it for you. This is particularly of use to organisations that know their long-term requirement is for Software CA but their immediate personnel and technical resources are insufficient to meet their needs.

The Digi-CA™ Server is configured, integrated and designed to meet your future environment and Digi-Sign hosts the software on a dedicated platform for you. As soon as your resources are at the appropriate levels, we migrate the entire system (without service interruption) to your site.

Service Approach

Digi-Sign Service Approach

The service approach is based on three principles:

• Complete life cycle Support
  Issue, reject, revoke, suspend and renew all of your digital
  certificates and get proper, live telephone support
• Total 'Look & Feel' Customisation
  Customisable systems set up to suit your organisations
  structure, multiple departments, multi-lingual, etc
• Flexible, Efficient & Cost Effective
  Deliver, when, how and where, as you request and as a true partner in the process by following the strict SLA

Service Overview

Service Overview

The principal difference between Digi-CA™ Service Xs, Xp and Xg is the level of integration and customisation you require. For example, Digi-CA™ Service Xs is provided as a standard Service and there is no customisation or integration offered. The Digi-CA™ Service Xp offers language localisation of the Digi-CA™ Control Centre and the end user interfaces and Xg could be a highly integrated Service involving various databases, synchronisation and other features.

There are four versions of Digi-CA™ Service, each with self-explanatory names:

• Digi-SSL™ Service - is for SSLs in bulk (5 or more)
• Digi-Access™ Service - provides two factor authentication
• Digi-Mail Service™ - provides secure email
• Digi-ID™ Service - is for multi-use Digi-IDs™

Each of these services is explained in detail in the following sub sections and the principal difference between Digi-CA™ Service Xs, Xp and Xg in each case relates to the type of digital certificate it issues and the degree of integration and customisation required.

Digi-SSL™ Service

You may be seeking a simple solution for getting SSL certificates or perhaps you have a larger and more specific set of requirements. You need many different digital certificates for several organisational divisions and locations. Whether your requirement is large or small, Digi-SSL Server™ easily meets your needs.

Traditionally, organisations have to wait hours or even days for SSL certificates. Other certificate solutions are cumbersome, labour intensive and expensive. With Digi-SSL™ Service these issues and others are completely removed.

• Request any certificate and it is delivered in minutes
• Multiple organisations, locations, and departments can all use the same system
• Layered Security Access, enables super users, managers and ‘Read Only’ access
• Language localisation and multiple language interfaces and help files are included
• Customisable Automated certificate Renewal notification – no more missed renewal dates!
• Limitless domain names are added without charge
• Total certificate ‘Life Cycle’ Management for all your Digi-SSLs™ using one single system
• Total Digi-SSL™ Control without the overhead of building, managing and supporting it
• Automated accounting facility to reduce accounts administration time

You provide us with a list of domains that you need secured and before the Digi-SSL™ Service is activated these names are thoroughly Validated. All domain name validations are provided free-of-charge and once active, the Administrator is able to issue and revoke any Digi-SSL™ for any domain name in the system.

Ease of Migration

Digi-SSL™ Service has out performed even its best-known rivals by using the latest in digital certificate and Internet technologies offered by the Digi-CA™ certificate Engine core. It offers you a totally flexible, fast, convenient and easy to use Service.

Moving from your current SSL ordering system to the Digi-SSL™ Service couldn’t be easier. The Digi-CA Assistant™ can create a list of your SSLs automatically and then upload this list to the Digi-SSL™ Service system. The migration process occurs as part of your normal SSL Renewal process and this means that all your existing certificates remain valid until they need to be replaced. Using the Digi-CA Assistant™, the Digi-SSL™ Service automatically ensures that the migration process is child’s play

Signature

Signature Algorithms

The Signature Algorithm uses RSA and DSA and as these algorithms are always used in conjunction with a one-way hash function, the following hash functions can be applied:

• MD2 (not in common use anymore)
• MD5
• SHA-1
• SHA-256 (Digi-CA™ Server only)
• SHA-512 (Digi-CA™ Server only)

Signature Key Algorithms

The Signature Key generation algorithms use RSA and DSA (Digi-CA™ Server only).

Single Server

Single Server Digi-CA™ Server Xs Technical Diagram

The following technical installation diagram outlines the typical network requirement to run and operate a single server Digi-CA™ Server Xs system without a HSM. Backup server is optional.

Single Server Digi-CA™ Server Xs & HSM Technical Diagram

The following technical installation diagram outlines the typical network requirement to run and operate a single server Digi-CA™ Server Xs system with a HSM. Backup server is optional.

Standards

Other Algorithms Standards

The x.509 certificate can be used for many purposes, such as: electronic signature, two factor authentication, client authentication, email signing and encryption and many other applications.

The most common and most frequently used purposes can be included using further layers of security protocols and cryptographic algorithms, the most common of which are:

• AES: Advanced Encryption Standard;
• S/MIME AES: Secure / Multipurpose Internet Mail Extensions [S/MIME] Advanced Encryption Standard for secure email messaging;
• 3DES Encryption: Triple DES encryption algorithm standard;
• IDEA Encryption: IDEA encryption algorithm standard;
• SSLv3: version 3 of the Secure Socket Layer protocol used for secure web access;
• TLSv1: version 1 of the Transport Layer Security protocol used for secure web access;
• and others in accordance with specific customer projects and requirements.

Compliance to Standards

Digi-CA™ has been verified to comply with more than 70+ standards and here is a list of the most commonly requested standards that Digi-CA™ complies with:

Digi-CA™ standard compliance list
RSA Public Key Cryptography Standards		PKCS#1, PKCS#3, PKCS#5, PKCS#7, PKCS#8, PKCS#9, PKCS#10, PKCS#11, PKCS#12
Internet Engineering Task Force RFC standards or standard candidates		RFC 373, RFC 1231, RFC 1422, RFC 2246, RFC 2315, RFC 2459, RFC 2510, RFC 2527, RFC 2560, RFC 2587, RFC 2630, RFC 2634, RFC 2818, RFC 2898, RFC 2986, RFC 3039, RFC 3161, RFC 3279, RFC 3280, RFC 3628, RFC 3629, RFC 3647, RFC 3739, RFC 4514, RFC 5280
US Federal Information Processing Standards		FIPS 46, FIPS 180-2, FIPS 186-2, FIPS 197, FIPS 198
European Telecommunications Standards Institute standards		ETSI TS 102 280, ETSI TS 102 042, ETSI TS 102 040, ETSI TS 102 023, ETSI TS 101 861
CEN Workshop Agreement standards		CWA 14167-1, CWA 14172 (1-8)
ISO & Other standards		ITU X.509, ITU-T X.520, ISO 27001, ISO 7816 Parts (1 – 5), ISO 7816 (Parts 7 – 9), ISO 15408, GridPMA, EAL4, EAL4+, XKMS XML, NIST SP 800-38C, NIST SP 800-38B, NIST SP 800-90

Compatibility

Digi-SSL™ and Digi-Code™ certificates require browser compatibility. Digi-ID™ certificates require browser compatibility and also compatibility with Adobe® PDF whilst email software compatibility is required when being using Digi-Mail™ certificates.

Browser Client Compatibility

The following is a list of browsers that are compatible with Digi-SSLs™, Digi-Codes™ and Digi-ID™ certificates:

• Microsoft® Internet Explorer 5.5
• Microsoft® Internet Explorer 6.x+
• AOL® 5+*
• Opera 5+*
• Safari 1.2*
• Mozilla/5 1.7.2*
• Firefox 1.0*
• Netscape 4.x*
• Netscape 8.1+*

Email Client Compatibility

The following is a list of browsers that are compatible with the certificates used for Digi-Mail™:

• Microsoft® Outlook Express 5.5
• Microsoft® Outlook Express 6.x+
• Microsoft® Outlook 98, ME, 2000, 2003, XP
• AOL® Instant Messenger 5.2+
• Eudora 3.1+ (with EMS API plug-in)*
• Safari 1.2*
• Mozilla/5 1.7.2*
• Firefox 1.0*
• Netscape 4.x*
• Netscape 8.1+*

Steps

The Steps for Issuing an End Entity Certificate

Proof of Identity – When the end user first applies for the certificate, in most cases they must prove their identity. The information or documents required to provide ‘proof of identity’ are decided by the issuing authority and may include official papers and/or other documents. The precise requirement will be clearly identified in the CP.

Application Form - An application form must be completed.

Data Check – Once the end user’s application form details are received, the Registration Authority [RA] cross checks or validates the data for accuracy and authenticity.

Approval/Rejection – The RA either approves or rejects the application.

Notification – End user is notified that their certificate is available for collection or it is sent out automatically.

Collection – The end user receives the certificate and can use this to prove their identity.

Renewal – All certificates are renewed at fixed intervals, usually each year or every second year.

The Steps for Re-Issuing or Replacing an End Entity Certificate

Proof of Identity – When the end user first applies for a certificate, the information or documents required to provide ‘proof of identity’ are decided in the CP.

Application Form - An online application form must be completed.

Data Check – Once the end user’s application form details are received, the Registration Authority [RA] cross checks or validates the data for accuracy and authenticity.

Approval/Rejection – The RA either approves or rejects the application using the online RA Control Centre.

Notification – End user is notified that their certificate is available for collection as the final part of the Process or it is simply sent out automatically in a Package.

Collection – The end user receives the certificate and can use this to prove their identity.

Renewal – All certificates are renewed at fixed intervals, usually each year or every second year.

Typically the renewal process is simply a case of presenting the previous certificate and a new one is issued to replace it.

System Consoles

Digi-CA™ Overview

There are four consoles in the Digi-CA™ system, namely:

Error! Reference source not found.		CAMC		www.digi-sign.com/digi-ca/camc [6]
Error! Reference source not found.		RAMC		www.digi-sign.com/digi-ca/ramc [7]
Error! Reference source not found.		EERS		www.digi-sign.com/digi-ca/eers [8]
Error! Reference source not found.		CCDS		www.digi-sign.com/digi-ca/ccds [9]

The focus of this document is on the Digi-CA™ Management Console [CAMC]. Separate documents and online support resources provide detailed information on the Registration Authority Management Console [RAMC]; the End Entity Registration Service [EERS]; and the Active Content Dissemination Services [CCDS].

Digi-CA™ Management Console [CAMC]

The CA Administrator’s Management Console [CAMC] is the web based Certification Authority management module that enables the CA Administrator to control the principal services of the Digi-CA™ system.

Registration Authority Management Console [RAMC]

The RA Management Console [RAMC] Service Module is the central graphical user interface [GUI] for operating Registration Authorities and managing End Entity Certificates. For further details, please visit www.digi-sign.com/digi-ca/ramc [7]

End Entity Registration Service [EERS]

The End Entity Registration Service [EERS] is the GUI where end entities (e.g. users, devices and services) interface with the digital certificates and digital signatures issues by the Digi-CA™ system. For further details, please visit www.digi-sign.com/digi-ca/eers [8]

Certificate & CRL Dissemination Services [CCDS]

The Certificate & CRL Dissemination Services [CCDS] is a software application as described in various European Telecoms Standards Institute [ETSI] and CEN Workshop Agreement [CWA] Standards. Ultimately the CCDS provides dissemination for end entity public key certificates, key pairs, Certificate Revocation List [CRL] and Online Certificate Status Protocol [OCSP] services. For further details, please visit www.digi-sign.com/digi-ca/acds [10]

Technology

MIME Technology

The Digital Signature and message encryption implementation on email messages is achieved by mechanisms implemented directly in the email client software and that follows the S/MIME standard.

Both S/MIME message encryption and Digital Signatures are based on encryption technologies. Message body encryption creates a completely unreadable message body and Digital Signature. The diagram below shows how the encryption process generates a one-time Symmetric Key (also called a Session Key) that encrypts the message body.

The Symmetric Key is then encrypted with each recipient’s public key so that only the recipient can decrypt the Symmetric Key. The message is then sent. On the recipient end, the Private Key is used to decrypt the Symmetric Key, which is then used to decrypt the message. This process is transparent to the user and is performed with no interaction between clients. Symmetric encryption is much faster than asymmetric encryption. The reason is because symmetric encryption encrypts the data (message body) in bulk.

In the diagram on the following page, it illustrates the message encryption and decryption process. The four main steps detailed in the illustration are as follows:

	1	Message is encrypted with Session Key.
	2	Session Key is encrypted with recipient’s public key.
	3	After encrypted message is received, recipient decrypts Session Key with the recipient’s Private Key.
	4	Message is decrypted with Session Key.

When you add a Digital Signature to a message, a hash value of the message contents is computed. User Keys aren’t used to compute the hash value and the hash doesn’t identify anyone. The hash is only a small, unique digital fingerprint of the message. This hash value is then encrypted with the sender’s Private Key, and can be decrypted with the public key found in the sender’s certificate.

The recipient decrypts the original hash value with the sender’s public key, which might be sent with the signed message or can be found in the sender’s certificate. Your client verifies signatures. For encrypted messages, it decrypts the message first. The client computes a new hash value based on the text received and compared to the original hash value. If they match, you can trust the content’s integrity and the sender’s identity.

Trust Management

Total Trust Management™

Total Trust Management™ [TTM™] is a unique offering from Digi-Sign (although some try to copy it) and it means that you Trust us to Totally Manage the Digi-CA™ for you. TTM™ is much more than a dedicated telephone number for support; it’s a service where Digi-Sign personnel effectively work for you.

We ensure that the Digi-CA™ is introduced to your end users with the minimum of fuss. All you do is agree how you want us to operate the system and we do everything for you. It’s a bit like travelling ‘First Class’.

75% of Digi-CA™ owners use TTM™ in the first year, at least, so that they can see how we do everything and then learn by watching us. We assume the RA responsibility and solve any technical and Help Desk support issues from the end users.

Training an RA Administrator how to use the Digi-CA™, explaining the principles and importance of the CP and providing sufficient Administrator knowledge to undertake their work in a professional manner, can take time. Manuals, technical documentation, on site training and subsequent second and third level external support can assist the Administrator, but too often, the organisation does not have these vital, and necessary, resources available.

As with all new technology implementations in any organisation, the initial deployment and piloting of a project is critical to its success. Many CA installations have failed because this important principle was either misunderstood or miscalculated.

To solve all of these issues, in 2001 Digi-Sign pioneered the TTM™ service so that CA deployment is a simple execution. Since then, other organisations have attempted to 'copy' the TTM™ offering with varying degrees of success. However, to completely understand why TTM™ is so unique, an understanding of the technology used in Digi-CA™ is required.

Incredibly, most CAs available in the market today still use Legacy CA technology. The technology that was used to design what is at the very heart of these CAs is 1990's technology. The best way to illustrate the affect this has for Legacy CA users is to draw a comparison between Legacy CAs and the Desktop PC. Consider the difference between Windows® 3.1 with today’s versions of Windows® and the differences are obvious. The same is true of Legacy CAs.

Digi-CA™ uses the latest in CA technology and this enables Digi-Sign to offer the most comprehensive TTM™ service. The organisation that owns the Digi-CA™ is provided with read-only access to the system so that they can see the TTM™ service in 'real time' and learn from the actions carried out by the Digi-CA TTM™ Administrators.

Over time, the initial deployment and pilot projects are completed and full scale implementation is well advanced. In many cases, the organisation only uses the TTM™ service for the first year and by this time, digital certificates are already part of the organisation's total IT infrastructure.

With TTM™, the total implementation and adoption of certificates within the organisation can sometimes happen almost without anyone noticing. Some owners have even extended the TTM™ service to include the Total Trust Management of their Digi-SSL™ requirements too.

Types of Certificate

Digi-Sign Digital Certificates

Digi-Sign offers three types of digital certificate and both types of CA. With exception of Digi-Code™, these are offered in three Classes depending on your requirements.

Types of Certificate

The three types of digital certificate are:

Digi-SSL™		SSL certificates
Digi-Code™		Code signing certificates
Digi-ID™; Digi-Access™; Digi-Mail™		Client certificates

Certificate Classes

And there are several Classes for each of these certificates, e.g. Xn, Xs, Xp, Xe, Xg, etc. The three standard Classes are the Xs, Xp and Xg, where Xs is the basic Class and offers no real flexibility to the user and Xg is at the other end of the spectrum and is the most flexible.

Certificate Details

The following sub sections detail the different Types of certificate and the correct Class depending on your requirement.

Digi-SSL™ Certificates

Digi-SSLs™ are Secure Socket Layer [SSL] certificates and are used for securing and authenticating the following:

• web server
• mail server
• LDAP directory server
• database server

Digi-SSLs™ are the most commonplace digital certificate in use today. Web sites and other servers use Digi-SSLs™ in their thousands each year. If your requirement is predominantly for SSL and SSL Management, we recommend the Digi-SSL™ Service.

Digi-SSL™ Xs, Xp & Xg

Digi-SSL™ provides you with two functions:

• Website authentication
• Data encryption

Every application for any class of Digi-SSL™ is subjected to the Triple-Check Validations procedure. This means that two or more Validations Officers physically check your details and entitlement to get the Digi-SSL™ before it is issued to you. This rigorous checking procedure protects you from someone else stealing your online identity because the Digi-Sign Triple-Check Validations™ has a 100% track record of never issuing a digital certificate to the wrong party. Once this Digi-SSL™ is put on your website, visitors know your site is genuine.

The same Digi-SSL™ that authenticates your site to visitors can also be used for encrypting data and it is here that the Xp/Xg and Xs difference occurs. The main difference between Xp/Xg & Xs is that the Digi-SSL™ Xs is for low/no value transactions and Xp/Xg is for corporate users and commercial websites.

The Digi-Sign Certificate Practice Statement [CPS] v3.7, Sub section 2.4.1.a and 5.32.1 both state that the maximum warranty associated with a Digi-SSL™ Xs certificate is €0.01. So if your information is worth more than €0.01 and you require warranty protection, you should only use the Xs certificate to authenticate your website. This does not mean you can’t use the Xs for encrypting data, it only means that in the event of a fault in the Digi-SSL™, you have no warranty.

The maximum warranty associated with the Digi-SSL™ Xp or Xg certificate is €10,000. The CPS v3.7, Sub section 2.4.1.b and 5.32.2, both state clearly that this is for corporate or professional use and carries a warranty in the event of failure.

Other Differences between Xp/Xs & Xg would be that:

• Xp/Xg certificates are replaced free of charge any time during their life cycle. Xs are not.
• Xp/Xg certificates provide telephone support. Xs do not.
• Xp/Xg are issued with the secure Digi-Seal™ for displaying on your website. Xs are not.

Digi-SSL™ Xg certificates are only supplied in specific cases where multiple hosting specifications require flexible naming within the Digi-SSL™. This specialist configuration can include multiple Common Names within the same certificate, wildcard facilities or a combination of these requirements.

User Storage

Fused Storage

Fused User Protected Storage

In the case where the end entity certificates is stored in the Microsoft Internet Explorer certificate Store of the Desktop Profile for the user, there is an option in the Digi-CA Sever™ system to offer further security levels by enabling the User Protected setting. Depending on the CP, this can be offered to the end user as an option or it can be enforced. The security levels are:

• Low
• Medium
• High

The Low setting is the same as no User Protection and the check box remains unchecked. The Medium setting is where every time the certificate is required by any application a simple pop-up dialog appears so that the user is notified and must accept the request to use the certificate by clicking the OK button. And in the High setting, a pop-up dialog appears so that the user must enter a password before any request to use the certificate will be permitted.

If a High User Protection is enforced by the CP, or the user selects it, then the pop-up dialog will require them to enter a password to protect the end entity certificate.

This final setting where the user must enter a password is referred to a Two Factor Authentication, because the user must have an end entity certificates and know its password before they can use it. So something you have and something you know provides this Two Factor Authentication.

Storage Considerations

When choosing your Storage Type, careful consideration should be given to a number of factors. If the Private Key is not exportable and its life cycle is set to be valid for ten years, then will the device it is stored on still work 10 years from now? What happens if the device is lost, stolen or destroyed? Alternatively, if you decide that the Private Key can be exported, how do you prevent it being shared by several users? What is the disadvantage should sharing occur?

If you decide to enforce High User Protection, what happens if the user forgets their password and the certificate is rendered permanently unusable thereafter? On the other hand, if there’s no password, how easy would it be for someone else to use that certificate?

The Digi-CAST1™ Team of professional advisors are there to assist you in making the best choice for your environment and to help remove the element of risk from your purchase.

Validations

Digi-CA™

x.509 and cryptographic standards make it impossible that two identical certificates can be issued from the same Digi-CA™. Every certificate is unique.

A person’s ‘proof of identity’ can be proven using various traditional methods. For example: private information that only that specific person could know; a letter from a notary, lawyer, accountant, employer or Peace Commissioner identifying that person; bank, passport, national ID card or insurance number; eye scan, finger print, biometrics; etc. Every person is unique.

The whole purpose of the certificate is to identify the specific person or device in the digital world. Once the unique identity is proven using traditional methods, then the unique certificate can be issued.

The process of mapping the unique certificate to the unique person or device is called the Validation Process. The Validation Process is based on the specific CP for the specific certificate and is set out when Digi-CA™ is first designed and installed.

The Digi-CA™ is the digital equivalent of an identification authority like an employee ID card, a passport office or a national identity card issuer. In all of the above cases, the identity of the end user is checked and an ID is issued to certify that the person is who they claim to be. In the case of the Digi-CA™, it issues the certificate to each end user after their ‘real world’ identity has been verified.

The process of issuing the certificate is similar to the steps used to issue an employee ID card, passport or national ID card.

Validation Examples

• An organisation wants to clearly identify its employees to the ‘outside’ world.
  In this case, the users use email to communicate with other users outside their network. Because the company owns its own domain name, it only needs to restrict the Validations Process so that certificates are only issued to users with that specific domain name in their email address. Users simply fill in their name and email address and these are cross-checked against an email owner list. If the email address exists, the certificate is issued.
• An online service needs to restrict access to its services for fee paying members only.
  In this case, the users’ details and account details are already known. Because the company knows who has paid for the service, it only needs to restrict the Validations Process so that certificates are only issued to users with specific email addresses and account details. Users simple fill in their details and they are cross-checked against an email owner list. If the details are entered correctly, the certificate is issued.
• A Public Authority wants to identify users of its public services.
  Depending on the sensitivity of the data and the Data Protection Laws that must be followed, the Authority may need to issue the certificate pre-installed on smartcards and only give them to the end user when they turn up in person and present their ‘proof of identity’. The Authority must exercise its own procedures on what constitutes true ‘proof of identity’.
  In less stringent cases, certain Methods of Delivery or a combination of Methods may not require ‘proof of identity’.
• A legal document in electronic format needs two people to digitally sign it.
  If the lawyers acting on behalf of the clients send letters with some confidential information about the client (that only the lawyer and the client know) then this information can be used when the user enrolls on the web application form. If the details are entered correctly, the certificate is issued.
• A Service Provider wants to authenticate one hardware device to another central server device
  This is simply a case of matching one certificate Serial Number to the list pre-defined on the Digi-CA™ system. The certificates can be issued and only those devices containing the correct Serial Number will be authenticated to the central server.
• A medical organisation wants to provide patients, certified users and doctors with access to medical files
  As with the Public Authority, this may require a ‘proof of identity’ check. Another alternative would be to use a Method of Delivery where the user receives a Smartcard, for example, with the certificate pre-installed. Access to the medical files can occur on an as needed basis using a telephone identity check where details about the patient can be verified by telephone before activating the certificate and providing access to the records.
• Multiple entities want to exchange data using encryption that is limited to specific users.
  As described in the Methods of Delivery, the identity of these users can be simple (name, email, telephone and ID) or in high security environments, a higher security process of issuing the certificates will be used.

How an end entity certificate is validated is central to the security and legality of the certificate and the Digi-CA™. If the Validation Policy is weak or can be easily circumvented, then personal identity theft or impersonation is possible. In other words, there is no way to ‘tie’ the certificate to the user.

Why Digital Certificates

Why Digital Certificates are Needed

Every time a user sends an email it travels across the internet or World Wide Web. It is called the World Wide Web because the internet is made up of thousands of servers or a ‘web of servers’. Each and every communication visits a minimum of 8 and a maximum of 32 servers before it reaches its intended destination. Each of these points of contact represents a security risk. Scripts, viruses, hackers and other devices can intercept the data at any time and can copy or alter it unnoticed.

Device-to-device authentication, two-factor authentication, transaction signing and the inherent ‘digital identity’ within the digital certificate means that you know who and what you’re communicating with.

Encrypting information is only one aspect of security, the other is knowing the identity of the person. If two people choose to communicate by email, how can they be sure that any of the communications were transmitted without being tampered with? Equally, if a website owner wants to be sure that only a specific user gains access to secured information, how can this assurance be provided?

The simple answer is that digital certificates are the digital equivalent of a passport or signature. By opening a user’s digital certificate much of the information that would be available in a passport or drivers license can be viewed in the certificate. The person’s name, the organisation that they work for (or the organisation that issued the certificate) and other information is clearly legible. A digital certificate cannot be compromised or ‘cracked’, this provides the assurance necessary to assure the recipient that the person is genuinely who they claim to be.