1. Certification Authority

2. Overview  Identifying CA Hierarchy Design Requirements  Common CA Hierarchy Designs  Documenting Legal Requirements  Analyzing Design Requirements  Designing a Hierarchy Structure

3. 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

4. Roles in a Certification Authority Hierarchy Root CA Policy CA Issuing CA

5. Software Code Signing Encrypting File System Smart Card Logon Smart Card Logon 802.1x IP Security Internet Authentication Secure E-mail Applications That Use a PKI Windows 2003 Certificate Services Software Restriction Policy Software Restriction Policy Digital Signatures

6. Which Accounts Use PKI- Enabled Applications? Users Computers Services

7. How to Identify Technical Requirements ForAsk Security requirements 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 Who will manage CAs? Who will manage certificates? Availability requirements How many CAs does your organization require? How are certificates distributed between CAs?

8. How to Identify Business Requirements ForAsk External access requirements Will you issue certificates to non- employees? Will you get your certificates validated from external networks? Availability requirements 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?

9. 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

10. CA Hierarchy Based on Certificate Use Use a CA hierarchy based on certificate use to: Implement different issuance requirements Meet local legal requirements for a specific certificate type Implement different issuance requirements Meet local legal requirements for a specific certificate type Certificate Use S/MIME Root Policy EFS RAS

11. CA Hierarchy Based on Location Use a CA hierarchy based on location to: Meet legal requirements for local management Meet business requirements for CA availability Meet legal requirements for local management Meet business requirements for CA availability Location India Canada United States Root Policy

12. CA Hierarchy Based on Organizational Structure Use a CA hierarchy based on organizational structure to: Implement policies for each user category Delegate management of user categories to separate teams Implement policies for each user category Delegate management of user categories to separate teams Organizational Structure Root Policy Employee Contractor Partner

13. Documenting Legal Requirements  Steps for Designing Legal Requirements  Security Policy  Certificate Policy  Certification Practice Statement

14. Steps for Designing Legal Requirements Security Policy 1 1 Develop the security policy 1 1 Root CA Policy CA Issuing CA 4 4 Publish the CPS on the policy CA 4 4 Create the certificate policy 2 2 Certificate Policy 2 2 Create the CPS 3 3 Certificate Practice Statement 3 3

15. 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 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 Security Policy

16. 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 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 Certificate Policy

17. 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 Introduction General Provisions Identification and Authentication Operational Requirements Physical, Procedural, and Personnel Security Controls Technical Security Controls Certificate and CRL Profile Specification Administration Certification Practice Statement

18. 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

19. Recommendations for Meeting Security Requirements Requirement Recommended actions Secure root and policy CAs Remove root and policy CAs from the network Store offline CAs in a secure physical location Secure issuing CAs Use a secured server room with card access Minimize services on issuing CAs Protect private keys Use Software CSPs Use smart cards or PC card tokens with PIN numbers Use Hardware Security Modules Provide different issuance requirements Implement separate CAs to host certificate templates for each type of issuance requirement

20. Recommendations for Meeting External Access Requirements Requirements Recommended actions Enable external clients to recognize certificates Use a commercial CA Implement cross certification Implement qualified subordination Publish the CRL and AIA information externally Manage certificates issued to external users Issue certificates from a private CA hierarchy Trust certificates from another organization Implement certificate trust lists Implement cross certification or qualified subordination

21. Recommendations for Meeting Application Requirements Requirement Recommended action Minimize the number of issued certificates 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

22. Recommendations for Meeting Administration Requirements Requirement Recommended actions Support delegated administration Place CAs at same location as administrative staff Create a CA hierarchy based on project teams Implement role separation Support centralized administration Prohibit remote administration of CAs Deploy CAs in restricted physical locations Deploy fewer CAs and place them at major hubs of the network

23. Recommendations for Meeting Availability Requirements Requirement Recommended actions High availability of a certificate template Publish the certificate template to more than one CA in the CA hierarchy Support multiple regions Publish certificate templates to CAs in each geographic region Minimize CA failure 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

24. 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

25. Recommended Depth of a CA Hierarchy Requirements Recommended Depth Low security (1 level) A single root CA Small number of certificate requests Lower security requirements for CA security Medium security (2 levels) 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 High security (3-4 levels) Offline root and offline policy Online issuing subordinates Maximizing security Larger, geographically distributed, or high security organizations

26. Security Levels in the CA Hierarchy  Security at the root CA: Requires highest level of security Requires highest level of security Requires minimal access Requires minimal access  As the distance from the root CA increases: Security decreases Security decreases Access to issuing CAs increases Access to issuing CAs increases Root CA Policy CA Issuing CA More Less More Ease of Access Security

27. Considerations for Choosing a CA Type Decision points StandaloneEnterprise When to use Offline CAs Issuing CAs Active Directory Does not require Active Directory Requires Active Directory Certificate type Provides support for standard certificate types Implements certificate templates Certificate request management Issued or denied by a certificate manager Issued or denied based on certificate template permissions

28. 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 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