The Core Components of Entrust/PKI v5

IT-Secure.
com Technical comment

Core Components of the Entrust/PKI
The Core Components of Entrust/PKI v5
Classification Version and Date Author Comments and Questions to
Technical Comment for Public Distribution 2.0, September 20th, 2001 Luke OConnor, IT-Secure.com luke.oconnor@it-secure.com
SUMMARY There are many documents and standards, and more recently books, that describe the general components of a Public Key Infrastructure (PKI), including Certification and Registration Authorities, a Directory, a CA Database, and a Personal Security Environment for client certificates. The impression such documents give is that we should expect a noticeable degree of uniformity in the architectures and products being offered by the main PKI vendors. While there is agreement on the basic components, the inherent complexity of a commercial PKI solution almost guarantees that vendors will produce solutions with essentially unique features. This document gives an overview of the major components of the Entrust/PKI. The contents refer to Entrust version 5, but most technical statements also apply to Entrust version 6. We focus on the certificate and key life cycle management functions of the Entrust/PKI, since by examining these processes we are best able to understand the interworkings of the Entrust/PKI components.
2005 IT-Secure.com AG, Rmlangerstrasse 9, Postfach 1105, 8105 Watt, Zurich, Switerzerland. Tel: +41 (0)1 817 3690; Fax: +41 (0)1 817 3693.
Email: info@it-secure.com; Web: http://www.it-secure.com. Page 1
IT-Secure.com Technical comment

Contents
2 3 Introduction .................................................................................................3 Managed Certificates..................................................................................4
3.1 3.2 3.3 3.4 3.5 General Architecture ............................................................................................. 4 Registration and Issuance .................................................................................... 7 Certificate/Key Update .......................................................................................... 9 Certificate/Key Recovery .................................................................................... 10 Other managed CKLCM functions with Entrust................................................... 11
Unmanaged Certificates ...........................................................................13

4.1 General Architecture ........................................................................................... 13 4.2 Web Server Issuance and Registration............................................................... 14 4.3 Client Registration and Issuance ........................................................................ 15
5 6
Conclusion ................................................................................................17 Referenced Documents ............................................................................18

Introduction
In this document we provide a brief introduction to the core components of the Entrust/PKI, as implemented in version 5. Most technical statements concerning these components apply to Entrust version 6, and will also be accurate for future versions unless the vendor undertakes a major architectural shift in its core product offering. The general functions of a certificate/key life cycle management (CKLCM) sub-system are shown in Figure 1, adapted from the description provided in [Ada99]1. These functions are invoked as a certificate/key passes from issuance, to an operational state, and then finally to cancellation. To describe the core components of the Entrust/PKI we have chosen to explain how some of the functions listed in Figure 1 are implemented in the Entrust/PKI. We have used standard Entrust documentation and training material as the sources of technical information. Naturally enough there are many other Entrust/PKI components not considered in this document, such as Unity, Entrusts web browser plug-in. We focus our attention on the core components that would be installed as part of purchasing Entrust/PKI. Further, additional components such as Unity must comply with the basic architecture of the Entrust/PKI, so it is important to understand the functions of these basic components when a more complex Entrust-based PKI is to be developed.
Figure 1: CKLCM functions in a PKI.
A tag of the form [Ada99] denotes a reference listed in section 6.

