Understanding and Designing a Public Key Infrastructure
An Introduction to the Public Key Infrastructure (PKI)
It has grown more important to ensure the confidentiality and integrity for data communication where an organization's network contains intranets, extranets, and Internet Web sites. Because of the connectivity of networks today, an organization's network is exposed to unauthorized users who could possibly attempt to access and manipulate mission critical data or the confidential data of its clients. The need to authenticate the identities of users, computers and even other organizations, has led to the development of the public key infrastructure (PKI).
A public key infrastructure (PKI) can be defined as a set of technologies which control the distribution and utilization of unique identifiers, called public and private keys, through the utilization of digital certificates. The set of technologies that constitute the PKI is a collection of components, standards and operational policies. The PKI process is based on the use of public and private keys to provide confidentiality and integrity of an organization's data as it is transmitted over the network. When users partake in the PKI, messages are encoded using encryption, and digital signatures are created which authenticate their identities. The recipient of the message would then decrypt the encoded message. For a PKI implementation to operate, each computer in the communication process must have a public key and private key. The public key and private key pair is used to encrypt and decrypt data, to ensure data confidentiality. When two parties use a PKI, each one obtains a public key and a private key, with the private kept only being known by the owner of that particular key. The public key on the other hand is available to the public.
Before delving into the components and operations of the PKI, let's first look at what a properly designed and implemented PKI achieves:
- Confidentiality: A PKI implementation ensures confidentiality of data transmitted over the network between two parties. Data is protected through the encryption of messages, so even in cases where the data is intercepted; the data would not be able to be interpreted. Strong encryption algorithms ensure the privacy of data. Only the parties which possess the keys would be able to decode the message.
- Authentication: The PKI also provides the means by which the sender of the data messages and the recipient of the data messages can authenticate the identity of each other. Digital certificates which contain encrypted hashes are used in authentication, and to provide integrity.
- Integrity: Integrity of data is assured when data has been transmitted over the network, and have not been fiddled with, or modified in any manner. With PKI, any modification made to the original data, can be identified.
- Non-repudiation: In PKI, non-repudiation basically means that the sender of data cannot at a later stage deny sending the message. Digital signatures are used to associate senders to messages. The digital signature ensures that the senders of messages always sign their messages. This basically means that a particular person cannot, at a later stage, deny sending the message.
Understanding Cryptography and Encryption
To ensure that data is securely transmitted over the Internet, intranet, and extranet; cryptography is used. With PKI, you can define cryptography as being the science used to protect data. A type of cryptography, called encryption, uses mathematical algorithms to change data to a format that cannot be read, to protect the data. Encryption basically ensures that the content of a data message is hidden from unauthorized parties intercepting the message. A mathematical algorithm contains the method used to scramble the original message into ciphertext. A cryptographic key is utilized to either change plaintext (original message) to ciphertext (scrambled message) or to change ciphertext (scrambled message) to plaintext (original message). It is the ciphertext that is transmitted over the network. The message is decrypted into a readable format once it has reached the intended recipient.
As mentioned earlier, encryption is the type of cryptography that changes the original message to ciphertext. Encryption utilizes keys to encrypt and decrypt data. Longer complicated keys mean that data is more protected from interpretation by another person.
In Windows Server 2003, the cryptographic services utilize following encryption means:
- Block cipher: A block cipher basically divides the data into blocks, and encrypts each block in succession. Padding can be added to the last block. The majority of encryption methods utilize a block cipher.
- Streaming cipher: A streaming cipher utilizes a random number stream with cipher key, and encrypts a stream of bits.
In Windows Server 2003, support is included for the following encryption methods:
- RC2 and RC5: The RC2 and RC5 algorithms utilize the block encryption algorithms. Because the block encryption algorithms are used with variable block and key sizes, they are harder to decrypt, even when the intruder does know the original key sizes.
- RC4: The streaming encryption algorithm is used in RC4 with variable key sizes.
- Data Encryption Standard (DES): DES utilizes a block algorithm. Data is encrypted in 64-bit blocks, and a 40-bit or 50-bit key is used. DES was developed by IBM and the United States government. DES is considered an unsafe method to use!
- DESX: DESX was developed by Rivest of the RSA Labs. DESX places DES encryption within two XOR bit-wise replacement runs. Different keys are used.
- 3DES: 3DES offers more security than DES. Data is passed through the DES mechanisms thrice to produce the final output.
- Advanced Encryption Standard (AES): This is the newer encryption standard that utilizes the Rijndael algorithm. AES is expected to in the long run replace 3DES and DESX.
While there are many encryption methods which can be used to encrypt data, an encryption method is regarded as being one of the following types:
- Symmetric encryption: With symmetric encryption, the same key is used to encrypt and decrypt data. Symmetric encryption is also called shared key encryption. Symmetric algorithms have a fixed key length. The ability of the symmetric encryption algorithms to protect data is determined by the size of the key used in the particular algorithm.
- Asymmetric encryption: Asymmetric encryption is also called public key cryptography. The asymmetric algorithms use two keys which are mathematically connected. One key is used to encrypt data, and the other key is used to decrypt the data. The key used to encrypt data is called a public key. This key can be distributed publicly. The key which is used to decrypt the data is called the private key. The private key is secret, and is unique to a particular user. While the keys are indeed paired mathematically, you cannot determine the private key by hacking the public key.
Understanding Hashing Algorithms
The PKI utilizes hashing algorithms to provide data authentication and non-repudiation. A hashing algorithm is a complex mathematical algorithm, called a hash function, which is applied to a segment of the original message. This results in a fixed length output, called a hash value, which is unique to the original message. If the data is modified while being transmitted, the recipient is able to determine this because a single bit change results in many changes to the fixed length output of the hash. Digital signatures use the hashing technology to authenticate the identity of the sender. While a bigger hash means a more secure algorithm, performance is negatively impacted because these hashes take longer to create.
The hashing algorithms supported in Windows Server 2003 are outlined below:
- Message Digest 4 (MD4) and Message Digest 5 (MD5): MD4 and MD5 are RSA algorithms which both create a 128-bit output. Input is processed in 512-bit blocks. MD5 is used in Windows NT and Windows 2000 to hash the passwords of users. MD5 supports the Challenge Handshake Authentication Protocol (CHAP) for dial-in clients. MD5 is the stronger hash between the two hashing algorithms.
- Secure Hash Algorithm: SHA-1 also processes input in 512-bit blocks, but it creates a 160-bit output. This makes SHA-1 more secure than both MD4 and MD5. The algorithm is also faster than these two algorithms.
- Secure Hash Standard (SHS): The SHS has extensions to the SHA-1 standard with larger digest sizes, namely; SHA-256, SHA-384 and SHA-512.
The Components of Public Key Infrastructure (PKI)
The main functions that can be performed within a PKI are listed below:
- Publish certificates
- The enrollment of clients
- Create and use certificates
- Renew certificates that have expired
- Revoke certificates
To enable all of the above listed functions, the PKI consists of numerous policies, software and components that manage public and private keys, and certificates that authenticate users and verify data. Each component included in the PKI is discussed in the following section of this Article.
Digital Certificates
A digital certificate associates a public key with an owner. The certificate verifies the identity of the owner. A certificate cannot be forged because the authority that issued the certificate digitally signs the certificate. Certificates are issued for functions such as the encryption of data, code signing, Web user and Web server authentication, and for securing e-mail. Certificates in Windows XP and Windows Server 2003 are managed by the Data Protection API. When certificates are issued to a client, it is stored in the Registry and in Active Directory. You can also store certificates on smart cards. The information included in a certificate is determined by the type of certificate being used.
Certificates can contain all of the information listed below, or only some of the information listed below:
- The name of the user.
- The e-mail address of the user.
- The host name of the computer.
- The serial number of the certificate.
- The time for which the certificate is considered valid. The issuing Certificate Authority (CA) ensures that the serial number for each certificate is unique.
- The location of the certificate revocation list (CRL). The CRL is a list which stores the details of certificates which have been revoked.
- The CA's name that issued the certificate
- The purpose(s) for which the certificate can be utilized.
- Information on the policy which was used to initially authenticate the user of the certificate.
X.509 Standard
The X.509 standard, derived from the X.500 directory standard, defines digital certificates. It describes a certificate as the means by which the distinguished name of the user can be associated with the public key of the user. The distinguished name of the user is defined by a naming authority. The distinguished name is used by the issuing Certificate Authority (CA) as the unique name of the user.
The information included in an X.509 certificate is listed below:
- Version: This is the version of the certificate. Windows Certificate Authority (CA) servers issue the X.509 Version 3 certificates.
- Serial Number: A unique identifier assigned by the CA to the certificate.
- Signature Algorithm: This is the hashing algorithm used for the digital signature of the certificate, and is usually MD5 or SHA-1.
- Issuer: This is the Certification Authority that issued the certificate.
- Valid From: The date which the certificate was issued
- Valid To: This is the expiry date of the certificate.
- Subject: This is the distinguished name of the owner of the certificate.
- Public Key: This is public key which is associated with the private key.
- Thumbprint algorithm: This is the algorithm used to create the certificate hash.
- Thumbprint: The hash of the certificate which is used for positive identification of the certificate.
Certificate Authorities (CA)
A certificate authority (CA) is the trusted entity that issues digital certificates to users, computers or a service. An organization can have multiple CAs, which are arranged in a logical manner. A CA can be a trusted third party entity such as VeriSign or Thawte, or it can be an internal entity of the organization. An example of an internal CA entity is Windows Server 2003 Certificate Services. Windows Server 2003 Certificate Services can be used to create certificates for users and computers in Active Directory domains.
The tasks performed by a CA are listed below:
- Accepts the request for a certificate from a user, computer, application, or service.
- Authenticates the identity of the user, computer or service requesting the certificate. The CA utilizes its policies, and incorporates the type of certificate being requested; to verify the identity of the requestor.
- Creates the certificate for the requestor.
- Digitally signs the certificate using its own private key.
The process by which a user, computer, or service identifies itself to the CA is called registration. Registration can be automatically performed during the certificate enrollment process, or it can be performed by another trusted entity. An example of a trusted entity would be a smart card enrollment station. Certificate enrollment is the terminology used to refer to the process by which a user requests a certificate from a CA.
There are basically two type of CAs. The CA types are distinguished by the location in which they store their certificates:
- Enterprise CA: The enterprise CA stores the copy of its CA certificate in Active Directory. This CA type utilizes certificate templates to publish their certificates and certificate revocation lists (CRLs) to Active Directory. Enterprise CAs automatically responds to any certificate requests. This basically enables clients to access and obtain certificates, and locate them in their own local certificate stores. Because of these characteristics, enterprise CAs should not be used to issue certificates to any clients external to the enterprise.
- Standalone CA: A standalone CA stores information on its certificate locally, in a shared folder which can be accessed through a web URL. Standalone CAs depends on an Administrator to manually approve or deny any request sent for a certificate, by default. A standalone CA is typically used to issue certificates to users who are external to the organization.
CAs can be categorized into different trust models:
- Single CA trust model: In this model, one CA exists in the PKI. The CA server is basically a stand-alone server that does not exchange information with any other CA servers. The public key of the CA is distributed to users who need to use the CA for certificate requests.
- Hierarchical CA trust model: A hierarchical CA model exists when there is multiple CAs within the organization. This means is that the relationships between the CAs are hierarchical, as determined by the parent/child relationships that exist. In a hierarchical CA trust model, each CA is one of the following:
- Root CA: The root CA functions as the authority over all subordinate CAs located beneath it. It is basically the parent that issues certificates to the subordinate CAs beneath it. The root CA creates a self-signed certificate for itself. This is a certificate where the issuer and subject of the certificate are identical. With a hierarchical model, when a client trusts the root CA, it has to trust each subordinate CA located beneath the root CA. This is because they are issued certificates by the particular root CA.
- Subordinate CAs: There are two types of subordinate CAs in the hierarchical CA model, namely:
- Intermediate CAs: An intermediate CA is a subordinate CA which is located between a root CA and other subordinate CAs, called leaf CAs. What this means is that the intermediate CA is subordinate to the root CA, but is more high-ranking than leaf CAs. The function of an intermediate CA is to issue certificates to leaf CAs.
- Leaf CAs: The function of a leaf CA is to issue to certificates to users, servers and services who request CAs.
A certificate trust list (CTL) is a list that documents the trusted certificates of the enterprise. It is a list of root CAs which is trusted within the enterprise. Windows Server 2003 includes a predefined CTL which you can add CAs to, or remove CAs from. The benefit of using the Windows Server 2003 CTL is that you can automatically check certificates to this list. The Windows CTL is managed through Group Policy Objects (GPOs).
The Certificate Revocation List (CRL)
When a certificate is issued, the time for which the certificate remains valid is defined. There is however occasions when the CA can end the validity of the certificate through a procedure referred to as certificate revocation. A certificate is typically revoked when information included in the certificate has become invalid or untrusted. When the private key associated with the public key in the certificate is no longer secure or trusted, the certificate should be revoked without delay. The certificate revocation process is performed by the CA issuing the certificate revocation list (CRL), and it includes the serial numbers of those certificates which have been revoked.
CRLs can be categorized into the following types
- Simple CRLs: A simple CRL is a single file that grows as more revoked certificates are added to the list of certificates which have been revoked. A simple CRL stores the list of revoked certificates with the following information:
- Name of the CA
- The time which the CRL was issued
- The date/time when the following CRL is going to be published.
- Delta CRLs: With a delta CRL, a base CRL is initially sent to all affected entities. After this, periodic updates which are called deltas are sent to the entities. The deltas basically detail any updates that should be included.
The Online Certificate Status Protocol (OCSP) is also a means which can be used to determine whether a certificate is considered valid, and trusted. The OCSP process starts when a CA obtains a query, questioning the validity of a single certificate. The OCSP responder sends the response to the party that sent the request.
The information included in the response is listed below:
- The status of the certificate is identified as one of the following: Good, Revoked, Unknown.
- The time when the status of the certificate was last updated.
- The time when the status of the certificate is expected to be updated next.
- The time when the response was sent to the party that sent the request.
PKI Standards and Protocols
Standards and protocols is the set of integral components in the PKI which ensures that data is protected. The Public Key Cryptography Standards (PKCS) are listed below:
- PKCS #1, RSA Cryptography Standard: This standard describes data encryption with the RSA algorithm, and the syntax for RSA public keys and private keys. The public key syntax is for certificates and the private key syntax is for the encryption of private keys.
- PKCS #3, Diffie-Hellman Key Agreement Standard: The standard describes the Diffie-Hellman Key Agreement, which is a technology used to share secret keys between two entities. The secret key is used to encrypt data transmitted between the pair.
- PKCS #5, Password-Based Cryptography Standard: This standard describes the encryption of a string with a secret key which stemmed from a password. The output is an eight octet string.
- PKCS #6, Extended-Certificate Syntax Standard: This standard describes extended certificates. An extended certificate is an X.509 certificate that includes additional attributes.
- PKCS #7, Cryptographic Message Syntax Standard: This standard is the foundation for the Secure/Multipurpose Internet Mail Extensions (S/MIME) standard for digitally signed messages, and can be used in many different key management solutions.
- PKCS #8, Private Key Information Syntax Standard: This standard is similar to the PKCS #6, Extended-Certificate Syntax Standard, in that it also includes additional attributes, but with public key algorithms, for sending private key information.
- PKCS #9, Selected Attribute Types: This standard describes the attribute types which can be used in extended certificates, digitally signed messages, and private key information.
- PKCS #10, Certification Request Syntax Standard: PKCS #10 defines the syntax for the certificate requests which are sent to CAs.
- PKCS #11, Cryptographic Token Interface Standard: The standard describes an application program interface (API) for token devices such as smart cards, which can carry out certain cryptographic operations
- PKCS #12, Personal Information Exchange Syntax Standard: PKCS #12 defines the portable format (diskettes, smart cards) for storing and transmitting the private keys and certificates of users.
Certificate Policies
A certificate policy can be defined as the rule(s) which govern the manner in which a certificate can be used. In addition to the certificate policy describing how the certificate can be used, it also defines the relationship between the certificates and resources. A certificate practice statement (CPS) details the manner in which the CA intends to manage the certificates which it issues. It is recommended to use CAs that has CPSs. A certificate can also be issued under multiple certificate policies. In this case, a set of polices would define the processes and standards used to create and mange the certificates, another set of policies would be technical rules, and other policies would define security requirements.
Microsoft Windows PKI Components
In addition to the components just discussed, Windows includes four essential PKI components. Like the former components, these components each has a purpose, and performs a particular function within a PKI implementation. The Windows PKI components are outlined below.
- Microsoft Certificate Services: Windows Server 2003 includes Certificate Services which can be used to implement a PKI. Through certificate services, you can publish, issue, store and perform management tasks for certificates. The certificate services are considered a primary component of the Windows PKI because it provides the means for certificates and any policies associated with the management of certificates, to be centrally administered. While third party CAs such as VeriSign and Thawte can be used, the most cost effective solution for larger organizations that need a considerable amount of certificates issued, is to use a Windows PKI implementation.
- Active Directory: A Windows PKI implementation can use Active Directory to publish root CA certificates and to store PKI components. Through Active Directory, you can map certificates to user accounts, and control access to resources. Active Directory also enables centralized management through the creation of a public key Group Policy. A public key Group Policy enables you to stipulate which CAs is trusted, define PKI requirements for computers using the Windows PKI, and it also controls the auto-enrollment process and auto-renewal of certificates.
- CryptoAPI: The cryptoAPI enables programmers to develop software solutions which use encryption to communicate with the OS and other applications.
- CAPICOM: CAPICOM is a COM client which utilizes CryptoAPI and PKI to carry out cryptographic functions, such as authenticating and managing digital signatures, and data encryption for specific data.
New PKI Features in Windows Server 2003
Before delving into the planning and design phase of implementing a Windows Server 2003 PKI, lets first look at the new PKI features introduced with Windows Server 2003. The Windows Server 2003 improvements on the cryptography mechanisms included in Windows 2000 are listed below:
- Key archival and recovery is probably one of the most important new features in Windows Server 2003. Windows Server 2003 can store, and also re-issue encryption keys which are lost.
- The user auto-enrollment feature enables you to issue a User certificate when the user utilizes a Windows XP or Windows Server 2003 client to log on and authenticate to the domain. User certificates can be used for IPSec, S/MIME and EFS.
- For external CAs, the capability exists for a Windows Server 2003 client to use the Windows Update web site to verify the copy of the Root CA certificate when certificates issued by external CAs, have to be verified.
- Windows Server 2003 includes support for 3DES, which offers more security than DES, and it also includes support for the new Advanced Encryption Standard (AES). AES is the newer encryption standard that utilizes the Rijndael algorithm. AES is expected to replace 3DES and DESX.
- Windows Server 2003 includes support for the extended hashing algorithms defined in the Secure Hash Standard (publication FIPS 180-2). These are the SHA-256, SHA-384, and SHA-512 hashing algorithms which are more secure than SHA-1.
- Smart cards have also been enhanced. Smart cards can be utilized to log on to a server through Remote Desktop.
- The Net and RunAs utilities include the ability to operate with smart cards.
- Certificate templates have been enhanced in Windows Server 2003 to support certificate updates or modifications. The Certificate Templates MMC is used to perform these modifications. The modifications that are supported are listed bellow.
- You can configure a certificate template for client auto-enrollment, and for key archival and recovery.
- You can configure application policies
- You can modify enrollment policy.
- You can duplicate and rename certificate templates.
- You can configure access control on a certificate template for enrollment by a user/computer.
- Another new feature is delta CRLs. Because Delta CRLs only distribute updates when changes occurs, less network resources are needed.
- With Windows Server 2003, you can use role based administration for the management of a CA. The roles defined in Windows Server 2003 are:
- The CA Administrator is the top-level administrator.
- The Certificate Manager is responsible for issuing certificates, and for managing certificates and permissions.
- The Auditor is responsible for managing auditing and the managing security log.
- The Backup Operator is much like the Backup Operations OS group.
- Enrollees are the users of the PKI.
Planning and Designing a Windows Server 2003 Public Key Infrastructure (PKI)
Typical to any network design, the initial step is the planning phase. With a PKI implementation, the planning phase should deal with the following aspects:
- Determining the security needs of organization.
- Determine and verify whether certificates are capable of providing that particular security need
- Determine what certificates to use.
- Determine which users, computers, applications and services are going to use the certificates.
With a PKI implementation using computers running Windows Server 2003, the computers can create certificates which support the following (remember this list in your planning):
- Digital certificates: Digital certificates are used to verify the identity of the person sending the message, file, or data.
- Encrypting File System (EFS) user certificates and recovery certificates: EFS enables users to store data in an encrypted form on disk. The PKI can be used for EFS encryption keys because it simplifies the management of EFS.
- IPSec: As is the case with EFS, you can configure the Windows Server 2003 IPSec implementation to use the PKI for its encryption keys.
- A PKI can be used to authenticate clients and servers who partake in Internet communication. Servers and clients would be able to identify one another.
- The PKI can also be used to secure the wireless LAN by authenticating users prior to granting them access to the network.
- Smart card logon can be used to authenticate the identity of users at logon.
- You can use the PKI to secure e-mail by using the recipient's public key to encrypt the message text.
The structure of the organization can possibly impact the PKI implementation strategy that you would use. These factors are noted below:
- The locations of offices
- Link speeds
- Security requirements
- Client OS compatibility issues
- External factors such as legal regulations.
- Physical and administrative resources
The process recommended for planning and designing a PKI implementation is discussed next.
1. Determine the certificate requirements
You have to define the certificate requirements for the network before you implement any PKI within your environment. This step typically involves identifying the different levels of security needed within the organization in relation to the location of users. It is recommended that you start a certificate practice statement (CPS). This is basically a running document used during the planning and implementation of a PKI that describes how a certificate policy is to be implemented. The implementation strategy should, needless to say, be suited to the architecture and operating processes of the organization.
A certificate practice statement (CPS) should minimally include the following:
- Information that identifies the Certificate Authority (CA). This should include the name of the CA, and the CA server and DNS address.
- The security (physical, network) to be used to protect the CA.
- All certificate policies which are to be implemented by the CA.
- The certificate types which are going to be used.
- The cryptographic algorithms and key length for the CA certificate.
- The policies and procedures for issuing certificates, for renewing certificates, and for revoking certificates.
- The certificate validity period for certificates issued by the CA.
- The location and policy for the CRLs.
When designing security for your CA servers, bear in mind that the best approach to use to secure the root CA, is to actually disconnect it from the network. This prevents an unauthorized person from accessing the root CA when the network is under attack. The methods that can be used to make CA servers offline are listed below:
- For the root CA, you can deploy a stand-alone server, and then set it up to be physically disconnected from the network.
- You can leave the CA server online, and stop the CA service of the computer. This prevents the CA from issuing certificates, and also stops the auto-enrollment of certificates. The CA server is however still susceptible to intruders that are scanning your file system in an attempt to seize certificate data.
- In a high security environment, it is not unusual to physically shut down root CAs. The root CA is only brought online to issue certificates to intermediate CAs. The downfall in this strategy is that auditing cannot be performed on the root CA.
Your certificate policy statements, should minimally, include the information listed below:
- The purpose of the certificate
- The manner in which users are to authenticate to the CA.
- Define any legal concerns which could surface when a CA is compromised.
- Management requirements for private keys.
- Define whether the private keys can be archived, and exported.
- Define the minimum acceptable length for the public keys and private keys
- Certificate enrollment and certificate renewal requirements.
- User requirements. This should include the procedure users should take when a private key is lost.
2. Create a certification authority infrastructure
The next step in designing a PKI implementation is to plan the certification authority infrastructure that would ultimately provide certificates to your users, computers, applications, and services. This stage involves the clarification of the following aspects:
- The location of the root CA.
- Whether you will be using internal or external CAs
- Whether the CAs will be integrated with Active Directory
- The location of the CAs in the Active Directory forest
- The number of CAs needed for the organization.
- The function or role that the CA would fulfil.
- The Administrators who will be responsible for managing the CAs
When considering how many CAs to implement within your organization, consider the elements which affect the CA performance, listed below:
- The length of the encryption key used greatly determines how the CPU of the server is affected as a CA. The longer the key, the more processing time needed to issue the certificate.
- The CPU performance of the server also greatly influences a particular server's performance as a CA. A server that has faster processors typically operates better as a CA. This is especially true when it comes to issuing certificates with key lengths that are long.
- Disk performance affects the performance of a CA as well. While longer keys can increase the processing time to issue certificates, disk performance typically affects keys that are short in length, because should a bottleneck exist, it can slow down the certificate enrollment process.
3. Configure certificates
During the planning of the certificate configurations which you are going to use, consider the following:
- Certificate type: The certificate type would basically dictate the function of the certificate. Whether or not certificates are going to be used with smart cards is another factor to consider when planning the configuration.
- The strength of the encryption key (key length and algorithm).
- The certificate and key lifetimes. The longer the lifetime, the more likely that the certificate can be compromised.
- Whether or not certificates are going to be allowed to be renewed, or whether existing keys are going to be reused.
The factors that you should consider when defining certificate and key lifetimes are noted below:
- Length of private keys: Longer keys tend to be more difficult to hack than shorter keys, and can therefore add to the key's lifetimes.
- Cryptographic technology used: A key's lifetime can be extended by the use of strong cryptographic technologies.
- Security of the CAs and its private keys: The greater the network and physical security enjoyed by CAs and their private keys, the longer the certificate lifetime. If the CA is susceptible to being attacked, use short key lifetimes and long private keys for the CA.
- Certificates' users: Users internal to the organization could have longer certificate lifetimes than users external to the organization.
4. Define a certificate management strategy
The factors that should be addressed when you define the certificate management strategy for your PKI implementation are listed below:
- Whether users are to be allowed to individually request certificates
- Whether auto-enrollment and Web enrollment is going to be used.
- The manner in which certificates are going to be manually distributed to users, if applicable.
When planning for, and designing a PKI implementation for your organization, apply the PKI best practices listed below:
- Follow the guidelines recommended by Microsoft for the performance of the CA server when deciding on the number of CA servers to install within your organization.
- The initial planning phase of the PKI implementation should define whether external CAs are going to be used. Define whether the external CAs are going to issue and validate certificates.
- Secure the root CA! A compromised root CA could lead to the PKI implementation being compromised.
|
|
|
Bookmark Understanding and Designing a Public Key Infrastructure
