[1] Digi-CA™ is the Certificate Engine 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 Intellectual Property [IP] is that the Service and the Server versions of the Digi-CA™ [2] are effectively 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 Traditional CA [3]s) and thereby saves you considerable costs, should such a requirement arise.
The rules, methods and guidelines that specify how the Digi-CA™ will issue its Certificates and these processes and procedures are documented [4] in the Certificate Policy [Certificate Policy]. The Certificate Policy is the ‘Who, What, Where and How’ document that describes the principles of the Digital Certificate [5] usage and how they are to be distributed. This Certificate Policy is agreed before the Digi-CA™ is operational and all Digital Certificates must be deployed in accordance with the Certificate Policy. Appendix I is a questionnaire designed to assist in creating your Certificate Policy.
Digi-CA™ is delivered either as CA Software or as a Managed CA and it is available in three classes:
3.13.2 Digi-CA™ Xp - Professional CA
3.13.3 Digi-CA™ Xg - Trust Centre CA
[1] The two different types of Digi-CA™ systems are:
The Digi-CA™ Service is supplied as an online service from outside your organization.
Digi-CA™ Server is installed at your premises or your data centre.
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] 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™ [2] 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.
There are seven variations of Digi-CA™ Service namely:
[1] The simplest way to select the correct Digi-CA™ [2] for your organization 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™ [10]] 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.
Environment Requirement Users Recommended Digi-CA™
As explained in sub section 2.6.4.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.4 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 as indicated in the following sub sections 3.8 - 3.10.
[1] 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 [5].
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
2. The Delivery Method you will use
3. The Storage Type you select
Once these three principles are clearly understood, then you need to understand the long term impact of the Key Management you choose and this is dictated by the Digital Certificate Binding Option (see sub section 3.8.4) that you decide upon. The Digital Certificate Binding Option is the fourth and final Top Considerations when selecting the correct CA for you.
[1] Replicated directories are a fundamental requirement for delivering a resilient enterprise deployment.
Digi-CA™ has various configuration options for creating a replicated directory. In previous releases, replication was discussed in terms of a master server and some number of slave servers. A master accepted directory updates from other clients, and a slave only accepted updates from a (single) master. The replication structure was rigidly defined and any particular database could only fulfill a single role, either master or slave.
Digi-CA™ now supports a wide variety of replication topologies, these terms have been deprecated in favor of provider and consumer: A provider replicates directory updates to consumers; consumers receive replication updates from providers. Unlike the rigidly defined master/slave relationships, provider/consumer roles are quite fluid: replication updates received in a consumer can be further propagated by that consumer to other servers, so a consumer can also act simultaneously as a provider. Also, a consumer need not be an actual LDAP server; it may be just an LDAP client.
The following sections will describe the replication technology and discuss the various replication options that are available.
The LDAP Sync Replication engine, syncrepl for short, is a consumer-side replication engine that enables the consumer LDAP server to maintain a shadow copy of a DIT fragment. A syncrepl engine resides at the consumer and executes as one of the slapd(8) threads. It creates and maintains a consumer replica by connecting to the replication provider to perform the initial DIT content load followed either by periodic content polling or by timely updates upon content changes.
Syncrepl uses the LDAP Content Synchronization protocol (or LDAP Sync for short) as the replica synchronization protocol. LDAP Sync provides a stateful replication which supports both pull-based and push-based synchronization and does not mandate the use of a history store. In pull-based replication the consumer periodically polls the provider for updates. In push-based replication the consumer listens for updates that are sent by the provider in realtime. Since the protocol does not require a history store, the provider does not need to maintain any log of updates it has received (Note that the syncrepl engine is extensible and additional replication protocols may be supported in the future.).
Syncrepl keeps track of the status of the replication content by maintaining and exchanging synchronization cookies. Because the syncrepl consumer and provider maintain their content status, the consumer can poll the provider content to perform incremental synchronization by asking for the entries required to make the consumer replica up-to-date with the provider content. Syncrepl also enables convenient management of replicas by maintaining replica status. The consumer replica can be constructed from a consumer-side or a provider-side backup at any synchronization status. Syncrepl can automatically resynchronize the consumer replica up-to-date with the current provider content.
Syncrepl supports both pull-based and push-based synchronization. In its basic refreshOnly synchronization mode, the provider uses pull-based synchronization where the consumer servers need not be tracked and no history information is maintained. The information required for the provider to process periodic polling requests is contained in the synchronization cookie of the request itself. To optimize the pull-based synchronization, syncrepl utilizes the present phase of the LDAP Sync protocol as well as its delete phase, instead of falling back on frequent full reloads. To further optimize the pull-based synchronization, the provider can maintain a per-scope session log as a history store. In its refreshAndPersist mode of synchronization, the provider uses a push-based synchronization. The provider keeps track of the consumer servers that have requested a persistent search and sends them necessary updates as the provider replication content gets modified.
With syncrepl, a consumer server can create a replica without changing the provider's configurations and without restarting the provider server, if the consumer server has appropriate access privileges for the DIT fragment to be replicated. The consumer server can stop the replication also without the need for provider-side changes and restart.
Syncrepl supports partial, sparse, and fractional replications. The shadow DIT fragment is defined by a general search criteria consisting of base, scope, filter, and attribute list. The replica content is also subject to the access privileges of the bind identity of the syncrepl replication connection.
The LDAP Sync protocol allows a client to maintain a synchronized copy of a DIT fragment. The LDAP Sync operation is defined as a set of controls and other protocol elements which extend the LDAP search operation. This section introduces the LDAP Content Sync protocol only briefly. For more information, refer to RFC4533.
The LDAP Sync protocol supports both polling and listening for changes by defining two respective synchronization operations: refreshOnly and refreshAndPersist. Polling is implemented by the refreshOnly operation. The consumer polls the provider using an LDAP Search request with an LDAP Sync control attached. The consumer copy is synchronized to the provider copy at the time of polling using the information returned in the search. The provider finishes the search operation by returning SearchResultDone at the end of the search operation as in the normal search. Listening is implemented by the refreshAndPersist operation. As the name implies, it begins with a search, like refreshOnly. Instead of finishing the search after returning all entries currently matching the search criteria, the synchronization search remains persistent in the provider. Subsequent updates to the synchronization content in the provider cause additional entry updates to be sent to the consumer.
The refreshOnly operation and the refresh stage of the refreshAndPersist operation can be performed with a present phase or a delete phase.
In the present phase, the provider sends the consumer the entries updated within the search scope since the last synchronization. The provider sends all requested attributes, be they changed or not, of the updated entries. For each unchanged entry which remains in the scope, the provider sends a present message consisting only of the name of the entry and the synchronization control representing state present. The present message does not contain any attributes of the entry. After the consumer receives all update and present entries, it can reliably determine the new consumer copy by adding the entries added to the provider, by replacing the entries modified at the provider, and by deleting entries in the consumer copy which have not been updated nor specified as being present at the provider.
The transmission of the updated entries in the delete phase is the same as in the present phase. The provider sends all the requested attributes of the entries updated within the search scope since the last synchronization to the consumer. In the delete phase, however, the provider sends a delete message for each entry deleted from the search scope, instead of sending present messages. The delete message consists only of the name of the entry and the synchronization control representing state delete. The new consumer copy can be determined by adding, modifying, and removing entries according to the synchronization control attached to the SearchResultEntry message.
In the case that the LDAP Sync provider maintains a history store and can determine which entries are scoped out of the consumer copy since the last synchronization time, the provider can use the delete phase. If the provider does not maintain any history store, cannot determine the scoped-out entries from the history store, or the history store does not cover the outdated synchronization state of the consumer, the provider should use the present phase. The use of the present phase is much more efficient than a full content reload in terms of the synchronization traffic. To reduce the synchronization traffic further, the LDAP Sync protocol also provides several optimizations such as the transmission of the normalized entryUUIDs and the transmission of multiple entryUUIDs in a single syncIdSet message.
At the end of the refreshOnly synchronization, the provider sends a synchronization cookie to the consumer as a state indicator of the consumer copy after the synchronization is completed. The consumer will present the received cookie when it requests the next incremental synchronization to the provider.
When refreshAndPersist synchronization is used, the provider sends a synchronization cookie at the end of the refresh stage by sending a Sync Info message with refreshDone=TRUE. It also sends a synchronization cookie by attaching it to SearchResultEntry messages generated in the persist stage of the synchronization search. During the persist stage, the provider can also send a Sync Info message containing the synchronization cookie at any time the provider wants to update the consumer-side state indicator.
In the LDAP Sync protocol, entries are uniquely identified by the entryUUID attribute value. It can function as a reliable identifier of the entry. The DN of the entry, on the other hand, can be changed over time and hence cannot be considered as the reliable identifier. The entryUUID is attached to each SearchResultEntry or SearchResultReference as a part of the synchronization control.
The syncrepl engine utilizes both the refreshOnly and the refreshAndPersist operations of the LDAP Sync protocol. If a syncrepl specification is included in a database definition, slapd(8) launches a syncrepl engine as a slapd(8) thread and schedules its execution. If the refreshOnly operation is specified, the syncrepl engine will be rescheduled at the interval time after a synchronization operation is completed. If the refreshAndPersist operation is specified, the engine will remain active and process the persistent synchronization messages from the provider.
The syncrepl engine utilizes both the present phase and the delete phase of the refresh synchronization. It is possible to configure a session log in the provider which stores the entryUUIDs of a finite number of entries deleted from a database. Multiple replicas share the same session log. The syncrepl engine uses the delete phase if the session log is present and the state of the consumer server is recent enough that no session log entries are truncated after the last synchronization of the client. The syncrepl engine uses the present phase if no session log is configured for the replication content or if the consumer replica is too outdated to be covered by the session log. The current design of the session log store is memory based, so the information contained in the session log is not persistent over multiple provider invocations. It is not currently supported to access the session log store by using LDAP operations. It is also not currently supported to impose access control to the session log.
As a further optimization, even in the case the synchronization search is not associated with any session log, no entries will be transmitted to the consumer server when there has been no update in the replication context.
The syncrepl engine, which is a consumer-side replication engine, can work with any backends. The LDAP Sync provider can be configured as an overlay on any backend, but works best with the back-bdb or back-hdb backend.
The LDAP Sync provider maintains a contextCSN for each database as the current synchronization state indicator of the provider content. It is the largest entryCSN in the provider context such that no transactions for an entry having smaller entryCSN value remains outstanding. The contextCSN could not just be set to the largest issued entryCSN because entryCSN is obtained before a transaction starts and transactions are not committed in the issue order.
The provider stores the contextCSN of a context in the contextCSN attribute of the context suffix entry. The attribute is not written to the database after every update operation though; instead it is maintained primarily in memory. At database start time the provider reads the last saved contextCSN into memory and uses the in-memory copy exclusively thereafter. By default, changes to the contextCSN as a result of database updates will not be written to the database until the server is cleanly shut down. A checkpoint facility exists to cause the contextCSN to be written out more frequently if desired.
Note that at startup time, if the provider is unable to read a contextCSN from the suffix entry, it will scan the entire database to determine the value, and this scan may take quite a long time on a large database. When a contextCSN value is read, the database will still be scanned for any entryCSN values greater than it, to make sure the contextCSN value truly reflects the greatest committed entryCSN in the database. On databases which support inequality indexing, setting an eq index on the entryCSN attribute and configuring contextCSN checkpoints will greatly speed up this scanning step.
If no contextCSN can be determined by reading and scanning the database, a new value will be generated. Also, if scanning the database yielded a greater entryCSN than was previously recorded in the suffix entry's contextCSN attribute, a checkpoint will be immediately written with the new value.
The consumer also stores its replica state, which is the provider's contextCSN received as a synchronization cookie, in the contextCSN attribute of the suffix entry. The replica state maintained by a consumer server is used as the synchronization state indicator when it performs subsequent incremental synchronization with the provider server. It is also used as a provider-side synchronization state indicator when it functions as a secondary provider server in a cascading replication configuration. Since the consumer and provider state information are maintained in the same location within their respective databases, any consumer can be promoted to a provider (and vice versa) without any special actions.
Because a general search filter can be used in the syncrepl specification, some entries in the context may be omitted from the synchronization content. The syncrepl engine creates a glue entry to fill in the holes in the replica context if any part of the replica content is subordinate to the holes. The glue entries will not be returned in the search result unless ManageDsaIT control is provided.
Also as a consequence of the search filter used in the syncrepl specification, it is possible for a modification to remove an entry from the replication scope even though the entry has not been deleted on the provider. Logically the entry must be deleted on the consumer but in refreshOnly mode the provider cannot detect and propagate this change without the use of the session log on the provider.
[1] The production of any Digital Certificate [5], 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™ [2], 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 Digi-IDs™:
With Digi-CA™, you can choose the Disposable Digi-ID™ [10] Binding Option most frequently used in Traditional CA [3]s or you can use the more modern Binding Option that creates the Renewable Digi-ID™.
[1] Unlike most Traditional CAs, Digi-CA™ [2] offers both Disposable and Renewable Binding Options for your Digi-IDs™ [10]. As you come to truly understand the implications of selecting your Binding Option, you will come to see the relevance, or necessity, for Key Management.
[1] The Key Management issue can be complex and the sub sections of this document [4] are here only as an guideline to the deeper issues. In selecting the best approach for your environment, the Digi-CAST™ [12] Team can advise you and their advice will always be to keep things as simple as you can.
For Disposable Digi-IDs™, the Digi-CA™ [2] will require Key Management enabled in advance because after five years, with only 100,000 end users, there will actually be 500,000 Key-Pairs in circulation. If you decide that you must use Disposable Digi-IDs™ then you should consider the following questions, for example:
The solution to these problems is to have Key Management and Key Escrow services enabled in the Digi-CA™ during configuration and installation.
In the case of Renewable Digi-IDs™, you don’t really need Key Management and in many Trust Centre [13] environments, Key Eskrow services are not permitted by law. Also, as the end user has only one Digi-ID™ or Key-Pair to take care of, it is a much easier task to provide assistance and enable them to ‘self recover’ from their own Backup.
[1] Digi-CA™ [2] has different delivery options for each Digital Certificate [5] it produces. The most common use for Digi-CA™ is to deliver Digi-IDs™. Prior to the installation of the Digi-CA™, the Certificate Policy 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. A Digi-ID™ 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.
[1] For Digi-IDs™ there are two different Storage Types and several devices that need careful consideration when choosing how your Digi-IDs™ will be deployed. The correct selection is critical to the ease of operation combined with the level of security you need to achieve.
The Digi-ID™ 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 Digi-ID™ 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 Digi-ID™, just as they would any computer file. These devices can include Smart Cards and USB Tokens that don’t have CSP capabilities.
When selecting your storage device, you should consider its immediate intended use and also other future possible uses too. For example the Digi-ID™ 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 Digi-ID™ 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 advisor's are there to assist you in making the best choice for your environment and remove the element of risk from your purchase.
[1] When a CSP is used in the ‘manufacture’ of the Public and Private Key Pair that is used when generating the Digi-ID™, then there is the option to use two Digi-ID™ 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™ [2] offers both of these Types of Storage.
In the most common case where the Digi-ID™ 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.
In the case where the Digi-ID™ 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 Certificate Policy, this can be offered to the end user as an option or it can be enforced. The security levels are:
The Low setting is the same as no User Protection and the check box remains unchecked. The Medium setting is where every time the Digi-ID™ 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 Digi-ID™ 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 Digi-ID™ will be permitted.
If a High User Protection is enforced by the Certificate Policy, or the user selects it, then the pop-up dialog will require them to enter a password to protect the Digi-ID™.
This final setting where the user must enter a password is referred to a two factor authentication [8], because the user must have a Digi-ID™ and know its password before they can use it. So something you have and something you know provides this Two Factor Authentication.
[1] 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 Digi-ID™ [10] is rendered permanently unusable thereafter? On the other hand, ff there’s no password, how easy would it be for someone else to use that Digi-ID™?
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.
PROCESS B. User enrolls at the web application form. Application is validated and approved and the user receives an email with a Digi-ID™ container package (containing both the public and Private Key). A second activation email containing a password is sent and used in opening the package to install the Digi-ID™ on the device (PC Registry, Smartcard, USB Token or other suitable Digi-ID™ storage media device). This is an example of an Export Package Method.
PROCESS C. User receives a Smartcard, USB Token or any other Digi-ID™ storage media device with the Digi-ID™ pre-installed. The user completes the web application form. The Private Key is not exportable. Application is validated and approved and the user receives an email with a password to activate the device. This is an example of a Fused Package Method.
PROCESS D. User receives a pre-printed Smartcard with their photograph and other details and follows METHOD A to complete the process. This is an example of a Fused Process Method with High User Protection.
PROCESS E. A security printed P.I.N. number is delivered via registered courier or postal service. This is the same procedure as in METHOD B except that the user must enter the P.I.N. number when enrolling at the web application form stage. This is an example of an Export Package Method.
PROCESS F. Parts of METHOD A and Method E combined except that the P.I.N. number is also required when installing the Digi-ID™. This is an example of a Fused Process Method with High User Protection.
As stated, these are just some issuing processes and parts of one process can be combined with parts of another to meet the Certificate Policy requirements.
[1] The principal difference between Digi-CA™ Service Xs, Xp and Xg is the level of integration and customization you require. For example, Digi-CA™ Service Xs is provided as a standard Service and there is no customization or integration offered. The Digi-CA™ Service Xp offers language localization of the Digi-CA™ [2] Control Centre and the end user interfaces and Xg could be a highly integrated Service involving various databases, synchronization and other features.
There are seven versions of Digi-CA™ Service, each with self-explanatory names:
2 Digi-ISP Service™ - SSLs for ISPs and ICTs
3 Digi-IPSec Service™ - is for IPSec Certificates
4 Digi-Access™ [7] Service - provides two factor authentication [8]
5 Digi-Mail™ [9] Service - provides secure email [5]
6 Digi-ID™ Service - is for multi-use Digi-IDs™
7 Digi-CA™ Service - hosted and managed Digi-CA™
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 [5] it issues and the degree of integration and customization required.
Digi-Access™ uses Digi-IDs™ to authenticate individual users to the server and all web server software (even OEM versions like Oracle’s®) work with it. Within a few hours, 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 ‘bundled’ in most web browsers).
[1] Digi-Access™ [7] 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 favor, tokens are easy for the user to understand (it’s just a more powerful password) but the initial and ongoing costs are expensive. Tokens do provide good two factor authentication, but that’s it.
More and more organizations 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.
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 Digi-ID™ [10], 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 organization 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 Digi-IDs™ designed to provide the secure email [5] you need and as it comes from the TRoot, it will work in either a closed or an open user group.
The Digi-ID™ Service is used when you have more than a single requirement. You might need Digi-SSL™ and Digi-Access™ or any combination of the Services. With the Digi-ID™ Service, each service you require is configured according to your precise requirements and tested for with you before activation.
Digi-CA™ Service is where you actually purchase the Digi-CA Server™ software but we host it for you. This is particularly of use to organizations 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.
All you require is a single internet enabled PC with Internet Explorer® 5.5+ and to decide whether to store the Digi-ID™ used to access the system on a Digi-Card™, a Digi-Token™ or in the Certificate Store of that PC.
[1] The principal difference between Xs, Xp and Xg in each case relates to the degree of integration and customization 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 weeks and even months or years.
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.
[1] The basic requirement for every Digi-CA™ Server installation is the same. As more sophisticated environments arise for Digi-CA™ Server Xp or Digi-CA™ Server Xg, the requirements increase accordingly.
[1] You can own and operate a Digi-CA™ system without ever putting in place any statutory documents or standards [11] compliance [11] and many organizations because their application is commercial and doesn’t need third part accreditation. ‘Best Practice’ means you should consider having a Certificate Policy and we would recommend the following:
[1] The Certificate Policy for the Digi-CA™ [2] 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. As you will see in Section 7, there is a standard recognized format for writing your Certificate Policy but we suggest that you don’t need to follow this RFC format unless your CA requires certification [11] or accreditation. The Digi-CAST1™ Team will advise you on the best approach for your requirements.
In sub section 2.5.7.3, the Certificate Policy 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 Certificate Policy is agreed before the Digi-CA™ is operational and all Digi-IDs™ must then be deployed in accordance with the Certificate Policy.
Links:
[1] https://www.digi-sign.com/downloads/download.php?id=digi-ca-pdf
[2] https://www.digi-sign.com/digi-ca
[3] https://www.digi-sign.com/certificate+authority/traditional+ca
[4] https://www.digi-sign.com/digital+document
[5] https://www.digi-sign.com/digital+certificate
[6] https://www.digi-sign.com/digi-ssl
[7] https://www.digi-sign.com/digi-access
[8] https://www.digi-sign.com/two+factor+authentication
[9] https://www.digi-sign.com/digi-mail
[10] https://www.digi-sign.com/digi-id
[11] https://www.digi-sign.com/compliance/introduction
[12] https://www.digi-sign.com/service/digi-cast
[13] https://www.digi-sign.com/trust+centre
[14] https://www.digi-sign.com/demos/digi-ca+presentation
[15] https://www.digi-sign.com/support/digi-ssl/generate+csr
[16] https://www.digi-sign.com/aacd
[17] https://www.digi-sign.com/aacd/validations
[18] https://www.digi-sign.com/demos/aacd
[19] https://www.digi-sign.com/ssl+certificate
[20] https://www.digi-sign.com/digi-code
[21] https://www.digi-sign.com/digi-ca/time+stamp
[22] https://www.digi-sign.com/repository/certificate+practice+statement
[23] https://www.digi-sign.com/e+passport
[24] mailto:bob.smith@digi-sign.com
[25] mailto:mary.brown@domain.com
[26] mailto:mylissa.monton@hostname.com
[27] http://www.digi-sign.com/demos/digi-ca