Managed Certificates
As defined by the Entrust product family, a managed certificate is a certificate for which the Subscriber has dedicated software in their Personal Security Environment (PSE) to provide automatic CKLCM functions. This dedicated software is called Entrust/Entelligence [EE]2, or simply Entelligence, and is the basis for providing certificate-enabled applications to client (subscriber) desktops. Entelligence is responsible for interfacing clients to other Entrust/PKI components. Entrust defines an enterprise certificate to be a pair of managed certificates issued to a subscriber, one of which is used for encryption operations while the other is reserved for signing operations. The management of the certificate pair is not synchronized the certificates are not updated together for example but are in fact managed according to different encryption and signing policies set for the subscriber. For example, the signing key may be valid for six months while the decryption key may be valid for one year. This information, and other details concerning the subscriber, is stored in a policy (attribute) certificate for the subscriber (type). An enterprise certificate (pair) is the standard certificate type in Entrust to issue when a subscriber, usually a natural person, requires automatic management (CKLCM functions) of separate keys pairs for encrypting and signing. Requiring distinct keys for signing and encrypting is referred to as the dual-key pair model.3 To simplify the discussion given below, when using enterprise certificates the private key supporting digital signatures is referred to as the signing private key, while the corresponding certificate is referred to as the verification certificate. Similarly for confidentiality we define the decryption private key and the encryption certificate. In Entrust v5 the dual-key pair model can only be implemented via enterprise certificates, which implies that each certificate of the pair is managed and that Entelligence must be present at the subscriber desktop to perform the certificate management. Is it currently not possible to be issued with an unmanaged enterprise certificate pair, or to have a decryption private key managed and a signing key unmanaged (or vice versa). Thus when using Entrust, we see that the terms managed certificate pair, dual-key pair and enterprise certificate (pair) all essentially refer to the same concept.
3.1
General Architecture
The general architecture for Entrust/PKI v5 is shown in Figure 2. In this case managed (enterprise) certificates are issued to subscribers (Entrust users or clients) but the core Entrust/PKI components will be the same even if unmanaged certificates are issued to subscribers. The core components of the Entrust/PKI are Entrust/Authority, Entrust/RA and the Entrust/Authority Database. Each of these components is described briefly in Table 1 and are normally packaged together. A directory solution is also required, which may be purchased from Entrust or a third-party. Entelligence is required to support managed certificates but is not required for unmanaged certificates.
Entelligence is only supported on Windows and Mac PowerPC platforms. The product predecessor of Entelligence, called Entrust/Client, was supported on various Unix platforms but is now discontinued. In practice then, when we speak of a subscriber PSE with Entelligence, this almost certainly implies a Windows desktop. 3 See [Ada99] for further discussion on the dual-key pair model.

Entrust/PKI 5.0 Components

Entrust/Authority Entrust/RA Entrust/Entelligence
Functions
Create certificates for all Entrust users Create encryption keys for all Entrust users Manage a database containing Entrust user information to allow key recovery Enforces organisational security policies Graphical user interface to Entrust/Authority and other components of the PKI Many CKLCM functions can be initiated from the Entrust/RA May be run over a network connection (need not be on the same machine as Entrust/Authority). Communication to Entrust/Authority is secured. Interfaces to Entrust/Authority to provide seamless CKLCM functions for Entrust users such as certificate/key update, certificate validation and the creation of signing keys. Entrust users are also provided with an interface for cryptographic operations Stores information about Entrust users and the PKI itself. This information is encrypted with passwords of the Entrust Master Users. The stored information includes the CA signing key, decryption private keys, encryption certificates all Entrust users, and policy information on Entrust administrative roles. Default installation is an Informix Database LDAP compliant directory containing an entry for each Entrust user The directory contains user certificates, status information (CRLs and ARLs), policy information (attribute certificates) and various other information Default installation is an i500 Peer Logic Directory
Entrust/Authority Database
Directory
Table 1: A brief description of core Entrust/PKI components.
Entrust Authority performs the functions associated with the traditional notion of a Certificate Authority (CA). The three master users are configured at installation and have control over important administration functions such as stopping and starting Authority, and backing-up/restoring the Database. Authentication of master user operations is password-based and performed through a dedicated command-line interface. Consequently CKLCM functions are not required for these users. The Authority also establishes a separate identity, the CA User, for protocol interactions with other PKI components that require authentication. For example, the Certificate Management Protocol (CMP [RFC2510]) is used to exchange information between the Authority and instances of Entrust/RA and subscriber PSEs for managed certificates. We note that the CA user keys are distinct from the CA signing key used to issue certificate and CRLs/ARLs. Other administrators, besides the CA User, are provided with managed certificates. The private keys associated with the managed (enterprise) certificate pair, along with other information such key histories, are stored in a data structure known as a profile. A subscribers profile is the most important aspect of their PSE since, for example, it contains all their private keys past and present.4 Profiles are
Unfortunately the format of the Entrust profile is proprietary and undocumented. Recently a feature has been added to permit profile information to be exported to the more popular PKCS #12 format [PKCS12]. 2005 IT-Secure.com AG, Rmlangerstrasse 9, Postfach 1105, 8105 Watt, Zurich, Switerzerland. Tel: +41 (0)1 817 3690; Fax: +41 (0)1 817 3693.

