Certification Authority
Overview Identifying CA Hierarchy Design Requirements Common CA Hierarchy Designs Documenting Legal Requirements Analyzing Design Requirements Designing a Hierarchy Structure
Identifying CA Hierarchy Design Requirements Project Scope Applications that Use a PKI Which Accounts Use PKI-Enabled Applications? How to Identify Technical Requirements How to Identify Business Requirements
Roles in a Certification Authority Hierarchy Root CA Policy CA Issuing CA
Applications That Use a PKI Encrypting File System Digital Signatures Smart Card Logon Internet Authentication Windows 2003 Certificate Services Secure E-mail Software Restriction Policy 802.1x IP Security Software Code Signing
Which Accounts Use PKI- Enabled Applications? Users Computers Services
How to Identify Technical Requirements For Security requirements Ask What is your organization s security policy? Do you have any business partners? Do you have requirements for complying with industry or government standards? Administration requirements Availability requirements Who will manage CAs? Who will manage certificates? How many CAs does your organization require? How are certificates distributed between CAs?
How to Identify Business Requirements For External access requirements Availability requirements Ask Will you issue certificates to nonemployees? Will you get your certificates validated from external networks? Will you require certificate services at all hours? Will you require certificate services at all locations? Legal requirements What are your organization s security practices? What is the liability of the organization?
Common CA Hierarchy Designs CA Hierarchy Based on Certificate Usage CA Hierarchy Based on Location CA Hierarchy Based on Departments CA Hierarchy Based on Organizational Structure
CA Hierarchy Based on Certificate Use Certificate Use Root Policy S/MIME EFS RAS Use a CA hierarchy based on certificate use to: Implement different issuance requirements Meet local legal requirements for a specific certificate type
CA Hierarchy Based on Location Location Root Policy India Canada United States Use a CA hierarchy based on location to: Meet legal requirements for local management Meet business requirements for CA availability
CA Hierarchy Based on Organizational Structure Organizational Structure Root Policy Employee Contractor Partner Use a CA hierarchy based on organizational structure to: Implement policies for each user category Delegate management of user categories to separate teams
Documenting Legal Requirements Steps for Designing Legal Requirements Security Policy Certificate Policy Certification Practice Statement
Steps for Designing Legal Requirements 1 2 3 Root CA Security Policy Certificate Policy Certificate Practice Statement 4 Policy CA 1 2 3 4 Develop the security policy Create the certificate policy Create the CPS Publish the CPS on the policy CA Issuing CA
Security Policy A security policy: Defines for using security services Reflects an organization s business and IT strategy Identifies applications to secure by using certificates Defines security services to offer by using certificates
Certificate Policy A certificate policy describes: The user identification process Private key management requirements The process for responding to lost or compromised private keys Certificate enrollment and renewal requirements The maximum dollar value for transactions
Certification Practice Statement A CPS can include these sections: Introduction General Provisions Identification and Authentication Operational Requirements Physical, Procedural, and Personnel Security Controls Technical Security Controls Certificate and CRL Profile Specification Administration
Analyzing Design Requirements Recommendations for Meeting Security Requirements Recommendations for Meeting External Access Requirements Recommendations for Meeting Application Requirements Recommendations for Meeting Administration Requirements Recommendations for Meeting Availability Requirements
Recommendations for Meeting Security Requirements Requirement Secure root and policy CAs Secure issuing CAs Protect private keys Provide different issuance requirements Recommended actions Remove root and policy CAs from the network Store offline CAs in a secure physical location Use a secured server room with card access Minimize services on issuing CAs Use Software CSPs Use smart cards or PC card tokens with PIN numbers Use Hardware Security Modules Implement separate CAs to host certificate templates for each type of issuance requirement
Recommendations for Meeting External Access Requirements Requirements Enable external clients to recognize certificates Manage certificates issued to external users Trust certificates from another organization Recommended actions Use a commercial CA Implement cross certification Implement qualified subordination Publish the CRL and AIA information externally Issue certificates from a private CA hierarchy Implement certificate trust lists Implement cross certification or qualified subordination
Recommendations for Meeting Application Requirements Requirement Minimize the number of issued certificates Recommended action Implement multiple-use certificates Minimize the number of CAs Publish multiple certificates from one CA Manage CAs based on applications Publish each certificate template from a dedicated CA
Recommendations for Meeting Administration Requirements Requirement Support delegated administration Support centralized administration Recommended actions Place CAs at same location as administrative staff Create a CA hierarchy based on project teams Implement role separation Prohibit remote administration of CAs Deploy CAs in restricted physical locations Deploy fewer CAs and place them at major hubs of the network
Recommendations for Meeting Availability Requirements Requirement High availability of a certificate template Support multiple regions Minimize CA failure Recommended actions Publish the certificate template to more than one CA in the CA hierarchy Publish certificate templates to CAs in each geographic region Provide sufficient disk space for the predicted certificate enrollment activity Use separate physical disks for CA database and log files Implement RAID 5 or RAID 0+1 for database disk
Designing a CA Hierarchy Structure Recommended Depth of a CA Hierarchy Security Levels in the CA Hierarchy Considerations for Choosing a CA Type CA Management Using Role Separation Guidelines for Designing a CA Hierarchy
Recommended Depth of a CA Hierarchy Requirements Low security (1 level) Medium security (2 levels) High security (3-4 levels) Recommended Depth A single root CA Small number of certificate requests Lower security requirements for CA security Offline root and online subordinates A single offline CA is removed from the network Issuing online CAs Two or more CAs to issue each certificate template Offline root and offline policy Online issuing subordinates Maximizing security Larger, geographically distributed, or high security organizations
Security Levels in the CA Hierarchy Security at the root CA: Requires highest level of security Requires minimal access Less Root CA Policy CA More Security As the distance from the root CA increases: Security decreases Access to issuing CAs increases Ease of Access More Issuing CA Less
Considerations for Choosing a CA Type Decision points Standalone Enterprise When to use Offline CAs Issuing CAs Active Directory Certificate type Certificate request management Does not require Active Directory Provides support for standard certificate types Issued or denied by a certificate manager Requires Active Directory Implements certificate templates Issued or denied based on certificate template permissions
Guidelines for Designing a CA Hierarchy When designing a CA hierarchy: Define the scope of your CA hierarchy design Define all requirements for your CA hierarchy Deploy an offline root CA Design a hierarchy that is no more than 3-4 layers Define appropriate security levels for each CA Choose the appropriate CA policy for each CA Plan role separation early in the CA hierarchy design