password-protected but may also be stored on hardware tokens.5 A profile is created for a subscriber as a consequence of being issued a managed (enterprise) certificate in fact managing the certificate is largely about maintaining up-to-date key pairs for the subscriber in their profile. The CA User identity is issued a profile while the Master Users are not issued with profiles.
Figure 2: Entrust v5 Core PKI Architecture (managed client)
Day-to-day administration of subscribers is done via the Entrust/RA graphical-user interface (GUI). Using Entrust/RA requires an initial logon. The user requesting the logon must specify a subscriber identity, a profile for that identity and the password to open the profile. Secure interaction between Entrust/RA and other components of the Entrust/PKI will be protected using the subscriber keys and identity presented at logon. The First Officer and Security Officer are two default identities (roles) created at installation, issued with certificates and profiles for accessing Entrust/RA functionality. Figure 2 shows an instance of Entrust/RA on a machine separate to the host for Authority (lower left hand
The entire profile will not be stored on the token since it contains all the certificates that a subscriber has been issued. Typically a symmetric key management scheme defined by the token is used to store the majority of the profile encrypted on disk.

corner), used by the Security Officer role. However, there will always be an instance of Entrust/RA running on the Authority host. In typical descriptions of PKI architectures, Registration Authorities (RA) are optional components designed to assist in one or more registration processes (RPs) for the PKI. An RA is a component distinct from other PKI components, in particular, distinct from the issuing CA it is associated with. An RA often has no administrative rights as such in the PKI, and usually acts as an intermediary between a certificate applicant and an issuing CA. The Entrust/PKI system does not have a component corresponding to this type of functionality. In the Entrust/PKI system, the Entrust/RA component is the main GUI interface to a CA (Entrust/Authority) and as such, can be used to add users, change keys, recover users and so on. To understand the role of Entrust/RA it is best to consider a CA as a distributed application and Entrust/RA to be one distributed component of the CA. It is for this reason that Entrust/RA users must logon and have their actions authenticated using their profile.
3.2
Registration and Issuance
We now consider the process behind registering a user (subscriber) and issuing them with a managed certificate. This process is represented in Figure 3, where it has been broken down into 6 steps and a few sub-steps. The outcome of the process is to create a new Entrust user with a certificatepopulated directory entry and to deliver a profile securely to the users (subscribers) PSE. The profile will be delivered into a PSE that must include Entelligence. The process begins by a Security Officer (or another user with similar privileges) logging on to Entrust/RA and requesting the creation of a new user and an enterprise certificate for the user. There is a default policy specifying the characteristics of an enterprise certificate, such as which keys and algorithms should be generated and the validity period of the corresponding certificates. The validity period for the signing private key is expressed as a percentage of the validity period for the corresponding signature verification certificate. A typical default setting would be to have the signature verification certificate valid for 3 years (36 months) and the corresponding private signing key valid for 33% of this time (in other words, one year). Thus, in the first year after issuance signatures can be created with the signing key and verified with the corresponding verification certificate. In the remaining two years of the validity period, signatures created in the first year can still be verified but no new signatures can be created with the given signing key. A new signing key is issued to the user after the first year so that their ability to sign is uninterrupted. This policy on signatures and signing keys is enforced solely by the CKLCM sub-system of Entrust. There is an X.509v3 certificate extension available for the purpose of limiting the lifetime of a certificates private key, but the PKIX Internet X.509 certificate profile [RFC2549] recommends against its use, and Entrust respects this recommendation. 6 When the current signing key of a user nears expiration, a new signing key/verification certificate pair is generated (CKLCM update function) and added to the users profile. This operation does not require an update to certificates in the users directory entry, as explained below. Subsequent signatures are made with the new signing key stored in the users profile.
No reason is given to support the recommendation (see section 4.2.1.4 of [RFC2549]).

Figure 3: Registration and Issuance of a Managed Certificate
Returning to Figure 3, the Security Officer typically accepts the default policy settings for an enterprise certificate and then gives their password (again) to initiate the process of creating a new Entrust user. The Authority receives the request (step 2), creates a directory entry and returns two parameters the Security officer (through the Entrust/RA GUI) called a reference number and an activation code. At this point the user has the Entrust status of inactive, as shown in the Entrust/RA GUI. The reference number and an activation code are passed to the user as part of the registration process, by say email or given in-person (step 3). The user requests Entelligence to create a profile and presents these parameters to complete the registration process. The signing private key is generated in the users PSE, and a certificate request is passed to the Authority. The Authority creates the verification certificate and also generates a decryption private key, backs this key up, creates the corresponding encryption certificate and writes it to the directory (step 5). Note that no copy of the verification certificate is written to the directory. Copies of the verification certificate, decryption private key and encryption certificate are returned to the user, and stored in the users profile (step 6). The user now has Entrust status active. As the verification certificate is only stored in the users profile and not in the directory, the operational assumption is that this certificate will be sent to each entity that needs to verify a signature produced by the user. For example, the secure email protocol S/MIME [SMIME] supports a feature to attach the verification certificate to signed

mail. More generally, the common PKCS #7 format [PKCS7] also supports the inclusion of relevant certificates along with data that is signed and/or encrypted. Thus in considering the issuance of an Entrust managed certificate we have encountered each of the CKLCM functions outlined in the issuance part of Figure 1.
3.3
Certificate/Key Update
One of the main features of Entrust enterprise certificates is the essentially automatic (minimal user involvement) in CKLCM functions. In this section we consider the CKLCM function of key update, which is the process where a given subscriber certificate expires according to its assigned validity period, without need for recovery or revocation during this period. The point is that this process should be, as much as possible, transparent to users (subscribers). Users should experience continued uninterrupted encryption/decryption and signing/verification operations over the period of time that they are subscribers in a given PKI.
Figure 4: Certificate key update with Managed Certificates

Figure 4 shows key update as a four-step process. We note that while the profile supports keys for signing and decryption, these keys and their corresponding certificates will be managed separately since their associated Entrust policies will be different. Typically a signing private key will need to be updated yearly, while a decryption private key will be updated less frequently, say every two years. Administrators are free to configure these private key life times as desired, but often the life time of the signing private key is relatively short, and will need to be updated more frequently than the decryption private key. To ensure that the user always has valid certificates/keys for signing and encrypting, it is prudent to attempt update operations before certificate/key expiration is imminent. Entrust supports the notion of a transition period, which specifies the point during the current validity period of a certificate/key that the CKLCM sub-system can begin attempting key update. The transition period is expressed as a percentage of the certificate/key validity period, and a suggested default is 50%. Once Entelligence detects that the transition period for a given certificate/key has been entered, a key update operation will be performed the next time the user logs on to Entelligence. As with initial registration, updated private signing keys are generated in the users PSE while updated decryption keys are generated and backed-up at the Authority. A new certificate is always created by the Authority and returned to the users profile as the result of a successful update operation. If the new certificate is an encryption certificate it is used to overwrite the existing certificate of this type in the directory entry for the user. It is important to note that the users directory entry will only ever have one certificate present at any given time, and this is the most recently generated encryption certificate for the user. The key update operation is performed as (secure) exchanges between the users PSE and the Authority, and does not involve other administrators or the Entrust/RA product. Apart from logging on to Entelligence, the key update operation is transparent to the user.
3.4
Certificate/Key Recovery
Another important CKLCM function is key recovery, activated in the event that subscriber no longer has access to some or all of their keys. Key recovery for an Entrust user includes this notion of recovery but is broader in the sense that it actually entails recovery of the users profile. With respect to Entrust, perhaps a more informative term would be PSE or profile recovery, but for the purposes of this document we will use key recovery in this enhanced sense. Key recovery requires that Entelligence be functioning on the user desktop, and if for some reason this is no longer the case then it must be reinstalled. Typical causes for key recovery include the user losing or forgetting their profile password, or the user suspecting compromise of keying material contained in the profile. Naturally enough key recovery is not an automatic CKLCM function and is in fact usually initiated at the request of the user to be recovered. As shown in Figure 5, the user contacts an administrator and requests key recovery (of their profile). As with registration, the Authority is then contacted and generates a new reference number and activation codes, which are passed back to the administrator and then to the user, potentially using some out-of-band mechanism. The user selects the key recovery option from Entelligence (which does not require a log on) and enters the reference number and activation code. This causes the old profile to be transferred from the Authority to the users PSE and the user also generates a new signing key. The Authority creates a corresponding verification certificate which is returned to the user and written into their profile. A new encryption certificate is not gener-

ated as a result of key recovery, and if the current decryption key is suspected of compromise it must be revoked separately.7 Alternatively, the Authority can generate a new profile and password for the profile which is passed back to the administrator, and then to the user. The user completes key recovery by logging on with the new password and the new copy of their profile.
Figure 5: Key Recovery with a Managed Client
3.5
Other managed CKLCM functions with Entrust
In the previous subsections we have given details concerning the issuance, key update and key recovery features of Entrust. The other CKLCM functions follow a similar flavour of interaction between Entelligence, the Authority and potentially an administrator. The central piece of the managed client environment is the profile, and Entelligence is used to synchronize the information contained therein
The author must check this point as there is a conflict between statements in the official Entrust Administration Guide and information received at an official Entrust training course. The course instructor stated that new encryption keys are also generated as a part of key recovery. 2005 IT-Secure.com AG, Rmlangerstrasse 9, Postfach 1105, 8105 Watt, Zurich, Switerzerland. Tel: +41 (0)1 817 3690; Fax: +41 (0)1 817 3693.

with other components of the PKI, mainly the Authority and the Directory. Please consult the Entrust administration Guide for more information (see [AENT] for example).

Unmanaged Certificates
We now discuss the some CKLCM functions associated with unmanaged certificates in the Entrust PKI v5 environment. We will consider the general architecture for this certificate type and then how certificates are issued to web servers and web browsers as examples of how the environment functions.
Figure 6: Entrust v5 Core PKI Architecture (unmanaged client).
4.1
General Architecture
The general architecture shown in Figure 6 is similar to the general architecture for managed certificates. The properties of the Authority remain the same, but the user in this case has no specific Entrust software resident in their PSE. In fact the PSE will be provided by the host operating system (say Windows) or by a certificate-enabled application on the client (say Netscape). A new PKI component shown is the Web Connector (WC) product, that runs as a CGI script on a web server which connects directly to the Authority. WC is essentially a web front-end for obtaining certificates for web servers and web browsers of users. When the users browser is Internet Explorer, the user acquires a certificate that is written in the Microsoft system-wide certificate store. This store can be programmed

against using MS CAPI [MSCAPI] to obtain cryptographic services based on this and other certificates, as well as having the certificates available to other standard application such as Outlook for S/MIME operations. In the case that the browser is Netscape, the user certificate can be retrieved and written to file in a standard format, where it can be imported to certificate-enabled applications as required. We note that the WC product is not required to produce unmanaged certificates, but rather WC represents a component of a particular registration process to issue unmanaged certificates. WC is a convenient tool to issue certificates to subscribers that takes advantage of existing certificate support on subscriber desktops.
4.2
Web Server Issuance and Registration
Before unmanaged clients can obtain certificates via WC, the web server hosting WC must itself have a certificate for the purposes supporting SSL sessions. The process of issuing a web server with a certificate is shown in Figure 7. Traditionally web servers run as stand-alone certificate-enabled applications, as do the web browsers that they serve. Apart from implying manual certificate management, this also means that no certificate validation is performed at the server when SSL client authentication is required, and no validation of the server certificate is performed if the client is unmanaged. Be that as it may, this is still a popular method for the provision of security services in web applications. 8 As with managed certificates, an administrator initiates the creation of a new web server certificate. The Authority creates an inactive user of type web server, and issues a reference number and activation code which are passed to the web server via some out-of-band method. The web server then generates a private key and a PKCS #10 request [PKCS10] for a corresponding certificate. This request and the received reference number and activation code are entered in the WC interface.9 The Authority creates a web server certificate from the PKCS #10 request and returns this certificate (along with its certification path) to the WC interface. The certificate is cut from the WC interface and pasted into a server window that accepts and stores the certificate. The server can now support server authenticated SSL connections, but to maintain this service the web server must request another certificate when this one expires.
This may change after a recent incident where Verisign mistakenly issued a pair of code signing certificates to a person who falsely claimed to be a Microsoft employee. Since there was no direct revocation method available (servers and browsers dont read CRLs), patches had to be applied to manually reject these rogue certificates. 9 Using Netscape for example, the certificate request must be cut from one window and pasted into a WC window. 2005 IT-Secure.com AG, Rmlangerstrasse 9, Postfach 1105, 8105 Watt, Zurich, Switerzerland. Tel: +41 (0)1 817 3690; Fax: +41 (0)1 817 3693.

Figure 7: Obtaining an unmanaged certificate for a web server.
4.3
Client Registration and Issuance
After a web server has been issued with a certificate, a client can connect to WC and request a certificate using an SSL connection to the web server hosting WC. The steps for obtaining a certificate are similar to those for the server, and are shown in Figure 8. Once again WC returns the new certificate (and its certification path), which is stored automatically. The client must request another certificate when this certificate expires.

Figure 8: Obtaining an unmanaged certificate for a client through WC

Conclusion
This paper has provided an overview of the Entrust/PKI through a presentation of its core architectural components, and how these components interact in the course of standard certificate and key life cycle management operations. While the Entrust/PKI can issue unmanaged certificates, the focus is clearly on supporting managed certificates in version 5. The creation and support of certifcates through subscriber profiles is the dominant consideration in the Entrust/PKI architecture. While many aspects of the Entrust/PKI rely on standard formats and protocols, the subscriber profile remains a proprietary data structure. In Entrust/PKI version 6 it is possible to export portions of the profile to the more common PKCS #12 format. The profile implements not only a managed certificate, but a pair a Entrust enterprise certificate to enforce separate certificates for signing/verification and encryption/decryption operations. Since verification certificates are only stored in profiles, browsing the directory only reveals one certificate issued to each subscriber. It is the experience of the author that many people who use or administer Entrust are not aware or do not fully understand the meaning of an enterprise certificate. Perhaps are better name would be an enterprise certificate pair. One experienced administrator that the author spoke to claimed that an enterprise certificate was implemented as a single certificate with two public keys included in one certificate. While this might be a reasonable conclusion to make from a casual reading of Entrust documentation, the X.509 standard explicitly states that the public key attribute of a certificate is single-valued. Currently Entrust subscribers can either be issued with one (unmanaged) certificate, or two (managed or enterprise) certificates. From the viewpoint of cryptographic operations, this distinction is based on whether signing/verification and encryption/decryption operations are to be handled by a single key pair or separate key pairs. Since signing keys have different life cylce requirements to decryption keys, for example with respect to key recovery, it is sensible to support distinct key pairs for a subscriber. However it is not clear how the Entrust architecture will adapt to the possibility of a subscriber requiring more than two key pairs. It seems likely that a future PKI requirement will be to reserve a key pair specifically for legally binding signature operations, perhaps protected by a smart card. A subscriber will also probably need another signing key pair for more common authentication operations such as SSL client-side authentication, though this signing operation need not have any long term legal consequences. Thus it is possible that a subscriber will require three key pairs: encryption/decryption for confidentiality, signing/verification for authentication and signing/verification for legal purposes. It is not clear how easily such a requirement could be incorporated into the current Entrust/PKI architecture.

6
[Ada99]
Referenced Documents
C. Adams, S. Lloyd. Understanding Public Key Infrastructure: concepts, standards and deployment considerations, Macmillan Technical Publishing, 1999. ISBN 1-57870-166-x. Publisher information at http://www.newriders.com/books/title.cfm?isbn=157870166X. Administering Entrust/PKI 5.0 on Windows NT. See Entrust Entelligence product page at http://www.entrust.com/entelligence/features.htm. Microsoft CryptoAPI version 2.0. Microsoft Developer Network (MSDN) documentation. Available online at http://msdn.microsoft.com/library/default.asp?url=/library/enus/security/hh/crypto/portalapi_3351.asp. RSA Laboratories. PKCS #7 Cryptographic Message Syntax Standard, version 1.5, 1993. Available at http://www.rsasecurity.com/rsalabs/pkcs/index.html. RSA Laboratories. PKCS #10 Certification Request Syntax Standard, version 1.7, May 2000. Available at http://www.rsasecurity.com/rsalabs/pkcs/index.html. RSA Laboratories. PKCS #12 Personal Information Exchange Syntax Standard, version 1.0, June 1999. Available at http://www.rsasecurity.com/rsalabs/pkcs/index.html. C. Adams, S. Farrell. Internet X.509 Public Key Infrastructure Certificate Management Protocols, Internet Engineering Task Force (IETF) RFC 2510, Security Area, Public-key Infrastructure (X.509) working group, March 1999. Available online at http://www.ietf.org/rfc/rfc2510.txt. R. Housley, W. Ford, W. Polk, and D. Solo. Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Internet Engineering Task Force (IETF) RFC 2549, Security Area, Public-key Infrastructure (X.509) working group, January 1999. Available online at http://www.ietf.org/rfc/rfc2549.txt. See the IETF S/MIME security area http://www.ietf.org/html.charters/smime-charter.html. working group homepage at
[AENT] [EE] [MSCAPI]
[PKCS7] [PKCS10] [PKCS12] [RFC2510]
[RFC2549]
[SMIME]

About the Author
Luke OConnor received his PhD from the University of Waterloo in 1992, where his thesis topic was the design and analysis of block ciphers. After working briefly for Certicom (then called Mobius), Dr. OConnor moved to the Security Group at the Distributed System Technology Centre, Australia, a group that he eventually lead. In 1996 Dr. OConnor accepted a position at the IBM Zurich Research Laboratory, Switzerland. He worked on several projects in cryptography and security including the MARS block cipher, the IBM submission to Advanced Encryption Standard (AES) program of the US government. In 2000 Dr. OConnor joined the Unisys European Security Centre of Excellence, concentrating on European PKI projects. In 2001 Dr. OConnor joined IT-Secure as a Senior Security Consultant, to focus his efforts on the PKI and security market in Switzerland.

The Core Components of Entrust/PKI v5

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

The Core Components of Entrust/PKI v5

Hochgeladen von

Copyright:

Verfügbare Formate

IT-Secure.

com Technical comment

The Core Components of Entrust/PKI v5

Classification Version and Date Author Comments and Questions to

IT-Secure.com Technical comment

Unmanaged Certificates ...........................................................................13

Conclusion ................................................................................................17 Referenced Documents ............................................................................18

IT-Secure.com Technical comment

Figure 1: CKLCM functions in a PKI.

A tag of the form [Ada99] denotes a reference listed in section 6.

IT-Secure.com Technical comment

IT-Secure.com Technical comment

Entrust/PKI 5.0 Components

Table 1: A brief description of core Entrust/PKI components.

IT-Secure.com Technical comment

Figure 2: Entrust v5 Core PKI Architecture (managed client)

IT-Secure.com Technical comment

Registration and Issuance

No reason is given to support the recommendation (see section 4.2.1.4 of [RFC2549]).

IT-Secure.com Technical comment

Figure 3: Registration and Issuance of a Managed Certificate

IT-Secure.com Technical comment

Figure 4: Certificate key update with Managed Certificates

IT-Secure.com Technical comment

IT-Secure.com Technical comment

Figure 5: Key Recovery with a Managed Client

Other managed CKLCM functions with Entrust

IT-Secure.com Technical comment

IT-Secure.com Technical comment

Figure 6: Entrust v5 Core PKI Architecture (unmanaged client).

IT-Secure.com Technical comment

Web Server Issuance and Registration

IT-Secure.com Technical comment

Figure 7: Obtaining an unmanaged certificate for a web server.

Client Registration and Issuance

IT-Secure.com Technical comment

Figure 8: Obtaining an unmanaged certificate for a client through WC

IT-Secure.com Technical comment

IT-Secure.com Technical comment

[AENT] [EE] [MSCAPI]

[PKCS7] [PKCS10] [PKCS12] [RFC2510]

IT-Secure.com Technical comment

About the Author

Das könnte Ihnen auch gefallen