Symantec Trust Network (STN) Certification Practice Statement

Version 3.8.14 December 12, 2013

Symantec Corporation 350 Ellis Street Mountain View, CA 94043 USA +1 650.527.8000 www.symantec.com

- i-

Symantec Trust Network (STN) Certification Practices Statement 2013 Symantec Corporation. All rights reserved. Printed in the United States of America. Published date: February 13, 2013

Important Acquisition Notice On August 9, 2010, Symantec Corporation completed the acquisition of VeriSign Incs Authentication division. As a result Symantec is now the registered owner of this Certificate Practices Statement document and the PKI Services described within this document. However a hybrid of references to both VeriSign and Symantec shall be evident within this document for a period of time until it is operationally practical to complete the re-branding of the Certification Authorities and services. Any references to VeriSign as a corporate entity should be strictly considered to be legacy language that solely reflects the history of ownership.

Trademark Notices Symantec, the Symantec logo, and the Checkmark Logo are the registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. The VeriSign logo, VeriSign Trust and other related marks are the trademarks or registered marks of VeriSign, Inc. or its affiliates or subsidiaries in the U.S. and other countries and licensed by Symantec Corporation. Other names may be trademarks of their respective owners. Without limiting the rights reserved above, and except as licensed below, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), without prior written permission of Symantec Corporation. Notwithstanding the above, permission is granted to reproduce and distribute this Symantec STN Certification Practices Statement on a nonexclusive, royalty-free basis, provided that (i) the foregoing copyright notice and the beginning paragraphs are prominently displayed at the beginning of each copy, and (ii) this document is accurately reproduced in full, complete with attribution of the document to Symantec Corporation. Requests for any other permission to reproduce this Symantec STN Certification Practices Statement (as well as requests for copies from Symantec) must be addressed to Symantec Corporation 350 Ellis Street, Mountain View, CA 94043 USA Attn: Practices Development. Tel: +1 650.527.8000 Fax: +1 650.527.8050. Net: practices@symantec.com.

- ii -

Table of Contents 1. INTRODUCTION ......................................................... 1 1.1 OVERVIEW ............................................................ 2 1.2 DOCUMENT NAME AND IDENTIFICATION .................. 3 1.3 PKI PARTICIPANTS ................................................ 3 1.3.1 Certification Authorities .................................. 3 1.3.2 Registration Authorities .................................. 3 1.3.3 Subscribers ..................................................... 4 1.3.4 Relying Parties ............................................... 4 1.3.5 Other Participants ........................................... 4 1.4 CERTIFICATE USAGE ............................................. 5 1.4.1 Appropriate Certificate Usages ...................... 5 1.4.2 Prohibited Certificate Uses ............................. 6 1.5 POLICY ADMINISTRATION ....................................... 6 1.5.1 Organization Administering the Document ..... 6 1.5.2 Contact Person ............................................... 7 1.5.3 Person Determining CP Suitability for the Policy 7 1.5.4 CPS Approval Procedure ............................... 7 1.6 DEFINITIONS AND ACRONYMS ................................ 7 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES ............................................................ 7 2.1 2.2 2.3 2.4 3. REPOSITORIES ...................................................... 7 PUBLICATION OF CERTIFICATE INFORMATION .......... 7 TIME OR FREQUENCY OF PUBLICATION ................... 8 ACCESS CONTROLS ON REPOSITORIES .................. 9 4.1.2 Enrollment Process and Responsibilities ..... 17 4.2 .................................................................................. 18 4.3 CERTIFICATE APPLICATION PROCESSING ............. 18 4.3.1 Performing Identification and Authentication Functions ................................................................... 18 4.3.2 Approval or Rejection of Certificate Applications ............................................................... 18 4.3.3 Time to Process Certificate Applications ...... 18 4.4 CERTIFICATE ISSUANCE....................................... 18 4.4.1 CA Actions during Certificate Issuance ........ 18 4.4.2 Notifications to Subscriber by the CA of Issuance of Certificate ............................................... 18 4.4.3 CABF Requirement for Certificate Issuance by a Root CA .................................................................. 18 4.5 CERTIFICATE ACCEPTANCE ................................. 19 4.5.1 Conduct Constituting Certificate Acceptance 19 4.5.2 Publication of the Certificate by the CA ........ 19 4.5.3 Notification of Certificate Issuance by the CA to Other Entities ......................................................... 19 4.6 KEY PAIR AND CERTIFICATE USAGE ..................... 19 4.6.1 Subscriber Private Key and Certificate Usage 19 4.6.2 Relying Party Public Key and Certificate Usage 19 4.7 CERTIFICATE RENEWAL ....................................... 20 4.7.1 Circumstances for Certificate Renewal ........ 20 4.7.2 Who May Request Renewal ......................... 20 4.7.3 Processing Certificate Renewal Requests ... 20 4.7.4 Notification of New Certificate Issuance to Subscriber ................................................................. 21 4.7.5 Conduct Constituting Acceptance of a Renewal Certificate ................................................... 21 4.7.6 Publication of the Renewal Certificate by the CA 21 4.7.7 Notification of Certificate Issuance by the CA to Other Entities ......................................................... 21 4.8 CERTIFICATE RE-KEY.......................................... 21 4.8.1 Circumstances for Certificate Re-Key .......... 21 4.8.2 Who May Request Certification of a New Public Key.................................................................. 22 4.8.3 Processing Certificate Re-Keying Requests 22 4.8.4 Notification of New Certificate Issuance to Subscriber ................................................................. 22 4.8.5 Conduct Constituting Acceptance of a ReKeyed Certificate ....................................................... 22 4.8.6 Publication of the Re-Keyed Certificate by the CA 22 4.8.7 Notification of Certificate Issuance by the CA to Other Entities ......................................................... 22 4.9 CERTIFICATE MODIFICATION ................................ 22 4.9.1 Circumstances for Certificate Modification ... 22 4.9.2 Who May Request Certificate Modification .. 23 4.9.3 Processing Certificate Modification Requests 23 4.9.4 Notification of New Certificate Issuance to Subscriber ................................................................. 23

IDENTIFICATION AND AUTHENTICATION .............. 9 3.1 NAMING ................................................................ 9 3.1.1 Type of Names ............................................... 9 3.1.2 Need for Names to be Meaningful................ 11 3.1.3 Anonymity or Pseudonymity of Subscribers . 11 3.1.4 Rules for Interpreting Various Name Forms . 11 3.1.5 Uniqueness of Names .................................. 11 3.1.6 Recognition, Authentication, and Role of Trademarks ............................................................... 11 3.2 INITIAL IDENTITY VALIDATION ............................... 11 3.2.1 Method to Prove Possession of Private Key 11 3.2.2 Authentication of Organization identity ......... 12 3.2.3 Authentication of Individual Identity .............. 13 3.2.4 Non-Verified Subscriber information ............ 14 3.2.5 Validation of Authority .................................. 14 3.2.6 Criteria for Interoperation ............................. 14 3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS ....................................................................... 15 3.3.1 Identification and Authentication for Routine Re-key 15 3.3.2 Identification and Authentication for Re-key After Revocation ........................................................ 16 3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST .................................................... 16

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS .............................................................. 17 4.1 CERTIFICATE APPLICATION .................................. 17 4.1.1 Who Can Submit a Certificate Application? . 17 - iii -

4.9.5 Conduct Constituting Acceptance of Modified Certificate .................................................................. 23 4.9.6 Publication of the Modified Certificate by the CA 23 4.9.7 Notification of Certificate Issuance by the CA to Other Entities ......................................................... 23 4.10 CERTIFICATE REVOCATION AND SUSPENSION ....... 23 4.10.1 Circumstances for Revocation ................. 23 4.10.2 Who Can Request Revocation ................. 24 4.10.3 Procedure for Revocation Request .......... 25 4.10.4 Revocation Request Grace Period .......... 25 4.10.5 Time within Which CA Must Process the Revocation Request .................................................. 25 4.10.6 Revocation Checking Requirements for Relying Parties .......................................................... 25 4.10.7 CRL Issuance Frequency......................... 26 4.10.8 Maximum Latency for CRLs ..................... 26 4.10.9 On-Line Revocation/Status Checking Availability 26 4.10.10 On-Line Revocation Checking Requirements ............................................................ 26 4.10.11 Other Forms of Revocation Advertisements Available 27 4.10.12 Special Requirements regarding Key Compromise .............................................................. 27 4.10.13 Circumstances for Suspension ................ 27 4.10.14 Who Can Request Suspension ................ 27 4.10.15 Procedure for Suspension Request ......... 27 4.10.16 Limits on Suspension Period ................... 27 4.11 CERTIFICATE STATUS SERVICES .......................... 27 4.11.1 Operational Characteristics ...................... 27 4.11.2 Service Availability ................................... 27 4.11.3 Optional Features ..................................... 27 4.12 END OF SUBSCRIPTION........................................ 27 4.13 KEY ESCROW AND RECOVERY ............................. 28 4.13.1 Key Escrow and Recovery Policy and Practices 28 4.13.2 Session Key Encapsulation and Recovery Policy and Practices .................................................. 29 5. FACILITY, MANAGEMENT, AND OPERATIONAL 6. CONTROLS ....................................................................... 29 5.1 PHYSICAL CONTROLS .......................................... 29 5.1.1 Site Location and Construction .................... 29 5.1.2 Physical Access............................................ 29 5.1.3 Power and Air Conditioning .......................... 30 5.1.4 Water Exposures .......................................... 30 5.1.5 Fire Prevention and Protection ..................... 30 5.1.6 Media Storage .............................................. 30 5.1.7 Waste Disposal............................................. 30 5.1.8 Off-Site Backup ............................................ 30 5.2 PROCEDURAL CONTROLS .................................... 30 5.2.1 Trusted Roles ............................................... 30 5.2.2 Number of Persons Required per Task ........ 31 5.2.3 Identification and Authentication for Each Role 31 5.2.4 Roles Requiring Separation of Duties .......... 32 5.3 PERSONNEL CONTROLS ...................................... 32 5.3.1 Qualifications, Experience, and Clearance Requirements ............................................................ 32 - iv -

5.3.2 Background Check Procedures ................... 32 5.3.3 Training Requirements ................................. 33 5.3.4 Retraining Frequency and Requirements .... 33 5.3.5 Job Rotation Frequency and Sequence ....... 33 5.3.6 Sanctions for Unauthorized Actions ............. 33 5.3.7 Independent Contractor Requirements ........ 34 5.3.8 Documentation Supplied to Personnel ......... 34 5.4 AUDIT LOGGING PROCEDURES ............................ 34 5.4.1 Types of Events Recorded ........................... 34 5.4.2 Frequency of Processing Log ...................... 35 5.4.3 Retention Period for Audit Log ..................... 35 5.4.4 Protection of Audit Log ................................. 35 5.4.5 Audit Log Backup Procedures ...................... 35 5.4.6 Audit Collection System (Internal vs. External) 35 5.4.7 Notification to Event-Causing Subject .......... 35 5.4.8 Vulnerability Assessments ........................... 35 5.5 RECORDS ARCHIVAL ........................................... 35 5.5.1 Types of Records Archived .......................... 35 5.5.2 Retention Period for Archive ........................ 36 5.5.3 Protection of Archive .................................... 36 5.5.4 Archive Backup Procedures ......................... 36 5.5.5 Requirements for Time-Stamping of Records 36 5.5.6 Archive Collection System (Internal or External) .................................................................... 36 5.5.7 Procedures to Obtain and Verify Archive Information................................................................. 36 5.6 KEY CHANGEOVER .............................................. 36 5.7 COMPROMISE AND DISASTER RECOVERY ............. 37 5.7.1 Incident and Compromise Handling Procedures ................................................................ 37 5.7.2 Computing Resources, Software, and/or Data Are Corrupted ............................................................ 37 5.7.3 Entity Private Key Compromise Procedures 37 5.7.4 Business Continuity Capabilities after a Disaster ..................................................................... 37 5.8 CA OR RA TERMINATION ..................................... 38 5.9 DATA SECURITY .................................................. 39 TECHNICAL SECURITY CONTROLS ..................... 39 6.1 KEY PAIR GENERATION AND INSTALLATION........... 39 6.1.1 Key Pair Generation ..................................... 39 6.1.2 Private Key Delivery to Subscriber ............... 40 6.1.3 Public Key Delivery to Certificate Issuer ...... 40 6.1.4 CA Public Key Delivery to Relying Parties ... 40 6.1.5 Key Sizes ..................................................... 40 6.1.6 Public Key Parameters Generation and Quality Checking ....................................................... 42 6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field) .............................................................. 42 6.2 PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS ................................... 42 6.2.1 Cryptographic Module Standards and Controls 42 6.2.2 Private Key (m out of n) Multi-Person Control 42 6.2.3 Private Key Escrow ...................................... 43 6.2.4 Private Key Backup ...................................... 43 6.2.5 Private Key Archival ..................................... 43

6.2.6 Private Key Transfer Into or From a Cryptographic Module ............................................... 43 6.2.7 Private Key Storage on Cryptographic Module 43 6.2.8 Method of Activating Private Key ................. 43 6.2.9 Method of Deactivating Private Key ............. 45 6.2.10 Method of Destroying Private Key ........... 45 6.2.11 Cryptographic Module Rating .................. 45 6.3 OTHER ASPECTS OF KEY PAIR MANAGEMENT ...... 45 6.3.1 Public Key Archival ....................................... 45 6.3.2 Certificate Operational Periods and Key Pair Usage Periods ........................................................... 46 6.4 ACTIVATION DATA ............................................... 47 6.4.1 Activation Data Generation and Installation . 47 6.4.2 Activation Data Protection ............................ 47 6.4.3 Other Aspects of Activation Data ................. 48 6.5 COMPUTER SECURITY CONTROLS........................ 48 6.5.1 Specific Computer Security Technical Requirements ............................................................ 48 6.5.2 Computer Security Rating ............................ 49 6.6 LIFE CYCLE TECHNICAL CONTROLS ..................... 49 6.6.1 System Development Controls ..................... 49 6.6.2 Security Management Controls .................... 49 6.6.3 Life Cycle Security Controls ......................... 49 6.7 NETWORK SECURITY CONTROLS ......................... 49 6.8 TIME-STAMPING .................................................. 49 7. CERTIFICATE, CRL, AND OCSP PROFILES ......... 49 7.1 CERTIFICATE PROFILE ......................................... 49 7.1.1 Version Number(s) ....................................... 50 7.1.2 Certificate Extensions ................................... 50 7.1.3 Algorithm Object Identifiers .......................... 52 7.1.4 Name Forms ................................................. 52 7.1.5 Name Constraints ......................................... 52 7.1.6 Certificate Policy Object Identifier ................ 53 7.1.7 Usage of Policy Constraints Extension ........ 53 7.1.8 Policy Qualifiers Syntax and Semantics ....... 53 7.1.9 Processing Semantics for the Critical Certificate Policies Extension .................................... 53 7.2 CRL PROFILE ..................................................... 53 7.2.1 Version Number(s) ....................................... 53 7.2.2 CRL and CRL Entry Extensions ................... 53 7.3 OCSP PROFILE .................................................. 54 7.3.1 Version Number(s) ....................................... 54 7.3.2 OCSP Extensions ......................................... 54 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS 54 8.1 8.2 8.3 8.4 8.5 8.6 9. FREQUENCY AND CIRCUMSTANCES OF ASSESSMENT 55 IDENTITY/QUALIFICATIONS OF ASSESSOR ............. 55 ASSESSOR'S RELATIONSHIP TO ASSESSED ENTITY55 TOPICS COVERED BY ASSESSMENT ..................... 55 ACTIONS TAKEN AS A RESULT OF DEFICIENCY ...... 55 COMMUNICATIONS OF RESULTS ........................... 56

OTHER BUSINESS AND LEGAL MATTERS .......... 56 9.1 FEES .................................................................. 56 9.1.1 Certificate Issuance or Renewal Fees.......... 56 9.1.2 Certificate Access Fees ................................ 56 - v-

Revocation or Status Information Access Fees 56 9.1.4 Fees for Other Services ............................... 56 9.1.5 Refund Policy ............................................... 56 9.2 FINANCIAL RESPONSIBILITY ................................. 57 9.2.1 Insurance Coverage ..................................... 57 9.2.2 Other Assets ................................................. 57 9.2.3 Extended Warranty Coverage ...................... 57 9.3 CONFIDENTIALITY OF BUSINESS INFORMATION...... 57 9.3.1 Scope of Confidential Information ................ 57 9.3.2 Information Not Within the Scope of Confidential Information ............................................ 57 9.3.3 Responsibility to Protect Confidential Information................................................................. 58 9.4 PRIVACY OF PERSONAL INFORMATION.................. 58 9.4.1 Privacy Plan ................................................. 58 9.4.2 Information Treated as Private ..................... 58 9.4.3 Information Not Deemed Private .................. 58 9.4.4 Responsibility to Protect Private Information 58 9.4.5 Notice and Consent to Use Private Information 58 9.4.6 Disclosure Pursuant to Judicial or Administrative Process .............................................. 58 9.4.7 Other Information Disclosure Circumstances 58 9.5 INTELLECTUAL PROPERTY RIGHTS........................ 58 9.5.1 Property Rights in Certificates and Revocation Information................................................................. 59 9.5.2 Property Rights in the CPS .......................... 59 9.5.3 Property Rights in Names ............................ 59 9.5.4 Property Rights in Keys and Key Material.... 59 9.6 REPRESENTATIONS AND W ARRANTIES ................. 59 9.6.1 CA Representations and Warranties ............ 59 9.6.2 RA Representations and Warranties ............ 60 9.6.3 Subscriber Representations and Warranties 60 9.6.4 Relying Party Representations and Warranties 60 9.6.5 Representations and Warranties of Other Participants ................................................................ 60 9.7 DISCLAIMERS OF W ARRANTIES ............................ 61 9.8 LIMITATIONS OF LIABILITY .................................... 61 9.9 INDEMNITIES ....................................................... 61 9.9.1 Indemnification by Subscribers .................... 61 9.9.2 Indemnification by Relying Parties ............... 62 9.9.3 Indemnification of Application Software Suppliers.................................................................... 62 9.10 TERM AND TERMINATION ..................................... 62 9.10.1 Term ......................................................... 62 9.10.2 Termination .............................................. 62 9.10.3 Effect of Termination and Survival ........... 62 9.11 INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS ................................................................. 63 9.12 AMENDMENTS ..................................................... 63 9.12.1 Procedure for Amendment ....................... 63 9.12.2 Notification Mechanism and Period ......... 63 9.12.3 Circumstances under Which OID Must be Changed 64 9.13 DISPUTE RESOLUTION PROVISIONS ..................... 64 9.13.1 Disputes among Symantec, Affiliates, and Customers ................................................................. 64

9.1.3

9.13.2 Disputes with End-User Subscribers or Relying Parties .......................................................... 64 9.14 GOVERNING LAW ................................................ 64 9.15 COMPLIANCE WITH APPLICABLE LAW .................... 64 9.16 MISCELLANEOUS PROVISIONS.............................. 65 9.16.1 Entire Agreement ..................................... 65 9.16.2 Assignment .............................................. 65 9.16.3 Severability ............................................... 65 9.16.4 Enforcement (Attorney's Fees and Waiver of Rights) 65 9.16.5 Force Majeure .......................................... 65 9.17 OTHER PROVISIONS ............................................ 65 APPENDIX A. TABLE OF ACRONYMS AND DEFINITIONS..................................................................... 66 TABLE OF ACRONYMS....................................................... 66 DEFINITIONS .................................................................... 66 TABLE OF CONTENTS .................................................... 73 1. INTRODUCTION ........................................................... 75

9.2.3 Subject Common Name Field ........................ 121 9.2.4 Subject Business Category Field ................... 121 9.2.5 Subject Jurisdiction of Incorporation or Registration Field .................................................... 121 9.2.6 Subject Registration Number Field ................ 122 9.2.7 Subject Physical Address of Place of Business Field ......................................................................... 122 9.2.8 Other Subject Attributes ................................. 122 9.3 CERTIFICATE POLICY IDENTIFICATION ........................ 122 9.4 MAXIMUM VALIDITY PERIOD FOR EV CODE SIGNING CERTIFICATE ................................................................. 122 9.5 SUBSCRIBER PUBLIC KEY ......................................... 122 SYMANTEC CERTIFICATES MEET THE REQUIREMENTS FOR
ALGORITHM TYPE AND KEY SIZE AS SET FORTH IN SECTION 6.1.5 OF THIS CPS. ALSO SEE APPENDIX B2 FOR MINIMUM CRYPTOGRAPHIC ALGORITHM AND KEY SIZES. .................. 122 9.6 CERTIFICATE SERIAL NUMBER .................................. 122 9.7 ADDITIONAL TECHNICAL REQUIREMENTS FOR EV CODE SIGNING CERTIFICATES .................................................. 122

10. EV CODE SIGNING CERTIFICATE REQUEST 2. BASIC CONCEPT OF THE EV CERTIFICATE ........... 75 REQUIREMENTS ............................................................ 123 2.1 PURPOSE OF EV SSL CERTIFICATES. ........................ 75 APPENDIX B4 ................................................................. 115 TABLE OF CONTENTS .................................................. 116 10.1 GENERAL REQUIREMENTS ...................................... 123 10.2 EV CODE SIGNING CERTIFICATE REQUEST REQUIREMENTS ............................................................. 123 10.3.1 General ......................................................... 123

1. INTRODUCTION ......................................................... 118 PRIOR TO THE ISSUANCE OF THE EV CODE SIGNING CERTIFICATE, SYMANTEC OBTAINS THE 2. PURPOSE ................................................................... 118 APPLICANTS AGREEMENT TO A LEGALLY 2.1 PURPOSE OF EV CODE SIGNING CERTIFICATES......... 118 ENFORCEABLE SUBSCRIBER AGREEMENT FOR THE 2.1.1 Secondary Purposes ...................................... 118 EXPRESS BENEFIT OF RELYING PARTIES AND 2.1.2 Excluded Purposes ........................................ 118 APPLICATION SOFTWARE VENDORS. THE SUBSCRIBER AGREEMENT MUST BE SIGNED BY AN 3. REFERENCES ............................................................ 118 AUTHORIZED CONTRACT SIGNER ACTING ON 4. DEFINITIONS ............................................................. 119 BEHALF OF THE APPLICANT, AND MUST APPLY TO THE EV CODE SIGNING CERTIFICATE TO BE ISSUED 5. ABBREVIATIONS AND ACRONYMS ....................... 119 PURSUANT TO THE CERTIFICATE REQUEST. A 6. CONVENTIONS .......................................................... 119 SEPARATE SUBSCRIBER AGREEMENT MAY BE USED FOR EACH CERTIFICATE REQUEST, OR A SINGLE 7. CERTIFICATE WARRANTIES AND SUBSCRIBER AGREEMENT MAY BE USED TO COVER REPRESENTATIONS ...................................................... 119 MULTIPLE FUTURE CERTIFICATE REQUESTS AND 7.1 EV CODE SIGNING CERTIFICATE W ARRANTIES .......... 119 RESULTING CERTIFICATES. ........................................ 123 7.2 BY THE APPLICANT ................................................... 120 10.3.2 Agreement Requirements ............................ 124 8. COMMUNITY AND APPLICABILITY ......................... 120 THE APPLICANTS AGREEMENT TO THE SUBSCRIBER 8.1 ISSUANCE OF EV CODE SIGNING CERTIFICATES ........ 120 AGREEMENT SHALL, AT A MINIMUM, SPECIFICALLY 8.2 EV CODE SIGNING POLICIES..................................... 120 NAME BOTH THE APPLICANT AND THE INDIVIDUAL 8.2.1 Implementation ............................................... 120 CONTRACT SIGNER SIGNING THE AGREEMENT ON 8.2.2 Disclosure ....................................................... 120 THE APPLICANTS BEHALF. THE SUBSCRIBER AGREEMENT SHALL CONTAIN, AMONG OTHER 8.3 COMMITMENT TO CONFORM WITH RECOMMENDATIONS ..................................................................................... 120 THINGS, PROVISIONS IMPOSING ON THE APPLICANT 8.4 INSURANCE .............................................................. 121 THE FOLLOWING OBLIGATIONS AND WARRANTIES: 8.5 OBTAINING EV CODE SIGNING CERTIFICATES ............ 121 ......................................................................................... 124 9. EV CERTIFICATE CONTENT AND PROFILE........... 121 11. VERIFICATION REQUIREMENTS........................... 125 11.1 GENERAL OVERVIEW .............................................. 125 9.1 ISSUER INFORMATION ............................................... 121 11.2 VERIFICATION OF APPLICANTS LEGAL EXISTENCE AND 9.2 SUBJECT INFORMATION ............................................ 121 IDENTITY........................................................................ 125 9.2.1 Subject Organization Name Field ................... 121 9.2.2 Subject Alternative Name Extension .............. 121 - vi -

11.3 VERIFICATION OF APPLICANTS LEGAL EXISTENCE AND IDENTITY ASSUMED NAME............................................ 125 11.4 VERIFICATION OF APPLICANTS PHYSICAL EXISTENCE ..................................................................................... 125 11.5 VERIFICATION OF APPLICANTS OPERATIONAL EXISTENCE .................................................................... 125 11.6 VERIFICATION OF APPLICANTS DOMAIN NAME ......... 125 11.7 VERIFICATION OF NAME, TITLE AND AUTHORITY OF CONTRACT SIGNER AND CERTIFICATE APPROVER ........... 125 11.8 VERIFICATION OF SIGNATURE ON SUBSCRIBER AGREEMENT AND EV CODE SIGNING CERTIFICATE REQUESTS ..................................................................... 125 11.9 VERIFICATION OF APPROVAL OF EV CODE SIGNING CERTIFICATE REQUEST .................................................. 125 11.10 VERIFICATION OF CERTAIN INFORMATION SOURCES ..................................................................................... 125 11.11 OTHER VERIFICATION REQUIREMENTS .................. 125 11.12 FINAL CROSS-CORRELATION AND DUE DILIGENCE . 126 11.13 REQUIREMENTS FOR RE-USE OF EXISTING DOCUMENTATION ........................................................... 126

17.4 PRE-ISSUANCE READINESS AUDIT .......................... 128 17.5 REGULAR SELF-AUDITS .......................................... 128 17.6 AUDITOR QUALIFICATION ........................................ 128 17.7 ROOT CA KEY PAIR GENERATION ........................... 128 18. LIABILITY AND INDEMNIFICATION ....................... 128 TABLE OF CONTENTS .................................................. 129 1. INTRODUCTION......................................................... 131 CA / BROWSER FORUM BASELINE REQUIREMENTS, V. 1.1.6 (AS OF 29 JULY 2013) 38 ......................................... 168 DELETED: BEFORE RENEWING AN EV CERTIFICATE, VERISIGN PERFORMS ALL AUTHENTICATION AND VERIFICATION TASKS REQUIRED BY THE GUIDELINES AND THIS PROCEDURE TO ENSURE THAT THE RENEWAL REQUEST IS PROPERLY AUTHORIZED BY THE APPLICANT AND THAT THE INFORMATION DISPLAYED IN THE EV CERTIFICATE IS STILL ACCURATE AND VALID. ............................................. 176

12. CERTIFICATE ISSUANCE BY A ROOT CA ........... 126 REPLACED THIS PARAGRAPH WITH CONTENT CONSISTENT WITH PUBLISHED ERRATA TO THE EV 13. CERTIFICATE REVOCATION AND STATUS GUIDELINES. ALSO INCLUDED A DEFINITION OF CHECKING ...................................................................... 126 RENEWAL CONSISTENT WITH THE GUIDELINES. .... 176 14. EMPLOYEE AND THIRD PARTY ISSUES .............. 127 APPENDIX B1: SUPPLEMENTAL VALIDATION PROCEDURES 14.1 TRUSTWORTHINESS AND COMPETENCE ................... 127 APPENDIX B2: MINIMUM ALGORITHM AND KEY SIZES FOR 14.2 DELEGATION OF FUNCTIONS TO REGISTRATION EV CERTIFICATES ....102 AUTHORITIES AND SUBCONTRACTORS............................. 127 APPENDIX B3: REQUIRED CERTIFICATE EXTENSIONS 103
APPENDIX B4: FOREIGN ORGANIZATION NAME GUIDELINES ...105 16. DATA SECURITY ..................................................... 127 APPENDIX C: SUPPLEMENTAL VALIDATION PROCEDURES FOR EV CODE-SIGNING CERTIFICATES 106 17. AUDIT ....................................................................... 127 APPENDIX D: SUPPLEMENTAL BASELINE REQUIREMENTS FOR PUBLICLY TRUSTED CERTIFICATES..119 17.1 ELIGIBLE AUDIT SCHEMES ...................................... 127 APPENDIX E: HISTORY OF CHANGES.....143 FOR EV SSL CERTIFICATES 72

15. DATA RECORDS ..................................................... 127

17.2 AUDIT PERIOD ........................................................ 127 17.3 AUDIT RECORD ...................................................... 127

- vii -

1. INTRODUCTION
This document is the Symantec Trust Network (STN) Certification Practice Statement (CPS). It states the practices that Symantec certification authorities (CAs) employ in providing certification services that include, but are not limited to, issuing, managing, revoking, and renewing certificates in accordance with the specific requirements of the Symantec Trust Network Certificate Policies (CP). The CP is the principal statement of policy governing the STN. It establishes the business, legal, and technical requirements for approving, issuing, managing, using, revoking, and renewing, digital Certificates within the STN and providing associated trust services. These requirements, called the STN Standards, protect the security and integrity of the STN, apply to all STN Participants, and thereby provide assurances of uniform trust throughout the STN. More information concerning the STN and STN Standards is available in the CP. Symantec has authority over a portion of the STN called its Sub-domain of the STN. Symantecs Sub-domain includes entities subordinate to it such as its Customers, Subscribers, and Relying Parties. While the CP sets forth requirements that STN Participants must meet, this CPS describes how Symantec meets these requirements within Symantecs Sub-domain of the STN. More specifically, this CPS describes the practices that Symantec employs for: securely managing the core infrastructure that supports the STN, and issuing, managing, revoking, and renewing STN Certificates

within Symantecs Sub-domain of the STN, in accordance with the requirements of the CP and its STN Standards. This CPS conforms to the Internet Engineering Task Force (IETF) RFC 3647 for Certificate Policy and Certification Practice Statement construction. CAs within the Symantec Trust Network hierarchy conform to the current version of the CA/Browser Forum (CABF) requirements including: Guidelines for the Issuance and Management of Extended Validation (EV) Certificates, Guidelines for the Issuance and Management of Extended Validation (EV) Code-Signing Certificates, and, Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, published at www.cabforum.org. In the event of any inconsistency between this document and those Requirement, those Requirements take precedence over this document. At this time, Symantecs Extended Validation (EV) SSL certificates, Extended Validation (EV) Code-Signing certificates and Domain-Validated (DV) and Organization-Validated (OV) SSL 1 Certificates issued by Symantec CAs under this CP conform with the CABF Requirements. Such DV and OV certificates are issued containing the corresponding policy identifier(s) specified in section 1.2 of the CP indicating adherence to and conformance with these requirements. Symantec CAs assert that all Certificates issued containing these policy identifier(s) are issued and managed in conformance with the CABF Requirements.
1

Additionally, Symantec issues organizational Client (non-SSL) certificates that are not subject to the CA Browser Forum Baseline Requirements. In addition to practices pertaining exclusively to the CA Browser Forum (ie, for OV SSL certificates), this CPS describes practices that pertain to any Class 2 or Class 3 certificate that is issued to an organization and contains organization information. Such certificates are referred to throughout this CPS as organizational certificates.

- 1-

Cross-Certification The Symantec Non-Federal Shared Service Provider (SSP) sub-domain of the STN, is crosscertified with the US Federal Bridge CA and operates in compliance with the requirements of the X.509 Certificate Policy for the Federal Bridge Certification Authority (FBCA) and the Symantec Non-Federal Shared Service Provider (SSP) Certification Practice Statement.

1.1

Overview

This CPS is specifically applicable to: Symantecs Public Primary Certification Authorities (PCAs), 2 Symantec Infrastructure CAs, and Symantec Administrative CAs supporting the Symantec Trust Network Symantecs Public CAs and the CAs of Enterprise Customers, who issue Certificates within Symantecs sub-domain of the STN. More generally, the CPS also governs the use of STN services within Symantecs sub-domain of the STN by all individuals and entities within Symantecs Sub-domain (collectively, Symantec Sub-domain Participants). Unless specifically noted within this CPS, Private CAs and hierarchies 3 managed by Symantec are outside the scope of this CPS. The CAs managed by Affiliates are also outside the scope of this CPS. The STN includes four classes of Certificates, Classes 1-4. The CP is a single document that defines these certificate policies, one for each of the Classes, and sets STN Standards for each Class. Symantec currently offers three Classes of Certificates within its Sub-domain of the STN. This CPS describes how Symantec meets the CP requirements for each Class within its Sub-domain. Thus, the CPS, as a single document, covers practices and procedures concerning the issuance and management of all three Certificate Classes. Symantec may publish Certificate Practices Statements that are supplemental to this CPS in order to conform with the specific policy requirements of Government, or other industry standards and requirements. These supplemental certificate policies shall be made available to subscribers for the certificates issued under the supplemental policies and their relying parties. The CPS is only one of a set of documents relevant to Symantecs Sub-domain of the STN. These other documents include: Ancillary confidential security and operational documents that supplement the CP and CPS by providing more detailed requirements, such as: o The Symantec Physical Security Policy, which sets forth security principles governing the STN infrastructure,
4

Symantec operates both public and private/internal Class 3 hierarchies within the scope of this CPS. The Class 3 Internal CA hierarchy is distinguished by a private PCA and the specified OID value as stipulated in section 1.2 of the CP. The private PCA certificate is configured to explicitly exclude Server Authentication and Code Signing from the certificate intended purposes.. 3 Authenticated Content Signing Certificates (ACS) are issued by a non-STN CA. However, reference is made to these certificates in certain sections of this CPS, for ACS customers to understand certain procedural differences used for these certificates. 4 Although these documents are not publicly available their specifications are included in Symantecs Annual WebTrust for Certification authorities audit and may be made available to customer under special Agreement

- 2-

o o

The Symantec Security and Audit Requirements (SAR) Guide, which describes detailed requirements for Symantec and Affiliates concerning personnel, physical, telecommunications, logical, and cryptographic key management security, and Key Ceremony Reference Guide, which presents detailed key management operational requirements.

Ancillary agreements imposed by Symantec. These agreements bind Customers, Subscribers, and Relying Parties of Symantec. Among other things, the agreements flow down STN Standards to these STN Participants and, in some cases, state specific practices for how they must meet STN Standards.

In many instances, the CPS refers to these ancillary documents for specific, detailed practices implementing STN Standards where including the specifics in the CPS could compromise the security of Symantecs Sub-domain of the STN.

1.2

Document Name and Identification

This document is the Symantec Trust Network (STN) Certification Practice Statement (CPS). STN Certificates contain object identifier values corresponding to the applicable STN Class of Certificate as listed in section 1.2 of the STN CP. Therefore, Symantec has not assigned this CPS an object identifier value. Certificate Policy Object Identifiers are used in accordance with Section 7.1.6. Domain validated and organization validated SSL Certificates contain the corresponding OID value in section 1.2 of the STN CP that indicates adherence to and compliance with the CA / Browser Forum Baseline Requirements.

1.3 1.3.1

PKI Participants Certification Authorities

The term Certification Authority (CA) is an umbrella term that refers to all entities authorized to issue public key certificates within the STN. The CA term encompasses a subcategory of issuers 5 called Primary Certification Authorities (PCA). PCAs act as roots of four domains , one for each class of Certificate. Each PCA is a Symantec entity. Subordinate to the PCAs are Certification Authorities that issue Certificates to end-user Subscribers or other CAs. Symantec also operates the Symantec Class 3 Internal Administrator CA hierarchy that is limited to Symantec internal administrative uses. Symantec also operates the Symantec Universal Root Certification Authority and the Symantec ECC Universal Root Certification Authority. The Universal Root CAs issue Class 3 and selected Class 2 Subordinate CAs. Symantec enterprise customers may operate their own CAs as subordinate CAs to a public STN PCA. Such a customer enters into a contractual relationship with Symantec to abide by all the requirements of the STN CP and the STN CPS. These subordinate CAs may, however implement a more restrictive practices based on their internal requirements.

1.3.2

Registration Authorities

A Registration Authority is an entity that performs identification and authentication of certificate applicants for end-user certificates, initiates or passes along revocation requests for certificates
5

Class 4 certificates are not currently issued by the STN

- 3-

for end-user certificates, and approves applications for renewal or re-keying certificates on behalf of a STN CA. Symantec may act as an RA for certificates it issues. Third parties, who enter into a contractual relationship with Symantec, may operate their own RA and authorize the issuance of certificates by a STN CA. Third party RAs must abide by all the requirements of the STN CP, the STN CPS and the terms of their enterprise services agreement with Symantec. RAs may, however implement more restrictive practices based on their internal 6 requirements.

1.3.3

Subscribers

Subscribers under the STN include all end users (including entities) of certificates issued by a STN CA. A subscriber is the entity named as the end-user Subscriber of a certificate. End-user Subscribers may be individuals, organizations or, infrastructure components such as firewalls, routers, trusted servers or other devices used to secure communications within an Organization. In some cases certificates are issued directly to individuals or entities for their own use. However, there commonly exist other situations where the party requiring a certificate is different from the subject to whom the credential applies. For example, an organization may require certificates for its employees to allow them to represent the organization in electronic transactions/business. In such situations the entity subscribing for the issuance of certificates (i.e. paying for them, either through subscription to a specific service, or as the issuer itself) is different from the entity which is the subject of the certificate (generally, the holder of the credential). Two different terms are used in this CPS to distinguish between these two roles: "Subscriber", is the entity which contracts with Symantec for the issuance of credentials and; Subject", is the person to whom the credential is bound. The Subscriber bears ultimate responsibility for the use of the credential but the Subject is the individual that is authenticated when the credential is presented. When Subject is used, it is to indicate a distinction from the Subscriber. When Subscriber is used it may mean just the Subscriber as a distinct entity but may also use the term to embrace the two. The context of its use in this CPS will invoke the correct understanding. CAs are technically also subscribers of certificates within the STN, either as a PCA issuing a self signed Certificate to itself, or as a CA issued a Certificate by a superior CA. References to end entities and subscribers in this CP, however, apply only to end -user Subscribers.

1.3.4

Relying Parties

A Relying Party is an individual or entity that acts in reliance of a certificate and/or a digital signature issued under the STN. A Relying party may, or may not also be a Subscriber within the STN.

1.3.5

Other Participants

Not applicable

An example of a third party RA is a customer of Managed PKI services customer.

- 4-

1.4 1.4.1
1.4.1.1

Certificate Usage Appropriate Certificate Usages

Certificates Issued to Individuals

Individual Certificates are normally used by individuals to sign and encrypt e-mail and to authenticate to applications (client authentication). While the most common usages for individual certificates are included in Table 1 below, an individual certificate may be used for other purposes, provided that a Relying Party is able to reasonably rely on that certificate and the usage is not otherwise prohibited by law, the STN CP, the CPS under which the certificate has been issued and any agreements with Subscribers.
Certificate Class Low assurance level Class 1 Certificates Class 2 Certificates Class 3 Certificates Assurance Level Medium assurance level High assurance level Signing Usage Encryption Client Authentication

Table 1. Individual Certificate Usage 1.4.1.2 Certificates Issued to Organizations

Organizational Certificates are issued to organizations after authentication that the Organization legally exists and that other Organization attributes included in the certificate (excluding nonverified subscriber information) are authenticated e.g. ownership of an Internet or e-mail domain. It is not the intent of this CPS to limit the types of usages for Organizational Certificates. While the most common usages are included in Table 2 below, an Organizational Certificate may be used for other purposes, provided that a Relying Party is able to reasonably rely on that certificate and the usage is not otherwise prohibited by law, by the STN CP, by any CPS under which the certificate has been issued and any agreements with Subscribers.
Assurance Level Certificate Class
Class 3 Certificates Class 3 EV SSL Certificates Class 3 EV Code Signing Certificates Class 3 OV Certificates

Usage High Code/ Content Signing Secure SSL/TLSsessions

7

High with Extended Validation

High with CABF OV Validation

Authen tication

Signing and Encryption

Table 2. Organizational Certificate Usage

In limited circumstances Class 2 certificates may be issued by a Managed MPKI customer to an affiliated organization (and not an individual within the organization). Such certificate may be used for organization authentication and application signing only. Except as expressly authorized by Symantec through an Enterprise Service Agreement imposing authentication and practice requirements consistent with the security standards of this CPS, Subscribers are prohibited

- 5-

1.4.1.3

Assurance levels

Low assurance certificates are certificates that should not be used for authentication purposes or to support Non-repudiation. The digital signature provides modest assurances that the e-mail originated from a sender with a certain e-mail address. The Certificate, however, provides no proof of the identity of the Subscriber. The encryption application enables a Relying Party to use the Subscribers Certificate to encrypt messages to the Subscriber, although the sending Relying Party cannot be sure that the recipient is in fact the person named in the Certificate. Medium assurance certificates are certificates that are suitable for securing some inter- and intra-organizational, commercial, and personal e-mail requiring a medium level of assurances of the Subscriber identity, in relation to Class 1 and 3. High assurance certificates are individual and organizational certificates Class 3 Certificates that provide a high level of assurance of the identity of the Subscriber in comparison with Class 1 and 2. High assurance with extended validation certificates are Class 3 certificates issued by Symantec in conformance with the Guidelines for Extended Validation Certificates.

1.4.2

Prohibited Certificate Uses

Certificates shall be used only to the extent the use is consistent with applicable law, and in particular shall be used only to the extent permitted by applicable export or import laws. Symantec Certificates are not designed, intended, or authorized for use or resale as control equipment in hazardous circumstances or for uses requiring fail-safe performance such as the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control systems, or weapons control systems, where failure could lead directly to death, personal injury, or severe environmental damage. Also, Class 1 Certificates shall not be used as proof of identity or as support of non repudiation of identity or authority. Client Certificates are intended for client applications and shall not be used as server or organizational Certificates. CA Certificates may not be used for any functions except CA functions. In addition, end-user Subscriber Certificates shall not be used as CA Certificates. Symantec periodically rekeys Intermediate CAs. Third party applications or platforms that have an Intermediate CA embedded as a root certificate may not operate as designed after the Intermediate CA has been rekeyed. Symantec therefore does not warrant the use of Intermediate CAs as root certificates and recommends that Intermediate CAs not be embedded into applications and/or platforms as root certificates. Symantec recommends the use of PCA Roots as root certificates.

1.5 1.5.1

Policy Administration Organization Administering the Document

Symantec Corporation 350 Ellis Street Mountain View CA 94043 USA

from using this certificate for code and content signing, SSL encryption and S/mime signing and such key usage will be disabled for these certificates.

- 6-

1.5.2

Contact Person

PKI Policy Manager, Symantec Trust Network Policy Management Authority c/o Symantec Corporation 350 Ellis Street Mountain View, CA 94043 USA +1 (650) 527-8000 (voice) +1 (650) 527-8050 (fax) practices@symantec.com

1.5.3

Person Determining CP Suitability for the Policy

The STN Policy Management Authority (PMA) determines the suitability and applicability of this CPS.

1.5.4

CPS Approval Procedure

Approval of this CPS and subsequent amendments shall be made by the PMA. Amendments shall either be in the form of a document containing an amended form of the CPS or an update notice. Amended versions or updates shall be linked to the Practices Updates and Notices section of the Symantec Repository located at: www.symantec.com/about/profile/policies/repository.jsp. Updates supersede any designated or conflicting provisions of the referenced version of the CPS. The PMA shall determine whether changes to the CPS require a change in the Certificate policy object identifiers of the Certificate policies corresponding to each Class of Certificate.

1.6

Definitions and Acronyms

See Appendix A for a table of acronyms and definitions.

2. Publication and Repository Responsibilities

2.1 Repositories

Symantec is responsible for the repository functions for its own CAs and the CAs of its Enterprise Customers (Managed PKI customers). Symantec publishes Certificates it issues to end-user Subscribers in the repository in accordance with CPS 2.2. Upon revocation of an end-user Subscribers Certificate, Symantec publishes notice of such revocation in the repository. Symantec issues CRLs for its own CAs and the CAs of Service Centers and Enterprise Customers within its Sub-domain, pursuant to the provisions of this CPS. In addition, Enterprise Customers who have contracted for Online Certificate Status Protocol (OCSP) services, Symantec provides OCSP services pursuant to the provisions of this CPS.

2.2

Publication of Certificate Information

Symantec maintains a web-based repository that permits Relying Parties to make online inquiries regarding revocation and other Certificate status information. Symantec provides Relying Parties with information on how to find the appropriate repository to check Certificate status and, if OCSP (Online Certificate Status Protocol) is available, how to find the right OCSP responder. Symantec publishes the Certificates it issues on behalf of its own CAs, and the CAs of Client Service Centers in their Sub-domain. Upon revocation of an end-user Subscribers Certificate,

- 7-

Symantec shall publish notice of such revocation in the repository. In addition, Symantec issues Certificate Revocation Lists (CRLs) and, if available, provide OCSP services (Online Certificate Status Protocol) for its own CAs and the CAs of Service Centers within its Sub-domain. Symantec will at all times publish a current version of: The STN CP This STN CPS, Subscriber Agreements, Relying Party Agreements Symantec is responsible for the repository function for: Symantecs Public Primary Certification Authorities (PCAs) and Symantec Infrastructure/Administrative CAs supporting the STN, and Symantecs CAs and Enterprise Customers CAs that issue Certificates within Symantecs Sub-domain of the STN. Symantec publishes certain CA information in the repository section of Symantecs web site at www.symantec.com/about/profile/policies/repository.jsp as described below. Symantec publishes the STN CP, this CPS, Subscriber Agreements, and Relying Party Agreements in the repository section of Symantecs web site. Symantec publishes Certificates in accordance with Table 3 below.
Certificate Type STN PCA and STN Issuing Root CA Certificates Publication Requirements Available to Relying Parties through inclusion in current browser software and as part of a Certificate Chain that can be obtained with the end-user Subscriber Certificate through the query functions described below. Available to Relying Parties as part of a Certificate Chain that can be obtained with the end-user Subscriber Certificate through the query functions described below. Available through query of the LDAP directory server at directory.verisign.com. Available through query of the LDAP directory server at directory.verisign.com. Optionally published and available to Relying Parties through query functions in the Symantec Repository at https://digitalid.verisign.com/services/client/index.html and query of the LDAP directory server at directory.verisign.com, except for Class 3 SSL and Code Signing Certificates which are available through query functions in the Symantec Repository at https://digitalid.verisign.com/services/server/search.htm. Made available through the query functions listed above, although at the discretion of the Managed PKI Customer, the Certificate may be accessible only via a search using the Certificates serial number. Not available through public query

STN Issuing CA Certificates

Certificate of the STN CA supporting Managed PKI Lite Certificates and CA Certificates of Managed PKI Customers Symantec OCSP Responder Certificates End-User Subscriber Certificates with exceptions for certain Class 3 Certificates depending on usage.

End-User Subscriber Certificates issued through Managed PKI Customers

End-User Subscriber Certificates issued by Symantec Class 3 Organizational VIP Device CA

Table 3 Certificate Publication Requirements

2.3

Time or Frequency of Publication

Updates to this CPS are published in accordance with Section 9.12. Updates to Subscriber Agreements and Relying Party Agreements are published as necessary. Certificates are

- 8-

published upon issuance. Certificate status information is published in accordance with the provisions of this CPS.

2.4

Access Controls on Repositories

Information published in the repository portion of the Symantec web site is publicly-accessible information. Read only access to such information is unrestricted. Symantec requires persons to agree to a Relying Party Agreement or CRL Usage Agreement as a condition to accessing Certificates, Certificate status information, or CRLs. Symantec has implemented logical and physical security measures to prevent unauthorized persons from adding, deleting, or modifying repository entries.

3. Identification and Authentication

3.1 Naming

Unless where indicated otherwise in this STN CP, this CPS or the content of the digital certificate, names appearing in Certificates issued under STN are authenticated.

3.1.1

Type of Names

While the STN is currently owned by Symantec Corporation, legacy certificates have been issued in the name of the former owner. Any legacy certificate that indicates the Organization (O) as VeriSign, Inc. and Organizational Unit (OU) as VeriSign Trust Network shall mean Symantec Corporation and the Symantec Trust Network, respectively.

STN CA Certificates contain an X.501 Distinguished Name (DN) in the Issuer and Subject fields. STN CA Distinguished Names consist of the components specified in Table 4 below.
Attribute Country (C) = Organization (O) = Organizational Unit (OU) = Value US or not used. 8 Symantec Corporation, or <organization name> Symantec CA Certificates may contain multiple OU attributes. Such attributes may contain one or more of the following: CA Name Symantec Trust Network A statement referencing the applicable Relying Party Agreement governing terms of use of the Certificate A copyright notice. Text to describe the type of Certificate. Not used. Not used except for the Symantec Commercial Software Publishers CA, which uses Internet. This attribute includes the CA Name (if the CA Name is not specified in an OU attribute) or is not used.

State or Province (S) = Locality (L) = Common Name (CN) =

Table 4 Distinguished Name Attributes in CA Certificates End-user Subscriber Certificates contain an X.501 DN in the Subject name field and consist of the components specified in Table 5 below.
Attribute Country (C) = Organization (O) = Value 2 letter ISO country code or not used. The Organization attribute is used as follows: Symantec Corporation for OCSP Responder and optionally for

For a CA dedicated to a customer organization, the (o=) component shall be the legal name of the organization.

- 9-

Attribute

Value 9 individual Certificates that do not have an organization affiliation.

Organizational Unit (OU) =

State or Province (S) = Locality (L) = Common Name (CN) =

E-Mail Address (E) =

Subscriber organizational name for web server Certificates and individual Certificates that have an organization affiliation. Symantec end-user Subscriber Certificates may contain multiple OU attributes. Such attributes may contain one or more of the following: Subscriber organizational unit (for organizational Certificates and individual Certificates that have an organization affiliation) Symantec Trust Network A statement referencing the applicable Relying Party Agreement governing terms of use of the Certificate A copyright notice 10 Authenticated by Symantec and Member, Symantec Trust Network in Certificates whose applications were authenticated by Symantec Persona Not Validated for Class 1 Individual Certificates 11 Text to describe the type of Certificate. No organization affiliation (for code signing certificates issued to individuals) Indicates the Subscribers State or Province (State is not a require d field in certificates issued to individuals). Indicates the Subscribers Locality (Locality is not a required field in certificates issued to individuals). This attribute includes: The OCSP Responder Name (for OCSP Responder Certificates) Domain name (for web server Certificates) Organization name (for code/object signing Certificates) Persons name (for individual Certificates or code-signing certificates issued to individuals). Persona Not Validated for Class 1 individual Certificates E-mail address for Class 1 individual Certificates and generally for MPKI Subscriber Certificates

Table 5 Distinguished Name Attributes in End User Subscriber Certificates The Common Name (CN=) component of the Subject distinguished name of end-user Subscriber Certificates is authenticated in the case of Class 2-3 Certificates. The authenticated Common Name value included in the Subject DN of Organizational Certificates is a domain name) or the legal name of the organization or unit within the organization. The authenticated Common Name value included in the Subject DN of a Class 3 Organizational ASB Certificate, however, is the generally accepted personal name of the organizational representative authorized to use the organizations private key, and the organization (O=) component is the legal name of the organization. The Common Name value included in the Subject DN of individual Certificates represents the individuals generally accepted personal name.

EV SSL certificate content and profile requirements are discussed in Section 6 of Appendix B3 to this CPS.
9

In the case of the Symantec Corporation organization, under certain approved cases for Class 2 certificates, the O value may additionally include a suffix containing internal information used for internal purposes. Symantec attests that the organization name in the format Symantec Corporation <suffix> (e.g., Symantec Corporation Build 5315) shall accurately represent the legal entity Symantec Corporation. 10 An affiliate or customer that contracts to perform the RA services shall indicate the name of the organization performing the Subscriber authentication. 11 Under certain approved cases, Class 2 certificates may be issued for internal purposes. Such certificates shall contain the Symantec organization name in the DN and an OU value reflecting the inherent lack of trust in the certificate for usage other than the intended internal purpose.

- 10 -

3.1.1.1

CABF Naming Requirements

EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 9 of Appendix B1, Appendix C and Appendix D, respectively.

3.1.2

Need for Names to be Meaningful

Class 2 and 3 end-user Subscriber Certificates contain names with commonly understood semantics permitting the determination of the identity of the individual or organization that is the Subject of the Certificate. STN CA certificates contain names with commonly understood semantics permitting the determination of the identity of the CA that is the Subject of the Certificate.

3.1.3

Anonymity or Pseudonymity of Subscribers

The identity of Class 1 individual Subscribers is not authenticated. Class 1 subscribers may use pseudonyms. Unless when required by law or requested by a State or Government authority to protect the identity of certain end user subscribers (e.g., minors, or sensitive government employee information), Class 2 and 3 Subscribers are not permitted to use pseudonyms (names other than a Subscribers true personal or organization al name). Each request for anonymity in a certificate will be evaluated on its merits by the PMA and, if allowed the certificate will indicate that identity has been authenticated but is protected.

3.1.4

Rules for Interpreting Various Name Forms

No stipulation

3.1.5

Uniqueness of Names

Symantec ensures that Subject Distinguished Name (DN) of the Subscriber is unique within the domain of a specific CA through automated components of the Subscriber enrollment process. It is possible for a Subscriber to have two or more certificates with the same Subject DN.

3.1.6

Recognition, Authentication, and Role of Trademarks

Certificate Applicants are prohibited from using names in their Certificate Applications that infringe upon the Intellectual Property Rights of others. Symantec, however, does not verify whether a Certificate Applicant has Intellectual Property Rights in the name appearing in a Certificate Application or arbitrate, mediate, or otherwise resolve any dispute concerning the ownership of any domain name, trade name, trademark, or service mark. Symantec is entitled, without liability to any Certificate Applicant, to reject or suspend any Certificate Application because of such dispute.

3.2 3.2.1

Initial Identity Validation Method to Prove Possession of Private Key

The certificate applicant must demonstrate that it rightfully holds the private key corresponding to the public key to be listed in the Certificate. The method to prove possession of a private key shall be PKCS #10, another cryptographically equivalent demonstration, or another Symantecapproved method. This requirement does not apply where a key pair is generated by a CA on behalf of a Subscriber, for example where pre-generated keys are placed on smart cards.

- 11 -

3.2.2

Authentication of Organization identity

Whenever a certificate contains an organization name, the identity of the organization and other enrollment information provided by Certificate Applicants (except for Non-verified Subscriber Information) is confirmed in accordance with the procedures set forth in Symantecs documented Validation Procedures. At a minimum Symantec shall: Determine that the organization exists by using at least one third party identity proofing service or database, or alternatively, organizational documentation issued by or filed with the applicable government agency or competent authority that confirms the existence of the organization, Confirm by telephone, confirmatory postal mail, or comparable procedure to the Certificate Applicant certain information about the organization, that the organization has authorized the Certificate Application, and that the person submitting the Certificate Application on behalf of the Certificate Applicant is authorized to do so. When a certificate includes the name of an individual as an authorized representative of the Organization, the employment of that individual and his/her authority to act on behalf of the Organization shall also be confirmed. Where a domain name or e-mail address is included in the certificate Symantec authenticates the Organizations right to use that domain name either as a fully qualified Domain name or an e-mail domain. Additional checks necessary to satisfy United States export regulations and licenses issued by the United States Department of Commerce Bureau of Industry and Science (BIS) are performed by Symantec and Affiliates when required. Additional procedures are performed for specific types of Certificates as described in Table 6 below.
Certificate Type Extended Validation (EV) Certificates Additional Procedures Symantecs procedures for issuing EV SSL Certificates are described in Appendix B1 to this CPS. Symantecs procedures for issuing EV Code-Signing Certificates are described in Appendix C to this CPS. Symantecs procedures for issuing OV and DV certificates, distinguished throughout the CPS as CABF requirements for OV and DV certificates. Symantec verifies that the Organization is a bank or financial institution, or classified under one of the following SIC codes: 60xx Depository institutions 61xx Non-depository credit institutions 62xx Security, commodity brokers, and services 63xx Insurance carriers 64xx Insurance agents, brokers, and services 67xx Holding and other investment offices 7372 Prepackaged software 7373 Computer integrated systems design 7374 Data processing and preparation 3661 Telephone and telegraph apparatus 8721 Accounting, auditing, and bookkeeping. Symantec verifies that the key pair was generated on FIPS 140 certified hardware

Organization Validated (OV) and Domain Validated (DV) Certificates OFX Server IDs

Hardware Protected SSL Certificate and Hardware Protected EV CodeSigning Certificate

- 12 -

Certificate Type Managed PKI for Intranet SSL Certificate Authenticated Content Signing (ACS) Certificate

Additional Procedures Symantec verifies that the host name or IP address assigned to a Device is not accessible from the Internet (publicly facing), and is owned by the Certificate Subscriber. Before Symantec digitally signs any content using ACS it authenticates that the content is the original content signed by the Organization using its Code Signing Certificate.

Table 6 Specific Authentication Procedures

3.2.2.1

CABF Verification Requirements for Organization Applicants

EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 11 of Appendix B1, Appendix C and Appendix D, respectively.. 3.2.2.2 Mozilla Verification Requirements for Organization Applicants

For requests for internationalized domain names (IDNs) in Certificates, Symantec performs domain name owner verification to detect cases of homographic spoofing of IDNs. Symantec employs an automated process that searches various whois services to find the owner of a particular domain. A search failure result is flagged for manual review and the RA manually rejects the Certificate Request. Additionally, the RA rejects any domain name that visually appears to be made up of multiple scripts within one hostname label. Symantec actively participates in the CA/Browser Forum providing input to the standards for IDN Certificates and fully commits to conforming with standards drafted by that body.

3.2.3

Authentication of Individual Identity

Authentication of individual identity differs according to the Class of Certificate. The minimum authentication standard for each class of STN certificate is explained in Table 7 below.

Certificate Class Class 1 Class 2

Class 3

Authentication of Identity No identity authentication. There is a limited confirmation of the Subscribers e -mail address by requiring the Subscriber to be able to answer an e-mail to that address. Authenticate identity by matching the identity provided by the Subscriber to: information residing in the database of a Symantec-approved identity proofing service, such as a major credit bureau or other reliable source of information providing, or information contained in the business records or databases of business information (employee or customer directories) of an RA approving certificates to its own affiliated individuals The authentication of Class 3 individual Certificates is based on the personal (physical) presence of the Certificate Applicant before an agent of the CA or RA, or before a notary public or other official with comparable authority within the Certificate Applicants jurisdiction. The agent, notary or other official shall check the identity of the Certificate Applicant against a well-recognized form of governmentissued photographic identification, such as a passport or drivers license and one other identification credential. The authentication of Class 3 Administrator certificates is based on authentication of the organization and a confirmation from the organization of the identity and authorization of the person to act as Administrator.

- 13 -

Certificate Class

Authentication of Identity Symantec may also have occasion to approve Certificate Applications for their own Administrators. Administrators are Trusted Persons within an organization. In this case, authentication of their Certificate Applications shall be based on confirmation of their identity in connection with their employment or retention as an independent 12 contractor and background checking procedures. The identity of the Certificate Subscriber is verified substantially in compliance with the requirements of the X.509 Certificate Policy for the Federal Bridge Certification Authority (FBCA) and the Symantec Non-Federal Shared Service Provider (SSP) Certification Practice Statement.

Shared Service Provider (SSP) Certificates for Non-Federal entities

Table 7. Authentication of individual identity

3.2.4

Non-Verified Subscriber information

Non-verified subscriber information includes: 13 Organization Unit (OU) with certain exceptions Subscribers name in Class 1 certificates Any other information designated as non-verified in the certificate.

3.2.5

Validation of Authority

Whenever an individuals name is associated with an Organization name in a certificate in such a way to indicate the individuals affiliation or authorization to act on behalf of the Organization the Symantec or a RA: determines that the Organization exists by using at least one third party identity proofing service or database, or alternatively, organizational documentation issued by or filed with the applicable government that confirms the existence of the organization, and Uses information contained in the business records or databases of business information (employee or customer directories) of an RA approving certificates to its own affiliated individuals or confirms by telephone, confirmatory postal mail, or comparable procedure to the organization, the employment with the Organization of the individual submitting the Certificate Application and, when appropriate, his/her authority to act on behalf of the Organization.

3.2.6

Criteria for Interoperation

Symantec may provide interoperation services that allow a non-STN CA to be able to interoperate with the STN by unilaterally certifying that CA. CAs enabled to interoperate in this way will comply with the STN CP as supplemented by additional policies when required. Symantec shall only allow interoperation with the STN of a non-STN CA in circumstances where the CA, at a minimum: Enters into a contractual agreement with Symantec

12 Symantec may approve Administrator Certificates to be associated with a non-human recipient such as a device, or a server. Authentication of a Class 3 Administrator Certificate Application for a non-human recipient shall include: Authentication of the existence and identity of the service named as the Administrator in the Certificate Application Authentication that the service has been securely implemented in a manner consistent with it performing an Administrative function Confirmation of the identity and authorization of the person enrolling for the Administrator certificate for the service named as Administrator in the Certificate Application. 13 Domain-validated and organization-validated certificates that attest compliance with CA/Browser Forum guidelines may contain Organizational Unit values that are validated.

- 14 -

Operates under a CPS that meets STN requirements for the classes of certificates it will issues Passes a compliance assessment before being allowed to interoperate Passes an annual compliance assessment for ongoing eligibility to interoperate.

3.3

Identification and Authentication for Re-key Requests

Prior to the expiration of an existing Subscribers Certificate, it is necessary for the Subscriber to obtain a new certificate to maintain continuity of Certificate usage. Symantec generally requires that the Subscriber generate a new key pair to replace the expiring key pair (technically defined as rekey) However, in certain cases (i.e., for web server certificates) Subscribers may request a new certificate for an existing key pair (technically defined as renewal). Generally speaking, both Rekey and Renewal are commonly described as Certific ate Renewal, focusing on the fact that the old Certificate is being replaced with a new Certificate and not emphasizing whether or not a new key pair is generated. For all Classes and Types of STN Certificates, except for Class 3 Server Certificates, this distinction is not important as a new key pair is always generated as part of Symantecs end-user Subscriber Certificate replacement process. However, for Class 3 Server Certificates, because the Subscriber key pair is generated on the web server and most web server key generation tools permit the creation of a new Certificate Request for an existing key pair, there is a distinction between rekey and renewal.

3.3.1

Identification and Authentication for Routine Re-key

Re-key procedures ensure that the person or organization seeking to rekey an end-user Subscriber Certificate is in fact the Subscriber of the Certificate. One acceptable procedure is through the use of a Challenge Phrase (or the equivalent thereof), or proof of possession of the private key. Subscribers choose and submit with their enrollment information a Challenge Phrase. Upon renewal of a Certificate, if a Subscriber correctly submits the Subscribers Challenge Phrase (or the equivalent thereof) with the Subscribers reenrollment information, and the enrollment information (including Corporate and Technical contact information) has not changed, a renewal Certificate is automatically issued. As an alternative to using a challenge phrase (or equivalent) Symantec may send an e-mail message to the e-mail address associated with the verified corporate contact for the certificate being renewed, requesting confirmation of the Certificate renewal order and authorization to issue the Certificate. Upon receipt of confirmation authorizing issuance of the Certificate, Symantec will issue the 14 Certificate if the enrollment information (including Corporate and Technical contact information ) has not changed. After rekeying or renewal in this fashion, and on at least alternative instances of subsequent rekeying or renewal thereafter, Symantec or the RA reconfirms the identity of the Subscriber in accordance with the identification and authentication requirements of an original Certificate 15 Application. In particular, for retail Class 3 Organizational SSL Certificates, Symantec re-authenticates the Organization name and domain name included in the certificate at intervals described in section 6.3.2. In circumstances where: The challenge phrase is correctly used for the subsequent renewal certificate, or a confirmatory response is obtained to an e-mail to the corporate contact and: The certificate Distinguished Name has not been changed, and
14

If contact information has changed via an approved formal contact change procedure the certificate shall still qualify for automated renewal. 15 The authentication of a request to rekey/renew a Class 3 Organizational ASB Certificate, however, requires the use of a Challenge Phrase as well as the same identification and authentication as for the original Certificate Application.

- 15 -

The Corporate and Technical Contact information remains unchanged from that which was previously verified,

Symantec will not have to reconfirm by telephone, confirmatory postal mail, or comparable procedure to the Certificate Applicant certain information about the organization, that the organization has authorized the Certificate Application, and that the person submitting the Certificate Application on behalf of the Certificate Applicant is authorized to do so. Rekey after 30-days from expiration of the Certificate are re-authenticated as an original Certificate Application and are not automatically issued.

3.3.2

Identification and Authentication for Re-key After Revocation

Re-key/renewal after revocation is not permitted if the revocation occurred because: the Certificate (other than a Class 1 Certificate) was issued to a person other than the one named as the Subject of the Certificate, or the Certificate (other than a Class 1 Certificate) was issued without the authorization of the person or entity named as the Subject of such Certificate, or the entity approving the Subscribers Certificate Application discovers or has reason t o believe that a material fact in the Certificate Application is false. or For any other reason deemed necessary by Symantec to protect the STN Subject to the foregoing paragraph, renewal of an Organizational or CA Certificate following revocation of the Certificate is permissible as long as renewal procedures ensure that the Organization or CA seeking renewal is in fact the Subscriber of the Certificate. Renewed Organizational Certificates shall contain the same Subject DN as the Subject DN of the Organizational Certificate being renewed. Renewal of an individual Certificate following revocation must ensure that the person seeking renewal is, in fact, the Subscriber. One acceptable procedure is the use of a Challenge Phrase (or the equivalent thereof). Other than this procedure or another Symantec-approved procedure, the requirements for the identification and authentication of an original Certificate Application shall be used for renewing a Certificate following revocation.

3.4

Identification and Authentication for Revocation Request

Prior to the revocation of a Certificate, Symantec verifies that the revocation has been requested by the Certificates Subscriber, the entity that approved the Certificate Application. Acceptable procedures for authenticating the revocation requests of a Subscriber include: Having the Subscriber for certain certificate types submit the Subscribers Challenge Phrase (or the equivalent thereof), and revoking the Certificate automatically if it matches the Challenge Phrase (or the equivalent thereof) on record, (Note that this option may not be available to all customers.) Receiving a message from the Subscriber that requests revocation and contains a digital signature verifiable with reference to the Certificate to be revoked, Communication with the Subscriber providing reasonable assurances in light of the Class of Certificate that the person or organization requesting revocation is, in fact the Subscriber. Such communication, depending on the circumstances, may include one or more of the following: telephone, facsimile, e-mail, postal mail, or courier service. Symantec Administrators are entitled to request the revocation of end-user Subscriber Certificates within Symantecs sub-domain. Symantec authenticates the identity of Administrators via access control using SSL and client authentication before permitting them to perform revocation functions, or another STN-approved procedure.

- 16 -

RAs using an Automated Administration Software Module may submit bulk revocation requests to Symantec. Such requests shall be authenticated via a digitally signed request signed with the private key in the RAs Automated Administration hardware token. The requests to revoke a CA Certificate shall be authenticated by Symantec to ensure that the revocation has in fact been requested by the CA.

4. Certificate Life-Cycle Operational Requirements

4.1 4.1.1 Certificate Application Who Can Submit a Certificate Application?

Below is a list of people who may submit certificate applications: Any individual who is the subject of the certificate, Any authorized representative of an Organization or entity, Any authorized representative of a CA, Any authorized representative of an RA.

4.1.2
4.1.2.1

Enrollment Process and Responsibilities

End-User Certificate Subscribers

All end-user Certificate Subscribers shall manifest assent to the relevant Subscriber Agreement that contains representations and warranties described in Section 9.6.3 and undergo an enrollment process consisting of: completing a Certificate Application and providing true and correct information, generating, or arranging to have generated, a key pair, delivering his, her, or its public key, directly or through an RA, to Symantec demonstrating possession and/or exclusive control of the private key corresponding to the public key delivered to Symantec. 4.1.2.2 CABF Certificate Application Requirements

EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 10 of Appendix B1, Appendix C and Appendix D, respectively. 4.1.2.3 CA and RA Certificates

Subscribers of CA and RA Certificates enter into a contract with Symantec. CA and RA Applicants shall provide their credentials to demonstrate their identity and provide contact information during the contracting process. During this contracting process or, at the latest, prior to the Key Generation Ceremony to create a CA or RA key pair, the applicant shall cooperate with Symantec to determine the appropriate distinguished name and the content of the Certificates to be issued by the applicant.
29

On an exceptionary basis there may be instances where subscriber certificates will be issued directly from the root. This exception shall only be used in the event of a subscriber certificate with a key pair size and length that is 2048 bit or less

- 17 -

4.2 4.3 4.3.1 Certificate Application Processing Performing Identification and Authentication Functions

Symantec or an RA shall perform identification and authentication of all required Subscriber information in terms of Section 3.2.

4.3.2

Approval or Rejection of Certificate Applications

Symantec or an RA will approve an application for a certificate if the following criteria are met: Successful identification and authentication of all required Subscriber information in terms of Section 3.2 Payment has been received Symantec or an RA will reject a certificate application if: Identification and authentication of all required Subscriber information in terms of Section 3.2 cannot be completed, or The Subscriber fails to furnish supporting documentation upon request, or The Subscriber fails to respond to notices within a specified time, or Payment has not been received, or The RA believes that issuing a certificate to the Subscriber may bring the STN into disrepute.

4.3.3

Time to Process Certificate Applications

Symantec begins processing certificate applications within a reasonable time of receipt. There is no time stipulation to complete the processing of an application unless otherwise indicated in the relevant Subscriber Agreement, CPS or other Agreement between STN participants. A certificate application remains active until rejected.

4.4 4.4.1

Certificate Issuance CA Actions during Certificate Issuance

A Certificate is created and issued following the approval of a Certificate Application by Symantec or following receipt of an RAs request to issue the Certificate. Symantec creates and issues to a Certificate Applicant a Certificate based on the information in a Certificate Application following approval of such Certificate Application.

4.4.2

Notifications to Subscriber by the CA of Issuance of Certificate

Symantec shall, either directly or through an RA, notify Subscribers that they have created such Certificates, and provide Subscribers with access to the Certificates by notifying them that their Certificates are available. Certificates shall be made available to end-user Subscribers, either by allowing them to download them from a web site or via a message sent to the Subscriber containing the Certificate.

4.4.3

CABF Requirement for Certificate Issuance by a Root CA

EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN

- 18 -

Supplemental Procedures, in section 12 of Appendix B1, Appendix C and Appendix D, respectively.

4.5 4.5.1

Certificate Acceptance Conduct Constituting Certificate Acceptance

The following conduct constitutes certificate acceptance: Downloading a Certificate or installing a Certificate from a message attaching it constitutes the Subscribers acceptance of the Certificate. Failure of the Subscriber to object to the certificate or its content constitutes certificate acceptance.

4.5.2

Publication of the Certificate by the CA

Symantec publishes the Certificates it issues in a publicly accessible repository.

4.5.3

Notification of Certificate Issuance by the CA to Other Entities

RAs may receive notification of the issuance of certificates they approve.

4.6 4.6.1

Key Pair and Certificate Usage Subscriber Private Key and Certificate Usage

Use of the Private Key corresponding to the public key in the certificate shall only be permitted once the Subscriber has agreed to the Subscriber Agreement and accepted the certificate. The certificate shall be used lawfully in accordance with Symantecs Subscriber Agreement the terms of the STN CP and this CPS. Certificate use must be consistent with the KeyUsage field extensions included in the certificate (e.g., if Digital Signature is not enabled then the certificate must not be used for signing). Subscribers shall protect their private keys from unauthorized use and shall discontinue use of the private key following expiration or revocation of the certificate. Parties other than the Subscriber shall not archive the Subscriber Private Key except as set forth in section 4.12.

4.6.2

Relying Party Public Key and Certificate Usage

Relying parties shall assent to the terms of the applicable Relying Party Agreement as a condition of relying on the certificate. Reliance on a certificate must be reasonable under the circumstances. If the circumstances indicate a need for additional assurances, the Relying Party must obtain such assurances for such reliance to be deemed reasonable. Before any act of reliance, Relying Parties shall independently assess: the appropriateness of the use of a Certificate for any given purpose and determine that the Certificate will, in fact, be used for an appropriate purpose that is not prohibited or otherwise restricted by this CPS. Symantec is not responsible for assessing the appropriateness of the use of a Certificate. That the certificate is being used in accordance with the KeyUsage field extensions included in the certificate (e.g., if Digital Signature is not enabled then the certificate may not be relied upon for validating a Subscribers signature).

- 19 -

The status of the certificate and all the CAs in the chain that issued the certificate. If any of the Certificates in the Certificate Chain have been revoked, the Relying Party is solely responsible to investigate whether reliance on a digital signature performed by an enduser Subscriber Certificate prior to revocation of a Certificate in the Certificate chain is reasonable. Any such reliance is made solely at the risk of the Relying party.

Assuming that the use of the Certificate is appropriate, Relying Parties shall utilize the appropriate software and/or hardware to perform digital signature verification or other cryptographic operations they wish to perform, as a condition of relying on Certificates in connection with each such operation. Such operations include identifying a Certificate Chain and verifying the digital signatures on all Certificates in the Certificate Chain.

4.7

Certificate Renewal

Certificate renewal is the issuance of a new certificate to the subscriber without changing the public key or any other information in the certificate. Certificate renewal is supported for Class 3 certificates where the key pair is generated on a web server as most web server key generation tools permit the creation of a new Certificate Request for an existing key pair.

4.7.1

Circumstances for Certificate Renewal

Prior to the expiration of an existing Subscribers Certificate, it is necessary for the Subscriber to renew a new certificate to maintain continuity of Certificate usage. A certificate may also be renewed after expiration.

4.7.2

Who May Request Renewal

Only the subscriber for an individual certificate or an authorized representative for an Organizational certificate may request certificate renewal.

4.7.3

Processing Certificate Renewal Requests

Renewal procedures ensure that the person or organization seeking to renew an end-user Subscriber Certificate is in fact the Subscriber (or authorized by the Subscriber) of the Certificate. One acceptable procedure is through the use of a Challenge Phrase (or the equivalent thereof), or proof of possession of the private key. Subscribers choose and submit with their enrollment information a Challenge Phrase (or the equivalent thereof). Upon renewal of a Certificate, if a Subscriber correctly submits the Subscribers Challenge Phrase (or the equivalent thereof) with the Subscribers reenrollment information, and the enrollment information (including Corporate 16 and Technical contact information ) has not changed, a renewal Certificate is automatically issued. As an alternative to using a challenge phrase (or equivalent) Symantec may send an email message to the e-mail address associated with the verified corporate contact for the certificate being renewed, requesting confirmation of the Certificate renewal order and authorization to issue the Certificate. Upon receipt of confirmation authorizing issuance of the Certificate, Symantec will issue the Certificate if the enrollment information (including Corporate 17 and Technical contact information ) has not changed.

16

If contact information has changed via an approved formal contact change procedure the certificate shall still qualify for automated renewal. 17 If contact information has changed via an approved formal contact change procedure the certificate shall still qualify for automated renewal.

- 20 -

After renewal in this fashion, and on at least alternative instances of subsequent renewal thereafter, Symantec or an RA shall reconfirm the identity of the Subscriber in accordance with the requirements specified in this CPS for the authentication of an original Certificate Application. In particular, for retail Class 3 Organizational SSL Certificates, Symantec re-authenticates the Organization name and domain name included in the certificate at intervals described in section 6.3.2. In circumstances where: The challenge phrase is correctly used for the subsequent renewal certificate, or a confirmatory response is obtained to an e-mail to the corporate contact, and: The certificate Distinguished Name has not been changed, and The Corporate and Technical Contact information remains unchanged from that which was previously verified, Symantec will not have to reconfirm by telephone, confirmatory postal mail, or comparable procedure to the Certificate Applicant certain information about the organization, that the organization has authorized the Certificate Application and that the person submitting the Certificate Application on behalf of the Certificate Applicant is authorized to do so. Other than this procedure or another Symantec-approved procedure, the requirements for the authentication of an original Certificate Application shall be used for renewing an end-user Subscriber Certificate.

4.7.4

Notification of New Certificate Issuance to Subscriber

Notification of issuance of certificate renewal to the Subscriber is in accordance with Section 4.3.2

4.7.5

Conduct Constituting Acceptance of a Renewal Certificate

Conduct constituting Acceptance of a renewed certificate is in accordance with Section 4.4.1

4.7.6

Publication of the Renewal Certificate by the CA

The renewed certificate is published in Symantecs publicly accessible repository.

4.7.7

Notification of Certificate Issuance by the CA to Other Entities

RAs may receive notification of the issuance of certificates they approve.

4.8

Certificate Re-Key

Certificate rekey is the application for the issuance of a new certificate that certifies the new public key. Certificate rekey is supported for all certificate Classes.

4.8.1

Circumstances for Certificate Re-Key

Prior to the expiration of an existing Subscribers Certificate, it is necessary for the Subscriber to re-key the certificate to maintain continuity of Certificate usage. A certificate may also be re-keyed after expiration.

- 21 -

4.8.2

Who May Request Certification of a New Public Key

Only the subscriber for an individual certificate or an authorized representative for an Organizational certificate may request certificate renewal

4.8.3

Processing Certificate Re-Keying Requests

Re-key procedures ensure that the person or organization seeking to renew an end-user Subscriber Certificate is in fact the Subscriber (or authorized by the Subscriber) of the Certificate. One acceptable procedure is through the use of a Challenge Phrase (or the equivalent thereof), or proof of possession of the private key. Subscribers choose and submit with their enrollment information a Challenge Phrase (or the equivalent thereof). Upon renewal of a Certificate, if a Subscriber correctly submits the Subscribers Challenge Phrase (or the equivalent thereof) with the Subscribers reenrollment information, and the enrollment information (including contact 18 information ) has not changed, a renewal Certificate is automatically issued. Subject to the provisions of Section 3.3.1, after re-keying in this fashion, and on at least alternative instances of subsequent re-keying thereafter, Symantec or an RA shall reconfirm the identity of the Subscriber in accordance with the requirements specified in this CPS for the authentication of an original Certificate Application. Other than this procedure or another Symantec-approved procedure, the requirements for the authentication of an original Certificate Application shall be used for re-keying an end-user Subscriber Certificate.

4.8.4

Notification of New Certificate Issuance to Subscriber

Notification of issuance of a re-keyed certificate to the Subscriber is in accordance with Section 4.3.2

4.8.5

Conduct Constituting Acceptance of a Re-Keyed Certificate

Conduct constituting Acceptance of a re-keyed certificate is in accordance with Section 4.4.1

4.8.6

Publication of the Re-Keyed Certificate by the CA

The re-keyed certificate is published in Symantecs publicly accessible repository.

4.8.7

Notification of Certificate Issuance by the CA to Other Entities

RAs may receive notification of the issuance of certificates they approve.

4.9 4.9.1

Certificate Modification Circumstances for Certificate Modification

Certificate modification refers to the application for the issuance of a new certificate due to changes in the information in an existing certificate (other than the subscribers public key). Certificate modification is considered a Certificate Application in terms of Section 4.1.

18

If contact information has changed via an approved formal contact change procedure the certificate shall still qualify for automated renewal.

- 22 -

4.9.2

Who May Request Certificate Modification

See Section 4.1.1.

4.9.3

Processing Certificate Modification Requests

Symantec or an RA shall perform identification and authentication of all required Subscriber information in terms of Section 3.2.

4.9.4

Notification of New Certificate Issuance to Subscriber

See Section 4.3.2.

4.9.5

Conduct Constituting Acceptance of Modified Certificate

See Section 4.4.1.

4.9.6

Publication of the Modified Certificate by the CA

See Section 4.4.2.

4.9.7

Notification of Certificate Issuance by the CA to Other Entities

See Section 4.4.3.

4.10

Certificate Revocation and Suspension

4.10.1 Circumstances for Revocation

Only in the circumstances listed below, will an end-user Subscriber certificate be revoked by Symantec (or by the Subscriber) and published on a CRL. Upon request from a subscriber who can no longer use (or no longer wishes to use) a certificate for a reason other than one mentioned below, Symantec will flag the certificate as inactive in its database but will not publish the certificate on a CRL. An end-user Subscriber Certificate is revoked if: Symantec, a Customer, or a Subscriber has reason to believe or strongly suspects that there has been a Compromise of a Subscribers private key, Symantec or a Customer has reason to believe that the Subscriber has materially breached a material obligation, representation, or warranty under the applicable Subscriber Agreement, The Subscriber Agreement with the Subscriber has been terminated, The affiliation between an Enterprise Customer with a Subscriber is terminated or has otherwise ended, The affiliation between an organization that is a Subscriber of a Class 3 Organizational ASB Certificate and the organizational representative controlling the Subscribers private key is terminated or has otherwise ended, Symantec or a Customer has reason to believe that the Certificate was issued in a manner not materially in accordance with the procedures required by the applicable CPS, the Certificate (other than a Class 1 Certificate) was issued to a person other than the one named as the Subject of the Certificate, or the Certificate (other than a Class 1 Certificate) was issued without the authorization of the person named as the Subject of such Certificate,

- 23 -

Symantec or a Customer has reason to believe that a material fact in the Certificate Application is false, Symantec or a Customer determines that a material prerequisite to Certificate Issuance was neither satisfied nor waived, In the case of Class 3 organizational Certificates, the Subscribers organization name changes, The information within the Certificate, other than Non-verified Subscriber Information, is incorrect or has changed, The Subscriber identity has not been successfully re-verified in accordance with section 6.3.2, The Subscriber has not submitted payment when due, or The continued use of that certificate is harmful to the STN.

When considering whether certificate usage is harmful to the STN, Symantec considers, among other things, the following: The nature and number of complaints received The identity of the complainant(s) Relevant legislation in force Responses to the alleged harmful use from the Subscriber When considering whether the use of a Code Signing Certificate is harmful to the STN, Symantec additionally considers, among other things, the following: The name of the code being signed The behavior of the code Methods of distributing the code Disclosures made to recipients of the code Any additional allegations made about the code Symantec may also revoke an Administrator Certificate if the Administrators authority to act as Administrator has been terminated or otherwise has ended. Symantec Subscriber Agreements require end-user Subscribers to immediately notify Symantec of a known or suspected compromise of its private key. 4.10.1.1 CABF Requirements for Reasons for Revocation EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 13 of Appendix B1, Appendix C and Appendix D, respectively.

4.10.2 Who Can Request Revocation

Individual Subscribers can request the revocation of their own individual Certificates through an authorized representative of Symantec or an RA. In the case of organizational Certificates, a duly authorized representative of the organization shall be entitled to request the revocation of Certificates issued to the organization. A duly authorized representative of Symantec or a RA shall be entitled to request the revocation of an RA Administrators Certificate. The entity that approved a Subscribers Certificate Application shall also be entitled to revoke or request the revocation of the Subscribers Certificate. Only Symantec is entitled to request or initiate the revocation of the Certificates issued to its own CAs. RAs are entitled, through their duly authorized representatives, to request the revocation of their own Certificates, and their Superior Entities shall be entitled to request or initiate the revocation of their Certificates.

- 24 -

4.10.3 Procedure for Revocation Request

4.10.3.1 Procedure for Requesting the Revocation of an End-User Subscriber Certificate

An end-user Subscriber requesting revocation is required to communicate the request to Symantec or the Customer approving the Subscribers Certificate Application, who in turn will initiate revocation of the certificate promptly. For Enterprise customers, the Subscriber is required to communicate the request to the Enterprise Administrator who will communicate the revocation request to Symantec for processing. Communication of such revocation request shall be in accordance with CPS 3.4. Non-Enterprise customers shall communicate a revocation request in accordance with CPS 3.4. Where an Enterprise Customer initiates revocation of an end-user Subscriber Certificate upon its own initiative, the Managed PKI Customer or ASB Customer instructs Symantec to revoke the Certificate. 4.10.3.2 CABF Requirements for Certificate Revocation Process EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 13 of Appendix B1 and C and section 13.1 of Appendix D, respectively.

4.10.3.3

Procedure for Requesting the Revocation of a CA or RA Certificate

A CA or RA requesting revocation of its CA or RA Certificate is required to communicate the request to Symantec. Symantec will then revoke the Certificate. Symantec may also initiate CA or RA Certificate revocation.

4.10.4 Revocation Request Grace Period

Revocation requests shall be submitted as promptly as possible within a commercially reasonable time.

4.10.5 Time within Which CA Must Process the Revocation Request

Symantec takes commercially reasonable steps to process revocation requests without delay.

4.10.6 Revocation Checking Requirements for Relying Parties

Relying Parties shall check the status of Certificates on which they wish to rely. One method by which Relying Parties may check Certificate status is by consulting the most recent CRL from the CA that issued the Certificate on which the Relying Party wishes to rely. Alternatively, Relying Parties may meet this requirement either by checking Certificate status using the applicable webbased repository or by using OCSP (if available). CAs shall provide Relying Parties with information on how to find the appropriate CRL, web-based repository, or OCSP responder (where available) to check for revocation status.

- 25 -

4.10.7 CRL Issuance Frequency

CRLs for end-user Subscriber Certificates are issued at least once per day. CRLs for CA Certificates shall be issued at least annually, but also whenever a CA Certificate is revoked. CRLs for Authenticated Content Signing (ACS) Root CAs are published annually and also whenever a CA Certificate is revoked. If a Certificate listed in a CRL expires, it may be removed from later-issued CRLs after the Certificates expiration. 4.10.7.1 CABF Requirements for CRL Issuance CRL issuance for EV SSL Certificates, EV Code Signing, and domain-validated and organizationvalidated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 13 of Appendix B1 and C, and section 13.2.2 of Appendix D, respectively.
19

4.10.8 Maximum Latency for CRLs

CRLs are posted to the repository within a commercially reasonable time after generation. This is generally done automatically within minutes of generation.

4.10.9 On-Line Revocation/Status Checking Availability

Online revocation and other Certificate status information are available via a web-based repository and, where offered, OCSP. In addition to publishing CRLs, Symantec provides Certificate status information through query functions in the Symantec Repository. Certificate status information is available though web-based query functions accessible through the Symantec Repository at https://digitalid.verisign.com/services/client/index.html (for Individual Certificates) and https://digitalid.verisign.com/services/server/search.htm (for SSL and Code Signing Certificates). Symantec also provides OCSP Certificate status information. Enterprise Customers who contract for OCSP services may check Certificate status through the use of OCSP. The URL for the relevant OCSP Responder is communicated to the Enterprise Customer. 4.10.9.1 CABF Requirements for OCSP Availability OCSP availability for EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 13 of Appendix B1 and C, and section 13.2.2 of Appendix D, respectively.

4.10.10

On-Line Revocation Checking Requirements

A relying party must check the status of a certificate on which he/she/it wishes to rely. If a Relying Party does not check the status of a Certificate on which the Relying Party wishes to rely by consulting the most recent relevant CRL, the Relying Party shall check Certificate status by

19

CRLs for the Symantec Class 3 Organizational VIP Device CA are only issued whenever a certificate issued by that CA is revoked.

- 26 -

consulting the applicable repository or by requesting Certificate status using the applicable OCSP responder (where OCSP services are available).

4.10.11
Not applicable.

Other Forms of Revocation Advertisements Available

4.10.12

Special Requirements regarding Key Compromise

Symantec uses commercially reasonable efforts to notify potential Relying Parties if it discovers, or have reason to believe, that there has been a Compromise of the private key of one of their own CAs or one of the CAs within their sub-domains.

4.10.13
Not applicable.

Circumstances for Suspension

4.10.14
Not applicable.

Who Can Request Suspension

4.10.15
Not applicable.

Procedure for Suspension Request

4.10.16
Not applicable.

Limits on Suspension Period

4.11

Certificate Status Services

4.11.1 Operational Characteristics

The Status of public certificates is available via CRL at Symantecs website, LDAP directory and via an OCSP responder (where available).

4.11.2 Service Availability

Certificate Status Services are available 247 without scheduled interruption. Certificate status services for EV SSL Certificates, EV Code Signing, and Organization-validated and Domain-validated SSL Certificates, conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 13 of Appendix B1 and C and section 13.2.3 of Appendix D, respectively.

4.11.3 Optional Features

OCSP is an optional status service feature that is not available for all products and must be specifically enabled for other products.

4.12

End of Subscription

A subscriber may end a subscription for a Symantec certificate by: Allowing his/her/its certificate to expire without renewing or re-keying that certificate

- 27 -

Revoking of his/her/its certificate before certificate expiration without replacing the certificates.

4.13

Key Escrow and Recovery

With the exception of enterprises deploying Managed PKI Key Management Services no STN participant may escrow CA, RA or end-user Subscriber private keys. Enterprise customers using the Key Escrow option within the Symantec Managed PKI Service can escrow copies of the private keys of Subscribers whose Certificate Applications they approve. The enterprise customer may escrow keys either within the enterprises premises or Symantecs secure data center. If operated out of the enterprises premises, Symantec does not store copies of Subscriber private keys but nevertheless plays an important role in the Subscriber key recovery process.

4.13.1 Key Escrow and Recovery Policy and Practices

Enterprise customers using the Key Escrow option within the Symantec Managed PKI service (or an equivalent service approved by Symantec) are permitted to escrow end-user Subscribers private key. Escrowed private keys shall be stored in encrypted form using the Managed PKI Key Manager software. Except for enterprise customers using the Managed PKI Key Manager Service (or an equivalent service approved by Symantec), the private keys of CAs or end-user Subscribers shall not be escrowed. End-user Subscriber private keys shall only be recovered under the circumstances permitted within the Managed PKI Key Management Service Administrators Guide, under which: Enterprise customers using Managed PKI Key Manager shall confirm the identity of any person purporting to be the Subscriber to ensure that a purported Subscriber request for the Subscribers private key is, in fact, from the Subscriber and not an imposter, Enterprise customers shall recover a Subscribers private key without the Subscribers authority only for their legitimate and lawful purposes, such as to comply with judicial or administrative process or a search warrant, and not for any illegal, fraudulent, or other wrongful purpose, and Such Enterprise customers shall have personnel controls in place to prevent Key Management Service Administrators and other persons from obtaining unauthorized access to private keys. It is recommended that Enterprise Customers using the Key Escrow option within the Symantec Managed PKI Service: Notify the subscribers that their private keys are escrowed Protect subscribers escrowed keys from unauthorized disclosure, Protect all information, including the administrators own key(s) that could be used to recover subscribers escrowed keys. Release subscribers escrowed keys only for properly authenticated and authorized requests for recovery. Revoke the Subscribers Key pair prior to recovering the encryption key under certain circumstances such as to discontinue the use of a lost certificate. Not be required to communicate any information concerning a key recovery to the subscriber except when the subscriber him/herself has requested recovery. Not disclose or allow to be disclosed escrowed keys or escrowed key-related information to any third party unless required by the law, government rule, or regulation; by the enterprises organization policy; or by order of a court of competent jurisdiction.

- 28 -

4.13.2 Session Key Encapsulation and Recovery Policy and Practices

Private keys are stored in the Key Manager database in encrypted form. Each Subscribers private key is individually encrypted with its own triple-DES symmetric key. A Key Escrow Record (KER) is generated then the triple-DES key is combined with a random session key to form a session key mask (MSK). The resulting MSK together with the certificate request information is securely sent and stored in the Managed PKI database at Symantec. The KER (containing the end users private key) and the individual session key are stored in the Key Manager database and all residual key material is destroyed. The Managed PKI database is operated out of Symantecs secure data center. The enterprise customer may choose to operate the Key Manager database either on the enterprises premises or out of Symantecs secure data center. Recovery of a private key and digital certificate requires the Managed PKI administrator to securely log on to the Managed PKI Control Center, select the appropriate key pair to recover and click a recover hyperlink. Only after an approved administrator clicks the recover link is the MSK for that key pair returned from the Managed PKI database. The Key Manager retrieves the session key from the KMD and combines it with the MSK to regenerate the triple-DES key which was used to originally encrypt the private ke y, allowing recovery of the end users private key. As a final step, an encrypted PKCS#12 file is returned to the administrator and ultimately distributed to the end user.

5. Facility, Management, and Operational Controls

5.1 Physical Controls

Symantec has implemented the Symantec Physical Security Policy, which supports the security requirements of this CPS. Compliance with these policies is included in Symantecs independent audit requirements described in Section 8. Symantec Physical Security Policy contains sensitive security information and is only available upon agreement with Symantec. An overview of the requirements are described in the subsections following.

5.1.1

Site Location and Construction

STN CA and RA operations are conducted within a physically protected environment that deters, prevents, and detects unauthorized use of, access to, or disclosure of sensitive information and systems whether covert or overt. Symantec also maintains disaster recovery facilities for its CA operations. Symantecs disaster recovery facilities are protected by multiple tiers of physical security comparable to those of Symantecs primary facility.

5.1.2

Physical Access

STN CA systems are protected by a minimum of four tiers of physical security, with access to the lower tier required before gaining access to the higher tier. Progressively restrictive physical access privileges control access to each tier. Sensitive CA operational activity, any activity related to the lifecycle of the certification process such as authentication, verification, and issuance, occur within very restrictive physical tiers. Access to each tier requires the use of a proximity card employee badge. Physical access is automatically logged and video recorded. Additional tiers enforce individual access control through the use of two factor authentication including biometrics. Unescorted personnel, including untrusted employees or visitors, are not allowed into such secured areas.

- 29 -

The physical security system includes additional tiers for key management security which serves to protect both online and offline storage of CSUs and keying material. Areas used to create and store cryptographic material enforce dual control, each through the use of two factor authentication including biometrics. Online CSUs are protected through the use of locked cabinets. Offline CSUs are protected through the use of locked safes, cabinets and containers. Access to CSUs and keying material is restricted in accordance with Symantecs segregation of duties requirements. The opening and closing of cabinets or containers in these tiers is logged for audit purposes.

5.1.3

Power and Air Conditioning

Symantecs secure facilities are equipped with primary and backup: power systems to ensure continuous, uninterrupted access to electric power and heating/ventilation/air conditioning systems to control temperature and relative humidity.

5.1.4

Water Exposures

Symantec has taken reasonable precautions to minimize the impact of water exposure to Symantec systems.

5.1.5

Fire Prevention and Protection

Symantec has taken reasonable precautions to prevent and extinguish fires or other damaging exposure to flame or smoke. Symantecs fire prevention and protection measures have been designed to comply with local fire safety regulations.

5.1.6

Media Storage

All media containing production software and data, audit, archive, or backup information is stored within Symantec facilities or in a secure off-site storage facility with appropriate physical and logical access controls designed to limit access to authorized personnel and protect such media from accidental damage (e.g., water, fire, and electromagnetic).

5.1.7

Waste Disposal

Sensitive documents and materials are shredded before disposal. Media used to collect or transmit sensitive information are rendered unreadable before disposal. Cryptographic devices are physically destroyed or zeroized in accordance the manufacturers guidance prior to disposal. Other waste is disposed of in accordance with Symantecs normal waste disposal requirements.

5.1.8

Off-Site Backup

Symantec performs routine backups of critical system data, audit log data, and other sensitive information. Offsite backup media are stored in a physically secure manner using a bonded third party storage facility and Symantecs disaster recovery facility.

5.2 5.2.1

Procedural Controls Trusted Roles

Trusted Persons include all employees, contractors, and consultants that have access to or control authentication or cryptographic operations that may materially affect: the validation of information in Certificate Applications;

- 30 -

the acceptance, rejection, or other processing of Certificate Applications, revocation requests, renewal requests, or enrollment information; the issuance, or revocation of Certificates, including personnel having access to restricted portions of its repository; the handling of Subscriber information or requests.

Trusted Persons include, but are not limited to: customer service personnel, cryptographic business operations personnel, security personnel, system administration personnel, designated engineering personnel, and executives that are designated to manage infrastructural trustworthiness. Symantec considers the categories of personnel identified in this section as Trusted Persons having a Trusted Position. Persons seeking to become Trusted Persons by obtaining a Trusted Position must successfully complete the screening requirements set out in this CPS.

5.2.2

Number of Persons Required per Task

Symantec has established, maintains, and enforces rigorous control procedures to ensure the segregation of duties based on job responsibility and to ensure that multiple Trusted Persons are required to perform sensitive tasks. Policy and control procedures are in place to ensure segregation of duties based on job responsibilities. The most sensitive tasks, such as access to and management of CA cryptographic hardware (cryptographic signing unit or CSU) and associated key material, require multiple Trusted Persons. These internal control procedures are designed to ensure that at a minimum, two trusted personnel are required to have either physical or logical access to the device. Access to CA cryptographic hardware is strictly enforced by multiple Trusted Persons throughout its lifecycle, from incoming receipt and inspection to final logical and/or physical destruction. Once a module is activated with operational keys, further access controls are invoked to maintain split control over both physical and logical access to the device. Persons with physical access to modules do not hold Secret Shares and vice versa. Other manual operations such as the validation and issuance of Class 3 Certificates, not issued by an automated validation and issuance system, require the participation of at least two (2) Trusted Persons, or a combination of at least one trusted person and an automated validation and issuance process. Manual operations for Key Recovery may optionally require the validation of two (2) authorized Administrators.

5.2.3

Identification and Authentication for Each Role

For all personnel seeking to become Trusted Persons, verification of identity is performed through the personal (physical) presence of such personnel before Trusted Persons performing Symantec HR or security functions and a check of well-recognized forms of identification (e.g., passports and drivers licenses). Identity is further confirmed through the background checking procedures in CPS 5.3.1. Symantec ensures that personnel have achieved Trusted Status and departmental approval has been given before such personnel are: issued access devices and granted access to the required facilities;

- 31 -

issued electronic credentials to access and perform specific functions on STN CA, RA, or other IT systems.

5.2.4

Roles Requiring Separation of Duties

Roles requiring Separation of duties include (but are not limited to) the validation of information in Certificate Applications; the acceptance, rejection, or other processing of Certificate Applications, revocation requests, key recovery requests or renewal requests, or enrollment information; the issuance, or revocation of Certificates, including personnel having access to restricted portions of the repository; the handling of Subscriber information or requests the generation, issuing or destruction of a CA certificate the loading of a CA to a Production environment

5.3

Personnel Controls

Personnel seeking to become Trusted Persons must present proof of the requisite background, qualifications, and experience needed to perform their prospective job responsibilities competently and satisfactorily, as well as proof of any government clearances, if any, necessary to perform certification services under government contracts. Background checks are repeated at least every 5 years for personnel holding Trusted Positions.

5.3.1

Qualifications, Experience, and Clearance Requirements

Symantec requires that personnel seeking to become Trusted Persons present proof of the requisite background, qualifications, and experience needed to perform their prospective job responsibilities competently and satisfactorily, as well as proof of any government clearances, if any, necessary to perform certification services under government contracts.

5.3.2

Background Check Procedures

Prior to commencement of employment in a Trusted Role, Symantec conducts background checks which include the following: confirmation of previous employment, check of professional reference, confirmation of the highest or most relevant educational degree obtained, search of criminal records (local, state or provincial, and national), check of credit/financial records, search of drivers license records, and search of Social Security Administration records. To the extent that any of the requirements imposed by this section cannot be met due to a prohibition or limitation in local law or other circumstances, Symantec will utilize a substitute investigative technique permitted by law that provides substantially similar information, including but not limited to obtaining a background check performed by the applicable governmental agency. The factors revealed in a background check that may be considered grounds for rejecting candidates for Trusted Positions or for taking action against an existing Trusted Person generally include (but are not limited to) the following: Misrepresentations made by the candidate or Trusted Person, Highly unfavorable or unreliable professional references, Certain criminal convictions, and

- 32 -

Indications of a lack of financial responsibility.

Reports containing such information are evaluated by human resources and security personnel, who determine the appropriate course of action in light of the type, magnitude, and frequency of the behavior uncovered by the background check. Such actions may include measures up to and including the cancellation of offers of employment made to candidates for Trusted Positions or the termination of existing Trusted Persons. The use of information revealed in a background check to take such actions is subject to the applicable federal, state, and local laws.

5.3.3

Training Requirements

Symantec provides its personnel with training upon hire as well as the requisite on-the-job training needed for them to perform their job responsibilities competently and satisfactorily. Symantec maintains records of such training. Symantec periodically reviews and enhances its training programs as necessary. Symantecs training programs are tailored to the individuals responsibilities and include the following as relevant: Basic PKI concepts, Job responsibilities, Symantec security and operational policies and procedures, Use and operation of deployed hardware and software, Incident and Compromise reporting and handling, and Disaster recovery and business continuity procedures. 5.3.3.1 CABF Requirements for Training and Skill Level

For EV SSL Certificates, EV Code Signing, and Organization-validated and Domain-validated SSL Certificates, personnel training is provided as set forth in the STN Supplemental Procedures, in section 14.1 of Appendix B1, Appendix C and Appendix D, respectively.

5.3.4

Retraining Frequency and Requirements

Symantec provides refresher training and updates to their personnel to the extent and frequency required to ensure that such personnel maintain the required level of proficiency to perform their job responsibilities competently and satisfactorily.

5.3.5

Job Rotation Frequency and Sequence

Not applicable

5.3.6

Sanctions for Unauthorized Actions

Appropriate disciplinary actions are taken for unauthorized actions or other violations of Symantec policies and procedures. Disciplinary actions may include measures up to and including termination and are commensurate with the frequency and severity of the unauthorized actions.

- 33 -

5.3.7

Independent Contractor Requirements

In limited circumstances, independent contractors or consultants may be used to fill Trusted Positions. Any such contractor or consultant is held to the same functional and security criteria that apply to a Symantec employees in a comparable position. Independent contractors and consultants who have not completed or passed the background check procedures specified in CPS 5.3.2 are permitted access to Symantecs secure facilities only to the extent they are escorted and directly supervised by Trusted Persons at all times.

5.3.8

Documentation Supplied to Personnel

Symantec provides its employees the requisite training and other documentation needed to perform their job responsibilities competently and satisfactorily.

5.4 5.4.1

Audit Logging Procedures Types of Events Recorded

Symantec manually or automatically logs the following significant events: CA key life cycle management events, including: o Key generation, backup, storage, recovery, archival, and destruction o Cryptographic device life cycle management events. CA and Subscriber certificate life cycle management events, including: o Certificate Applications, renewal, rekey, and revocation o Successful or unsuccessful processing of requests o Generation and issuance of Certificates and CRLs. Security-related events including: o Successful and unsuccessful PKI system access attempts o PKI and security system actions performed by Symantec personnel o Security sensitive files or records read, written or deleted o Security profile changes o System crashes, hardware failures and other anomalies o Firewall and router activity o CA facility visitor entry/exit. Log entries include the following elements: Date and time of the entry Serial or sequence number of entry, for automatic journal entries Identity of the entity making the journal entry Description/kind of entry. Symantec RAs and Enterprise Administrators log Certificate Application information including: Kind of identification document(s) presented by the Certificate Applicant Record of unique identification data, numbers, or a combination thereof (e.g., Certificate Applicants drivers license number) of identification documents, if applicable Storage location of copies of applications and identification documents Identity of entity accepting the application Method used to validate identification documents, if any Name of receiving CA or submitting RA, if applicable. EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA /Browser Forum requirements as set forth in the STN Supplemental Procedures in section 15, Appendix B1, Appendix C and Appendix D, respectively.

- 34 -

5.4.2

Frequency of Processing Log

The CA system is continuously monitored to provide real time alerts of significant security and operational events for review by designated system security personnel. Monthly reviews of the audit logs include verifying that the logs have not been tampered with and thoroughly investigating any alerts or irregularities detected in the logs. Actions taken based on audit log reviews are also documented.

5.4.3

Retention Period for Audit Log

Audit logs shall be retained onsite for at least two (2) months after processing and thereafter archived in accordance with Section 5.5.2.

5.4.4

Protection of Audit Log

Audit logs are protected with an electronic audit log system that includes mechanisms to protect the log files from unauthorized viewing, modification, deletion, or other tampering.

5.4.5

Audit Log Backup Procedures

Incremental backups of audit logs are created daily and full backups are performed weekly.

5.4.6

Audit Collection System (Internal vs. External)

Automated audit data is generated and recorded at the application, network and operating system level. Manually generated audit data is recorded by Symantec personnel.

5.4.7

Notification to Event-Causing Subject

Where an event is logged by the audit collection system, no notice is required to be given to the individual, organization, device, or application that caused the event.

5.4.8

Vulnerability Assessments

Events in the audit process are logged, in part, to monitor system vulnerabilities. Logical security vulnerability assessments (LSVAs) are performed, reviewed, and revised following an examination of these monitored events. LSVAs are based on real-time automated logging data and are performed on a daily, monthly, and annual basis. An annual LSVA will be an input into an entitys annual Compliance Audit.

5.5 5.5.1

Records Archival Types of Records Archived

Symantec archives: All audit data collected in terms of Section 5.4 Certificate application information Documentation supporting certificate applications Certificate lifecycle information e.g., revocation, rekey and renewal application information

- 35 -

5.5.2

Retention Period for Archive

Records shall be retained for at least the time periods set forth below following the date the Certificate expires or is revoked. Five (5) years for Class 1 Certificates, Ten (10) years and six (6) months for Class 2 and Class 3 Certificates

5.5.3

Protection of Archive

Symantec protects the archive so that only authorized Trusted Persons are able to obtain access to the archive. The archive is protected against unauthorized viewing, modification, deletion, or other tampering by storage within a Trustworthy System. The media holding the archive data and the applications required to process the archive data shall be maintained to ensure that the archive data can be accessed for the time period set forth in this CPS.

5.5.4

Archive Backup Procedures

Symantec incrementally backs up electronic archives of its issued Certificate information on a daily basis and performs full backups on a weekly basis. Copies of paper-based records shall be maintained in an off-site secure facility.

5.5.5

Requirements for Time-Stamping of Records

Certificates, CRLs, and other revocation database entries shall contain time and date information. Such time information need not be cryptographic-based.

5.5.6

Archive Collection System (Internal or External)

Symantec archive collection systems are internal, except for enterprise RA Customers. Symantec assists its enterprise RAs in preserving an audit trail. Such an archive collection system therefore is external to that enterprise RA.

5.5.7

Procedures to Obtain and Verify Archive Information

Only authorized Trusted Personnel are able to obtain access to the archive. The integrity of the information is verified when it is restored.

5.6

Key Changeover

STN CA key pairs are retired from service at the end of their respective maximum lifetimes as defined in this CPS. STN CA Certificates may be renewed as long as the cumulative certified lifetime of the CA key pair does not exceed the maximum CA key pair lifetime. New CA key pairs will be generated as necessary, for example to replace CA key pairs that are being retired, to supplement existing, active key pairs and to support new services. Prior to the expiration of the CA Certificate for a Superior CA, key changeover procedures are enacted to facilitate a smooth transition for entities within the Superior CAs hierarchy from the old Superior CA key pair to new CA key pair(s). Symantecs CA key changeover process requires that: A Superior CA ceases to issue new Subordinate CA Certificates no later than 60 days before the point in time (Stop Issuance Date) where the remaining lifetime of the Superior CA key pair equals the approved Certificate Validity Period for the specific type(s) of Certificates issued by Subordinate CAs in the Superior CAs hierarchy.

- 36 -

Upon successful validation of Subordinate CA (or end-user Subscriber) Certificate requests received after the Stop Issuance Date, Certificates will be signed with a new CA key pair.

The Superior CA continues to issue CRLs signed with the original Superior CA private key until the expiration date of the last Certificate issued using the original key pair has been reached

5.7 5.7.1

Compromise and Disaster Recovery Incident and Compromise Handling Procedures

Backups of the following CA information shall be kept in off-site storage and made available in the event of a Compromise or disaster: Certificate Application data, audit data, and database records for all Certificates issued. Back-ups of CA private keys shall be generated and maintained in accordance with CP 6.2.4. Symantec maintains backups of the foregoing CA information for their own CAs, as well as the CAs of Enterprise Customers within its Sub-domain.

5.7.2

Computing Resources, Software, and/or Data Are Corrupted

In the event of the corruption of computing resources, software, and/or data, such an occurrence is reported to Symantec Security and Symantecs incident handling procedures are enacted. Such procedures require appropriate escalation, incident investigation, and incident response. If necessary, Symantecs key compromise or disaster recovery procedures will be enacted.

5.7.3

Entity Private Key Compromise Procedures

Upon the suspected or known Compromise of a STN CA, Symantec infrastructure or Customer CA private key, Symantecs Key Compromise Response procedures are enacted by the Symantec Security Incident Response Team (SSIRT). This team, which includes Security, Cryptographic Business Operations, Production Services personnel, and other Symantec management representatives, assesses the situation, develops an action plan, and implements the action plan with approval from Symantec executive management. If CA Certificate revocation is required, the following procedures are performed: The Certificates revoked status is communicated to Relying Parties through the Symantec Repository in accordance with CPS 4.9.7, Commercially reasonable efforts will be made to provide additional notice of the revocation to all affected STN Participants, and The CA will generate a new key pair in accordance with CPS 5.6, except where the CA is being terminated in accordance with CPS 5.8.

5.7.4

Business Continuity Capabilities after a Disaster

Symantec has created and maintains business continuity plans so that in the event of a business disruption, critical business functions may be resumed. Symantec maintains a Disaster Recovery Facility (DRF) located at a Symantec-owned facility geographically separate from the primary Production Facility. The DRF is a hardened facility designed to federal government and military specifications and is also specifically equipped to meet Symantecs security standards. In the event of a natural or man-made disaster requiring permanent cessation of operations from Symantecs primary facility, the Corporate Symantec Business Continuity Team and the Symantec Authentication Operations Incident Management Team will coordinate with cross functional management teams to make the decision to formally declare a disaster situation and manage the incident. Once a disaster situation is declared, restoration of Symantecs Production services functionality at the DRF will be initiated.

- 37 -

Symantec has developed a Disaster Recovery Plan (DRP) for its managed PKI services including the STN PKI service. The DRP identifies conditions for activating the plan and what constitutes an acceptable system outage and recovery time. The DRP defines the procedures for the teams to reconstitute Symantec STN operations using backup data and backup copies of the STN keys. Additionally, for EV SSL Certificates, EV Code Signing, and Organization-validated and Domainvalidated SSL Certificates, Symantecs DRP includes the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 16 of Appendix B1 and C and section 16.4 of Appendix D, respectively. The target recovery time for restoring critical Production service functionality is no greater than 24 hours. Symantec conducts at least one disaster recovery test per calendar year to ensure functionality of services at the DRF. Formal Business Continuity Exercises are also conducted yearly in coordination with the Corporate Symantec Business Continuity Team where procedures for additional types of scenarios (e.g. pandemic, earthquake, flood, power outage) are tested and evaluated. Symantec takes significant steps to develop, maintain, and test sound business recovery plans, and Symantecs planning for a disaster or significant business disruption is consistent with many of the best practices established within the industry. Symantec maintains redundant hardware and backups of its CA and infrastructure system software at its disaster recovery facility. In addition, CA private keys are backed up and maintained for disaster recovery purposes in accordance with CPS 6.2.4. Symantec maintains offsite backups of important CA information for STN CAs as well as the CAs of Service Centers, and Enterprise Customers, within Symantecs Sub-domain. Such information includes, but is not limited to: Certificate Application data, audit data (per Section 4.5), and database records for all Certificates issued.

5.8

CA or RA Termination

In the event that it is necessary for a STN CA, or Enterprise Customer CA to cease operation, Symantec makes a commercially reasonable effort to notify Subscribers, Relying Parties, and other affected entities of such termination in advance of the CA termination. Where CA termination is required, Symantec and, in the case of a Customer CA, the applicable Customer, will develop a termination plan to minimize disruption to Customers, Subscribers, and Relying Parties. Such termination plans may address the following, as applicable: Provision of notice to parties affected by the termination, such as Subscribers, Relying Parties, and Customers, informing them of the status of the CA, Handling the cost of such notice, The revocation of the Certificate issued to the CA by Symantec, The preservation of the CAs archives and records for the time periods required in this CPS, The continuation of Subscriber and customer support services, The continuation of revocation services, such as the issuance of CRLs or the maintenance of online status checking services, The revocation of unexpired unrevoked Certificates of end-user Subscribers and subordinate CAs, if necessary,

- 38 -

Refunding (if necessary) Subscribers whose unexpired unrevoked Certificates are revoked under the termination plan or provision, or alternatively, the issuance of replacement Certificates by a successor CA, Disposition of the CAs private key and the hardware tokens containing such private key, and Provisions needed for the transition of the CAs services to a successor CA.

5.9

Data Security

For the issuance of EV SSL Certificates, EV Code Signing, and Organization-validated and Domain-validated SSL Certificates, Symantec conforms to the CA / Browser Forum requirements for Data Security as set forth in the STN Supplemental Procedures, in section 16 of Appendix B1, Appendix C and Appendix D, respectively.

6. Technical Security Controls

6.1 6.1.1 Key Pair Generation and Installation Key Pair Generation

CA key pair generation is performed by multiple pre-selected, trained and trusted individuals using Trustworthy Systems and processes that provide for the security and required cryptographic strength for the generated keys. For PCA and Issuing Root CAs, the cryptographic modules used for key generation meet the requirements of FIPS 140-1 level 3. For other CAs (including STN CAs and Managed PKI Customer CAs), the cryptographic modules used meet the requirements of at least FIPS 140-1 level 2. All CA key pairs are generated in pre-planned Key Generation Ceremonies in accordance with the requirements of the Key Ceremony Ref erence Guide, the CA Key Management Tool Users Guide, and the Symantec SAR Guide. The activities performed in each key generation ceremony are recorded, dated and signed by all individuals involved. These records are kept for audit and tracking purposes for a length of time deemed appropriate by Symantec Management. Generation of RA key pairs is generally performed by the RA using a FIPS 140-1 level 1 certified cryptographic module provided with their browser software. Enterprise Customers generate the key pair used by their Automated Administration servers. Symantec recommends that Automated Administration server key pair generation be performed using a FIPS 140-1 level 2 certified cryptographic module. Generation of end-user Subscriber key pairs is generally performed by the Subscriber. For Class 1 Certificates, Class 2 Certificates, and Class 3 Code/Object Signing Certificates, the Subscriber typically uses a FIPS 140-1 level 1 certified cryptographic module provided with their browser software for key generation. For server Certificates, the Subscriber typically uses the key generation utility provided with the web server software. For ACS Application IDs, Symantec generates a key pair on behalf of the Subscriber using a random numbers seed generated on a cryptographic module that, at a minimum, meets the requirements of FIPS 140-1 level 3. Supplementary practices in Appendix B and C identify additional requirements for Certificates conforming to the CA/Browser Forum requirements.

- 39 -

6.1.2

Private Key Delivery to Subscriber

When end-user Subscriber key pairs are generated by the end-user Subscriber, private key delivery to a Subscriber is not applicable. For ACS Application IDs, private key delivery to a Subscriber is also not applicable. Where RA or end-user Subscriber key pairs are pre-generated by Symantec on hardware tokens or smart cards, such devices are distributed to the RA or end-user Subscriber using a commercial delivery service and tamper evident packaging. The data required to activate the device is communicated to the RA or end-user Subscriber using an out of band process. The distribution of such devices is logged by Symantec. Where end-user Subscriber key pairs are pre-generated by Enterprise Customers on hardware tokens or smart cards, such devices are distributed to the end-user Subscriber using a commercial delivery service and tamper evident packaging. The required activation data required to activate the device is communicated to the RA or end-user Subscriber using an out of band process. The distribution of such devices is logged by the Enterprise Customer. For Enterprise Customers using Managed PKI Key Manager for key recovery services, the Customer may generate encryption key pairs (on behalf of Subscribers whose Certificate Applications they approve) and transmit such key pairs to Subscribers via a password protected PKCS #12 file.

6.1.3

Public Key Delivery to Certificate Issuer

End-user Subscribers and RAs submit their public key to Symantec for certification electronically through the use of a PKCS#10 Certificate Signing Request (CSR) or other digitally signed package in a session secured by Secure Sockets Layer (SSL). Where CA, RA, or end-user Subscriber key pairs are generated by Symantec, this requirement is not applicable.

6.1.4

CA Public Key Delivery to Relying Parties

Symantec makes the CA Certificates for its PCAs and root CAs available to Subscribers and Relying Parties through their inclusion in web browser software. As new PCA and root CA Certificates are generated, Symantec provides such new Certificates to the browser manufacturers for inclusion in new browser releases and updates. Symantec generally provides the full certificate chain (including the issuing CA and any CAs in the chain) to the end-user Subscriber upon Certificate issuance. STN CA Certificates may also be downloaded from the LDAP Directory at directory.verisign.com.

6.1.5

Key Sizes

Key pairs shall be of sufficient length to prevent others from determining the key pairs private key using cryptanalysis during the period of expected utilization of such key pairs. The Symantec Standard for minimum key sizes is the use of key pairs equivalent in strength to 2048 bit RSA for 20 PCAs and CAs. . The following table lists Symantec Root key pairs and strengths:
20

CA trust is extended to Symantecs first and second generation (G1 and G2) legacy Trusted Roots with 1024 bit RSA key pairs for support of customer legacy platforms and 1024-bit RSA end-entity certificates may be issued with expiration on or before January 31, 2014. Additional individual exceptions may be permitted for affiliates of Symantec Corporation operating the Processing Center software capabilities in accordance with section 6.3.2, with prior approval to preserve business continuity of legacy applications beyond 2013. 20 Symantec reserves the right to issue a minimal undisclosed number of SSL server certificates intended to be used by client software other than standard web browsers. These certificates contain a critical EKU extension without the serverAuth flag and with a special flag 2.16.840.1.113733.1.8.54.1 that indicates that it should not be used with standard web browsers

- 40 -

21Under special circumstances where the Customers, Subscribers, and/or Relying Parties application do not support key sizes or key pairs of of 2048 bit strength or greater, Symantec reserves the right to issue certificates with non-standard minimum key sizes and key pairs of less than 2048 bit RSA or DSA for PCAs and CAs. Such certificates will have the serverAuth flag removed and a designated OID 2.16.840.1.113733.1.8.54.1 set in the EKU field. The Customers, Subscribers, and Relying Parties will use such certificates at their own risk.

Public Key Algorithm 2048 bit RSA

Class Generation Class 1, 2, 3 PCAs G3 PCAs Class 3 PCA G5 PCA SHA256 Class 1, 2 and Class 3 Universal Root PCA G6 PCAs 384 bit ECC SHA384 Class 1, 2, 3* PCAs G4 PCAs 4096 bit RSA SHA384 Class 3 PCA G6 PCA 2048_256 bit DSA SHA256 Class 1, 2, 3 PCAs G7 PCAs * There are two Class 3 G4 Roots (one branded VeriSign (legacy) and one branded Symantec). Table: Symantec Root CAs and Key Sizes

Signature Algorithm SHA1

All Classes of STN PCAs and CAs, and RAs and end entity certificates use either SHA-1 or SHA2 for digital signature hash algorithm and certain versions of Symantec Processing Center support the use of SHA-256 and SHA-384 has algorithms in end-entity Subscriber Certificates.

6.1.5.1

CABF Requirements for Key Sizes

EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA /Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 9.5, Appendix B1, Appendix C and Appendix D, respectively. Symantec Root CA Certificates meet the following requirements for algorithm type and key size:
Validity period beginning on or before 31 Dec 2010 MD5 Not Recommended, SHA-1, SHA-256, SHA-384 or SHA512 2048** N/A Validity period beginning after 31 Dec 2010 SHA-1*, SHA-256, SHA-384 or SHA512 2048 2048

Digest algorithm

Minimum RSA modulus size (bits) Minimum DSA modulus size (bits) ECC curve

NIST P-256, P-384 or P-521 NIST P-256, P-384 or P-521 Table 4A Algorithms and key sizes for Root CA Certificates

Symantec Subordinate CA Certificates meet the following requirements for algorithm type and key size:
Validity period beginning on or before 31 Dec 2010 and ending on or before 31 Dec 2013 SHA-1, SHA-256, SHA-384 or SHA512 1024 2048 Validity period beginning after 31 Dec 2010 or ending after 31 Dec 2013 SHA-1*, SHA-256, SHA-384 or SHA512 2048 2048

Digest algorithm Minimum RSA modulus size (bits) Minimum DSA

- 41 -

modulus size (bits) ECC curve NIST P-256, P-384 or P-521 NIST P-256, P-384 or P-521 Table 4B Algorithms and key sizes for Subordinate CA Certificates

Symantec CAs shall only issue Subscriber certificates with keys containing the following algorithm types and key sizes.
Validity period ending on or before 31 Dec 2013 SHA-1*, SHA-256, SHA-384 or SHA512 1024 Validity period ending after 31 Dec 2013 SHA-1*, SHA-256, SHA-384 or SHA512 2048

Digest algorithm

Minimum RSA modulus size (bits) Minimum DSA 2048 2048 modulus size (bits) ECC curve NIST P-256, P-384 or P-521 NIST P-256, P-384 or P-521 Table 4C Algorithms and key sizes for Subscriber Certificates

* SHA-1 may be used until SHA-256 is supported widely by browsers used by a substantial portion of relying parties worldwide. ** A Root CA Certificate issued prior to 31 Dec 2010 with an RSA key size less than 2048 bits may still serve as a trust anchor Subscriber Certificates issued in accordance with these Requirements.

Symantec CAs reserve the right to reject a certificate request if the requested Public Key does not meet the minimum algorithm key sizes set forth in this section.

6.1.6

Public Key Parameters Generation and Quality Checking

Not applicable.

6.1.7

Key Usage Purposes (as per X.509 v3 Key Usage Field)

Refer to Section 7.1.2.1.

6.2

Private Key Protection and Cryptographic Module Engineering Controls

Symantec has implemented a combination of physical, logical, and procedural controls to ensure the security of Symantec and Enterprise Customer CA private keys. Subscribers are required by contract to take necessary precautions to prevent the loss, disclosure, modification, or unauthorized use of private keys.

6.2.1

Cryptographic Module Standards and Controls

For PCA and Issuing Root CA key pair generation and CA private key storage, Symantec uses hardware cryptographic modules that are certified at or meet the requirements of FIPS 140-1 Level 3.

6.2.2

Private Key (m out of n) Multi-Person Control

Symantec has implemented technical and procedural mechanisms that require the participation of multiple trusted individuals to perform sensitive CA cryptographic operations. Symantec uses Secret Sharing to split the activation data needed to make use of a CA private key into separate parts called Secret Shares which are held by trained and trusted individuals called Shareholders. A threshold number of Secret Shares (m) out of the total number of Secret

- 42 -

Shares created and distributed for a particular hardware cryptographic module (n) is required to activate a CA private key stored on the module. The threshold number of shares needed to sign a CA certificate is three (3). It should be noted that the number of shares distributed for disaster recovery tokens may be less than the number distributed for operational tokens, while the threshold number of required shares remains the same. Secret Shares are protected in accordance with this CPS.

6.2.3

Private Key Escrow

CA private keys are not escrowed. Escrow of private keys for end user subscribers is explained in more detail in Section 4.12.

6.2.4

Private Key Backup

Symantec creates backup copies of CA private keys for routine recovery and disaster recovery purposes. Such keys are stored in encrypted form within hardware cryptographic modules and associated key storage devices. Cryptographic modules used for CA private key storage meet the requirements of this CPS. CA private keys are copied to backup hardware cryptographic modules in accordance with this CPS. Modules containing onsite backup copies of CA private keys are subject to the requirements of CPS. Modules containing disaster recovery copies of CA private keys are subject to the requirements of this CPS. Symantec does not store copies of RA private keys. For the backup of end-user Subscriber private keys, see Section 6.2.3 and Section 4.12. For ACS Application IDs, Symantec does not store copies of Subscriber private keys.

6.2.5

Private Key Archival

Upon expiration of a STN CA Certificate, the key pair associated with the certificate will be securely retained for a period of at least 5 years using hardware cryptographic modules that meet the requirements of this CPS. These CA key pairs shall not be used for any signing events after the expiration date of the corresponding CA Certificate, unless the CA Certificate has been renewed in terms of this CPS. Symantec does not archive copies of RA and Subscriber private keys.

6.2.6

Private Key Transfer Into or From a Cryptographic Module

Symantec generates CA key pairs on the hardware cryptographic modules in which the keys will be used. In addition, Symantec makes copies of such CA key pairs for routine recovery and disaster recovery purposes. Where CA key pairs are backed up to another hardware cryptographic module, such key pairs are transported between modules in encrypted form.

6.2.7

Private Key Storage on Cryptographic Module

CA or RA private keys held on hardware cryptographic modules shall be stored in encrypted form.

6.2.8

Method of Activating Private Key

All Symantec sub-domain Participants shall protect the activation data for their private keys against loss, theft, modification, unauthorized disclosure, or unauthorized use.

- 43 -

6.2.8.1

Class 1 Certificates

The Standard for Class 1 private key protection is for Subscribers to take commercially reasonable measures for the physical protection of the Subscribers workstation to prevent use of the workstation and its associated private key without the Subscribers authorization. In addition, Symantec recommends that Subscribers use a password in accordance with Section 6.4.1 or security of equivalent strength to authenticate the Subscriber before the activation of the private key, which includes, for instance, a password to operate the private key, a Windows logon or screen saver password, or a network logon password. 6.2.8.2 Class 2 Certificates

The Standard for Class 2 Private Key protection is for Subscribers to: Use a password in accordance with Section 6.4.1 or security of equivalent strength to authenticate the Subscriber before the activation of the private key, which includes, for instance, a password to operate the private key, or a Windows logon or screen saver password; and Take commercially reasonable measures for the physical protection of the Subscribers workstation to prevent use of the workstation and its associated private key without the Subscribers authorization. When deactivated, private keys shall be kept in encrypted form only. 6.2.8.3 Class 3 Certificates other than Administrator Certificates

The Standard for Class 3 private key protection (other than Administrators) is for Subscribers to: Use a smart card, biometric access device or security of equivalent strength to authenticate the Subscriber before the activation of the private key; and Take commercially reasonable measures for the physical protection of the Subscribers workstation to prevent use of the workstation and its associated private key without the Subscribers authorization. Use of a password along with a smart card or biometric access device in accordance with Section 6.4.1 is recommended. When deactivated, private keys shall be kept in encrypted form only. 6.2.8.4 Administrators Private Keys (Class 3)

The Standard for Administrators private key protection requires them to: Use a smart card, biometric access device, password in accordance with Section 6.4.1, or security of equivalent strength to authenticate the Administrator before the activation of the private key, which includes, for instance, a password to operate the private key, a Windows logon or screen saver password, or a network logon password; and Take commercially reasonable measures for the physical protection of the Administrators workstation to prevent use of the workstation and its associated private key without the Administrators authorization. Symantec recommends that Administrators use a smart card, biometric access device, or security of equivalent strength along with the use of a password in accordance with Section 6.4.1 to authenticate the Administrator before the activation of the private key. When deactivated, private keys shall be kept in encrypted form only.

- 44 -

6.2.8.5

Enterprise RAs using a Cryptographic Module (with Automated Administration or with Managed PKI Key Manager Service)

The Standard for private key protection for Administrators using such a cryptographic module requires them to: Use the cryptographic module along with a password in accordance with Section 6.4.1 to authenticate the Administrator before the activation of the private key; and Take commercially reasonable measures for the physical protection of the workstation housing the cryptographic module reader to prevent use of the workstation and the private key associated with the cryptographic module without the Administrators authorization. 6.2.8.6 Private Keys Held by Processing Centers (Class 1-3)

An online CAs private key shall be activated by a threshold number of Shareholders, as defined in Section 6.2.2, supplying their activation data (stored on secure media). Once the private key is activated, the private key may be active for an indefinite period until it is deactivated when the CA goes offline. Similarly, a threshold number of Shareholders shall be required to supply their activation data in order to activate an offline CAs private key. Once the private key is activated, it shall be active only for one time.

6.2.9

Method of Deactivating Private Key

STN CA private keys are deactivated upon removal from the token reader. RA private keys (used for authentication to the RA application) are deactivated upon system log off. RAs are required to log off their workstations when leaving their work area. Client Administrators, RA, and end-user Subscriber private keys may be deactivated after each operation, upon logging off their system, or upon removal of a smart card from the smart card reader depending upon the authentication mechanism employed by the user. In all cases, enduser Subscribers have an obligation to adequately protect their private key(s) in accordance with this CPS. The private key associated with an ACS Application ID is deleted immediately after it has been used for code signing.

6.2.10 Method of Destroying Private Key

Where required, Symantec destroys CA private keys in a manner that reasonably ensures that there are no residuals remains of the key that could lead to the reconstruction of the key. Symantec utilizes the zeroization function of its hardware cryptographic modules and other appropriate means to ensure the complete destruction of CA private keys. When performed, CA key destruction activities are logged. The private key associated with an ACS Application ID is deleted immediately after it has been used for code signing.

6.2.11 Cryptographic Module Rating

See Section 6.2.1

6.3 6.3.1

Other Aspects of Key Pair Management Public Key Archival

STN CA, RA and end-user Subscriber Certificates are backed up and archived as part of Symantecs routine backup procedures.

- 45 -

6.3.2

Certificate Operational Periods and Key Pair Usage Periods

The Operational Period of a Certificate ends upon its expiration or revocation. The Operational Period for key pairs is the same as the Operational Period for the associated Certificates, except that they may continue to be used for decryption and signature verification. The maximum Operational Periods for Symantec Certificates for Certificates issued on or after the effective date 21 of this CPS are set forth in Table 8 below . End user Subscriber Certificates that are renewals of existing subscriber certificates may have a longer validity period (up to 3 months). In addition, STN CAs stop issuing new Certificates at an appropriate date prior to the expiration of the CAs Certificate such that no Certificate issued by a Subordinate CA expires after the expiration of any Superior CA Certificates.
Certificate Issued By: PCA self-signed (1024 bit RSA) PCA self-signed (2048 bit RSA) PCA self-signed (256 bit ECC) PCA self-signed (384 bit ECC) PCA to Offline intermediate CA PCA to online CA Offline intermediate CA to online CA Online CA to End-user Individual Subscriber Validity Period Up to 30 years Up to 50 years Up to 30 years Up to 30 years Generally 10 years but up to 15 years after renewal Generally 5 years but up to 10 years after renewal Generally 5 years but up to 10 years after renewal
22 23

Online CA to End-Entity Organizational Subscriber

Normally up to 3 years, but under the conditions described 24 below, up to 6 years under the conditions described below with no option to renew or re-key. After 6 years new enrollment is required. 25 Normally up to 6 years under the conditions described below with no option to renew or re-key. After 6 years new enrollment is required.

Table 8 Certificate Operational Periods In terms of Section 6.3.2 of the STN CP, the Symantec PMA has approved an exception to extend a limited number CAs beyond the specified limits, in order to ensure uninterrupted PKI services during CA key pair migration. This exception can be applied to affiliates of Symantec Corporation operating the Processing Center software capabilities for customer, infrastructure and Admin CAs only that are not associated with CAs issuing SSL certificates. This exception may not be used to extend a CAs validity beyond a 14-year total validity to a maximum of August 31, 2014, and shall not be made available after December 31, 2013. Except as noted in this section, Symantec sub-domain participants shall cease all use of their key pairs after their usage periods have expired.

21

Individual exceptions must be approved by Symantec for certificate validity periods beyond the limits set in Section 6.3.2 and are strictly limited to certificates using stronger encryption algorithms or longer key lengths e.g. the use of SHA 2 or ECC algorithms and/or the use of 4096 bit or larger keys. In consideration of approval, additional requirements for protection of the private key may be imposed, such as generation and storage on a Hardware device. 22 The Symantec Onsite Administrator CA-Class 3, Class 3 Secure Server Operational Administrator CA and Class 3 OnSite Enterprise Administrator CA G2 have a validity beyond 10 years to support legacy systems and shall be revoked when appropriate 23 If 6-year end-user subscriber certificates are issued, the online CA certificat es operational period will be 10 years with no option to renew. CA re-key will be required after 5 years. 24 If 6-year end-user subscriber certificates are issued, the online CA certificates operational period will be 10 years with no option to renew. CA re-key will be required after 5 years. 25 At a minimum, the Distinguished Name of certificates issued with a validity of more than 3 years is re-verified after three years from date of certificate issuance. With the exception of the Symantec Automated Administration certificate, Organizational end-entity certificates used solely to support the operation of a portion of the STN may be issued with a validity period of 5 years and up to a maximum of 10 years after renewal.

- 46 -

Certificates issued by CAs to end-user Subscribers may have Operational Periods longer than three years, up to six years, if the following requirements are met: Protection of the Subscriber key pairs in relation to its operational environment for Organizational Certificates, operation within the enhanced protection of a data center and for Individual Certificates, the Subscribers key pairs reside on a hardware token, such as a smart card, Subscribers are required to undergo re-authentication at least every 3 years under Section 3.2.3, If a Subscriber is unable to complete re-authentication procedures successfully or is unable to prove possession of such private key when required by the foregoing, the CA shall revoke the Subscribers Certificate. Symantec also operates the "Symantec Class 3 International Server CA", Thawte SGC CA and the "Class 3 Open Financial Exchange CA" which are online CAs signed by a PCA. The validity of these CAs may exceed the validity periods described in Table 8 above to ensure continued interoperability of certificates offering SGC and OFX capability. 6.3.2.1 CABF Validity Period Requirements

EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA /Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 9.4 of Appendix B1, Appendix C and Appendix D, respectively.

6.4 6.4.1

Activation Data Activation Data Generation and Installation

Activation data (Secret Shares) used to protect tokens containing STN CA private keys is generated in accordance with the requirements of CPS 6.2.2 and the Key Ceremony Reference Guide. The creation and distribution of Secret Shares is logged. RAs are required to select strong passwords to protect their private keys. Symantecs password selection guidelines require that passwords: be generated by the user; have at least fifteen characters; have at least one alphabetic and one numeric character; have at least one lower-case letter; not contain many occurrences of the same character; not be the same as the operator's profile name; and not contain a long substring of the user's profile name. Symantec strongly recommends that Enterprise Administrators, RAs, and end-user Subscribers choose passwords that meet the same requirements. Symantec also recommends the use of two factor authentication mechanisms (e.g., token and passphrase, biometric and token, or biometric and passphrase) for private key activation.

6.4.2

Activation Data Protection

Symantec Shareholders are required to safeguard their Secret Shares and sign an agreement acknowledging their Shareholder responsibilities. RAs are required to store their Administrator/RA private keys in encrypted form using password protection and their browsers high security option.

- 47 -

Symantec strongly recommends that Client Administrators, RAs and end-user Subscribers store their private keys in encrypted form and protect their private keys through the use of a hardware token and/or strong passphrase. The use of two factor authentication mechanisms (e.g., token and passphrase, biometric and token, or biometric and passphrase) is encouraged.

6.4.3
6.4.3.1

Other Aspects of Activation Data

Activation Data Transmission

To the extent activation data for private keys are transmitted, STN Participants shall protect the transmission using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys. To the extent Windows or network logon user name/password combination is used as activation data for an end-user Subscriber, the passwords transferred across a network shall be protected against access by unauthorized users. 6.4.3.2 Activation Data Destruction

Activation data for CA private keys shall be decommissioned using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of the private keys protected by such activation data. After the record retention periods in Section 5.5.2 lapse, Symantec shall decommission activation data by overwriting and/or physical destruction.

6.5

Computer Security Controls

Symantec performs all CA and RA functions using Trustworthy Systems that meet the requirements of Symantecs SAR Guide. Enterprise Customers must use Trustworthy Systems.

6.5.1

Specific Computer Security Technical Requirements

Symantec ensures that the systems maintaining CA software and data files are Trustworthy Systems secure from unauthorized access. In addition, Symantec limits access to production servers to those individuals with a valid business reason for such access. General application users do not have accounts on production servers. Symantecs production network is logically separated from other components. This separation prevents network access except through defined application processes. Symantec uses firewalls to protect the production network from internal and external intrusion and limit the nature and source of network activities that may access production systems. Symantec requires the use of passwords that have a minimum character length and a combination of alphanumeric and special characters. Symantec requires that passwords be changed on a periodic basis. Direct access to Symantec databases supporting Symantecs CA Operations is limited to Trusted Persons in Symantecs Production Operations group having a valid business reason for such access. 6.5.1.1 CABF Requirements for System Security

EV SSL Certificates, EV Code Signing, and domain validated and organization validated SSL Certificates conform to the CA /Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 16.5 of Appendix B1, Appendix C and Appendix D, respectively.

- 48 -

6.5.2

Computer Security Rating

No stipulation.

6.6 6.6.1

Life Cycle Technical Controls System Development Controls

Applications are developed and implemented by Symantec in accordance with Symantec systems development and change management standards. Symantec also provides software to its Enterprise Customers for performing RA and certain CA functions. Such software is developed in accordance with Symantec system development standards. Symantec developed software, when first loaded, provides a method to verify that the software on the system originated from Symantec, has not been modified prior to installation, and is the version intended for use.

6.6.2

Security Management Controls

Symantec has mechanisms and/or policies in place to control and monitor the configuration of its CA systems. Symantec creates a hash of all software packages and Symantec software updates. This hash is used to verify the integrity of such software manually. Upon installation and periodically thereafter, Symantec validates the integrity of its CA systems.

6.6.3

Life Cycle Security Controls

No stipulation

6.7

Network Security Controls

Symantec performs all its CA and RA functions using networks secured in accordance with the Security and Audit Requirements (SAR) Guide to prevent unauthorized access and other malicious activity. Symantec protects its communications of sensitive information through the use of encryption and digital signatures.

6.8

Time-Stamping

Certificates, CRLs, and other revocation database entries shall contain time and date information. Such time information need not be cryptographic-based.

7. Certificate, CRL, and OCSP Profiles

7.1 Certificate Profile

Symantec Certificates generally conform to (a) ITU-T Recommendation X.509 (1997): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997 and (b) RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, April 26 2002 (RFC 5280) . As applicable to the Certificate type, STN Certificates conform to the

26

While STN certificates generally conform to RFC 5280, certain limited provisions may not be supported.

27

STN certificates that do not conform to the current version of the CA/Browser Forum Baseline Requirements that have a key pair and key length size less than 2048bit may have server auth removed and/or a designated OID of 2.16.840.1.113733.1.8.54.1.

- 49 -

current version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. At a minimum, X.509 Certificates shall contain the basic fields and indicated prescribed values or value constraints in Table 9 below:
Field Serial Number Signature Algorithm Issuer DN Valid From Valid To Subject DN Subject Public Key Signature Value or Value constraint Unique value per Issuer DN that exhibits at least 20 bits of entropy. Object identifier of the algorithm used to sign the certificate (See CP 7.1.3) See Section 7.1.4 Universal Coordinate Time base. Synchronized to Master Clock of U.S. Naval Observatory. Encoded in accordance with RFC 5280. Universal Coordinate Time base. Synchronized to Master Clock of U.S. Naval Observatory. Encoded in accordance with RFC 5280. See CP 7.1.4 Encoded in accordance with RFC 5280 Generated and encoded in accordance with RFC 5280

Table 9 Certificate Profile Basic Fields

7.1.1

Version Number(s)

Symantec Certificates are X.509 Version 3 Certificates although certain Root Certificates are permitted to be X.509 Version 1 Certificates to support legacy systems. CA certificates shall be X.509 Version 1 or Version 3 CA Certificates. End-user Subscriber Certificates shall be X.509 Version 3.

7.1.2

Certificate Extensions

Symantec populates X.509 Version 3 STN Certificates with the extensions required by Section 7.1.2.1-7.1.2.8. Private extensions are permissible, but the use of private extensions is not warranted under this CP and the applicable CPS unless specifically included by reference. EV SSL certificate extension requirements are described in Appendix B3 to this CPS. 7.1.2.1 Key Usage

X.509 Version 3 Certificates are generally populated in accordance with RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, April 2002. The criticality field of the KeyUsage extension is generally set to TRUE for CA certificates and may be set to either TRUE or FALSE for end entity Subscriber certificates. Note: The non-Repudiation bit is not required to be set in these Certificates because the PKI industry has not yet reached a consensus as to what the non-Repudiation bit means. Until such a consensus emerges, the non-Repudiation bit might not be meaningful for potential Relying Parties. Moreover, the most commonly used applications do not always respect the nonRepudiation bit. Therefore, setting the bit might not help Relying Parties make a trust decision. Consequently, this CPS does not require that the non-Repudiation bit be set. It may be set in the
27 27

The non-Repudiation bit may also be referred to as ContentCommitment in Digital Certificates in accordance with the X.509 standard.
28

STN certificates that have a non-standard key pair and key length size of less than 2048bit are authorized to be used within a selected group or closed eco system.

- 50 -

case of dual key pair signature Certificates issued through Managed PKI Key Manager, or as otherwise requested. Any dispute relating to non-repudiation arising from the use of a digital certificate is a matter solely between the Subscriber and the Relying Party(s). Symantec shall incur no liability in relation thereto. 7.1.2.2 Certificate Policies Extension

The CertificatePolicies extension of X.509 Version 3 Certificates are populated with the object identifier for the STN CP in accordance with CP Section 7.1.6 and with policy qualifiers set forth in CP Section 7.1.8. The criticality field of this extension shall be set to FALSE. 7.1.2.2.1 CABF Requirement for Certificate Policies Extension EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 9.3 of Appendix B1, Appendix C, and Appendix D, respectively. 7.1.2.3 Subject Alternative Names

The subjectAltName extension of X.509 Version 3 Certificates are populated in accordance with RFC 5280 with the exception of those issued under Public Lite accounts which may optionally exclude the email address in SubjectAltName. The criticality field of this extension shall be set to FALSE. 7.1.2.4 Basic Constraints

Symantec X.509 Version 3 CA Certificates BasicConstraints extension shall have the CA field set to TRUE. End-user Subscriber Certificates BasicConstraints extension shall have the CA field set to FALSE. The criticality field of this extension shall be set to TRUE for CA Certificates, but may be set to TRUE or FALSE for end-user Subscriber Certificates. Symantec X.509 Version 3 CA Certificates shall have a pathLenConstraint field of the BasicConstraints extension set to the maximum number of CA certificates that may follow this Certificate in a certification path. CA Certificates issued to an online Enterprise Customer issuing end-user Subscriber Certificates shall have a pathLenConstraint field set to a value of 0 indicating that only an end-user Subscriber Certificate may follow in the certification path. 7.1.2.5 Extended Key Usage

By default, ExtendedKeyUsage is set as a non-critical extension. STN CA Certificates do not include the ExtendedKeyUsage extension. 7.1.2.6 CRL Distribution Points

Most Symantec X.509 Version 3 end user Subscriber Certificates and Intermediate CA Certificates include the cRLDistributionPoints extension containing the URL of the location where a Relying Party can obtain a CRL to check the CA Certificates status. The criticality field of this extension is set to FALSE. 7.1.2.7 Authority Key Identifier

Symantec generally populates the Authority Key Identifier extension of X.509 Version 3 end user Subscriber Certificates and Intermediate CA Certificates . When the certificate issuer contains the

- 51 -

Subject Key Identifier extension, the Authority Key Identifier is composed of the 160-bit SHA-1 hash of the public key of the CA issuing the Certificate. Otherwise, the Authority Key Identifier extension includes the issuing CAs subject distinguished name and serial number. The criticality field of this extension is set to FALSE. 7.1.2.8 Subject Key Identifier

Where Symantec populates X.509 Version 3 STN Certificates with a subjectKeyIdentifier extension, the keyIdentifier based on the public key of the Subject of the Certificate is generated in accordance with one of the methods described in RFC 5280. Where this extension is used, the criticality field of this extension is set to FALSE.

7.1.3

Algorithm Object Identifiers

Symantec Certificates are signed using one of following algorithms. sha256withRSAEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11} ecdsa-with-Sha256 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-X962(10045) signatures(4) ecdsa-with-SHA2 (3) 2} ecdsa-with-Sha384 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-X962(10045) signatures(4) ecdsa-with-SHA2 (3) 3} sha-1WithRSAEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5} md5WithRSAEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4}

Certificate signatures produced using these algorithms shall comply with RFC 3279. Either sha28 1WithRSAEncryption or sha256WithRSAEncryption will be used over md5WithRSAEncryption .

7.1.4

Name Forms

Symantec populates STN Certificates with an Issuer Name and Subject Distinguished Name in accordance with Section 3.1.1. The Issuer Name shall be populated in each Certificate issued containing the Country, Organization Name and the Common Name of the Issuer CA. In addition, Symantec may include within end-user Subscriber Certificates an additional Organizational Unit field that contains a notice stating that the terms of use of the Certificate are set forth in a URL which is a pointer to the applicable Relying Party Agreement. This OU must appear if a pointer to the applicable Relying Party Agreement is not included in the policy extension of the certificate.

7.1.5

Name Constraints

No stipulation

28

md5WithRSAEncryption is used only with prior approval to preserve business continuity of legacy applications.

- 52 -

7.1.6

Certificate Policy Object Identifier

Where the Certificate Policies extension is used, Certificates contain the object identifier for the Certificate Policy corresponding to the appropriate Class of Certificate as set forth in the STN CP Section1.2. For legacy Certificates issued prior to the publication of the STN CP which include the Certificate Policies extension, Certificates refer to the STN CPS. 7.1.6.1 CABF Requirements for Certificate Policy Object Identifier

EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 9.3 of Appendix B1, Appendix C and Appendix D, respectively.

7.1.7

Usage of Policy Constraints Extension

No stipulation

7.1.8

Policy Qualifiers Syntax and Semantics

Symantec generally populates X.509 Version 3 STN Certificates with a policy qualifier within the Certificate Policies extension. Generally, such Certificates contain a CPS pointer qualifier that points to the applicable Relying Party Agreement or the STN CPS. In addition, some Certificates contain a User Notice Qualifier which points to the applicable Relying Party Agreement.

7.1.9

Processing Semantics for the Critical Certificate Policies Extension

No stipulation

7.2

CRL Profile

Version 2 CRLs conform to RFC 5280 and contain the basic fields and contents specified in Table 13 below:
Field Version Signature Algorithm Issuer Effective Date Next Update Revoked Certificates Value or Value constraint See Section 7.2.1. Algorithm used to sign the CRL in accordance with RFC 3279. (See CPS 7.1.3) Entity who has signed and issued the CRL. Issue date of the CRL. CRLs are effective upon issuance. Date by which the next CRL will be issued. CRL issuance frequency is in accordance with the requirements of Section 4.9.7. Listing of revoked certificates, including the Serial Number of the revoked Certificate and the Revocation Date.

Table 13 CRL Profile Basic Fields

7.2.1

Version Number(s)

Symantec supports both X.509 Version1 and Version 2 CRLs. Version 2 CRLs comply with the requirements of RFC 5280.

7.2.2

CRL and CRL Entry Extensions

No stipulation.

- 53 -

7.3

OCSP Profile

OCSP (Online Certificate Status Protocol) is a way to obtain timely information about the revocation status of a particular certificate. Symantec validates: Class 2 Enterprise certificates using the Enterprise OCSP which conforms to RFC 2560, and Class 2 Enterprise certificates and Class 3 organization certificates using the Symantec Trusted Global Validation (TGV) service which conforms to RFC 5019. CABF Requirement for OCSP Signing For EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates, Symantec provides OCSP responses as set forth in the STN Supplemental Procedures, in section 13 of Appendix B1 and C, and section 13.2.5 and Appendix D, respectively.

7.3.1

Version Number(s)

Version 1 of the OCSP specification as defined by RFC2560 and Version 1 of the OCSP specification as defined by RFC 5019 are supported.

7.3.2

OCSP Extensions

Symantec TGV Service uses secure timestamp and validity period to establish the current freshness of each OCSP response. Symantec does not use a nonce to establish the current freshness of each OCSP response and clients should not expect a nonce in the response to a request that contains a nonce. Instead, clients should use the local clock to check for response freshness.

8. Compliance Audit and Other Assessments

An annual WebTrust for Certification Authorities v2.0 or later examination is performed for Symantecs data center operations and key management operations supporting Symantecs public and Managed PKI CA services including the STN Root CAs, Class 3 Organizational CAs, Class 2 Organizational and Individual CAs, and Class 1 Individual CAs specified in Section 1.3.1. Customer-specific CAs are not specifically audited as part of the audit of Symantecs operations unless required by the Customer. Symantec shall be entitled to require that Enterprise Customers undergo a compliance audit under this CPS and audit programs for these types of Customers. In addition to compliance audits, Symantec shall be entitled to perform other reviews and investigations to ensure the trustworthiness of Symantecs Sub-domain of the STN, which include, but are not limited to: Symantec shall be entitled, within its sole and exclusive discretion, to perform at any time an Exigent Audit/Investigation on a Customer in the event Symantec has reason to believe that the audited entity has failed to meet STN Standards, has experienced an incident or compromise, or has acted or failed to act, such that the audited entitys failure, the incident or compromise, or the act or failure to act poses an actual or potential threat to the security or integrity of the STN. Symantec shall be entitled to perform Supplemental Risk Management Reviews on a Customer following incomplete or exceptional findings in a Compliance Audit or as part of the overall risk management process in the ordinary course of business.

Symantec shall be entitled to delegate the performance of these audits, reviews, and investigations to a third party audit firm. Entities that are subject to an audit, review, or

- 54 -

investigation shall provide reasonable cooperation with Symantec and the personnel performing the audit, review, or investigation. CABF Requirement for Self-Audits For EV SSL Certificates, EV Code Signing, and Organization-validated and Domain-validated SSL Certificates, Symantec shall conduct self-audits as set forth in the STN Supplemental Procedures, in section 17.5 of Appendix B1 and C, and section 17.8 of Appendix D, respectively.

8.1

Frequency and Circumstances of Assessment

Compliance Audits are conducted at least annually at the sole expense of the audited entity. Audits are conducted over unbroken sequences of audit periods with each period no longer than one year duration.

8.2

Identity/Qualifications of Assessor

Symantecs CA compliance audits are performed by a public accounting firm that: Demonstrates proficiency in conducting the WebTrust for Certification Authorities v2.0 or later, Demonstrates proficiency in public key infrastructure technology, information security tools and techniques, security auditing, and the third-party attestation function, Is accredited by the American Institute of Certified Public Accountants (AICPA), which requires the possession of certain skill sets, quality assurance measures such as peer review, competency testing, standards with respect to proper assignment of staff to engagements, and requirements for continuing professional education, Is bound by law, government regulation, or professional code of ethics; and maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage.

8.3

Assessor's Relationship to Assessed Entity

Compliance audits of Symantecs operations are performed by a public accounting firm that is independent of Symantec.

8.4

Topics Covered by Assessment

The scope of Symantecs annual WebTrust for Certification Authorities (or equivalent) audit includes CA environmental controls, key management operations and Infrastructure/Administrative CA controls, certificate life cycle management and CA business practices disclosure.

8.5

Actions Taken as a Result of Deficiency

With respect to compliance audits of Symantecs operations, significant exceptions or deficiencies identified during the Compliance Audit will result in a determination of actions to be taken. This determination is made by Symantec management with input from the auditor. Symantec management is responsible for developing and implementing a corrective action plan. If Symantec determines that such exceptions or deficiencies pose an immediate threat to the security or integrity of the STN, a corrective action plan will be developed within 30 days and implemented within a commercially reasonable period of time. For less serious exceptions or deficiencies, Symantec Management will evaluate the significance of such issues and determine the appropriate course of action.

- 55 -

8.6

Communications of Results

Symantec makes its annual Audit Report publicly available no later than three (3) months after the end of the audit period. In the event of a delay greater than three months, Symantec shall provide an explanatory letter signed by the Qualified Auditor. A copy of Symantecs WebTrust for CA audit report can be found at www.symantec.com/about/profile/policies/repository.jsp.

9. Other Business and Legal Matters

9.1 9.1.1 Fees Certificate Issuance or Renewal Fees

Symantec is entitled to charge end-user Subscribers for the issuance, management, and renewal of Certificates.

9.1.2

Certificate Access Fees

Symantec does not charge a fee as a condition of making a Certificate available in a repository or otherwise making Certificates available to Relying Parties.

9.1.3

Revocation or Status Information Access Fees

Symantec does not charge a fee as a condition of making the CRLs required by the CP available in a repository or otherwise available to Relying Parties. Symantec is, however, entitled to charge a fee for providing customized CRLs, OCSP services, or other value-added revocation and status information services. Symantec does not permit access to revocation information, Certificate status information, or time stamping in their repositories by third parties that provide products or services that utilize such Certificate status information without Symantecs prior express written consent.

9.1.4

Fees for Other Services

Symantec does not charge a fee for access to this CPS. Any use made for purposes other than simply viewing the document, such as reproduction, redistribution, modification, or creation of derivative works, shall be subject to a license agreement with the entity holding the copyright to the document.

9.1.5

Refund Policy

Within Symantecs Sub-domain, the following refund policy (reproduced at www.symantec.com/about/profile/policies/repository.jsp) is in effect: Symantec adheres to, and stands behind, rigorous practices and policies in undertaking certification operations and in issuing certificates. Nevertheless, if for any reason a subscriber is not completely satisfied with the certificate issued to him, her, or it, the subscriber may request that Symantec revoke the certificate within thirty (30) days of issuance and provide the subscriber with a refund. Following the initial thirty (30) day period, a subscriber may request that Symantec revoke the certificate and provide a refund if Symantec has breached a warranty or other material obligation under this CPS or the NetSure(sm) Protection Plan relating to the subscriber or the subscribers certificate. After Symantec revokes the subscribers certificate, Symantec will promptly credit the subscriber's credit card account (if the certificate was paid for via credit card) or otherwise reimburse the subscriber via check, for the full amount of the applicable fees paid for the certificate. To request a refund, please call customer service at +1 650 426-3400. This refund

- 56 -

policy is not an exclusive remedy and does not limit other remedies that may be available to subscribers.

9.2 9.2.1

Financial Responsibility Insurance Coverage

Enterprise Customers are encouraged to maintain a commercially reasonable level of insurance coverage for errors and omissions, either through an errors and omissions insurance program with an insurance carrier or a self-insured retention. Symantec maintains such errors and omissions insurance coverage.

9.2.2

Other Assets

Enterprise Customers shall have sufficient financial resources to maintain their operations and perform their duties, and they must be reasonably able to bear the risk of liability to Subscribers and Relying Parties. Symantecs financial resources are set forth in disclosures appearing at: http://investor.symantec.com/phoenix.zhtml?c=89422&p=irol-irhome.

9.2.3

Extended Warranty Coverage

The NetSure Protection Plan is an extended warranty program that provides Symantec SSL and code signing certificate subscribers with protection against loss or damage that is due to a defect in Symantecs issuance of the certificate or other malfeasance caused by Symantecs negligence or breach of its contractual obligations, provided that the subscriber of the certificate has fulfilled its obligations under the applicable service agreement. For general information concerning the NetSure Protection Plan, and a discussion of which Certificates are covered by it, see www.symantec.com/about/profile/policies/repository.jsp.

9.3 9.3.1

Confidentiality of Business Information Scope of Confidential Information

The following records of Subscribers shall, subject to Section 9.3.2, be kept confidential and private (Confidential/Private Information): CA application records, whether approved or disapproved, Certificate Application records, Private keys held by enterprise Customers using Managed PKI Key Manager and information needed to recover such Private Keys, Transactional records (both full records and the audit trail of transactions), Audit trail records created or retained by Symantec or a Customer, Audit reports created by Symantec or a Customer (to the extent such reports are maintained), or their respective auditors (whether internal or public), Contingency planning and disaster recovery plans, and Security measures controlling the operations of Symantec hardware and software and the administration of Certificate services and designated enrollment services.

9.3.2

Information Not Within the Scope of Confidential Information

Certificates, Certificate revocation and other status information, Symantec repositories and information contained within them are not considered Confidential/Private Information. Information not expressly deemed Confidential/Private Information under Section 9.3.1 shall be considered neither confidential nor private. This section is subject to applicable privacy laws.

- 57 -

9.3.3

Responsibility to Protect Confidential Information

Symantec secures private information from compromise and disclosure to third parties.

9.4 9.4.1

Privacy of Personal Information Privacy Plan

Symantec has implemented a privacy policy, which is located at: www.symantec.com/about/profile/privacypolicy/index.jsp, in compliance with CP 9.4.1.

9.4.2

Information Treated as Private

Any information about Subscribers that is not publicly available through the content of the issued certificate, certificate directory and online CRLs is treated as private

9.4.3

Information Not Deemed Private

Subject to local laws, all information made public in a certificate is deemed not private.

9.4.4

Responsibility to Protect Private Information

STN participants receiving private information shall secure it from compromise and disclosure to third parties and shall comply with all local privacy laws in their jurisdiction.

9.4.5

Notice and Consent to Use Private Information

Unless where otherwise stated in this CPS, the applicable Privacy Policy or by agreement, private information will not be used without the consent of the party to whom that information applies. This section is subject to applicable privacy laws

9.4.6

Disclosure Pursuant to Judicial or Administrative Process

Symantec shall be entitled to disclose Confidential/Private Information if, in good faith, Symantec believes that: disclosure is necessary in response to subpoenas and search warrants. disclosure is necessary in response to judicial, administrative, or other legal process during the discovery process in a civil or administrative action, such as subpoenas, interrogatories, requests for admission, and requests for production of documents. This section is subject to applicable privacy laws.

9.4.7

Other Information Disclosure Circumstances

No Stipulation

9.5

Intellectual Property rights

The allocation of Intellectual Property Rights among Symantec Sub-domain Participants other than Subscribers and Relying Parties is governed by the applicable agreements among such Symantec Sub-domain Participants. The following subsections of Section 9.5 apply to the Intellectual Property Rights in relation to Subscribers and Relying Parties.

- 58 -

9.5.1

Property Rights in Certificates and Revocation Information

CAs retain all Intellectual Property Rights in and to the Certificates and revocation information that they issue. Symantec and Customers grant permission to reproduce and distribute Certificates on a nonexclusive royalty-free basis, provided that they are reproduced in full and that use of Certificates is subject to the Relying Party Agreement referenced in the Certificate. Symantec and Customers shall grant permission to use revocation information to perform Relying Party functions subject to the applicable CRL Usage Agreement, Relying Party Agreement, or any other applicable agreements.

9.5.2

Property Rights in the CPS

STN Participants acknowledge that Symantec retains all Intellectual Property Rights in and to this CPS.

9.5.3

Property Rights in Names

A Certificate Applicant retains all rights it has (if any) in any trademark, service mark, or trade name contained in any Certificate Application and distinguished name within any Certificate issued to such Certificate Applicant.

9.5.4

Property Rights in Keys and Key Material

Key pairs corresponding to Certificates of CAs and end-user Subscribers are the property of the CAs and end-user Subscribers that are the respective Subjects of these Certificates, subject to the rights of enterprise Customers using Managed PKI Key Manager, regardless of the physical medium within which they are stored and protected, and such persons retain all Intellectual Property Rights in and to these key pairs. Without limiting the generality of the foregoing, Symantecs Root public keys and the Root Certificates containing them, including all PCA public keys and self-signed Certificates, are the property of Symantec. Symantec licenses software and hardware manufacturers to reproduce such root Certificates to place copies in trustworthy hardware devices or software. Finally, Secret Shares of a CAs private key are the property of the CA, and the CA retains all Intellectual Property Right in and to such Secret Shares even though they cannot obtain physical possession of the those shares or the CA from Symantec.

9.6 9.6.1

Representations and Warranties CA Representations and Warranties

Symantec warrants that: There are no material misrepresentations of fact in the Certificate known to or originating from the entities approving the Certificate Application or issuing the Certificate, There are no errors in the information in the Certificate that were introduced by the entities approving the Certificate Application or issuing the Certificate as a result of a failure to exercise reasonable care in managing the Certificate Application or creating the Certificate, Their Certificates meet all material requirements of this CPS, and Revocation services and use of a repository conform to the applicable CPS in all material aspects. Subscriber Agreements may include additional representations and warranties.

- 59 -

9.6.1.1

CABF Warranties and Obligations

EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in sections 7.1 and 18 of Appendix B1 and C, and sections 7.1 (CA Warranties) and 18.3 (Root CA Obligations) of Appendix D, respectively.

9.6.2

RA Representations and Warranties

RAs warrant that: There are no material misrepresentations of fact in the Certificate known to or originating from the entities approving the Certificate Application or issuing the Certificate, There are no errors in the information in the Certificate that were introduced by the entities approving the Certificate Application as a result of a failure to exercise reasonable care in managing the Certificate Application, Their Certificates meet all material requirements of this CPS, and Revocation services (when applicable) and use of a repository conform to the applicable CPS in all material aspects. Subscriber Agreements may include additional representations and warranties.

9.6.3

Subscriber Representations and Warranties

Subscribers warrant that: Each digital signature created using the private key corresponding to the public key listed in the Certificate is the digital signature of the Subscriber and the Certificate has been accepted and is operational (not expired or revoked) at the time the digital signature is created, Their private key is protected and that no unauthorized person has ever had access to the Subscribers private key, All representations made by the Subscriber in the Certificate Application the Subscriber submitted are true, All information supplied by the Subscriber and contained in the Certificate is true, The Certificate is being used exclusively for authorized and legal purposes, consistent with this CPS, and The Subscriber is an end-user Subscriber and not a CA, and is not using the private key corresponding to any public key listed in the Certificate for purposes of digitally signing any Certificate (or any other format of certified public key) or CRL, as a CA or otherwise. Subscriber Agreements may include additional representations and warranties.

9.6.4

Relying Party Representations and Warranties

Relying Party Agreements require Relying Parties to acknowledge that they have sufficient information to make an informed decision as to the extent to which they choose to rely on the information in a Certificate, that they are solely responsible for deciding whether or not to rely on such information, and that they shall bear the legal consequences of their failure to perform the Relying Party obligations in terms of this CPS. Relying Party Agreements may include additional representations and warranties.

9.6.5

Representations and Warranties of Other Participants

No stipulation

- 60 -

9.7

Disclaimers of Warranties

To the extent permitted by applicable law, Subscriber Agreements and Relying Party Agreements shall disclaim Symantecs possible warranties, including any warranty of merchantability or fitness for a particular purpose, outside the context of the NetSure Protection Plan.

9.8

Limitations of Liability

To the extent Symantec has issued and managed the Certificate(s) at issue in compliance with its Certificate Policy and its Certification Practice Statement, Symantec shall have no liability to the Subscriber, any Relying Party, or any other third parties for any damages or losses suffered as a result of the use or reliance on such Certificate(s). To the extent permitted by applicable law, Subscriber Agreements and Relying Party Agreements shall limit Symantecs liability outside the context of the NetSure Protection Plan. Limitations of liability shall include an exclusion of indirect, special, incidental, and consequential damages. They shall also include the following liability caps limiting Symantecs damages concerning a specific Certificate:
Class Class 1 Class 2 Class 3 Liability Caps One Hundred U.S. Dollars ($ 100.00 US) Five Thousand U.S. Dollars ($ 5,000.00 US) One Hundred Thousand U.S. Dollars ($ 100,000.00 US)

Table 14 Liability Caps The liability caps in Table 14 limit damages recoverable outside the context of the NetSure Protection Plan. Amounts paid under the NetSure Protection Plan are subject to their own liability caps. The liability caps under the NetSure Protection Plan for different kinds of Certificates range from $50,000 US to $250,000 US. See the NetSure Protection Plan for more detail at www.symantec.com/about/profile/policies/repository.jsp. The liability (and/or limitation thereof) of Subscribers shall be as set forth in the applicable Subscriber agreements. The liability (and/or limitation thereof) of enterprise RAs and the applicable CA shall be set out in the agreement(s) between them. The liability (and/or limitation thereof) of Relying Parties shall be as set forth in the applicable Relying Party Agreements. Symantecs limitation of liability for EV certificates is further described in Section 37 of Appendix B1 to this CPS.

9.9 9.9.1

Indemnities Indemnification by Subscribers

To the extent permitted by applicable law, Subscribers are required to indemnify Symantec for: Falsehood or misrepresentation of fact by the Subscriber on the Subscribers Certificate Application, Failure by the Subscriber to disclose a material fact on the Certificate Application, if the misrepresentation or omission was made negligently or with intent to deceive any party, The Subscribers failure to protect the Subscribers private key, to use a Trustworthy System, or to otherwise take the precautions necessary to prevent the compromise, loss, disclosure, modification, or unauthorized use of the Subscribers private key, or

- 61 -

The Subscribers use of a name (including without limitation within a common name, domain name, or e-mail address) that infringes upon the Intellectual Property Rights of a third party.

The applicable Subscriber Agreement may include additional indemnity obligations.

9.9.2

Indemnification by Relying Parties

To the extent permitted by applicable law, Relying Party Agreements shall require Relying Parties to indemnify Symantec for: The Relying Partys failure to perform the obligations of a Relying Party, The Relying Partys reliance on a Certificate that is not reasonable under the circumstances, or The Relying Partys failure to check the status of such Certificate to determine if the Certificate is expired or revoked. The applicable Relying Party Agreement may include additional indemnity obligations.

9.9.3

Indemnification of Application Software Suppliers

Notwithstanding any limitations on its liability to Subscribers and Relying Parties, the CA understands and acknowledges that the Application Software Suppliers who have a Root Certificate distribution agreement in place with the Symantec Root CA do not assume any obligation or potential liability of the CA under these Requirements or that otherwise might exist because of the issuance or maintenance of Certificates or reliance thereon by Relying Parties or others. Thus the CA shall defend, indemnify, and hold harmless each Application Software Supplier for any and all claims, damages, and losses suffered by such Application Software Supplier related to a Certificate issued by the CA, regardless of the cause of action or legal theory involved. This does not apply, however, to any claim, damages, or loss suffered by such Application Software Supplier related to a Certificate issued by the CA where such claim, damage, or loss was directly caused by such Application Software Suppliers software displaying as not trustworthy a Certificate that is still valid, or displaying as trustworthy: (1) a Certificate that has expired, or (2) a Certificate that has been revoked (but only in cases where the revocation status is currently available from the CA online, and the application software either failed to check such status or ignored an indication of revoked status).

9.10

Term and Termination

9.10.1 Term
The CPS becomes effective upon publication in the Symantec Repository. Amendments to this CPS become effective upon publication in the Symantec Repository.

9.10.2 Termination
This CPS as amended from time to time shall remain in force until it is replaced by a new version.

9.10.3 Effect of Termination and Survival

Upon termination of this CPS, Symantec Sub-domain participants are nevertheless bound by its terms for all certificates issued for the remainder of the validity periods of such certificates.

- 62 -

9.11

Individual Notices and Communications with Participants

Unless otherwise specified by agreement between the parties, Symantec Sub-domain participants shall use commercially reasonable methods to communicate with each other, taking into account the criticality and subject matter of the communication.

9.12

Amendments

9.12.1 Procedure for Amendment

Amendments to this CPS may be made by the Symantec Policy Management Authority (PMA). Amendments shall either be in the form of a document containing an amended form of the CPS or an update. Amended versions or updates shall be linked to the Practices Updates and Notices section of the Symantec Repository located at: www.symantec.com/about/profile/policies/repository.jsp. Updates supersede any designated or conflicting provisions of the referenced version of the CPS. The PMA shall determine whether changes to the CPS require a change in the Certificate policy object identifiers of the Certificate policies corresponding to each Class of Certificate.

9.12.2 Notification Mechanism and Period

Symantec and the PMA reserve the right to amend the CPS without notification for amendments that are not material, including without limitation corrections of typographical errors, changes to URLs, and changes to contact information. The PMAs decision to design ate amendments as material or non-material shall be within the PMAs sole discretion Proposed amendments to the CPS shall appear in the Practices Updates and Notices section of the Symantec Repository, which is located at: www.symantec.com/about/profile/policies/repository.jsp. The PMA solicits proposed amendments to the CPS from other Symantec Sub-domain participants. If the PMA considers such an amendment desirable and proposes to implement the amendment, the PMA shall provide notice of such amendment in accordance with this section. Notwithstanding anything in the CPS to the contrary, if the PMA believes that material amendments to the CPS are necessary immediately to stop or prevent a breach of the security of the STN or any portion of it, Symantec and the PMA shall be entitled to make such amendments by publication in the Symantec Repository. Such amendments will be effective immediately upon publication. Within a reasonable time after publication, Symantec shall provide notice to Affiliates of such amendments. 9.12.2.1 Comment Period

Except as otherwise stated, the comment period for any material amendments to the CPS shall be fifteen (15) days, starting on the date on which the amendments are posted on the Symantec Repository. Any Symantec Sub-domain participant shall be entitled to file comments with the PMA up until the end of the comment period. 9.12.2.2 Mechanism to Handle Comments

The PMA shall consider any comments on the proposed amendments. The PMA shall either (a) allow the proposed amendments to become effective without amendment, (b) amend the proposed amendments and republish them as a new amendment when required, or (c) withdraw the proposed amendments. The PMA is entitled to withdraw proposed amendments by notifying Affiliates and providing notice in the Practices Updates and Notices section of the Symantec

- 63 -

Repository. Unless proposed amendments are amended or withdrawn, they shall become effective upon the expiration of the comment period.

9.12.3 Circumstances under Which OID Must be Changed

If the PMA determines that a change is necessary in the object identifier corresponding to a Certificate policy, the amendment shall contain new object identifiers for the Certificate policies corresponding to each Class of Certificate. Otherwise, amendments shall not require a change in Certificate policy object identifier.

9.13

Dispute Resolution Provisions

9.13.1 Disputes among Symantec, Affiliates, and Customers

Disputes among Symantec Sub-domain participants shall be resolved pursuant to provisions in the applicable agreements among the parties.

9.13.2 Disputes with End-User Subscribers or Relying Parties

To the extent permitted by applicable law, Subscriber Agreements and Relying Party Agreements shall contain a dispute resolution clause. Disputes involving Symantec require an initial negotiation period of sixty (60) days followed by litigation in the federal or state court encompassing Santa Clara County, California, in the case of claimants who are U.S. residents, or, in the case of all other claimants, arbitration administered by the International Chamber of Commerce (ICC) in accordance with the ICC Rules of Conciliation and Arbitration, unless otherwise approved by Symantec.

9.14

Governing Law

Subject to any limits appearing in applicable law, the laws of the State of California, U.S.A., shall govern the enforceability, construction, interpretation, and validity of this CPS, irrespective of contract or other choice of law provisions and without the requirement to establish a commercial nexus in California, USA. This choice of law is made to ensure uniform procedures and interpretation for all STN Participants, no matter where they are located. This governing law provision applies only to this CPS. Agreements incorporating the CPS by reference may have their own governing law provisions, provided that this Section 9.14 governs the enforceability, construction, interpretation, and validity of the terms of the CPS separate and apart from the remaining provisions of any such agreements, subject to any limitations appearing in applicable law. This CPS is subject to applicable national, state, local and foreign laws, rules, regulations, ordinances, decrees, and orders including, but not limited to, restrictions on exporting or importing software, hardware, or technical information.

9.15

Compliance with Applicable Law

This CPS is subject to applicable national, state, local and foreign laws, rules, regulations, ordinances, decrees, and orders including, but not limited to, restrictions on exporting or importing software, hardware, or technical information. Symantec licenses its CAs in each jurisdiction that it operates where licensing is required by the law of such jurisdiction for the issuance of Certificates.

- 64 -

9.16

Miscellaneous Provisions

9.16.1 Entire Agreement

Not applicable

9.16.2 Assignment
Not applicable

9.16.3 Severability
In the event that a clause or provision of this CPS is held to be unenforceable by a court of law or other tribunal having authority, the remainder of the CPS shall remain valid.

9.16.4 Enforcement (Attorney's Fees and Waiver of Rights)

Not applicable

9.16.5 Force Majeure

To the extent permitted by applicable law, Subscriber Agreements and Relying Party Agreements shall include a force majeure clause protecting Symantec.

9.17

Other Provisions

Not applicable

- 65 -

Appendix A. Table of Acronyms and Definitions

Table of Acronyms
Term AICPA ANSI ACS BIS CA ccTLD CICA CP CPS CRL DBA DNS EV FIPS FQDN ICC IM IANA ICANN ISO KRB LSVA NIST OCSP OID PCA PIN PKCS PKI PMA QGIS QIIS RA RFC SAR S/MIME SSL STN TLD TLS VOID Definition American Institute of Certified Public Accountants. The American National Standards Institute. Authenticated Content Signing. The United States Bureau of Industry and Science of the United States Department of Commerce. Certification Authority. Country Code Top-Level Domain Canadian Instituted of Chartered Accountants Certificate Policy. Certification Practice Statement. Certificate Revocation List. Doing Business As Domain Name System Extended Validation United State Federal Information Processing Standards. Fully Qualified Domain Name International Chamber of Commerce. Instant Messaging Internet Assigned Numbers Authority Internet Corporation for Assigned Names and Numbers International Organization for Standardization Key Recovery Block. Logical security vulnerability assessment. (US Government) National Institute of Standards and Technology Online Certificate Status Protocol. Object Identifier Primary Certification Authority. Personal identification number. Public-Key Cryptography Standard. Public Key Infrastructure. Policy Management Authority. Qualified Government Information Source Qualified Independent Information Source Registration Authority. Request for comment. Security Audit Requirements Secure multipurpose Internet mail extensions. Secure Sockets Layer. Symantec Trust Network. Top-Level Domain Transport Layer Security Voice Over Internet Protocol

Definitions
Term Administrator Administrator Certificate Affiliate Definition A Trusted Person within the organization of a Processing Center, Service Center, Managed PKI Customer, or Gateway Customer that performs validation and other CA or RA functions. A Certificate issued to an Administrator that may only be used to perform CA or RA functions. A leading trusted third party, for example in the technology, telecommunications, or financial services

- 66 -

Term

Affiliate Practices Legal Requirements Guidebook Affiliated Individual

Applicant Applicant Representative

Application Software Vendor

Applicant

Applicant Representative

Application Software Supplier Attestation Letter Audit Report Automated Administration Automated Administration Software Module Certificate

Definition industry, that has entered into an agreement with Symantec to be a STN distribution and services channel within a specific territory. In the CAB Forum context, the term Affiliate refers to: A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity. A Symantec document setting forth requirements for Affiliate CPSs, agreements, validation procedures, and privacy policies, as well as other requirements that Affiliates must meet. A natural person that is related to a Managed PKI Customer, Managed PKI Lite Customer, or Gateway Customer entity (i) as an officer, director, employee, partner, contractor, intern, or other person within the entity, (ii) as a member of a Symantec registered community of interest, or (iii) as a person maintaining a relationship with the entity where the entity has business or other records providing appropriate assurances of the identity of such person. The Private Organization or Government Entity that applies for (or seeks renewal of) an EV Certificate naming it as the Subject. An individual person employed by the Applicant for an EV certificate: (i) who signs and submits, or approves an EV Certificate Request on behalf of an Applicant, and/or (ii) who signs and submits a Subscriber Agreement on behalf of an Applicant. A developer of Internet browser software or other software that displays or uses certificates and distributes root certificates, such as KDE, Microsoft Corporation, Mozilla Corporation, Opera Software ASA, and Red Hat, Inc. The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request. A natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant: (i) who signs and submits, or approves a certificate request on behalf of the Applicant, and/or (ii) who signs and submits a Subscriber Agreement on behalf of the Applicant, and/or (iii) who acknowledges and agrees to the Certificate Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the CA. A supplier of Internet browser software or other relying-party application software that displays or uses Certificates and incorporates Root Certificates. A letter attesting that Subject Information is correct written by an accountant, lawyer, government official, or other reliable third party customarily relied upon for such information. A report from a Qualified Auditor stating the Qualified Auditors opinion on whether an entitys processes and controls comply with the mandatory provisions of these Requirements. A procedure whereby Certificate Applications are approved automatically if enrollment information matches information contained in a database. Software provided by Symantec that performs Automated Administration. A message that, at least, states a name or identifies the CA, identifies the Subscriber, contains the Subscribers public key, identifies the Certificates Operational Period, contains a Certificate serial number, and is digitally signed by the CA. An individual or organization that requests the issuance of a Certificate by a CA. A request from a Certificate Applicant (or authorized agent of the Certificate Applicant) to a CA for the issuance of a Certificate. who has express authority to represent the Applicant of an EV Certificate to (i) act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and (ii) to approve EV Certificate Requests submitted by other Certificate Requesters. An ordered list of Certificates containing an end-user Subscriber Certificate and CA Certificates, which terminates in a root Certificate. Certificate requests and data related thereto (whether obtained from the Applicant or otherwise) in the CAs possession or control or to which the CA has access. Criteria that an entity must meet in order to satisfy a Compliance Audit. Processes, practices, and procedures associated with the use of keys, software, and hardware, by which the CA verifies Certificate Data, issues Certificates, maintains a Repository, and revokes Certificates. This document, which is entitled Symantec Trust Network Certificate Policies and is the principal statement of policy governing the STN. Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates

Certificate Applicant Certificate Application Certificate Approver

Certificate Chain Certificate Data Certificate Management Control Objectives Certificate Management Process

Certificate Policies (CP) Certificate Problem Report

- 67 -

Term Certificate Requester

Certificate Revocation List (CRL)

Certificate Signing Request Certification Authority (CA) Certification Practice Statement (CPS) Challenge Phrase

Class Client Service Center Compliance Audit Compromise

Confidential/Private Information Contract Signer

Country CRL Usage Agreement Cross Certificate Customer Delegated Third Party

Definition A Certificate Requester is a natural person who is employed and authorized by the Applicant, or an authorized agent who has express authority to represent the Applicant or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant. A periodically (or exigently) issued list, digitally signed by a CA, of identified Certificates that have been revoked prior to their expiration dates in accordance with CP 3.4. The list generally indicates the CRL issuers name, the date of issue, the date of the next scheduled CRL issue, the revoked Certificates serial numbers, and the specific times and reasons for revocation. A message conveying a request to have a Certificate issued. An entity authorized to issue, manage, revoke, and renew Certificates in the STN. A statement of the practices that Symantec or an Affiliate employs in approving or rejecting Certificate Applications and issuing, managing, and revoking Certificates, and requires its Managed PKI Customers and Gateway Customers to employ. A secret phrase chosen by a Certificate Applicant during enrollment for a Certificate. When issued a Certificate, the Certificate Applicant becomes a Subscriber and a CA or RA can use the Challenge Phrase to authenticate the Subscriber when the Subscriber seeks to revoke or renew the Subscribers Certificate. A specified level of assurances as defined within the CP. See CP 1.1.1. A Service Center that is an Affiliate providing client Certificates either in the Consumer or Enterprise line of business. A periodic audit that a Processing Center, Service Center, Managed PKI Customer, or Gateway Customer undergoes to determine its conformance with STN Standards that apply to it. A violation (or suspected violation) of a security policy, in which an unauthorized disclosure of, or loss of control over, sensitive information may have occurred. With respect to private keys, a Compromise is a loss, theft, disclosure, modification, unauthorized use, or other compromise of the security of such private key. Information required to be kept confidential and private pursuant to CP 2.8.1. A Contract Signer is a natural person who is employed by the Applicant, or an authorized agent who has express authority to represent the Applicant who has authority on behalf of the Applicant to sign Subscriber Agreements on behalf of the Applicant for an EV Certificate. A Country shall mean a Sovereign state as defined in the Guidelines. An agreement setting forth the terms and conditions under which a CRL or the information in it can be used. A certificate that is used to establish a trust relationship between two Root CAs. An organization that is either a Managed PKI Customer, or Gateway Customer. A natural person or Legal Entity that is not the CA but is authorized by the CA to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein. A deposit account held at a bank or other financial institution, the funds deposited in which are payable on demand. The primary purpose of demand accounts is to facilitate cashless payments by means of check, bank draft, direct debit, electronic funds transfer, etc. Usage varies among countries, but a demand deposit account is commonly known as: a checking account, a share draft account, a current account, or a checking account. Correspondence or other documentation provided by a Domain Name Registrant attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace. The label assigned to a node in the Domain Name System. The set of all possible Domain Names that are subordinate to a single node in the Domain Name System. Sometimes referred to as the owner of a Domain Name, but more properly the person(s) or entity(ies) registered with a Domain Name Registrar as having the right to control how a Domain Name is used, such as the natural person or Legal Entity that is listed as the Registrant by WHOIS or the Domain Name Registrar. A person or entity that registers Domain Names under the auspices of or by agreement with: (i) the Internet Corporation for Assigned Names and Numbers (ICANN), (ii) a national Domain Name authority/registry, or (iii) a Network Information Center (including their affiliates, contractors, delegates, successors, or assigns). A line of business that an Affiliate enters to provide Managed PKI services to Managed PKI Customers. An EV Certificate that an Managed PKI for SSL Customer authorizes Symantec to issue at third and higher domain levels that contain the domain that have been verified by Symantec.

Demand Deposit Account

Domain Authorization Domain Name Domain Namespace Domain Name Registrant

Domain Name Registrar

Enterprise, as in Enterprise Service Center Enterprise EV Certificate:

- 68 -

Term Enterprise RA

Expiry Date EV Certificate: EV OID

Exigent Audit/Investigation

Extended Validation Fully-Qualified Domain Name Government Entity

Intellectual Property Rights Intermediate Certification Authority (Intermediate CA) Internal Server Name International Organization

Issuing CA Key Compromise

Key Generation Ceremony Key Generation Script Key Manager Administrator Key Pair Key Recovery Block (KRB) Key Recovery Service Legal Entity Managed PKI

Managed PKI Administrator Managed PKI Control Center Managed PKI Key Manager Managed PKI Key Management Service Administrators Guide Manual Authentication NetSure Protection Plan

Definition A Managed PKI for SSL customer that can request multiple valid EV Certificates for Domains and Organizations verified by Symantec for domains at third and higher domain levels that contain a domain that was verified by Symantec in the original EV Certificate, in accordance with the requirements of these Guidelines. The Not After date in a Certificate that defines the end of a Certificates validity period. A digital certificate that contains information specified in the EV Guidelines and that has been validated in accordance with the Guidelines. An identifying number, called an object identifier, that is included in the certificatePolicies field of an EV certificate that: (i) indicates which CA policy statement relates to that certificate, and which, (ii) by pre-agreement with one or more Application Software Vendor, marks the certificate as being an EV Certificate. An audit or investigation by Symantec where Symantec has reason to believe that an entitys failure to meet STN Standards, an incident or Compromise relating to the entity, or an actual or potential threat to the security of the STN posed by the entity has occurred. Validation Procedures defined by the Guidelines for Extended Validation Certificates published by a forum consisting of major certification authorities and browser vendors. A Domain Name that includes the labels of all superior nodes in the Internet Domain Name System. A government-operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.). Rights under one or more of the following: any copyright, patent, trade secret, trademark, and any other intellectual property rights. A Certification Authority whose Certificate is located within a Certificate Chain between the Certificate of the root CA and the Certificate of the Certification Authority that issued the end-user Subscribers Certificate. A Server Name (which may or may not include an Unregistered Domain Name) that is not resolvable using the public DNS. An International Organization is an organization founded by a constituent document, e.g., charter, treaty, convention, or similar document, signed by, or on behalf of, a minimum of two or more Sovereign State governments. In relation to a particular Certificate, the CA that issued the Certificate. This could be either a Root CA or a Subordinate CA. A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, an unauthorized person has had access to it, or there exists a practical technique by which an unauthorized person may discover its value. A procedure whereby a CAs or RAs key pair is generated, its private key is transferred into a cryptographic module, its private key is backed up, and/or its public key is certified. A documented plan of procedures for the generation of a CA Key Pair. An Administrator that performs key generation and recovery functions for a Managed PKI Customer using Managed PKI Key Manager. The Private Key and its associated Public Key. A data structure containing a Subscribers private key that is encrypted using an encryption key. KRBs are generated using Managed PKI Key Manager software. A Symantec service that provides encryption keys needed to recover a Key Recovery Block as part of a Managed PKI Customers use of Managed PKI Key Manager to recover a Subscribers private key. An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a countrys legal system. Symantecs fully integrated managed PKI service that allows enterprise Customers of Symantec and its Affiliates to distribute Certificates to individuals, such as employees, partners, suppliers, and customers, as well as devices, such as servers, routers, and firewalls. Managed PKI permits enterprises to secure messaging, intranet, extranet, virtual private network, and e-commerce applications. An Administrator that performs validation or other RA functions for an Managed PKI Customer. A web-based interface that permits Managed PKI Administrators to perform Manual Authentication of Certificate Applications A key recovery solution for those Managed PKI Customers choosing to implement key recovery under a special Managed PKI Agreement. A document setting forth the operational requirements and practices for Managed PKI Customers using Managed PKI Key Manager. A procedure whereby Certificate Applications are reviewed and approved manually one-by-one by an Administrator using a web-based interface. An extended warranty program, which is described in CP 9.2.3.

- 69 -

Term Nonverified Subscriber Information

Definition Information submitted by a Certificate Applicant to a CA or RA, and included within a Certificate, that has not been confirmed by the CA or RA and for which the applicable CA and RA provide no assurances other than that the information was submitted by the Certificate Applicant. Non-repudiation An attribute of a communication that provides protection against a party to a communication falsely denying its origin, denying that it was submitted, or denying its delivery. Denial of origin includes the denial that a communication originated from the same source as a sequence of one or more prior messages, even if the identity associated with the sender is unknown. Note: only an adjudication by a court, arbitration panel, or other tribunal can ultimately prevent repudiation. For example, a digital signature verified with reference to a STN Certificate may provide proof in support of a determination of Non-repudiation by a tribunal, but does not by itself constitute Non-repudiation. Object Identifier A unique alphanumeric or numeric identifier registered under the International Organization for Standardizations applicable standard for a specific object or object class. OCSP (Online Certificate Status An online Certificate-checking protocol for providing Relying Parties with real-time Certificate status Protocol) information. OCSP Responder An online server operated under the authority of the CA and connected to its Repository for processing Certificate status requests. See also, Online Certificate Status Protocol. Offline CA STN PCAs, Issuing Root CAs and other designated intermediate CAs that are maintained offline for security reasons in order to protect them from possible attacks by intruders by way of the network. These CAs do not directly sign end user Subscriber Certificates. Online CA CAs that sign end user Subscriber Certificates are maintained online so as to provide continuous signing services. Online Certificate Status Protocol A protocol for providing Relying Parties with real-time Certificate status information. (OCSP) Operational Period The period starting with the date and time a Certificate is issued (or on a later date and time certain if stated in the Certificate) and ending with the date and time on which the Certificate expires or is earlier revoked. Parent Company: A parent company is defined as a company that owns a majority of the Subsidiary Parent Company Company and this can be verified by referencing a QIIS or from financial statement supplied by a registered Chartered Professional Accountant (CPA) or equivalent outside of the USA. PKCS #10 Public-Key Cryptography Standard #10, developed by RSA Security Inc., which defines a structure for a Certificate Signing Request. PKCS #12 Public-Key Cryptography Standard #12, developed by RSA Security Inc., which defines a secure means for the transfer of private keys. Policy Management Authority The organization within Symantec responsible for promulgating this policy throughout the STN. (PMA) Primary Certification Authority A CA that acts as a root CA for a specific Class of Certificates, and issues Certificates to CAs (PCA) subordinate to it. Principal Individual(s) Individuals of a Private Organization, Government Entity or Business Entity that are either owners, partners, managing members, directors or officers, as identified by their title of employment, or an employee, contractor or agent authorized by such entity or organization to conduct business related to the request, issuance and use of EV Certificates. Private Key The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted with the corresponding Public Key. Processing Center An organization (Symantec or certain Affiliates) that creates a secure facility housing, among other things, the cryptographic modules used for the issuance of Certificates. In the Consumer and Web Site lines of business, Processing Centers act as CAs within the STN and perform all Certificate lifecycle services of issuing, managing, revoking, and renewing Certificates. In the Enterprise line of business, Processing Centers provide lifecycle services on behalf of their Managed PKI Customers or the Managed PKI Customers of the Service Centers subordinate to them. Public Key The key of a Key Pair that may be publicly disclosed by the holder of the corresponding Private Key and that is used by a Relying Party to verify Digital Signatures created with the holder's corresponding Private Key and/or to encrypt messages so that they can be decrypted only with the holder's corresponding Private Key. Public Key Infrastructure (PKI) The architecture, organization, techniques, practices, and procedures that collectively support the implementation and operation of a Certificate-based public key cryptographic system. The STN PKI consists of systems that collaborate to provide and implement the STN. Publicly-Trusted Certificate A Certificate that is trusted by virtue of the fact that its corresponding Root Certificate is distributed as a trust anchor in widely-available application software. Qualified Auditor A natural person or Legal Entity that meets the requirements of Section 17.6 (Auditor Qualifications). Registered Domain Name A Domain Name that has been registered with a Domain Name Registrar. Registration Agency A Governmental Agency that registers business information in connection with an entitys busine ss formation or authorization to conduct business under a license, charter or other certification. A

- 70 -

Definition Registration Agency MAY include, but is not limited (i) a State Department of Corporations or a Secretary of State; (ii) a licensing agency, such as a State Department of Insurance; or (iii) a chartering agency, such as a state office or department of financial regulation, banking or finance, or a federal agency such as the Comptroller of Currency (OCC) or Office of Thrift Supervision (OTC) Registration Authority (RA) An entity approved by a CA to assist Certificate Applicants in applying for Certificates, and to approve or reject Certificate Applications, revoke Certificates, or renew Certificates. Regulated Financial Institution A financial institution that is regulated, supervised, and examined by governmental, national, state or provincial, or local authorities having regulatory authority over such financial institution based on the governmental, national, state or provincial, or local laws under which such financial institution was organized and/or licensed. Reliable Method of A method of communication, such as a postal/courier delivery address, telephone number, or email Communication address, that was verified using a source other than the Applicant Representative. Relying Party An individual or organization that acts in reliance on a certificate and/or a digital signature. Relying Party Agreement An agreement used by a CA setting forth the terms and conditions under which an individual or organization acts as a Relying Party. Repository An online database containing publicly-disclosed PKI governance documents (such as Certificate Policies and Certification Practice Statements) and Certificate status information, either in the form of a CRL or an OCSP response. Reseller An entity marketing services on behalf of Symantec or an Affiliate to specific markets. Reserved IP Address An IPv4 or IPv6 address that the IANA has marked as reserved: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml Retail Certificate A Certificate issued by Symantec or an Affiliate, acting as CA, to individuals or organizations applying one by one to Symantec or an Affiliate on its web site. Root CA The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates. Root Certificate The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs. RSA A public key cryptographic system invented by Rivest, Shamir and Adleman. Secret Share A portion of a CA private key or a portion of the activation data needed to operate a CA private key under a Secret Sharing arrangement. Secret Sharing The practice of splitting a CA private key or the activation data to operate a CA private key in order to enforce multi-person control over CA private key operations under CP 6.2.2. Secure Sockets Layer (SSL) The industry-standard method for protecting Web communications developed by Netscape Communications Corporation. The SSL security protocol provides data encryption, server authentication, message integrity, and optional client authentication for a Transmission Control Protocol/Internet Protocol connection. Security and Audit Requirements A Symantec document that sets forth the security and audit requirements and practices for (SAR) Guide Processing Centers and Service Centers. Security and Practices Review A review of an Affiliate performed by Symantec before an Affiliate is permitted to become operational. Service Center An Affiliate that does not house Certificate signing units for the issuance of Certificates for the purpose of issuing Certificates of a specific Class or type, but rather relies on a Processing Center to perform issuance, management, revocation, and renewal of such Certificates. Sovereign State A Sovereign state is a state, or country, that administers its own government, and is not dependent upon, or subject to, another power. Sub-domain The portion of the STN under control of an entity and all entities subordinate to it within the STN hierarchy. Subject The natural person, device, system, unit, or Legal Entity identified in a Certificate as the Subject and holder of a private key corresponding to a public key. The Subject is either the Subscriber or a device under the control and operation of the Subscriber. The term Subject can, in the case of an organizational Certificate, refer to the equipment or device that holds a private key. A Subject is assigned an unambiguous name, which is bound to the public key contained in the Subjects Certificate. Subject Identity Information Information that identifies the Certificate Subject. Subject Identity Information does not include a domain name listed in the subjectAltName extension or the Subject commonName field. Subordinate CA A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA. Subscriber In the case of an individual Certificate, a person who is the Subject of, and has been issued, a Certificate. In the case of an organizational Certificate, an organization that owns the equipment or device that is the Subject of, and that has been issued, a Certificate. A Subscriber is capable of using, and is authorized to use, the private key that corresponds to the public key listed in the Certificate. Subscriber Agreement An agreement used by a CA or RA setting forth the terms and conditions under which an individual or organization acts as a Subscriber.

Term

- 71 -

Term Subsidiary Company

Superior Entity Supplemental Risk Management Review Symantec Symantec Digital Notarization Service Terms of Use Trusted Person

Trusted Position Trustworthy System

Symantec Repository Symantec Trust Network (STN)

STN Participant STN Standards Unregistered Domain Name Valid Certificate Validation Specialists Validity Period Wildcard Certificate

Definition A subsidiary company is defined as a company that is majority owned by Applicant as verified by referencing a QIIS or from financial statement supplied by a registered Chartered Professional Accountant (CPA) or equivalent outside of the USA. An entity above a certain entity within a STN hierarchy (the Class 1, 2, or 3 hierarchy). A review of an entity by Symantec following incomplete or exceptional findings in a Compliance Audit of the entity or as part of the overall risk management process in the ordinary course of business. Means, with respect to each pertinent portion of this CPS, Symantec Corporation and/or any wholly owned Symantec subsidiary responsible for the specific operations at issue. A service offered to Managed PKI Customers that provides a digitally signed assertion (a Digital Receipt) that a particular document or set of data existed at a particular point in time. Provisions regarding the safekeeping and acceptable uses of a Certificate issued in accordance with these Requirements when the Applicant/Subscriber is an Affiliate of the CA. An employee, contractor, or consultant of an entity within the STN responsible for managing infrastructural trustworthiness of the entity, its products, its services, its facilities, and/or its practices as further defined in CP 5.2.1. The positions within a STN entity that must be held by a Trusted Person. Computer hardware, software, and procedures that are reasonably secure from intrusion and misuse; provide a reasonable level of availability, reliability, and correct operation; are reasonably suited to performing their intended functions; and enforce the applicable security policy. A trustworthy system is not necessarily a trusted system as recognized in classified government nomencl ature. Symantecs database of Certificates and other relevant Symantec Trust Network information accessible on-line. The Certificate-based Public Key Infrastructure governed by the Symantec Trust Network Certificate Policies, which enables the worldwide deployment and use of Certificates by Symantec and its Affiliates, and their respective Customers, Subscribers, and Relying Parties. An individual or organization that is one or more of the following within the STN: Symantec, an Affiliate, a Customer, a Universal Service Center, a Reseller, a Subscriber, or a Relying Party. The business, legal, and technical requirements for issuing, managing, revoking, renewing, and using Certificates within the STN. A Domain Name that is not a Registered Domain Name. A Certificate that passes the validation procedure specified in RFC 5280. Someone who performs the information verification duties specified by these Requirements. The period of time measured from the date when the Certificate is issued until the Expiry Date. A Certificate containing an asterisk (*) in the left-most position of any of the Subject Fully-Qualified Domain Names contained in the Certificate.

- 72 -

Appendix B1
Supplemental Validation Procedures for Extended Validation (EV) SSL Certificates
Reference: CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation (EV) Certificates, www.cabforum.org . Table of Contents
1. Introduction 2. Basic Concept of the EV Certificate 2.1 Purpose of EV Certificates 2.1.1 Primary Purposes 2.1.2 Secondary Purposes 2.1.3 Excluded Purposes 3. References 4. Definitions 5. Abbreviations and Acronyms 6. Conventions 7. EV Certificate Warranties and Representations 7.1 EV Certificate Warranties 7.2 By the Applicant 8. Community and Applicability 8.1 Issuance of EV Certificates 8.2 EV Policies 8.3 Commitment to Conform 8.4 Insurance 8.5 Obtaining EV Certificates 8.5.1 Private Organization Subjects 8.5.2 Government Entity Subjects 8.5.3 Business Entity Subjects 8.5.4 Non-Commercial Entity Subjects 9. EV Certificate Content and Profile 9.1 Issuer Information 9.2 Subject Information 9.2.1 Subject Organization name (Required) 9.2.2 Subject Alternate name Extension (Required) 9.2.3 Common name (Deprecated) 9.2.4 Subject Business Category (Required) 9.2.5 Subject Jurisdiction of Incorporation or Registration (Required) 9.2.6 Subject Registration Number (Required) 9.2.7 Subject Physical Address of Place of Business 9.2.8 Other Subject Attributes 9.3 Certificate Policy Identification 9.3.1 EV Certificate Policy Identification Requirements 9.3.2 EV Subscriber Certificates 9.3.3 Root CA Certificates 9.3.4 EV Subordinate CA Certificate 9.4 Maximum Validity Period 9.5. Subscriber Public Key 9.6. Certificate Serial Number 9.7. Other Technical Requirements for EV Certificates 10. EV Certificate Request Requirements 10.1 General Requirements 10.1.1 Documentation Requirements 10.1.2 Role Requirements 10.2 EV Certificate Request Requirements

- 73 -

10.3 Subscriber Agreement Requirements 11. Information Verification Requirements 11.1 General Overview 11.2 Verification of Applicants Legal Existence and Identity 11.3 Verification of Applicants Legal Existence and Identity Assumed Name 11.4 Verification of Applicants Physical Existence 11.4.1 Address of Applicants Place of Business 11.4.2 Telephone Number for Applicants Place of Business 11.5 Verification of Applicants Operational Existence 11.6 Verification of Applicants Domain Name 11.7 Verification of Name, Title and Authority of Contract Signer & Certificate Approver 11.7.1 Verification Requirements 11.7.2 Verification Name, Title and Agency 11.7.3 Verification - Authority 11.7.4 Pre-Authorized Certificate Approver 11.8 Verification of Signature on Subscriber Agreement and EV Certificate Requests 11.8.1 Verification Requirements 11.8.2 Methods of Signature Verification 11.9 Verification of Approval of EV Certificate Request 11.10 Verification of Certain Information Sources 11.10.1 Verified Legal Opinion 11.10.2 Verified Accountant Letter 11.10.3 Face-to-Face Validation 11.10.4 Independent Confirmation From Applicant 11.10.5 Qualified Independent Information Sources (QIIS) 11.10.6 Qualified Government Information Sources (QGIS) 11.10.7 Qualified Government Tax Information Source 11.11 Other Verification Requirements 11.11.1 High Risk Status 11.11.2 Denied Lists and Other Legal Black Lists 11.11.3 Parent/Subsidiary/Affiliate Relationship 11.12 Final Cross-Correlation and Due Diligence 11.13 Requirements for Re-Use of Existing Documentation 11.13.1 For Validated Data 11.13.2 Validation for Existing Subscribers 11.13.3 Exceptions 11.13.4 Validation of Re-issuance Requests 12. Certificate Issuance by a Root CA 13. Certificate Revocation and Status Checking 14. Employee and Third Party Issues 14.1 Trustworthiness and Competence 14.1.1 Identity and Background Verification 14.1.2 Training and Skill Level 14.1.3 Separation of Duties 14.2 Delegation of Functions to Registration Authorities and Subcontractors 14.2.1 General 14.2.2 Enterprise RAs 14.2.3 Guideline Compliance Obligation 14.2.4 Allocation of Liabilty 15. Data Records 16. Data Security 17. Audit 17.1 Annual Independent Audit 17.2 Audit Period 17.3 Audit Record 17.4 Pre-Issuance Readiness Audit 17.5 Regular Self Audits 17.6 Auditor Qualification 17.7 Root CA Key Pair Generation 18. Liability and Indemnification

- 74 -

1. INTRODUCTION
This Appendix articulates supplemental procedures to Symantecs CPS for issuing Extended Validation Certificates (EV Certificates) in conformance with the Guidelines for Extended Validation Certificates (Guidelines), published by the CA Browser Forum at www.cabforum.org, that describe certain of the minimum requirements that a Certificate Authority (CA) must meet in order to issue Extended Validation Certificates (EV Certificates). This Appendix addresses EV Certificates used for SSL/TLS authentication on the Internet. Organization information from Valid EV Certificates may be displayed in a special manner by certain software applications (e.g., browser software) in order to provide users with a trustworthy confirmation of the identity of the entity that controls the website they are accessing.

2. BASIC CONCEPT OF THE EV CERTIFICATE

2.1 Purpose of EV SSL Certificates.
EV Certificates are intended for establishing Web-based data communication conduits via the TLS/SSL protocols and for verifying the authenticity of executable code.

2.1.1 Primary Purposes

The primary purposes of an EV Certificate are to: (1)Identify the legal entity that controls a Web site: Provide a reasonable assurance to the user of an Internet browser that the Web site the user is accessing is controlled by a specific legal entity identified in the EV Certificate by name, address of Place of Business, Jurisdiction of Incorporation or Registration and Registration Number or other disambiguating information; and (2)Enable encrypted communications with a Web site: Facilitate the exchange of encryption keys in order to enable the encrypted communication of information over the Internet between the user of an Internet browser and a Web site.

2.1.2 Secondary Purposes

The secondary purposes of an EV Certificate are to help establish the legitimacy of a business claiming to operate a Web site or distribute executable code, and to provide a vehicle that can be used to assist in addressing problems related to phishing, malware, and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the business, EV Certificates may help to: (1)Make it more difficult to mount phishing and other online identity fraud attacks using Certificates; (2)Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves to users; and (3)Assist law enforcement organizations in their investigations of phishing and other online identity fraud, including where appropriate, contacting, investigating, or taking legal action against the Subject. 7

- 75 -

2.1.3 Excluded Purposes

EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is not intended to provide any assurances, or otherwise represent or warrant: (1)That the Subject named in the EV Certificate is actively engaged in doing business; (2)That the Subject named in the EV Certificate complies with applicable laws; (3)That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings; or (4)That it is safe to do business with the Subject named in the EV Certificate.

3 References
See Baseline Requirements, which are available at www.cabforum.org.

4 Definitions
Capitalized Terms are defined in the Baseline Requirements except where provided below: Accounting Practitioner: A certified public accountant, chartered accountant, or a person with an equivalent license within the country of the Applicants Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility; provided that an accounting standards body in the jurisdiction maintains full (not suspended or associate) membership status with the International Federation of Accountants. Baseline Requirements: The Baseline Requirements for the Issuance and Management of PubliclyTrusted Certificates as published by the CA/Browser Forum and any amendments to such document. Business Entity: Any entity that is neither a Private Organization nor a Government Entity as defined herein. Examples include general partnerships, unincorporated associations, and sole proprietorships. Certificate Approver: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to (i) act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and (ii) to approve EV Certificate Requests submitted by other Certificate Requesters. Certificate Requester: A natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant. Confirmation Request: An appropriate out-of-band communication requesting verification or confirmation of the particular fact at issue. Confirming Person: A position within an Applicants organization that confirms the particular fact at issue. Contract Signer: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. Control: Control (and its correlative meanings, controlled by and under common control with) means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors; or (3) vote that portion of voting shares required for control under the law of the entitys Jurisdiction of Incorporation or Registration but in no case less than 10%. Country: A Country shall mean a Sovereign State as defined in these Guidelines. Demand Deposit Account: A deposit account held at a bank or other financial institution, the funds deposited in which are payable on demand. The primary purpose of demand accounts is to facilitate cashless payments by means of check, bank draft, direct debit, electronic funds transfer, etc. Usage varies among countries, but a demand deposit account is commonly known as a share draft account, a current account, or a checking account. 8

- 76 -

Domain Authorization Document: Documentation provided by, or a CAs documentation of a communication with, the domain name registrar or the person or entity listed in WHOIS as the registering the domain name (including any private, anonymous, or proxy registration service) attesting that the Applicant has the exclusive right to use the specified domain name. Enterprise EV Certificate: An EV Certificate that an Enterprise RA authorizes the CA to issue at third and higher domain levels. Enterprise EV RA: An RA that is authorized by the CA to authorize the CA to issue EV Certificates at third and higher domain levels. EV Authority: A source other than the Certificate Approver, through which verification occurs that the Certificate Approver is expressly authorized by the Applicant, as of the date of the EV Certificate Request, to take the Request actions described in these Guidelines. EV Certificate: A certificate that contains subject information specified in these Guidelines and that has been validated in accordance with these Guidelines. EV Certificate Beneficiaries: Persons to whom the CA and its Root CA make specified EV Certificate Warranties. EV Certificate Renewal: The process whereby an Applicant who has a valid unexpired and non-revoked EV Certificate makes an application, to the CA that issued the original certificate, for a newly issued EV Certificate for the same organizational name and Domain Name prior to the expiration of the Applicant's existing EV Certificate but with a new 'valid to' date beyond the expiry of the current EV Certificate. EV Certificate Reissuance: The process whereby an Applicant who has a valid unexpired and nonrevoked EV Certificate makes an application, to the CA that issued the original certificate, for a newly issued EV Certificate for the same organizational name and Domain Name prior to the expiration of the Applicant's existing EV Certificate but with a 'valid to' date that matches that of the current EV Certificate. EV Certificate Request: A request from an Applicant to the CA requesting that the CA issue an EV Certificate to the Applicant, which request is validly authorized by the Applicant and signed by the Applicant Representative. EV Certificate Warranties: In conjunction with the CA issuing an EV Certificate, the CA and its Root CA, during the period when the EV Certificate is Valid, promise that the CA has followed the requirements of these Guidelines and the CAs EV Policies in issuing the EV Certifica te and in verifying the accuracy of the information contained in the EV Certificate. EV OID: An identifying number, in the form of an object identifier, that is included in the certificatePolicies field of a certificate that: (i) indicates which CA policy statement relates to that certificate, and (ii) by pre-agreement with one or more Application Software Supplier, marks the certificate as being an EV Certificate. EV Policies: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. EV Processes: The keys, software, processes, and procedures by which the CA verifies Certificate Data under this Guideline, issues EV Certificates, maintains a Repository, and revokes EV Certificates. Extended Validation Certificate: See EV Certificate. Government Agency: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of Private Organizations is established (e.g., the government agency that issued the Certificate of Incorporation). In the context of Business Entities, the government agency in the jurisdiction of operation that registers business entities. In the case of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. Government Entity: A government-operated legal entity, agency, department, ministry, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.). Guidelines: This document. Incorporating Agency: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of Private Organizations is established (e.g., the government agency that issues Certificates of Incorporation). In the context of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. 9

- 77 -

Independent Confirmation From Applicant: Confirmation of a particular fact received by the CA pursuant to the provisions of the Guidelines or binding upon the Applicant. Individual: A natural person. International Organization: An organization founded by a constituent document, e.g., a charter, treaty, convention or similar document, signed by, or on behalf of, a minimum of two Sovereign State governments. Jurisdiction of Incorporation: In the context of a Private Organization, the country and (where applicable) the state or province or locality where the organizations legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a Government Entity, the country and (where applicable) the state or province where the Entitys legal existence was created by law. Jurisdiction of Registration: In the case of a Business Entity, the state, province, or locality where the organization has registered its business presence by means of filings by a Principal Individual involved in the business. Latin Notary: A person with legal training whose commission under applicable law not only includes authority to authenticate the execution of a signature on a document but also responsibility for the correctness and content of the document. A Latin Notary is sometimes referred to as a Civil Law Notary. Legal Existence: A Private Organization, Government Entity, or Business Entity has Legal Existence if it has been validly formed and not otherwise terminated, dissolved, or abandoned. Legal Practitioner: A person who is either a lawyer or a Latin Notary as described in these Guidelines and competent to render an opinion on factual claims of the Applicant. Maximum Validity Period: 1. The maximum time period for which the issued EV Certificate is valid. 2. The maximum period after validation by the CA that certain Applicant information may be relied upon in issuing an EV Certificate pursuant to these Guidelines. Notary: A person whose commission under applicable law includes authority to authenticate the execution of a signature on a document. Parent Company: A company that Controls a Subsidiary Company. Place of Business: The location of any facility (such as a factory, retail store, warehouse, etc) where the Applicants business is conducted. Principal Individual: An individual of a Private Organization, Government Entity, or Business Entity that is either an owner, partner, managing member, director, or officer, as identified by their title of employment, or an employee, contractor or agent authorized by such entity or organization to conduct business related to the request, issuance, and use of EV Certificates. Private Organization: A non-governmental legal entity (whether ownership interests are privately held or publicly traded) whose existence was created by a filing with (or an act of) the Incorporating Agency in its Jurisdiction of Incorporation. Qualified Auditor: An independent public accounting firm that meets the auditing qualification requirements specified in Section 17.6 of these Guidelines. Qualified Government Information Source: A database maintained by a Government Entity (e.g. SEC filings) that meets the requirements of Section 11.10.6. Qualified Government Tax Information Source: A Qualified Governmental Information Source that specifically contains tax information relating to Private Organizations, Business Entities, or Individuals. Qualified Independent Information Source: A regularly-updated and current, publicly available, database designed for the purpose of accurately providing the information for which it is consulted, and which is generally recognized as a dependable source of such information. Registration Agency: A Governmental Agency that registers business information in connection with an entitys business formation or authorization to conduct business under a license, charter or other certification. A Registration Agency MAY include, but is not limited to (i) a State Department of Corporations or a Secretary of State; (ii) a licensing agency, such as a State Department of Insurance; or (iii) a chartering agency, such as a state office or department of financial regulation, banking or finance, or a federal agency such as the Office of the Comptroller of the Currency or Office of Thrift Supervision. 10

- 78 -

Registered Agent: An individual or entity that is: (i) authorized by the Applicant to receive service of process and business communications on behalf of the Applicant; and (ii) listed in the official records of the Applicants Jurisdiction of Incorporation as acting in the role specified in (i) above. Registered Office: The official address of a company, as recorded with the Incorporating Agency, to which official documents are sent and at which legal notices are received. Registration Number: The unique number assigned to a Private Organization by the Incorporating Agency in such entitys Jurisdiction of Incorporation. Regulated Financial Institution: A financial institution that is regulated, supervised, and examined by governmental, national, state or provincial, or local authorities. Root Key Generation Script: A documented plan of procedures to be performed for the generation of the Root CA Key Pair. Signing Authority: One or more Certificate Approvers designated to act on behalf of the Applicant. Sovereign State: A state or country that administers its own government, and is not dependent upon, or subject to, another power. Subsidiary Company: A company that is controlled by a Parent Company. Superior Government Entity: Based on the structure of government in a political subdivision, the Government Entity or Entities that have the ability to manage, direct and control the activities of the Applicant. Suspect code: Code that contains malicious functionality or serious vulnerabilities, including spyware, malware and other code that installs without the user's consent and/or resists its own removal, and code that can be exploited in ways not intended by its designers to compromise the trustworthiness of the platforms on which it executes. Translator: An individual or Business Entity that possesses the requisite knowledge and expertise to accurately translate the words of a document written in one language to the native language of the CA. Verified Accountant Letter: A document meeting the requirements specified in Section 11.10.2 of these Guidelines Verified Legal Opinion: A document meeting the requirements specified in Section 11.10.1 of these Guidelines. WebTrust EV Program: The additional audit procedures specified for CAs that issue EV Certificates by the AICPA/CICA to be used in conjunction with its WebTrust Program for Certification Authorities. WebTrust Program for CAs: The then-current version of the AICPA/CICA WebTrust Program for Certification Authorities. WebTrust Seal of Assurance: An affirmation of compliance resulting from the WebTrust Program for CAs.

5 Abbreviations and Acronyms

Abbreviations and Acronyms are defined in the Baseline Requirements except as otherwise defined herein: BIPM International Bureau of Weights and Measures BIS (US Government) Bureau of Industry and Security CEO Chief Executive Officer CFO Chief Financial Officer CIO Chief Information Officer CISO Chief Information Security Officer COO Chief Operating Officer CPA Chartered Professional Accountant CSO Chief Security Officer EV Extended Validation gTLD Generic Top-Level Domain 11

- 79 -

IFAC International Federation of Accountants IRS Internal Revenue Service ISP Internet Service Provider QGIS Qualified Government Information Source QTIS Qualified Government Tax Information Source QIIS Qualified Independent Information Source SEC (US Government) Securities and Exchange Commission UTC(k) National realization of Coordinated Universal Time

6 Conventions
Terms not otherwise defined in these Guidelines shall be as defined in applicable agreements, user manuals, certification practice statements (CPS), and certificate policies (CP) of the CA issuing EV Certificates. The key words "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these Guidelines shall be interpreted in accordance with RFC 2119.

7 Certificate Warranties and Representations 7.1 EV Certificate Warranties

When the CA issues an EV Certificate, the CA and its Root CA represent and warrant to the Certificate Beneficiaries listed in Section 7.1.1 of the Baseline Requirements, during the period when the EV Certificate is Valid, that the CA has followed the requirements of these Guidelines and its EV Policies in issuing and managing the EV Certificate and in verifying the accuracy of the information contained in the EV Certificate. The EV Certificate Warranties specifically include, but are not limited to, the following: (A) Legal Existence: The CA has confirmed with the Incorporating or Registration Agency in the Subjects Jurisdiction of Incorporation or Registration that, as of the date the EV Certificat e was issued, the Subject named in the EV Certificate legally exists as a valid organization or entity in the Jurisdiction of Incorporation or Registration; (B) Identity: The CA has confirmed that, as of the date the EV Certificate was issued, the legal name of the Subject named in the EV Certificate matches the name on the official government records of the Incorporating or Registration Agency in the Subjects Jurisdiction of Incorporation or Registration, and if an assumed name is also included, that the assumed name is properly registered by the Subject in the jurisdiction of its Place of Business; (C) Right to Use Domain Name: The CA has taken all steps reasonably necessary to verify that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate has the exclusive right to use all the Domain Name(s) listed in the EV Certificate; (D) Authorization for EV Certificate: The CA has taken all steps reasonably necessary to verify that the Subject named in the EV Certificate has authorized the issuance of the EV Certificate; (E) Accuracy of Information: The CA has taken all steps reasonably necessary to verify that all of the other information in the EV Certificate is accurate, as of the date the EV Certificate was issued; (F) Subscriber Agreement: The Subject named in the EV Certificate has entered into a legally valid and enforceable Subscriber Agreement with the CA that satisfies the requirements of these Guidelines or, if they are affiliated, the Applicant Representative has acknowledged and accepted the Terms of Use; (G) Status: The CA will follow the requirements of these Guidelines and maintain a 24 x 7 onlineaccessible Repository with current information regarding the status of the EV Certificate as Valid or revoked; and (H) Revocation: The CA will follow the requirements of these Guidelines and revoke the EV Certificate for any of the revocation reasons specified in these Guidelines. 12

- 80 -

7.2 By the Applicant

EV Certificate Applicants make the commitments and warranties set forth in Section 10.3.2 of these Guidelines for the benefit of the CA and Certificate Beneficiaries.

8 Community and Applicability 8.1 Issuance of EV Certificates

The CA MAY issue EV Certificates, provided that the CA and its Root CA satisfy the requirements in these Guidelines and the Baseline Requirements. If a court or government body with jurisdiction over the activities covered by these Guidelines determines that the performance of any mandatory requirement is illegal, then such requirement is considered reformed to the minimum extent necessary to make the requirement valid and legal. This applies only to operations or certificate issuances that are subject to the laws of that jurisdiction. The parties involved SHALL notify the CA / Browser Forum of the facts, circumstances, and law(s) involved, so that the CA/Browser Forum may revise these Guidelines accordingly.

8.2 EV Policies 8.2.1 Implementation

Each CA MUST develop, implement, enforce, display prominently on its Web site, and periodically update as necessary its own auditable EV Certificate practices, policies and procedures, such as a Certification Practice Statement (CPS) and Certificate Policy (CP) that: (A) Implement the requirements of these Guidelines as they are revised from time-to-time; (B) Implement the requirements of (i) the then-current WebTrust Program for CAs, and (ii) the then-current WebTrust EV Program or ETSI TS 102 042 V2.1.1; and (C) Specify the CAs and its Root CAs entire root certificate hierarchy including all r oots that its EV Certificates depend on for proof of those EV Certificates authenticity.

8.2.2 Disclosure
Each CA MUST publicly disclose their EV Policies through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA is also REQUIRED to publicly disclose its CA business practices as required by both WebTrust for CAs and ETSI TS 102 042 V2.1.1. The disclosures MUST be structured in accordance with either RFC 2527 or RFC 3647.

8.3 Commitment to Comply with Recommendations

Each CA SHALL publicly give effect to these Guidelines and represent that they will adhere to the latest published version by incorporating them into their respective EV Policies, using a clause such as the following (which must include a link to the official version of these Guidelines): [Name of CA] conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document. In addition, the CA MUST include (directly or by reference) the applicable requirements of these Guidelines in all contracts with Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve or relate to the issuance or maintenance of EV Certificates. The CA MUST enforce compliance with such terms.

8.4 Insurance
Each CA SHALL maintain the following insurance related to their respective performance and obligations under these Guidelines: 13

- 81 -

(A) Commercial General Liability insurance (occurrence form) with policy limits of at least two million US dollars in coverage; and (B) Professional Liability/Errors and Omissions insurance, with policy limits of at least five million US dollars in coverage, and including coverage for (i) claims for damages arising out of an act, error, or omission, unintentional breach of contract, or neglect in issuing or maintaining EV Certificates, and (ii) claims for damages arising out of infringement of the proprietary rights of any third party (excluding copyright, and trademark infringement), and invasion of privacy and advertising injury. Such insurance MUST be with a company rated no less than A- as to Policy Holders Rating in the current edition of Bests Insurance Guide (or with an association of companies each of the members of which are so rated). A CA MAY self-insure for liabilities that arise from such party's performance and obligations under these Guidelines provided that it has at least five hundred million US dollars in liquid assets based on audited financial statements in the past twelve months, and a quick ratio (ratio of liquid assets to current liabilities) of not less than 1.0.

8.5 Obtaining EV Certificates 8.5.1 General

The CA MAY only issue EV Certificates to Applicants that meet the Private Organization, Government Entity, Business Entity and Non-Commercial Entity requirements specified below.

8.5.2 Private Organization Subjects

An Applicant qualifies as a Private Organization if: (1) The entitys legal existence is created or recognized by a by a filing with (or an act of) the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration (e.g., by issuance of a certificate of incorporation, registration number, etc.) or created or recognized by a Government Agency (e.g. under a charter, treaty, convention, or equivalent recognition instrument); (2) The entity designated with the Incorporating or Registration Agency a Registered Agent, a Registered Office (as required under the laws of the Jurisdiction of Incorporation or Registration), or an equivalent facility; (3) The entity is not designated on the records of the Incorporating or Registration Agency by labels such as inactive, invalid, not current, or the equivalent; (4) The entity has a verifiable physical existence and business presence; (5) The entitys Jurisdiction of Incorporation, Registration, Charter, or License, and/or its Place of Business is not in any country where the CA is prohibited from doing business or issuing a certificate by the laws of the CAs jurisdiction; and (6) The entity is not listed on any government denial list or prohibited list (e.g., trade embargo) under the laws of the CAs jurisdiction.

8.5.3 Government Entity Subjects

An Applicant qualifies as a Government Entity if: (1) The entitys legal existence was established by the political subdivision in which the entity operates; (2) The entity is not in any country where the CA is prohibited from doing business or issuing a certificate by the laws of the CAs jurisdiction; and (3) The entity is not listed on any government denial list or prohibited list (e.g., trade embargo) under the laws of the CAs jurisdiction.

8.5.4 Business Entity Subjects

An Applicant qualifies as a Business Entity if: 14

- 82 -

(1) The entity is a legally recognized entity that filed certain forms with a Registration Agency in its jurisdiction, the Registration Agency issued or approved the entitys char ter, certificate, or license, and the entitys existence can be verified with that Registration Agency; (2) The entity has a verifiable physical existence and business presence; (3) At least one Principal Individual associated with the entity is identified and validated by the CA; (4) The identified Principal Individual attests to the representations made in the Subscriber Agreement; (5) the CA verifies the entitys use of any assumed name used to represent the entity pursuant to the requirements of Section 11.3 herein; (6) The entity and the identified Principal Individual associated with the entity are not located or residing in any country where the CA is prohibited from doing business or issuing a certificate by the laws of the CAs jurisdiction; and (7) The entity and the identified Principal Individual associated with the entity are not listed on any government denial list or prohibited list (e.g., trade embargo) under the laws of the CAs jurisdiction.

8.5.5 Non-Commercial Entity Subjects

An Applicant qualifies as a Non-Commercial Entity if: (A) The Applicant is an International Organization Entity, created under a charter, treaty, convention or equivalent instrument that was signed by, or on behalf of, more than one country's government. The CA/Browser Forum may publish a listing of Applicants who qualify as an International Organization for EV eligibility; and (B) The Applicant is not headquartered in any country where the CA is prohibited from doing business or issuing a certificate by the laws of the CA's jurisdiction; and (C) The Applicant is not listed on any government denial list or prohibited list (e.g., trade embargo) under the laws of the CA's jurisdiction. Subsidiary organizations or agencies of an entity that qualifies as a Non-Commercial Entity also qualifies for EV Certificates as a Non-Commercial Entity.

9 EV Certificate Content and Profile

This section sets forth minimum requirements for the content of the EV Certificate as they relate to the identity of the CA and the Subject of the EV Certificate.

9.1 Issuer Information

Issuer Information listed in an EV Certificate MUST comply with Section 9.1 of the Baseline Requirements.

9.2 Subject Information

Subject to the requirements of these Guidelines, the EV Certificate and certificates issued to Subordinate CAs that are not controlled by the same entity as the CA MUST include the following information about the Subject organization in the fields listed:

9.2.1 Subject Organization Name Field

Certificate field: subject:organizationName (OID 2.5.4.10 ) Required/Optional: Required Contents: This field MUST contain the Subjects full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subjects Jurisdiction of Incorporatio n or Registration or as otherwise verified by the CA as provided herein. A CA MAY abbreviate the organization prefixes or suffixes in the organization name, e.g., if the official record shows Company Name Incorporated the CA MAY include Company Name, Inc. 15

- 83 -

When abbreviating a Subjects full legal name as allowed by this subsection, the CA MUST use abbreviations that are not misleading in the Jurisdiction of Incorporation or Registration. In addition, an assumed name or DBA name used by the Subject MAY be included at the beginning of this field, provided that it is followed by the full legal organization name in parenthesis. If the combination of names or the organization name by itself exceeds 64 characters, the CA MAY abbreviate parts of the organization name, and/or omit non-material words in the organization name in such a way that the text in this field does not exceed the 64-character limit; provided that the CA checks this field in accordance with section 10.11.1 and a Relying Party will not be misled into thinking that they are dealing with a different organization. In cases where this is not possible, the CA MUST NOT issue the EV Certificate.

9.2.2 Subject Alternative Name Extension

Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extenstion MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subjects server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates.

9.2.3 Subject Common Name Field

Certificate field: subject:commonName (OID: 2.5.4.3) Required/Optional: Deprecated (Discouraged, but not prohibited) Contents: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subjects server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates.

9.2.4 Subject Business Category Field

Certificate field: subject:businessCategory (OID: 2.5.4.15) Required/Optional: Required Contents: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of Section 8.2.2, 8.2.3, 8.2.4 or 8.2.5 of these Guidelines, respectively.

9.2.5 Subject Jurisdiction of Incorporation or Registration Field

Certificate fields: Locality (if required): subject:jurisdictionOfIncorporationLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1) ASN.1 - X520LocalityName as specified in RFC 5280 State or province (if required): subject:jurisdictionOfIncorporationStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2) ASN.1 - X520StateOrProvinceName as specified in RFC 5280 Country: subject:jurisdictionOfIncorporationCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3) ASN.1 X520countryName as specified in RFC 5280 Required/Optional: Required 16

- 84 -

Contents: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subjects Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction.

9.2.6 Subject Registration Number Field

Certificate field: Subject:serialNumber (OID: 2.5.4.5) Required/Optional: Required Contents: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field in any one of the common date formats. For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in any one of the common date formats.

9.2.7 Subject Physical Address of Place of Business Field

Certificate fields: Number and street: subject:streetAddress (OID: 2.5.4.9) City or town: subject:localityName (OID: 2.5.4.7) State or province (where applicable): subject:stateOrProvinceName (OID: 2.5.4.8) Country: subject:countryName (OID: 2.5.4.6) Postal code: subject:postalCode (OID: 2.5.4.17) Required/Optional: City, state, and country Required; Street and postal code Optional Contents: This field MUST contain the address of the physical location of the Subjects Place of Business.

9.2.8 Other Subject Attributes

All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA. CAs SHALL NOT include Fully-Qualified Domain Names in Subject attributes except as specified in Sections 9.2.1 and SHALL NOT include any Subject Organization Information except as specified in Section 9.2. Optional subfields within the Subject field MUST either contain information verified by the CA or MUST be left empty. Metadata such as ., -, and characters, and/or any other indication that the field is empty, absent or incomplete, MUST not be used. 17

- 85 -

9.3 Certificate Policy Identification 9.3.1 EV Certificate Policy Identification Requirements

This section sets forth minimum requirements for the contents of EV Certificates as they relate to the identification of EV Certificate Policy.

9.3.2 EV Subscriber Certificates

Each EV Certificate issued by the CA to a Subscriber MUST contain a policy identifier defined by the CA in the certificates certificatePolicies extension that: (i) indicates which CA policy statement rel ates to that Certificate, (ii) asserts the CAs adherence to and compliance with these Guidelines, and (iii), by pre agreement with the Application Software Supplier, marks the Certificate as being an EV Certificate.

9.3.3 Root CA Certificates

The Application Software Supplier identifies Root CAs that are approved to issue EV Certificates by storing EV policy identifiers in metadata associated with Root CA Certificates.

9.3.4 EV Subordinate CA Certificates

(1) Certificates issued to Subordinate CAs that are not controlled by the issuing CA MUST contain one or more policy identifiers defined by the issuing CA that explicitly identify the EV Policies that are implemented by the Subordinate CA. (2) Certificates issued to Subordinate CAs that are controlled by the Root CA MAY contain the special anyPolicy identifier (OID: 2.5.29.32.0).

9.3.5 Subscriber Certificates

A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the Issuing CA, in the Certificates certificatePolicies extension that indicates adherence to and compliance with these Guidelines. Each CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these Guidelines.

9.4 Maximum Validity Period For EV Certificate

The validity period for an EV Certificate SHALL NOT exceed twenty seven months. It is RECOMMENDED that EV Subscriber Certificates have a maximum validity period of twelve months.

9.5 Subscriber Public Key

The requirements in Section 9.5 of the Baseline requirements apply equally to EV Certificates.

9.6 Certificate Serial Number

The requirements in Section 9.6 of the Baseline requirements apply equally to EV Certificates.

9.7 Additional Technical Requirements for EV Certificates

Both Appendix A Minimum Cryptographic Algorithms of the Baseline Requirements and Key Sizes and Appendix B Certificate Extensions of the Baseline Requirements apply to EV Certificates with the following exceptions: 1) If a Subordinate CA Certificates is issued to a Subordinate CA not controlled by the entity that controls the Root CA, the policy identifiers in the certificatePolicies extension MUST include the CAs Extended Validation policy identifier. Otherwise, it MAY contain the anyPolicy identifier. 2) The following fields MUST be present if the Subordinate CA is not controlled by the entity that controls the Root CA. certificatePolicies:policyQualifiers:policyQualifierId id-qt 1 [RFC 5280] certificatePolicies:policyQualifiers:qualifier:cPSuri HTTP URL for the Root CA's Certification Practice Statement 18

- 86 -

3) The certificatePolicies extension in EV Certificates issued to Subscribers MUST include the following: certificatePolicies:policyIdentifier (Required) certificatePolicies:policyQualifiers:policyQualifierId (Required) -qt 1 [RFC 5280] certificatePolicies:policyQualifiers:qualifier:cPSuri (Required) te CA's Certification Practice Statement 4) The cRLDistribution Point extension MUST be present in Subscriber Certificates if the certificate does not specify OCSP responder locations in an authorityInformationAccess extension.

10 EV Certificate Request Requirements 10.1 General Requirements 10.1.1 Documentation Requirements

The documentation requirements in Section 10.1 of the Baseline requirements apply equally to EV Certificates.

10.1.2 Role Requirements

The following Applicant roles are required for the issuance of an EV Certificate. 1. Certificate Requester: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. A Certificate Requester is a natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant. 2. Certificate Approver: The EV Certificate Request MUST be approved by an authorized Certificate Approver. A Certificate Approver is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to (i) act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and (ii) to approve EV Certificate Requests submitted by other Certificate Requesters. 3. Contract Signer: A Subscriber Agreement applicable to the requested EV Certificate MUST be signed by an authorized Contract Signer. A Contract Signer is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. (4) Applicant Representative: In the case where the CA and the Subscriber are affiliated, Terms of Use applicable to the requested EV Certificate MUST be acknowledged and agreed to by an authorized Applicant Representative. An Applicant Representative is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to acknowledge and agree to the Terms of Use. The Applicant MAY authorize one individual to occupy two or more of these roles. The Applicant MAY authorize more than one individual to occupy any of these roles.

10.2 EV Certificate Request Requirements

The Certificate Request requirements in Section 10.2 apply equally to EV Certificates subject to the additional more stringent ageing and updating requirement of Section 11.13 of these Guidelines. 19

- 87 -

10.3 Requirements for Subscriber Agreement and Terms of Use

Section 10.3 of the Baseline Requirements applies equally to EV Certificates. In cases where the Certificate Request does not contain all necessary information about the Applicant, the CA MUST additionally confirm the data with the Certificate Approver or Contract Signer rather than the Applicant.

11 Verification Requirements 11.1 General Overview

This part of the Guidelines sets forth Verification Requirements and Acceptable Methods of Verification for each such Requirement.

11.1.1 Verification Requirements Overview

Before issuing an EV Certificate, the CA MUST ensure that all Subject organization information to be included in the EV Certificate conforms to the requirements of, and is verified in accordance with, these Guidelines and matches the information confirmed and documented by the CA pursuant to its verification processes. Such verification processes are intended to accomplish the following: (A)Verify the Applicants legal existence and identity (as more fully set forth in Section 11.2 herein), (B)Verify the Applicants physical existence (business presence at a physical address), and (C)Verify the Applicants operational existence (business activity). a registered holder, or has exclusive control, of the Domain Name(s) to be included in the EV Certificate; (A)Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, (B)Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and (C)Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request.

11.1.2 Acceptable Methods of Verification Overview

As a general rule, the CA is responsible for taking all verification steps reasonably necessary to satisfy each of the Verification Requirements set forth in the subsections below. The Acceptable Methods of Verification set forth in each of Sections 11.2 through11.13 (which usually include alternatives) are considered to be the minimum acceptable level of verification required of the CA. In all cases, however, the CA is responsible for taking any additional verification steps that may be reasonably necessary under the circumstances to satisfy the applicable Verification Requirement.

11.2 Verification of Applicants Legal Existence and Identity 11.2.1 Verification Requirements
To verify the Applicants legal existence and identity, the CA MUST do the following. (1) Private Organization Subjects (A) Legal Existence: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicants Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as inactive, invalid, not current, or the equivalent. 20

- 88 -

(B) Organization Name: Verify that the Applicants formal legal name as recorded with the Incorporating or Registration Agency in the Applicants Jurisdiction of Incorporation or Registration matches the Applicants name in the EV Certificate Request. (C) Registration Number: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicants Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicants date of Incorporation or Registration. (D) Registered Agent: Obtain the identity and address of the Applicants Registered Agent or Registered Office (as applicable in the Applicants Jurisdiction of Incorporation or Registration). (2) Government Entity Subjects (A) Legal Existence: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. (B) Entity Name: Verify that the Applicants formal legal name matches the Applicants name in the EV Certificate Request. (C) Registration Number: The CA MUST attempt to obtain the Applicants date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. (3) Business Entity Subjects (A) Legal Existence: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application. (B) Organization Name: Verify that the Applicants formal legal name as recognized by the Registration Authority in the Applicants Jurisdiction of Registration matches the Applicants name in the EV Certificate Request. (C) Registration Number: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicants Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicants date of Registration. (D) Principal Individual: Verify the identity of the identified Principal Individual. (4) Non-Commercial Entity Subjects (International Organizations) (A) Legal Existence: Verify that the Applicant is a legally recognized International Organization Entity. (B) Entity Name: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. (C) Registration Number: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity.

11.2.2 Acceptable Method of Verification

(1) Private Organization Subjects: All items listed in Section 11.2.1(1) MUST be verified directly with, or obtained directly from, the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Such verification MAY be through use of a Qualified Government Information Source operated by, or on behalf of, the Incorporating or Registration Agency, or by direct contact with the Incorporating or Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Incorporating or Registration Agency, or from a Qualified Independent Information Source. (2) Government Entity Subjects: All items listed in Section 11.2.1(2) MUST either be verified directly with, or obtained directly from, one of the following: (i) a Qualified Government Information Source in the political subdivision in which such Government Entity operates; (ii) a superior governing Government Entity in the same 21

- 89 -

political subdivision as the Applicant (e.g. a Secretary of State may verify the legal existence of a specific State Department), or (iii) from a judge that is an active member of the federal, state or local judiciary within that political subdivision, or (iv) an attorney representing the Government Entity. Any communication from a judge SHALL be verified in the same manner as is used for verifying factual assertions that are asserted by an Attorney as set forth in Section 11.10.1. Such verification MAY be by direct contact with the appropriate Government Entity in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained from a Qualified Independent Information Source. (3) Business Entity Subjects: All items listed in Section 11.2.1(3) above, MUST be verified directly with, or obtained directly from, the Registration Agency in the Applicant's Jurisdiction of Registration. Such verification MAY be performed by means of a Qualified Government Information Source, a Qualified Governmental Tax Information Source, or by direct contact with the Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Qualified Governmental Tax Information Source or Registration Agency, or from a Qualified Independent Information Source. In addition, the CA MUST validate a Principal Individual associated with the Business Entity pursuant to the requirements in subsection (4), below. (4) Principal Individual: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agencys face -toface validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. (A) Face-To-Face Validation: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicants jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: (i) A Personal Statement that includes the following information: 1. Full name or names by which a person is, or has been, known (including all other names used); 2. Residential Address at which he/she can be located; 3. Date of birth; and 4. An affirmation that all of the information contained in the Certificate Request is true and correct. (ii) A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: 1. A passport; 2. A drivers license; 3. A personal identification card; 4. A concealed weapons permit; or 5. A military ID. (iii) At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. 1. Acceptable financial institution documents include: a. A major credit card, provided that it contains an expiration date and it has not expired' b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, c. A mortgage statement from a recognizable lender that is less than six months old, d. A bank statement from a regulated financial institution that is less than six months old. 22

- 90 -

2. Acceptable non-financial documents include: a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, c. A certified copy of a birth certificate, d. A local authority tax bill for the current year, e. A certified copy of a court order, such as a divorce certificate, annulment papers, or adoption papers. The Third-Party Validator performing the face-to-face validation MUST: (i) Attest to the signing of the Personal Statement and the identity of the signer; and (ii) Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. (B) Verification of Third-Party Validator: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicants jurisdiction), lawyer, or accountant in the jurisdiction of the Individuals residency, and that the Third -Party Validator actually did perform the services and did attest to the signature of the Individual. (C) Cross-checking of Information: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: (i) the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and (ii) electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CAs jurisdiction. (5) Non-Commercial Entity Subjects (International Organization): All items listed in Section 11.2.1 (4) MUST be verified either: (A) With reference to the constituent document under which the International Organization was formed; or (B) Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or (C) Directly against any current list of qualified entities that the CA/Browser Forum may maintain at www.cabforum.org. (D) In cases where the International Organization applying for the EV Certificate is an organ or agency including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency.

11.3 Verification of Applicants Legal Existence and Identity Assumed Name 11.3.1 Verification Requirements
If, in addition to the Applicants formal legal name, as recorded with the applicable Incorporating Agency or Registration Agency in the Applicants Jurisdiction of Incorporation or Registration, the Applicants identity, as asserted in the EV Certificate, is to contain any assumed name (also known as doing business as, DBA, or d/b/a in the US, and trading as in the UK) under which the Applicant conducts business, the CA MUST verify that: (i) the 23

- 91 -

Applicant has registered its use of the assumed name with the appropriate government agency for such filings in the jurisdiction of its Place of Business (as verified in accordance with these Guidelines), and (ii) that such filing continues to be valid.

11.3.2 Acceptable Method of Verification

To verify any assumed name under which the Applicant conducts business: (1) The CA MAY verify the assumed name through use of a Qualified Government Information Source operated by, or on behalf of, an appropriate government agency in the jurisdiction of the Applicants Place of Business, or by direct contact with such government agency in person or via mail, e-mail, Web address, or telephone; or (2) The CA MAY verify the assumed name through use of a Qualified Independent Information Source provided that the QIIS has verified the assumed name with the appropriate government agency. (3) The CA MAY rely on a Verified Legal Opinion, or a Verified Accountant Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid.

11.4 Verification of Applicants Physical Existence 11.4.1 Address of Applicants Place of Business
(1) Verification Requirements: To verify the Applicant's physical existence and business presence, the CA MUST verify that the physical address provided by the Applicant is an address where the Applicant or a Parent/Subsidiary Company conducts business operations (not, for example, a mail drop or P.O. box, or 'care of' (C/O) address, such as an address for an agent of the Organization), and is the address of the Applicant's Place of Business. (2) Acceptable Methods of Verification (A) Place of Business in the Country of Incorporation or Registration (i) For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and whose Place of Business is NOT the same as that indicated in the relevant Qualified Government Information Source used in Section 11.2 to verify legal existence: (1) For Applicants listed at the same Place of Business address in the current version of either at least one QGIS (other than that used to verify legal existence), QIIS or QTIS, the CA MUST confirm that the Applicant's address, as listed in the EV Certificate Request, is a valid business address for the Applicant or a Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY rely on the Applicant's representation that such address is its Place of Business; (2) For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST: (a) Verify that the Applicant's business is located at the exact address stated in the EV Certificate Request (e.g., via permanent signage, employee confirmation, etc.), (b) Identify the type of facility (e.g., office in a commercial building, private residence, storefront, etc.) and whether it appears to be a permanent business location, (c) Indicate whether there is a permanent sign (that cannot be moved) that identifies the Applicant, (d) Indicate whether there is evidence that the Applicant is conducting ongoing business activities at the site (not that it is just, for example, a mail drop, P.O. box, etc.), and (e) Include one or more photos of (i) the exterior of the site (showing signage indicating the Applicant's name, if present, and showing the street address if possible), and (ii) the interior reception area or workspace. 24

- 92 -

(2) For all Applicants, the CA MAY alternatively rely on a Verified Legal Opinion or a Verified Accountant Letter that indicates the address of the Applicant's or a Parent/Subsidiary Company's Place of Business and that business operations are conducted there. (3) For Government Entity Applicants, the CA MAY rely on the address contained in the records of the QGIS in the Applicant's jurisdiction. (4) For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and where the QGIS used in Section 11.2 to verify legal existence contains a business address for the Applicant, the CA MAY rely on the address in the QGIS to confirm the Applicant's or a Parent/Subsidiary Company's address as listed in the EV Certificate Request, and MAY rely on the Applicant's representation that such address is its Place of Business. (B) Place of Business not in the Country of Incorporation or Registration: The CA MUST rely on a Verified Legal Opinion or Verified Accountant's Letter that indicates the address of the Applicant's Place of Business and that business operations are conducted there.

11.4.2 Telephone Number for Applicants Place of Business

(1) Verification Requirements: To further verify the Applicants physical existence and business presence, as well as to assist in confirming other verification requirements, the CA MUST verify a main telephone number for one of the Applicants Places of Business. (2) Acceptable Methods of Verification: To verify the Applicants telephone number, the CA MUST perform items A and either B or C as listed below: (A) Confirm the Applicants telephone number by calling it and obtaining an affirmative response sufficient to enable a reasonable person to conclude that the Applicant is reachable by telephone at the number dialed; (B) Confirm that the telephone number is listed as one of the Applicants or Parent/Subsidiary Companys or Principal Individuals (for business entities) telephone numbers, matching an address of one of the Applicants Places of Business in records provided by the applicable phone company, or, alternatively, in at least one QIIS, QGIS, or QTIS; (C) Rely on a Verified Legal Opinion or a Verified Accountant Letter to the effect that the Applicants telephone number, as provided, is a main phone number for the Applicants Place of Busine ss.

11.5 Verification of Applicants Operational Existence 11.5.1 Verification Requirements

If the Applicant, or a Parent or Affiliate of the Applicant, has been in existence for less than three years, as indicated by the records of the Incorporating Agency or Registration Agency, and is not listed in either the current version of one QIIS or QTIS, the CA MUST verify that the Applicant has the ability to engage in business. In other words, if the Applicant is a Subsidiary or Affiliate of an entity that the CA verified as in existence for three or more years, then the CA MAY rely on the existence of the Parent or Affiliate as verification of the Applicants operational existence.

11.5.2 Acceptable Methods of Verification

To verify the Applicants operational existence, the CA MUST perform one of the following: (1) Verify that the Applicant has an active current Demand Deposit Account with a Regulated Financial Institution. The CA MUST receive authenticated documentation directly from a Regulated Financial Institution verifying that the Applicant has an active current Demand Deposit Account with the institution. (2) Rely on a Verified Legal Opinion or a Verified Accountant Letter to the effect that the Applicant has an active current Demand Deposit Account with a Regulated Financial Institution.

11.6 Verification of Applicants Domain Name 11.6.1 Verification Requirements

The CA MUST confirm that the Applicant: 25

- 93 -

(A) Is the registered holder of the Domain Name, or (B) Has been granted the exclusive right to use the Domain Name by the registered holder of the Domain Name; To verify the Applicants registration, or exclusive control, of the Domain Name(s) to be listed in the EV Certificate, the CA MUST verify that each such Domain Name is registered with an Internet Corporation for Assigned Names and Numbers (ICANN)-approved registrar or a registry listed by the Internet Assigned Numbers Authority (IANA). For Government Entity Applicants, the CA MAY rely on the Domain Name listed for that entity in the records of the QGIS in the Applicants Jurisdiction. The CA MUST compare any registration information that is publicly available from the WHOIS database with the verified Subject organization information and MUST confirm that it is neither misleading nor inconsistent. The CA MUST further confirm that the Applicant is aware of its registration or exclusive control of the Domain Name.

11.6.2 Acceptable Methods of Verification

(1) Applicant as Registered Holder: Acceptable methods by which the CA MAY verify that the Applicant is the registered holder of the Domain Name include the following: (A) Performing a WHOIS inquiry on the Internet for the Domain Name supplied by the Applicant, and obtaining a response indicating that the Applicant or a Parent/Subsidiary Company is the entity to which the Domain Name is registered; or (B) Communicating with the contact listed on the WHOIS record to confirm that the Applicant is the registered holder of the Domain Name and having the contact update the WHOIS records to reflect the proper Domain Name registration. Confirmation that the registered owner of the Domain Name is a Parent/Subsidiary Company of the Applicant, or a registered trading name of the Applicant is sufficient to establish that the Applicant is the registered owner of the Domain Name; (C) In cases where domain registration information is private, and the domain registrar offers services to forward communication to the registered domain holder, the CA MAY contact the Applicant through the domain registrar by e-mail or paper mail. (2) Applicants Exclusive Right to Use: In cases where the Applicant is not the registered holder of the Domain Name, the CA MUST verify the Applicants exclusive right to use the Domain Name(s). (A) In cases where the registered domain holder can be contacted using information obtained from WHOIS, or through the domain registrar, the CA MUST obtain positive confirmation from the registered domain holder by paper mail, e-mail, telephone, or facsimile that the Applicant has been granted the exclusive right to use the requested Fully Qualified Domain Name (FQDN). If the Top-Level Domain is a generic top-level domain (gTLD) such as .com, .net, or .org in accordance with RFC 1591, the CA MUST obtain positive confirmation from the second-level domain registration holder. For example, if the requested FQDN is www1.www.example.com, the CA MUST obtain positive confirmation from the domain holder of example.com. If the Top-Level Domain is a 2 letter Country Code Top-Level Domain (ccTLD), the CA MUST obtain positive confirmation from the domain holder at the appropriate domain level, based on the rules of the ccTLD. For example, if the requested FQDN is www.mysite.users.internet.co.uk, the CA MUST obtain positive confirmation from the domain holder of internet.co.uk. In addition, the CA MUST verify the Applicants exclusive right to use the Domain Name using one of the following methods: (i) Relying on a Verified Legal Opinion or a Verified Accountant Letter to the effect that the Applicant has the exclusive right to use the specified Domain Name in identifying itself on the Internet; or (ii) Relying on a representation from the Contract Signer, or the Certificate Approver, if expressly so authorized in a mutually-agreed-upon contract. (B) In cases where the registered domain holder cannot be contacted, the CA MUST: (i) Rely on a Verified Legal Opinion or a Verified Accountant Letter to the effect that the Applicant has the exclusive right to use the specified Domain Name in identifying itself on the Internet; and 26

- 94 -

(ii) Rely on a representation from the Contract Signer, or the Certificate Approver, if expressly so authorized in a mutually-agreed-upon contract, coupled with a practical demonstration by the Applicant establishing that it controls the Domain Name by making an agreed-upon change in information found online on a Web page identified by a uniform resource identifier containing the Applicants FQDN. (3) Knowledge: Acceptable methods by which the CA MAY verify that the Applicant is aware that it has exclusive control of the Domain Name include the following: (A) Relying on a Verified Legal Opinion or a Verified Accountant Letter to the effect that the Applicant is aware that it has exclusive control of the Domain Name; or (B) Obtaining a confirmation from the Contract Signer or Certificate Approver verifying that the Applicant is aware that it has exclusive control of the Domain Name. (4) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization.

11.7 Verification of Name, Title, and Authority of Contract Signer and Certificate Approver 11.7.1 Verification Requirements
For both the Contract Signer and the Certificate Approver, the CA MUST verify the following. (1) Name, Title and Agency: The CA MUST verify the name and title of the Contract Signer and the Certificate Approver, as applicable. The CA MUST also verify that the Contract Signer and the Certificate Approver are agents representing the Applicant. (2) Signing Authority of Contract Signer: The CA MUST verify that the Contract Signer is authorized by the Applicant to enter into the Subscriber Agreement (and any other relevant contractual obligations) on behalf of the Applicant, including a contract that designates one or more Certificate Approvers on behalf of the Applicant. (3) EV Authority of Certificate Approver: The CA MUST verify, through a source other than the Certificate Approver him- or herself, that the Certificate Approver is expressly authorized by the Applicant to do the following, as of the date of the EV Certificate Request: behalf of the Applicant; and from the Applicant by the CA for issuance of the EV Certificate; and

11.7.2 Acceptable Methods of Verification Name, Title and Agency

Acceptable methods of verification of the name, title, and agency status of the Contract Signer and the Certificate Approver include the following. (1) Name and Title: The CA MAY verify the name and title of the Contract Signer and the Certificate Approver by any appropriate method designed to provide reasonable assurance that a person claiming to act in such a role is in fact the named person designated to act in such role . (2) Agency: The CA MAY verify the agency of the Contract Signer and the Certificate Approver by: (A) Contacting the Applicants Human Resources Department by phone or mail (at the phone number or address for the Applicants Place of Business, verified in accordance with these Guidelines) and obtaining confirmation that the Contract Signer and/or the Certificate Approver, as applicable, is an employee; or (B) Obtaining an Independent Confirmation From the Applicant (as described in Section 11.10.4), or a Verified Legal Opinion (as described in Section 11.10.1), or a Verified Accountant Letter (as described in Section 27

- 95 -

11.10.2) verifying that the Contract Signer and/or the Certificate Approver, as applicable, is either an employee or has otherwise been appointed as an agent of the Applicant. (C) Obtaining confirmation from a QIIS or QGIS that the Contract Signer and/or Certificate Approver is an employee of the Applicant. The CA MAY also verify the agency of the Certificate Approver via a certification from the Contract Signer (including in a contract between the CA and the Applicant signed by the Contract Signer), provided that the employment or agency status and Signing Authority of the Contract Signer has been verified.

11.7.3 Acceptable Methods of Verification Authority

Acceptable methods of verification of the Signing Authority of the Contract Signer, and the EV Authority of the Certificate Approver, as applicable, include: (1) Legal Opinion: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by reliance on a Verified Legal Opinion (as described in Section 11.10.1); (2) Accountant Letter: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by reliance on a Verified Accountant Letter (as described in Section 11.10.2); (3) Corporate Resolution: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by reliance on a properly authenticated corporate resolution that confirms that the person has been granted such Signing Authority, provided that such resolution is (i) certified by the appropriate corporate officer (e.g., secretary), and (ii) the CA can reliably verify that the certification was validly signed by such person, and that such person does have the requisite authority to provide such certification; (4) Independent Confirmation from Applicant: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by obtaining an Independent Confirmation from the Applicant (as described in Section 11.10.4); (5) Contract between CA and Applicant: The EV Authority of the Certificate Approver MAY be verified by reliance on a contract between the CA and the Applicant that designates the Certificate Approver with such EV Authority, provided that the contract is signed by the Contract Signer and provided that the agency and Signing Authority of the Contract Signer have been verified; (6) Prior Equivalent Authority: The signing authority of the Contract Signer, and/or the EV authority of the Certificate Approver, MAY be verified by relying on a demonstration of Prior Equivalent Authority. (A) Prior Equivalent Authority of a Contract Signer MAY be relied upon for confirmation or verification of the signing authority of the Contract Signer when the Contract Signer has executed a binding contract between the CA and the Applicant with a legally valid and enforceable seal or handwritten signature and only when the contract was executed more than 90 days prior to the EV Certificate application. The CA MUST record sufficient details of the previous agreement to correctly identify it and associate it with the EV application. Such details MAY include any of the following: (i) Agreement title, (ii) Date of Contract Signers signature, (iii) Contract reference number, and (iv) Filing location. (B) Prior Equivalent Authority of a Certificate Approver MAY be relied upon for confirmation or verification of the EV Authority of the Certificate Approver when the Certificate Approver has performed one or more of the following: (i) Under contract to the CA, has served (or is serving) as an Enterprise RA for the Applicant, or (ii) Has participated in the approval of one or more certificate requests, for certificates issued by the CA and which are currently and verifiably in use by the Applicant. In this case the CA MUST have contacted the Certificate Approver by phone at a previously validated phone number or have accepted a signed and notarized letter approving the certificate request. 28

- 96 -

(7) QIIS or QGIS: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by a QIIS or QGIS that identifies the Contract Signer and/or the Certificate Approver as a corporate officer, sole proprietor, or other senior official of the Applicant. 8) Contract Signers Representation/Warranty: Provided that the CA verifies that the Contract Signer is an employee or agent of the Applicant, the CA MAY rely on the signing authority of the Contract Signer by obtaining a duly executed representation or warranty from the Contract Signer that includes the following acknowledgments: (A) That the Applicant authorizes the Contract Signer to sign the Subscriber Agreement on the Applicant's behalf, (B) That the Subscriber Agreement is a legally valid and enforceable agreement, (C) That, upon execution of the Subscriber Agreement, the Applicant will be bound by all of its terms and conditions, (D) That serious consequences attach to the misuse of an EV certificate, and (E) The contract signer has the authority to obtain the digital equivalent of a corporate seal, stamp or officer's signature to establish the authenticity of the company's Web site. Note: An example of an acceptable representation/warranty appears in Appendix E.

11.7.4 Pre-Authorized Certificate Approver

Where the CA and Applicant contemplate the submission of multiple future EV Certificate Requests, then, after the CA: Applicant; and procedures in Section 11.7.3. The CA and the Applicant MAY enter into a written agreement, signed by the Contract Signer on behalf of the Applicant, whereby, for a specified term, the Applicant expressly authorizes one or more Certificate Approver(s) designated in such agreement to exercise EV Authority with respect to each future EV Certificate Request submitted on behalf of the Applicant and properly authenticated as originating with, or otherwise being approved by, such Certificate Approver(s). Such an agreement MUST provide that the Applicant shall be obligated under the Subscriber Agreement for all EV Certificates issued at the request of, or approved by, such Certificate Approver(s) until such EV Authority is revoked, and MUST include mutually agreed-upon provisions for (i) authenticating the Certificate Approver when EV Certificate Requests are approved, (ii) periodic re-confirmation of the EV Authority of the Certificate Approver, (iii) secure procedures by which the Applicant can notify the CA that the EV Authority of any such Certificate Approver is revoked, and (iv) such other appropriate precautions as are reasonably necessary.

11.8 Verification of Signature on Subscriber Agreement and EV Certificate Requests

Both the Subscriber Agreement and each non-pre-authorized EV Certificate Request MUST be signed. The Subscriber Agreement MUST be signed by an authorized Contract Signer. The EV Certificate Request MUST be signed by the Certificate Requester submitting the document, unless the Certificate Request has been pre-authorized in line with Section 11.7.4 of these Guidelines. If the Certificate Requester is not also an authorized Certificate Approver, then an authorized Certificate Approver MUST independently approve the EV Certificate Request. In all cases, applicable signatures MUST be a legally valid and contain an enforceable seal or handwritten signature (for a paper Subscriber Agreement and/or EV Certificate Request), or a legally valid and enforceable electronic signature (for an electronic Subscriber Agreement and/or EV Certificate Request), that binds the Applicant to the terms of each respective document.

11.8.1 Verification Requirements

(1) Signature: The CA MUST authenticate the signature of the Contract Signer on the Subscriber Agreement and the signature of the Certificate Requester on each EV Certificate Request in a manner that makes it reasonably certain that the person named as the signer in the applicable document is, in fact, the person who signed the document on behalf of the Applicant. 29

- 97 -

(2) Approval Alternative: In cases where an EV Certificate Request is signed and submitted by a Certificate Requester who does not also function as a Certificate Approver, approval and adoption of the EV Certificate Request by a Certificate Approver in accordance with the requirements of Section 11.9 can substitute for authentication of the signature of the Certificate Requester on such EV Certificate Request.

11.8.2 Acceptable Methods of Signature Verification

Acceptable methods of authenticating the signature of the Certificate Requester or Contract Signer include the following. (1) A phone call to the Applicants or Agents phone number, as verified in accordance with these Guidelines, asking to speak to the Certificate Requester or Contract Signer, as applicable, followed by a response from someone who identifies themselves as such person confirming that he/she did sign the applicable document on behalf of the Applicant. (2) A letter mailed to the Applicants or Agents address, as verified through independent means in accordance with these Guidelines, for the attention of the Certificate Requester or Contract Signer, as applicable, followed by a phone or mail response from someone who identifies themselves as such person confirming that he/she did sign the applicable document on behalf of the Applicant. (3) Use of a signature process that establishes the name and title of the signer in a secure manner, such as through use of an appropriately secure login process that identifies the signer before signing, or through use of a digital signature made with reference to an appropriately verified certificate. (4) Notarization by a notary, provided that the CA independently verifies that such notary is a legally qualified notary in the jurisdiction of the Certificate Requester or Contract Signer.

11.9 Verification of Approval of EV Certificate Request 11.9.1 Verification Requirements

In cases where an EV Certificate Request is submitted by a Certificate Requester, before the CA issues the requested EV Certificate, the CA MUST verify that an authorized Certificate Approver reviewed and approved the EV Certificate Request.

11.9.2 Acceptable Methods of Verification

Acceptable methods of verifying the Certificate Approvers approval of an EV Certificate Request include: (1) Contacting the Certificate Approver by phone or mail at a verified phone number or address for the Applicant and obtaining oral or written confirmation that the Certificate Approver has reviewed and approved the EV Certificate Request; (2) Notifying the Certificate Approver that one or more new EV Certificate Requests are available for review and approval at a designated access-controlled and secure Web site, followed by a login by, and an indication of approval from, the Certificate Approver in the manner required by the Web site; or (3) Verifying the signature of the Certificate Approver on the EV Certificate Request in accordance with Section 11.8 of these Guidelines.

11.10 Verification of Certain Information Sources 11.10.1 Verified Legal Opinion

(1) Verification Requirements: Before relying on a legal opinion submitted to the CA, the CA MUST verify that such legal opinion meets the following requirements: (A) Status of Author: The CA MUST verify that the legal opinion is authored by an independent legal practitioner retained by and representing the Applicant (or an in-house legal practitioner employed by the Applicant) (Legal Practitioner) who is either: 30

- 98 -

Applicants Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility, or ( the country of the Applicants Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility (and that such jurisdiction recognizes the role of the Latin Notary); (B) Basis of Opinion: The CA MUST verify that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Legal Opinion are based on the Legal Practitioners stated familiarity with the relevant facts and the exercise of the Legal Practitioners professional judgment and expertise; (C) Authenticity: The CA MUST confirm the authenticity of the Verified Legal Opinion. (2) Acceptable Methods of Verification: Acceptable methods of establishing the foregoing requirements for a Verified Legal Opinion are: (A) Status of Author: The CA MUST verify the professional status of the author of the legal opinion by directly contacting the authority responsible for registering or licensing such Legal Practitioner(s) in the applicable jurisdiction; (B) Basis of Opinion: The text of the legal opinion MUST make it clear that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the legal opinion are based on the Legal Practitioners stated familiarity with the relevant facts and the exercise of the practitioners professional judgment and expertise. The legal opinion MAY also include disclaimers and other limitations customary in the Legal Practitioners jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Legal Practitioner, should the legal opinion prove to be erroneous. An acceptable form of legal opinion is attached as Appendix B; (C) Authenticity: To confirm the authenticity of the legal opinion, the CA MUST make a telephone call or send a copy of the legal opinion back to the Legal Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Legal Practitioner listed with the authority responsible for registering or licensing such Legal Practitioner, and obtain confirmation from the Legal Practitioner or the Legal Practitioners assistant that the legal opinion is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Legal Practitioner in records provided by the applicable phone company, QGIS, or QIIS. In circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in Section 11.10.1 (2)(A), no further verification of authenticity is required.

11.10.2 Verified Accountant Letter

(1) Verification Requirements: Before relying on an accountant letter submitted to the CA, the CA MUST verify that such accountant letter meets the following requirements: (A) Status of Author: The CA MUST verify that the accountant letter is authored by an independent Accounting Practitioner retained by and representing the Applicant (or an in-house professional accountant employed by the Applicant) who is a certified public accountant, chartered accountant, or has an equivalent license within the Applicants Jurisdiction of Incorporation, Jurisdiction of Registration, or the jurisdiction where the Applicant maintains an office or physical facility. Verification of license MUST be through that jurisdictions member of the International Federation of Accountants (IFAC) or through the regulatory organization in that jurisdiction appropriate to contact when verifying an accountants license to practice in that jurisdiction. (B) Basis of Opinion: The CA MUST verify that the Accounting Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Accountant Letter are based on the Accounting Practitioners stated familiarity with the relevant facts and the exercise of the Accounting Practitioners professional judgment and expertise; (C) Authenticity: The CA MUST confirm the authenticity of the Verified Accountant Letter. (2) Acceptable Methods of Verification: Acceptable methods of establishing the foregoing requirements for a Verified Accountant Letter are listed here. 31

- 99 -

(A) Status of Author: The CA MUST verify the professional status of the author of the accountant letter by directly contacting the authority responsible for registering or licensing such Accounting Practitioners in the applicable jurisdiction. (B) Basis of Opinion: The text of the Verified Accountant Letter MUST make clear that the Accounting Practitioner is acting on behalf of the Applicant and that the information in the letter is based on the Accounting Practitioners stated familiarity with the relevant facts and the exercise of the practitioners professional judgment and expertise. The Verified Accountant Letter MAY also include disclaimers and other limitations customary in the Accounting Practitioners jurisdiction, provide d that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Accounting Practitioner, should the Verified Accountant Letter prove to be erroneous. Acceptable forms of Verified Accountant Letter are attached as Appendix C. (C) Authenticity: To confirm the authenticity of the accountants opinion, the CA MUST make a telephone call or send a copy of the Verified Accountant Letter back to the Accounting Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Accounting Practitioner listed with the authority responsible for registering or licensing such Accounting Practitioners and obtain confirmation from the Accounting Practitioner or the Accounting Practitioners assistant that the accountant letter is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Accountant in records provided by the applicable phone company, QGIS, or QIIS. In circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in Section 11.10.2 (2)(A), no further verification of authenticity is required.

11.10.3 Face-to-Face Validation

(1) Verification Requirements: Before relying on face-to-face vetting documents submitted to the CA, the CA MUST verify that the Third-Party Validator meets the following requirements: (A) Qualification of Third-Party Validator: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicants jurisdiction), Lawyer, or Accountant in the jurisdiction of the individuals residency; (B) Document Chain of Custody: The CA MUST verify that the Third-Party Validator viewed the Vetting Documents in a face-to-face meeting with the individual being validated; (C) Verification of Attestation: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the attestation and vetting documents. (2) Acceptable Methods of Verification: Acceptable methods of establishing the foregoing requirements for vetting documents are: (A) Qualification of Third-Party Validator: The CA MUST verify the professional status of the ThirdParty Validator by directly contacting the authority responsible for registering or licensing such Third-Party Validators in the applicable jurisdiction; (B) Document Chain of Custody: The Third-Party Validator MUST submit a statement to the CA which attests that they obtained the Vetting Documents submitted to the CA for the individual during a face-toface meeting with the individual; (C) Verification of Attestation: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the vetting documents received from the Third-Party Validator. The CA MUST make a telephone call to the Third-Party Validator and obtain confirmation from them or their assistant that they performed the face-to-face validation. The CA MAY rely upon self-reported information obtained from the Third-Party Validator for the sole purpose of performing this verification process. In circumstances where the attestation is digitally signed, in a manner that confirms the authenticity of the documents, and the identity of the signer as verified by the CA in Section 11.10.3 (1)(A), no further verification of authenticity is required.

11.10.4 Independent Confirmation From Applicant

An Independent Confirmation from the Applicant is a confirmation of a particular fact (e.g., knowledge of its exclusive control of a Domain Name, confirmation of the employee or agency status of a Contract Signer or Certificate Approver, confirmation of the EV Authority of a Certificate Approver, etc.) that is: 32

- 100 -

the inquiry) that has the appropriate authority to confirm such a fact, and who represents that he/she has confirmed such fact;

An Independent Confirmation from the Applicant MAY be obtained via the following procedure: (1) Confirmation Request: The CA MUST initiate a Confirmation Request via an appropriate out-of-band communication, requesting verification or confirmation of the particular fact at issue as follows: (A) Addressee: The Confirmation Request MUST be directed to: (i) A position within the Applicants organization that qualifies as a Confirming Person (e.g., Secretary, President, CEO, CFO, COO, CIO, CSO, Director, etc.) and is identified by name and title in a current QGIS, QIIS, QTIS, Verified Legal Opinion, Ver ified Accountant Letter, or by contacting the Applicants Human Resources Department by phone or mail (at the phone number or address for the Applicants Place of Business, verified in accordance with these Guidelines); or (ii) The Applicants Registered Agent or Registered Office in the Jurisdiction of Incorporation as listed in the official records of the Incorporating Agency, with instructions that it be forwarded to an appropriate Confirming Person; or (iii) A named individual verified to be in the direct line of management above the Contract Signer or Certificate Approver by contacting the Applicants Human Resources Department by phone or mail (at the phone number or address for the Applicants Place of Business, verified in accordance with these Guidelines). (B) Means of Communication: The Confirmation Request MUST be directed to the Confirming Person in a manner reasonably likely to reach such person. The following options are acceptable: (i) By paper mail addressed to the Confirming Person at: ( Guidelines, or Legal Opinion, or Verified Accountant Letter, or the Jurisdiction of Incorporation, or (ii) By e-mail addressed to the Confirming Person at the business e-mail address for such person listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter; or (iii) By telephone call to the Confirming Person, where such person is contacted by calling the main phone number of the Applicants Place of Business (verified in accordance with these Guidelines) and asking to speak to such person, and a person taking the call identifies him- or herself as such person; or (iv) By facsimile to the Confirming Person at the Place of Business. The facsimile number must be listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter. The cover page must be clearly addressed to the Confirming Person. (2) Confirmation Response: The CA MUST receive a response to the Confirmation Request from a Confirming Person that confirms the particular fact at issue. Such response MAY be provided to the CA by telephone, by e-mail, or by paper mail, so long as the CA can reliably verify that it was provided by a Confirming Person in response to the Confirmation Request. (3) The CA MAY rely on a verified Confirming Person to confirm their own contact information: email address, telephone number, and facsimile number. The CA MAY rely on this verified contact information for future correspondence with the Confirming Person if: (A) The domain of the e-mail address is owned by the Applicant and is the Confirming Persons own e mail address and not a group e-mail alias; 33

- 101 -

(B) The Confirming Persons telephone/fax number is verified by the CA to be a telephone number that i s part of the organizations telephone system, and is not the personal phone number for the person.

11.10.5 Qualified Independent Information Source

A Qualified Independent Information Source (QIIS) is a regularly-updated and current, publicly available, database designed for the purpose of accurately providing the information for which it is consulted, and which is generally recognized as a dependable source of such information. A commercial database is a QIIS if the following are true: (1) Industry groups rely on the database for providing accurate location or contact information; (2) The database distinguishes between self-reported data and data reported by independent information sources; (3) The database provider identifies how frequently they update the information in their database; (4) Changes in the data that will be relied upon will be reflected in the database in no more than 12 months; and (5) The database provider uses authoritative sources independent of the Subject, or multiple corroborated sources, to which the data pertains. Databases in which the CA or its owners or affiliated companies maintain a controlling interest, or in which any Registration Authorities or subcontractors to whom the CA has outsourced any portion of the vetting process (or their owners or affiliated companies) maintain any ownership or beneficial interest do not qualify as a QIIS. The CA MUST check the accuracy of the database and ensure its data is acceptable.

11.10.6 Qualified Government Information Source

A Qualified Government Information Source (QGIS) is a regularly-updated and current, publicly available, database designed for the purpose of accurately providing the information for which it is consulted, and which is generally recognized as a dependable source of such information provided that it is maintained by a Government Entity, the reporting of data is required by law, and false or misleading reporting is punishable with criminal or civil penalties. Nothing in these Guidelines shall prohibit the use of third-party vendors to obtain the information from the Government Entity provided that the third party obtains the information directly from the Government Entity.

11.10.7 Qualified Government Tax Information Source

A Qualified Government Tax Information Source is a Qualified Government Information Source that specifically contains tax information relating to Private Organizations, Business Entities or Individuals (e.g., the IRS in the United States).

11.11 Other Verification Requirements 11.11.1 High Risk Status

The requirements of Section 11.5 of the Baseline Requirements apply equally to EV Certificates.

11.11.2 Denied Lists and Other Legal Black Lists

(1) Verification Requirements: The CA MUST verify whether the Applicant, the Contract Signer, the Certificate Approver, the Applicants Jurisdiction of Incorporation, Registration, or Place of Business: business with such organization or person under the laws of the country of the CAs jurisdiction(s) of operation; or f Incorporation, Registration, or Place of Business in any country with which the laws of the CAs jurisdiction prohibit doing business. The CA MUST NOT issue any EV Certificate to the Applicant if either the Applicant, the Contract Signer, or Certificate Approver or if the Applicants Jurisdiction of Incorporation or Registration or Place of Business is on any such list. (2) Acceptable Methods of Verification: The CA MUST take reasonable steps to verify with the following lists and regulations: 34

- 102 -

(A) If the CA has operations in the U.S., the CA MUST take reasonable steps to verify with the following US Government denied lists and regulations: (i) BIS Denied Persons List - http://www.bis.doc.gov/dpl/thedeniallist.asp (ii) BIS Denied Entities List - http://www.bis.doc.gov/Entities/Default.htm (iii) US Treasury Department List of Specially Designated Nationals and Blocked Persons http://www.treas.gov/ofac/t11sdn.pdf (iv) US Government export regulations (B) If the CA has operations in any other country, the CA MUST take reasonable steps to verify with all equivalent denied lists and export regulations (if any) in such other country.

11.11.3 Parent/Subsidiary/Affiliate Relationship

A CA verifying an Applicant using information of the Applicant's Parent, Subsidiary, or Affiliate, when allowed under section 11.4.1, 11.4.2, 11.5.1, or 11.6.1, MUST verify the Applicant's relationship to the Parent, Subsidiary, or Affiliate. Acceptable methods of verifying the Applicant's relationship to the Parent, Subsidiary, or Affiliate include the following: (1) QIIS or QGIS: The relationship between the Applicant and the Parent, Subsidiary, or Affiliate is identified in a QIIS or QGIS; (2) Independent Confirmation from the Parent, Subsidiary, or Affiliate: A CA MAY verify the relationship between an Applicant and a Parent, Subsidiary, or Affiliate by obtaining an Independent Confirmation from the appropriate Parent, Subsidiary, or Affiliate (as described in Section 11.10.4); (3) Contract between CA and Parent, Subsidiary, or Affiliate: A CA MAY verify the relationship between an Applicant and a Parent, Subsidiary, or Affiliate by relying on a contract between the CA and the Parent, Subsidiary, or Affiliate that designates the Certificate Approver with such EV Authority, provided that the contract is signed by the Contract Signer and provided that the agency and Signing Authority of the Contract Signer have been verified; (4) Legal Opinion: A CA MAY verify the relationship between an Applicant and a Parent, Subsidiary, or Affiliate by relying on a Verified Legal Opinion (as described in Section 11.10.1); (5) Accountant Letter: A CA MAY verify the relationship between an Applicant and a Parent, Subsidiary, or Affiliate by relying on a Verified Accountant Letter (as described in Section 11.10.2); or (6) Corporate Resolution: A CA MAY verify the relationship between an Applicant and a Subsidiary by relying on a properly authenticated corporate resolution that approves creation of the Subsidiary or the Applicant, provided that such resolution is (i) certified by the appropriate corporate officer (e.g., secretary), and (ii) the CA can reliably verify that the certification was validly signed by such person, and that such person does have the requisite authority to provide such certification.

11.12 Final Cross-Correlation and Due Diligence

Except for Enterprise EV Certificates: (1) The results of the verification processes and procedures outlined in these Guidelines are intended to be viewed both individually and as a group. Thus, after all of the verification processes and procedures are completed, the CA MUST have a person who is not responsible for the collection of information review all of the information and documentation assembled in support of the EV Certificate application and look for discrepancies or other details requiring further explanation. (2) The CA MUST obtain and document further explanation or clarification from the Applicant, Certificate Approver, Certificate Requester, Qualified Independent Information Sources, and/or other sources of information, as necessary, to resolve those discrepancies or details that require further explanation. (3) The CA MUST refrain from issuing an EV Certificate until the entire corpus of information and documentation assembled in support of the EV Certificate Request is such that issuance of the EV Certificate will not communicate factual information that the CA knows, or the exercise of due diligence should discover from the assembled information and documentation, to be inaccurate,. If satisfactory explanation and/or additional documentation are not received within a reasonable time, the CA MUST decline the EV Certificate Request and SHOULD notify the Applicant accordingly. 35

- 103 -

(4) In the case where some or all of the documentation used to support the application is in a language other than the CAs normal operating language, the CA or its Affiliate MUST perform the requirements of this Final Cross-Correlation and Due Diligence section using employees under its control and having appropriate training, experience, and judgment in confirming organizational identification and authorization and fulfilling all qualification requirements contained in Section 14.1 of these Guidelines. When employees under the control of the CA do not possess the language skills necessary to perform the Final Cross-Correlation and Due Diligence a CA MAY: (A) Rely on language translations of the relevant portions of the documentation, provided that the translations are received from a Translator; or (B) When the CA has utilized the services of an RA, the CA MAY rely on the language skills of the RA to perform the Final Cross-Correlation and Due Diligence, provided that the RA complies with Section 11.12, Subsections (1), (2) and (3). Notwithstanding the foregoing, prior to issuing the EV Certificate, the CA MUST review the work completed by the RA and determine that all requirements have been met; or (C) When the CA has utilized the services of an RA, the CA MAY rely on the RA to perform the Final Cross-Correlation and Due Diligence, provided that the RA complies with this section and is subjected to the Audit Requirements of Sections 17.5 and 17.6. In the case of Enterprise EV Certificates to be issued in compliance with the requirements of Section 14.2 of these Guidelines, the Enterprise RA MAY perform the requirements of this Final Cross-Correlation and Due Diligence section.

11.13 Requirements for Re-use of Existing Documentation 11.13.1 For Validated Data
(1) The age of validated data used to support issuance of an EV Certificate (before revalidation is required) SHALL NOT exceed the following limits: (A) Legal existence and identity thirteen months; (B) Assumed name thirteen months; (C) Address of Place of Business thirteen months, but thereafter data MAY be refreshed by checking a Qualified Independent Information Source, even where a site visit was originally required; (D) Telephone number for Place of Business thirteen months; (E) Bank account verification thirteen months; (F) Domain Name thirteen months; (G) Identity and authority of Certificate Approver thirteen months, unless a contract is in place between the CA and the Applicant that specifies a different term, in which case, the term specified in such contract will control. For example, the contract MAY use terms that allow the assignment of roles that are perpetual until revoked, or until the contract expires or is terminated. (2) The age of information used by the CA to verify such an EV Certificate Request MUST NOT exceed the Maximum Validity Period for such information set forth above in subsection (1), based on the date the information was last updated by the QIIS, QGIS, or QTIS (e.g., if an online database was accessed by the CA on July 1, but contained data last updated by the QIIS, QGIS, or QTIS on February 1 of the same year, then the date on which the information was obtained would be considered to be February 1). (3) The CA MAY issue multiple EV Certificates listing the same Subject and based on a single EV Certificate Request, subject to the aging and updating requirement stated above. (4) Each EV Certificate issued by the CA MUST be supported by a valid current EV Certificate Request and a Subscriber Agreement signed by the appropriate Applicant Representative on behalf of the Applicant or Terms of Use acknowledged by the appropriate Applicant Representative. (5) In the case of outdated information, the CA MUST repeat the verification processes required in these Guidelines. 36

- 104 -

11.13.2 Validation for Existing Subscribers

In conjunction with an EV Certificate Request placed by an Applicant who is already a customer of the CA, the CA MUST perform all authentication and verification tasks required by these Guidelines to ensure that the request is properly authorized by the Applicant and that the information in the EV Certificate will still be accurate and valid.

11.13.3 Exceptions
Notwithstanding the requirements set forth in Section Error! Reference source not found., when performing the authentication and verification tasks for issuing an EV Certificate where the Applicant has a current valid EV Certificate issued by the CA, a CA MAY: (1) Rely on its prior authentication and verification of: (A) The Principal Individual of a Business Entity under Section 11.2.2 (4) if the Principal Individual is the same as the Principal Individual verified by the CA in connection with the previously issued EV Certificate; (B) The Applicant's Place of Business under Section 11.4.1; (C) The telephone number of the Applicant's Place of Business required by Section 11.4.2, but still MUST perform the verification required by Section 11.4.2 (2)(A); (D) The Applicant's Operational Existence under Section 11.5; (E) The name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester under Section 11.7, except where a contract is in place between the CA and the Applicant that specifies a specific term for the authority of the Contract Signer, and/or the Certificate Approver, and/or Certificate Requester in which case, the term specified in such contract will control; (F) The email address used by the CA for independent confirmation from the Applicant under Section 11.10.4 (1)(B)(ii); (2) Rely on a prior Verified Legal Opinion or Accountant Letter that established: (A) The Applicant's exclusive right to use the specified Domain Name under Section 11.6.2 (2)(A)(i) and Section 11.6.2 (2)(B)(i), provided that the CA verifies that either: (i) The WHOIS record still shows the same registrant as indicated when the CA received the prior Verified Legal Opinion or Verified Accountant Letter, or (ii) The Applicant establishes domain control via a practical demonstration as detailed in Section 11.6.2(2)(B)(ii). (B) That the Applicant is aware that it has exclusive control of the Domain Name, under Section 11.6.1 (3).

11.13.4 Validation of Re-issuance Requests

A CA may rely on previously verified information to issue a replacement certificate where: (1) The expiration date of the replacement certificate is the same as the expiration date of the currently valid EV Certificate that is being replaced, and (2) The Subject of the Certificate is the same as the Subject in the currently valid EV Certificate that is being replaced.

12 Certificate Issuance by a Root CA

Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation. Root CA Private Keys MUST NOT be used to sign EV Certificates. 37

- 105 -

13 Certificate Revocation and Status Checking

The requirements in Section 13 of the Baseline Requirements apply equally to EV Certificates. However, CAs MUST ensure that CRLs for an EV Certificate chain can be downloaded in no more than three (3) seconds over an analog telephone line under normal network conditions.

14 Employee and third party issues 14.1 Trustworthiness and Competence 14.1.1 Identity and Background Verification
Prior to the commencement of employment of any person by the CA for engagement in the EV Processes, whether as an employee, agent, or an independent contractor of the CA, the CA MUST: (1) Verify the Identity of Such Person: Verification of identity MUST be performed through: (A) The personal (physical) presence of such person before trusted persons who perform human resource or security functions, and (B) The verification of well-recognized forms of government-issued photo identification (e.g., passports and/or drivers licenses); and (2) Verify the Trustworthiness of Such Person: Verification of trustworthiness SHALL include background checks, which address at least the following, or their equivalent: (A) Confirmation of previous employment, (B) Check of professional references; (C) Confirmation of the highest or most-relevant educational qualification obtained; (D) Search of criminal records (local, state or provincial, and national) where allowed by the jurisdiction in which the person will be employed; and (3) In the case of employees already in the employ of the CA at the time of adoption of these Guidelines whose identity and background has not previously been verified as set forth above, the CA SHALL conduct such verification within three months of the date of adoption of these Guidelines.

14.1.2 Training and Skills Level

The requirements in Section 14.1.2 of the Baseline Requirements apply equally to EV Certificates and these Guidelines. The required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines.

14.1.3 Separation of Duties

(1) The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in Section 11.12, MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. (2) Such controls MUST be auditable. 38

- 106 -

14.2 Delegation of Functions to Registration Authorities and Subcontractors 14.2.1 General

The CA MAY delegate the performance of all or any part of a requirement of these Guidelines to an Affiliate or a Registration Authority (RA) or subcontractor, provided that the process employed by the CA fulfills all of the requirements of Section 11.12. Affiliates and/or RAs must comply with the qualification requirements of Section 14.1 of these Guidelines. The CA SHALL verify that the Delegated Third Partys personnel involved in the issuance of a Certificate meet the training and skills requirements of Section 14 and the document retention and event logging requirements of Section 15.

14.2.2 Enterprise RAs

The CA MAY contractually authorize the Subject of a specified Valid EV Certificate to perform the RA function and authorize the CA to issue additional EV Certificates at third and higher domain levels that are contained within the domain of the original EV Certificate (also known as an Enterprise EV Certificate). In such case, the Subject SHALL be considered an Enterprise RA, and the following requirements SHALL apply: rprise RA SHALL NOT authorize the CA to issue an Enterprise EV Certificate at the third or higher domain levels to any Subject other than the Enterprise RA or a business that is owned or directly controlled by the Enterprise RA; ect of an Enterprise EV Certificate MUST be an organization verified by the CA in accordance with these Guidelines; monitor compliance by the Enterprise RA; -Correlation and Due Diligence requirements of Section 11.12 of these Guidelines MAY be performed by a single person representing the Enterprise RA; and nterprise RA, except in the case where the CA maintains control over the Root CA Private Key or Subordinate CA Private Key used to issue the Enterprise EV Certificates, in which case, the Enterprise RA MAY be exempted from the audit requirements.

14.2.3 Guidelines Compliance Obligation

In all cases, the CA MUST contractually obligate each Affiliate, RA, subcontractor, and Enterprise RA to comply with all applicable requirements in these Guidelines and to perform them as required of the CA itself. The CA SHALL enforce these obligations and internally audit each Affiliates, RAs, subcontractors, and Enterprise RAs compliance with these Requirements on an annual basis.

14.2.4 Allocation of Liability

As specified in Section 14.2.4 of the Baseline Requirements.

15 Data Records
As specified in Section 15 of the Baseline Requirements.

16 Data Security
As specified in Section 16 of the Baseline Requirements. In addition, systems used to process and approve EV Certificate Requests MUST require actions by at least two trusted persons before creating an EV Certificate. 39

- 107 -

17 Audit 17.1 Eligible Audit Schemes

A CA issuing EV Certificates SHALL undergo an audit in accordance with one of the following schemes: (i) WebTrust Program for CAs audit and WebTrust EV Program audit, or (ii) ETSI TS 102 042 v2.1.1 audit. If the CA is a Government Entity, an audit of the CA by the appropriate internal government auditing agency is acceptable in lieu of the audits specified above, provided that such internal government auditing agency publicly certifies in writing that its audit addresses the criteria specified in one of the above audit schemes and certifies that the government CA has successfully passed the audit. EV audits MUST cover all CA obligations under these Guidelines regardless of whether they are performed directly by the CA or delegated to an RA or subcontractor.

17.2 Audit Period

CAs issuing EV Certificates MUST undergo an annual audit that meets the criteria of Section 17.1.

17.3 Audit Record

CAs SHOULD make its audit report publicly available no later than three months after the end of the audit period. If there is a delay greater than three months and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor.

17.4 Pre-Issuance Readiness Audit

(1) If the CA has a currently valid WebTrust Seal of Assurance for CAs, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete a point-in-time readiness assessment audit against the WebTrust EV Program. (2) If the CA has a currently valid ETSI 102 042 audit, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete a point-in-time readiness assessment audit against ETSI TS 102 042 V2.1.1. (3) If the CA does not have a currently valid WebTrust Seal of Assurance for CAs or an ETSI 102 042 audit, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete either: (i) a point-in-time readiness assessment audit against the WebTrust for CA Program, or (ii) a point-in-time readiness assessment audit against the WebTrust EV Program, or an ETSI TS 102 042 V2.1.1. audit. The CA MUST complete any required point-in-time readiness assessment no earlier than twelve (12) months prior to issuing an EV Certificate. The CA MUST undergo a complete audit under such scheme within ninety (90) days of issuing the first EV Certificate.

17.5 Regular Self Audits

During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. For all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of Section 11.12 of these Guidelines is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken.

17.6 Auditor Qualification

A Qualified Audit (as defined in Section 17.6 of the Baseline Requirements) MUST perform the CAs audit. 40

- 108 -

17.7 Root CA Key Pair Generation

All requirements in Section 17.7 of the Baseline Requirements apply equally to EV Certificates. However, for Root CA Key Pairs generated after the release of these Guidelines, the Root CA Key Pair generation ceremony MUST be witnessed by the CAs Qualified Auditor in order to observe the process and the controls over the integrity and confidentiality of the Root CA Key Pairs produced. The Qualified Auditor MUST then issue a report opining that the CA, during its Root CA Key Pair and Certificate generation process: its Certification Practices Statement; easonable assurance that the Root CA key pair was generated and protected in conformity with the procedures described in its CP/CPS and with its Root Key Generation Script; ired by its Root Key Generation Script.

18 Liability and Indemnification

CAs MAY limit their liability as described in Section 18 of the Baseline Requirements except that a CA MAY NOT limit its liability to Subscribers or Relying Parties for legally recognized and provable claims to a monetary amount less than two thousand US dollars per Subscriber or Relying Party per EV Certificate. A CA's indemnification obligations and a Root CAs obligations with respect to subordinate CAs are set forth in the Baseline Requirements. 41

- 109 -

Appendix A - User Agent Verification (Normative)

The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. At a minimum, the CA MUST host separate Web pages using certificates that are (i) valid (ii) revoked and (iii) expired. 42

- 110 -

Appendix B - Sample Legal Opinion Confirming Specified Information (Informative)

[Law Firm Letterhead] [Date] To: [Name of Issuing Certification Authority] [Address / fax number of Issuing CA may be sent by fax or email attachment] EV Certificate Request No. [CA Reference Number] [Exact company name of Client see footnote 1] [Exact name of Client Representative who signed the Application see footnote 2] [Insert date of Clients Application to the Issuing CA,]

Re: Client: Client Representative: Application Date:

- 111 -

Appendix B2
Minimum Cryptographic Algorithm and Key Sizes for EV Certificates 1. Root CA Certificates
Digest algorithm RSA ECC Minimum strength of algorithm SHA-1*, SHA-256, SHA-384 or SHA-512 2048 bit 256 or 384 bits

2. Subordinate CA Certificates
Digest algorithm RSA ECC Minimum strength of algorithm SHA-1*, SHA-256, SHA-384 or SHA-512 2048 bit 256 or 384 bits

3. Subscriber Certificates
Digest algorithm RSA ECC Minimum strength of algorithm SHA1*, SHA-256, SHA-384 or SHA-512 2048 bit 256 or 384 bits

*SHA-1 shall be used until SHA-256 is supported widely by browsers used by a majority of Relying Parties worldwide.

- 112 -

Appendix B3
EV Certificates Required Certificate Extensions 1. Root CA Certificate Root certificates generated after October 2006 MUST be X.509 v3. (a) basicConstraints If the certificate is v3 and is created after October 2006, this extension MUST appear as a critical extension in all CA certificates that contain Public Keys used to validate digital signatures on certificates. The CA field MUST be set true. The pathLenConstraint field SHOULD NOT be present. (b) keyUsage If the certificate is v3 and is created after October 2006, this extension MUST be present and MUST be marked critical. Bit positions for CertSign and cRLSign MUST be set. All other bit positions SHOULD NOT be set. (c) certificatePolicies This extension SHOULD NOT be present. (d) extendedKeyUsage This extension is not present. All other fields and extensions are set in accordance to RFC 5280. 2. Subordinate CA Certificate (a) certificatePolicies MUST be present and SHOULD NOT be marked critical. The set of policy identifiers MUST include the identifier for Symantecs EV policy. certificatePolicies:policyIdentifier (Required) o the anyPolicy identifier if subordinate CA is controlled by Symantec (b) cRLDistributionPoint is always present and NOT marked critical. It contains the HTTP URL of Symantecs CRL service. (c) authorityInformationAccess MUST be present and MUST NOT be marked critical. SHALL contain the HTTP URL of the Issuing CAs OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). An HTTP accessMethod SHOULD be included for Symantecs certificate (accessMethod = 1.3.6.1.5.5.7.48.2). (d) basicConstraints This extension MUST be present and MUST be marked critical in all CA certificates that contain Public Keys used to validate digital signatures on certificates. The CA field MUST be set true. The pathLenConstraint field MAY be present. (e) keyUsage This extension MUST be present and MUST be marked critical. Bit positions for CertSign and cRLSign MUST be set. All other bit positions MUST NOT be set.

- 113 -

All other fields and extensions MUST be set in accordance to RFC 5280. 3. Subscriber Certificate (a) certificatePolicies MUST be present and SHOULD NOT be marked critical. The set of policyIdentifiers MUST include the identifier for Symantecs EV policy. certificatePolicies:policyIdentifier (Required) o EV policy OID certificatePolicies:policyQualifiers:policyQualifierId (Required) o id-qt 2 [RFC 5280] certificatePolicies:policyQualifiers:qualifier (Required) o URI to the Certificate Practice Statement (b) cRLDistributionPoint is always present and NOT marked critical. It contains the HTTP URL of Symantecs CRL service. (c) authorityInformationAccess is always present and NOT marked critical. SHALL contain the HTTP URL of Symantecs OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). An HTTP accessMethod MAY be included for Symantecs certificate (accessMethod = 1.3.6.1.5.5.7.48.2). (d) basicConstraints (optional) If present, the CA field MUST be set false. (e) keyUsage (optional) If present, bit positions for CertSign and cRLSign MUST NOT be set. (f) extKeyUsage Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present. Other values SHOULD NOT be present. (f) SubjectAltName populated in accordance with RFC5280 and criticality is set to FALSE. All other fields and extensions set in accordance to RFC 5280.

- 114 -

Appendix B4
Foreign Organization Name Guidelines NOTE: This appendix is only relevant to EV applications from countries that do not have Latin character organization name registrations. More specific information for particular countries may be added to this appendix in the future. Where an EV Applicant's organization name is not registered with a QGIS in Latin characters and the applicant's foreign character organization name and registration have been verified with a QGIS in accordance with these Guidelines, Symantec MAY include a Latin character organization name in the EV certificate. In such a case, Symantec will follow the procedures laid down in this appendix. Romanized Names In order to include a transliteration/Romanization of the registered name, the Romanization will be verified by Symantec using a system officially recognized by the Government in the Applicant's jurisdiction of incorporation. If Symantec can not rely on a transliteration/Romanization of the registered name using a system officially recognized by the Government in the Applicant's jurisdiction of incorporation, then it MUST rely on one of the options below, in order of preference: A system recognized by the International Standards Organization (ISO), A system recognized by the United Nations or A Lawyers Opinion confirming the Romanization of the registered name.

English Name In order to include a Latin character name that is not a Romanization of the registered name in the EV certificate, Symantec will verify that the Latin character name is: Included in the Articles of Incorporation (or equivalent document) filed as part of the organization registration, or Recognized by a QGTIS in the Applicant's Jurisdiction of Incorporation as the applicant's recognized name for tax filings, or Confirmed with a QIIS to be the name associated with the registered organization, or Confirmed by a lawyer's opinion letter to be the trading name associated with the registered organization.

Country Specific Procedures F-1. Japan In addition to the procedures set out above: The Hepburn method of Romanization is acceptable for Japanese Romanizations. Symantec MAY verify the Romanized transliteration of Applicant's formal legal name with either a QIIS or a lawyer's opinion letter. Symantec MAY use the Financial Services Agency to verify an English Name. When used, Symantec will verify that the English name is recorded in the audited Financial Statements filed with the Financial Services Agency. When relying on Articles of Incorporation to verify an English Name, the Articles of Incorporation MUST be accompanied either: by a document, signed with the original Japanese Corporate Stamp, that proves that the Articles of Incorporation are authentic and current, or by a lawyer's opinion letter. Symantec will verify the authenticity of the Corporate Stamp.

- 115 -

Appendix C
Supplemental Validation Procedures for Extended Validation (EV) Code-Signing Certificates
Reference: CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation (EV) Code Signing Certificates, www.cabforum.org . Table of Contents
1 Scope 2 Purpose 3 References 4 Definitions 5 Abbreviations and Acronyms 6 Conventions 7 Certificate Warranties and Representations 7.1 EV Code Signing Certificate Warranties 7.2 By the Applicant 8 Community and Applicability 8.1 Issuance of EV Code Signing Certificates 8.2 EV Code Signing Policies 8.3 Commitment to Conform with Recommendations 8.4 Insurance 8.5 Obtaining EV Code Signing Certificates 9 EV Certificate Content and Profile 9.1 Issuer Information 9.2 Subject Information 9.2.1 Subject Organization name 9.2.2 Subject Alternate name Extension 9.2.3 Common name 9.2.4 Subject Business Category 9.2.5 Subject Jurisdiction of Incorporation or Registration 9.2.6 Subject Registration Number 9.2.7 Subject Physical Address of Place of Business 9.2.8 Other Subject Attributes 9.3 Certificate Policy Identification 9.4 Maximum Validity Period For EV Code Signing Certificate 9.5 Subscriber Public Key 9.6 Certificate Serial Number 9.7 Additional Technical Requirements for EV Code Signing Certificates 10 EV Code Signing Certificate Request Requirements 10.1 General Requirements 10.2 EV Code Signing Certificate Request Requirements 10.3 Requirements for Subscriber Agreement and Terms of Use 10.3.1 General 10.3.2 Agreement Requirements 11 Verification Requirements 11.1 General Overview 11.2 Verification of Applicants Legal Existence and Identity 11.3 Verification of Applicants Legal Existence and Identity Assumed Name 11.4 Verification of Applicants Physical Existence 11.5 Verification of Applicants Operational Existence 11.6 Verification of Applicants Domain Name 11.7 Verification of Name, Title, and Authority of Contract Signer and Certificate Approver 11.8 Verification of Signature on Subscriber Agreement and EV Code Signing Certificate Requests 11.9 Verification of Approval of EV Code Signing Certificate Request 11.10 Verification of Certain Information Sources

- 116 -

11.11 Other Verification Requirements 11.12 Final Cross-Correlation and Due Diligence 11.13 Requirements for Re-use of Existing Documentation 12 Certificate Issuance by a Root CA 13 Certificate Revocation and Status Checking 14 Employee and third party issues 14.1 Trustworthiness and Competence 14.2 Delegation of Functions to Registration Authorities and Subcontractors 15 Data Records 16 Data Security 17 Audit 17.1 Eligible Audit Schemes 17.2 Audit Period 17.3 Audit Record 17.4 Pre-Issuance Readiness Audit 17.5 Regular Self Audits 17.6 Auditor Qualification 17.7 Root CA Key Pair Generation 18 Liability and Indemnification

- 117 -

1. Introduction
These procedures for Extended Validation Certificates document supplemental procedures to Symantecs currently published CPS procedures for issuing Extended Validation Certificates (EV Certificates) in terms of the Guidelines for Extended Validation Certificates (Guidelines). The Guidelines describe certain of the minimum requirements that a Certificate Authority (CA) must meet in order to issue Extended Validation Certificates (EV Certificates) used for EV signatures in code-signing. Such EV code-signing attests to only one level of assurance in code. Subject Organization information from Valid EV Code Signing Certificates may be displayed in a special manner by certain relying-party software applications in order to provide users with a trustworthy confirmation of the identity of the entity providing the code signing services.

2. Purpose
2.1 Purpose of EV Code Signing Certificates
EV Code Signing (EV CS) Certificates and signatures are intended to be used to verify the identity of the certificate holder (Subscriber) and the integrity of its code. They provide assurance to a user or platform provider that code verified with the certificate has not been modified from its original form and is distributed by the legal entity identified in the EV Code Signing Certificate by name, Place of Business address, Jurisdiction of Incorporation or Registration, and other information. EV Code Signing Certificates may help to establish the legitimacy of signed code, help to maintain the trustworthiness of software platforms, help users to make informed software choices, and limit the spread of malware. The EV Code Signing Certificate does not identify a particular software object, but only its distributor.

2.1.1 Secondary Purposes

As specified in Section 2.1, Appendix B1, EV SSL Certificates.

2.1.2 Excluded Purposes

EV CS Certificates focus only on assuring the identity of the Subscriber and that the signed code has not been modified from its original form. EV Code Signing Certificates are not intended to provide any other assurances, representations, or warranties. Specifically, EV Code Signing Certificates do not warrant that code is free from vulnerabilities, malware, bugs, or other problems. EV Code Signing Certificates do not warrant or represent that: i. The Subject named in the EV Code Signing Certificate is actively engaged in doing business; ii. The Subject named in the EV Code Signing Certificate complies with applicable laws; iii. The Subject named in the EV Code Signing Certificate is trustworthy, honest, or reputable in its business dealings; or iv. It is safe to install code distributed by the Subject named in the EV Code Signing Certificate.

3. References
Refer to References provided in the CA/Browser Forum EV Code-Signing Guidelines located at http://cabforum.org/documents.html.

- 118 -

4. Definitions
Refer to Definitions provided in the CA/Browser Forum EV Code-Signing Guidelines located at http://cabforum.org/documents.html.

5. Abbreviations and Acronyms

Refer to Abbreviations and Acronyms provided in the CA/Browser Forum EV Code-Signing Guidelines located at http://cabforum.org/documents.html.

6. Conventions
No stipulation.

7. Certificate Warranties and Representations

7.1 EV Code Signing Certificate Warranties
When Symantec issues an EV Code Signing Certificate, the Symantec Issuing and Root CA represents and warrants to the Certificate Beneficiaries listed in Section 7.1.1, Appendix D, Supplemental Baseline Requirements, during the period when the EV Code Signing Certificate is Valid, that Symantec has followed the requirements of these Guidelines and its EV Policies in issuing and managing the EV Code Signing Certificate and in verifying the accuracy of the information contained in the EV Code Signing Certificate. These warranties specifically include, but are not limited to, the following: (A) Legal Existence: Symantec has confirmed with the Incorporating or Registration Agency in the Subjects Jurisdiction of Incorporation or Registration that, as of the date the EV Code Signing Object was issued, the Subject of the EV Code Signing Object legally exists as a valid organization or entity in the Jurisdiction of Incorporation or Registration; (B) Identity: Symantec has confirmed that, as of the date the EV Code Signing Object was issued, the legal name of the Subject named in the EV Code Signing Object matches the name on the official government records of the Incorporating or Registration Agency in the Subjects Jurisdiction of Incorporation or Registration, and if an assumed name is also included, that the assumed name is properly registered by the Subject in the jurisdiction of its Place of Business; (C) Authorization for EV Code Signing Certificate: Symantec has taken all steps reasonably necessary to verify that the Subject of the EV Code Signing Object authorized the issuance of the EV Code Signing Object; (D) Accuracy of Information: Symantec has taken all steps reasonably necessary to verify that all of the other information in the EV Code Signing Object is accurate, as of the date of issuance; (E) Subscriber Agreement: The Subject of the EV Code Signing Object has entered into a legally valid and enforceable Subscriber Agreement with Symantec that satisfies the requirements of these Guidelines or, if they are affiliated, the Applicant Representative has acknowledged and accepted the Terms of Use; (F) Status: The Issuer will follow the requirements of these Guidelines and maintain a 24 x 7 online-accessible Repository with current information regarding the status of the EV Code

- 119 -

Signing Object as Valid or revoked; and (G) Revocation: Symantec will follow the requirements of these Guidelines and revoke the EV Code Signing Object for any of the revocation reasons specified in these Guidelines.

7.2 By the Applicant

Applicants make the commitments and warranties set forth in Section 10.3.2 of this Appendix for the benefit of the Issuer and the Certificate Beneficiaries.

8. Community and Applicability

8.1 Issuance of EV Code Signing Certificates
When issuing EV CS Certificates, Symantec shall at all times satisfy the requirements as required by the Guidelines and set forth in this Appendix. Symantec shall at all times conform with all laws applicable to its business and the certificates it issues in each jurisdiction where it operates. Symantec shall notify the CA / Browser Forum of any occasions whereby a court or government body with jurisdiction over the activities (operations or certificate issuances) that are covered by the Guidelines determines that the performance of any mandatory requirement is deemed illegal subject to the laws of that jurisdiction..

8.2 EV Code Signing Policies 8.2.1 Implementation

The STN CPS, together with this Supplemental Appendix C to the STN CPS: Implements the requirements of the Guidelines as they are revised from time-to-time; Implements the requirements of (i) the then current WebTrust Program for CAs, and (ii) the then-current WebTrust EV Program, or an equivalent for both (i) and (ii) as approved by the CA/Browser Forum; Specifies Symantecs entire root certificate hierarchy including all ro ots that its EV Certificates depend on for proof of those EV Certificates authenticity. Symantecs root hierarchy structure is available at www.symauth.com/repository/hierarchy/hierarchy.pdf

8.2.2 Disclosure
Symantec publicly discloses its EV Policies through this CPS that is available on a 24x7 basis from the Symantec online repository. The STN CPS is structured according to the RFC 3647 format. Symantec publicly discloses its CA business practices through an annual WebTrust for CAs Audit in accordance with section 8 of this CPS.

8.3 Commitment to Conform with Recommendations

Symantec conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Code Signing Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document.

- 120 -

In addition, Symantec includes (directly or by reference) the applicable requirements of these Guidelines in all contracts with subordinate CA, RAs, Enterprise RAs, and subcontractors, that involve or relate to the issuance or maintenance of EV Code Signing Certificates. Symantec will enforce compliance with such terms.

8.4 Insurance
Symantec maintains insurance as specified in Section 8.4, Appendix B1, EV SSL Certificates.

8.5 Obtaining EV Code Signing Certificates

Symantec only issues EV Code Signing Certificates to Applicants that meet the requirements specified in Section 8.5, Appendix B1, EV SSL Certificates.

9. EV Certificate Content and Profile

This section sets forth minimum requirements for the content of the EV Code Signing Certificate as they relate to the identity of the CA and the Subject of the EV Code Signing Certificate.

9.1 Issuer Information

An EV Code Signing Certificate MUST include Issuer information as specified by Baseline Requirements for publicly trusted Certificates and set forth in Section 9.1Issuer Information, Appendix D, Supplemental Baseline Requirements.

9.2 Subject Information

EV Code Signing Objects issued to Subscribers MUST include the following information about the Subject organization in the fields listed:

9.2.1 Subject Organization Name Field

As specified in Section 9.2.1, Appendix B1, EV SSL Certificates.

9.2.2 Subject Alternative Name Extension

This field should not be included in the EV Code Signing Objects.

9.2.3 Subject Common Name Field

Certificate field: subject:commonName (OID: 2.5.4.3) Required/Optional: Deprecated (Discouraged, but not prohibited) Contents: If present, this field MUST NOT contain a Domain Name.

9.2.4 Subject Business Category Field

As specified in Section 9.2.4, Appendix B1, EV SSL Certificates.

9.2.5 Subject Jurisdiction of Incorporation or Registration Field

As specified in Section 9.2.5, Appendix B1, EV SSL Certificates.

- 121 -

9.2.6 Subject Registration Number Field

As specified in Section 9.2.6, Appendix B1, EV SSL Certificates.

9.2.7 Subject Physical Address of Place of Business Field

As specified in Section 9.2.7, Appendix B1, EV SSL Certificates.

9.2.8 Other Subject Attributes

All other optional attributes, when present within the subject field, MUST contain information that has been verified by Symantec. Optional subfields within the Subject field MUST either contain information verified by the Issuer or MUST be left empty. Metadata such as ., -, and characters, and/or any other indication that the field is empty, absent or incomplete, MUST not be used.

9.3 Certificate Policy Identification

As specified in Section 9.3, Appendix B1, EV SSL Certificates.

9.4 Maximum Validity Period For EV Code Signing Certificate

The validity period for an EV Code Signing Certificate issued to a Subscriber MUST NOT exceed thirty-nine (39) months.

9.5 Subscriber Public Key

Symantec Certificates meet the requirements for algorithm type and key size as set forth in section 6.1.5 of this CPS. Also see Appendix B2 for minimum cryptographic algorithm and key sizes.

9.6 Certificate Serial Number

Symantec CAs generate non-sequential certificate serial numbers that exhibit at least 20 bits of entropy.

9.7 Additional Technical Requirements for EV Code Signing Certificates

As specified in Section 9.7, Appendix B1, EV SSL Certificates, with the following exceptions: (A) the Domain Name as required for EV SSL Certificates SHALL be omitted; (B) the Certificate MUST include a SubjectAltName:permanentIdentifier which MUST contain the following: 1) The ISO 3166-2 country code corresponding Subjects Jurisdiction of Incorporation or Registration (CC), as specified in the subject:jurisdictionOfIncorporationCountryName field; 2) If applicable, the state, province, or locality of the Subjects Jurisdiction of Incorporation in uppercase characters as specified in the subjectjurisdictionOfIncorporationLocalityName or subject:jurisdictionofIncorporationStateorProvinceName field, expressed in an unabbreviated format (STATE);

- 122 -

3) The first one of the following that applies: a. The Registration Number as included in the Subject:serialNumber field (REG), or b. A date of Incorporation or Registration in YYYY-MM-DD format (DATE) and the Subjects Organization Name as included in the organizationName field (ORG), or c. A verifiable date of creation in YYYY-MM-DD format (DATE) and the Subjects Organization Name as included in the organizationName field (ORG), or d. the Subjects Organization Name as included in the organizationName field (O). Symantec formats data in the SubjectAltName:permanentIdentifier extension using Unicode as follows: CC-STATE (if applicable)- REG or DATE (if available)-ORG (if REG is not present). Characters representing the organization name MUST be uppercase Unicode. Any included - characters MUST be Unicode 002D and any included spaces in REG, STATE, or ORG MUST be Unicode 0020. Symantec MAY truncate or abbreviate an organization name included in this field to ensure that the combination does not exceed 64 characters provided that Symantec has checked this field in accordance with section 11, Appendix B1, EV SSL Certificates such that a Relying Party will not be misled into thinking that they are dealing with a different organization. If this is not possible, Symantec MUST NOT issue the EV Code Signing Certificate. (C) the keyUsage extension MUST be set as follows: This extension MUST be present and MUST be marked critical. The bit position for digitalSignature MUST be set. All other bit positions SHOULD NOT be set; AND (D) the extended keyUsage extension MUST be set as follows: This extension MUST be present, and the value id-kp-codeSigning MUST be present. Other values SHOULD NOT be present.

10. EV Code Signing Certificate Request Requirements

10.1 General Requirements
As specified in Section 10.1 of Appendix B1, EV SSL Certificates.

10.2 EV Code Signing Certificate Request Requirements

As specified in Section 10.2 of Appendix B1, EV SSL Certificates.

10.3 Requirements for Subscriber Agreement and Terms of Use 10.3.1 General
Prior to issuing an EV Code Signing Certificate, Symantec obtains, for the express benefit of the Issuer and the Certificate Beneficiaries, either: 1. The Applicants agreement to the Subscriber Agreement with the Issuer, or 2. The Applicants agreement to the Terms of Use agreement. Prior to the issuance of the EV Code Signing Certificate, Symantec obtains the Applicants agreement to a legally enforceable Subscriber Agreement for the express benefit of Relying Parties and Application Software Vendors. The Subscriber Agreement must be signed by an authorized Contract Signer acting on behalf of the Applicant, and must apply to the EV Code Signing Certificate to be issued pursuant to the Certificate Request. A separate Subscriber

- 123 -

Agreement may be used for each Certificate Request, or a single Subscriber Agreement may be used to cover multiple future Certificate Requests and resulting Certificates.

10.3.2 Agreement Requirements

The Applicants agreement to the Subscriber Agreement shall, at a minimum, specifically name both the Applicant and the individual Contract Signer signing the Agreement on the Applicants behalf. The Subscriber Agreement shall contain, among other things, provisions imposing on the Applicant the following obligations and warranties: 1. Accuracy of Information: An obligation and warranty to provide accurate and complete information at all times to Symantec, both in the certificate request and as otherwise requested by Symantec in connection with the issuance of the Certificate(s) to be supplied by Symantec; 2. Protection of Private Key: An obligation and warranty by the Applicant to take all reasonable measures to maintain sole control of, keep confidential, and properly protect at all times the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token); 3. Acceptance of Certificate: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy; 4. Use of the Certificate: An obligation and warranty to not knowingly sign software that contains Suspect Code and use the EV Code Signing Certificate as follows: a. only to sign code that complies with the requirements set forth in these Guidelines; b. solely in compliance with all applicable laws; c. solely for authorized company business; and d. solely in accordance with the Subscriber Agreement; 5. Reporting and Revocation: An obligation and warranty to promptly cease using a Certificate and its associated Private Key, and promptly request Symantec to revoke the Certificate, in the event that: a. there is evidence that the certificate was used to sign suspect code; b. any information in the Certificate is, or becomes, incorrect or inaccurate; or c. there is any actual or suspected misuse or compromise of either the key activation data or the Subscribers Private Key associated with th e Public Key included in the Certificate; 6. Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise. 7. Responsiveness: An obligation to respond to Symantecs instructions concerning Key Compromise or Certificate misuse within a specified time period. 8. Acknowledgment and Acceptance: An acknowledgment and acceptance that Symantec is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber or Terms of Use Forum Guideline Agreement or if Symantec discovers that the Certificate is being used to enable criminal activities such as phishing attacks, fraud, or the distribution of malware.

- 124 -

11. Verification Requirements

11.1 General Overview
This section sets forth Verification Requirements and Acceptable Methods of Verification for each such Requirement and the procedures used by Symantec to satisfy the requirements. Before issuing an EV Code Signing Certificate, Symantec ensures that all Subject organization information included in the EV Code Signing Certificate conforms to the requirements of, and has been verified in accordance with the EV Guidelines and matches the information confirmed and documented by Symantec pursuant to its verification processes set forth in sub-sections 11.2 through 11.13 following.

11.2 Verification of Applicants Legal Existence and Identity

As specified in Section 11.2 of Appendix B1, EV SSL Certificates.

11.3 Verification of Applicants Legal Existence and Identity Assumed Name

As specified in Section 11.3 of Appendix B1, EV SSL Certificates.

11.4 Verification of Applicants Physical Existence

As specified in Section 11.4 of Appendix B1, EV SSL Certificates.

11.5 Verification of Applicants Operational Existence

As specified in Section 11.5 of Appendix B1, EV SSL Certificates.

11.6 Verification of Applicants Domain Name

Code Signing Certificates SHALL NOT include a Domain Name.

11.7 Verification of Name, Title and Authority of Contract Signer and Certificate Approver
As specified in Section 11.7 of Appendix B1, EV SSL Certificates.

11.8 Verification of Signature on Subscriber Agreement and EV Code Signing Certificate Requests
As specified in Section 11.8 of Appendix B1, EV SSL Certificates.

11.9 Verification of Approval of EV Code Signing Certificate Request

As specified in Section 11.9 of Appendix B1, EV SSL Certificates.

11.10 Verification of Certain Information Sources

As specified in Section 11.10 of Appendix B1, EV SSL Certificates.

11.11 Other Verification Requirements

As specified in Section 11.11 of Appendix B1, EV SSL Certificates.

- 125 -

11.12 Final Cross-Correlation and Due Diligence

As specified in Section 11.12 of Appendix B1, EV SSL Certificates.

11.13 Requirements for Re-use of Existing Documentation

As specified in Sections 9.7 and 11.13 of Appendix B1, EV SSL Certificates.

12. Certificate Issuance by a Root CA

Symantec enforces multi-person controls for certificate issuance by the Root CA. The Root CA Private Keys are not used to sign EV Code Signing Certificates.

13. Certificate Revocation and Status Checking

As specified in Section 13 of Appendix B1, EV SSL Certificates, and additionally: (A) Revocation Reasons: Subscribers are expected to not intentionally include Suspect Code in their signed software. Intentionally signing Suspect Code is a violation of the terms of the Subscriber Agreement, and will likely result in revocation of the EV Code Signing Object. (B) Revocation Status Information: Symantec provides accurate and up-to-date revocation status information for at least one year following the expiration of the associated certificate, and, upon request, for a period not less than one year beyond expiry of the EV Code Signing Certificate. (C) Revocation Processing: Whenever practical, platforms should check the revocation status of the certificates that they rely upon. However, this is not always practical, for instance, when signed code has to be loaded earlier in the boot sequence than the network communication stack. In the timestamp model, the platform should deviate from the RFC 5280 certification path validation algorithm and check the revocation status, not only of the timestamp certificate, but also of the Subscribers EV Code Signing Certificate at the time of reliance rather than at the time the time-stamp was applied. In addition to checking revocation status, where practical, platforms should consult blacklists of suspect software. (D) Revocation Consequences: A certificate may have a one-to-one relationship with the software object that it verifies. In such cases, revocation of the certificate only invalidates the signature on the code that is suspect. If, on the other hand, a certificate has a one-to-many relationship with the software objects that it verifies, then revocation of the certificate invalidates the signatures on all those software objects, some of which may be perfectly sound. (E) Responsiveness. Symantec responds to all plausible notices of Suspect Code in a signed software object that verifies with a certificate that Symantec has issued, by setting the revocation status of that certificate to revoked.

- 126 -

14. Employee and Third Party Issues

14.1 Trustworthiness and Competence
As specified in Section 14.1 of Appendix B1, EV SSL Certificates.

14.2 Delegation of Functions to Registration Authorities and Subcontractors

Symantec shall not delegate the RA functions for EV Code Signing Certificates.

15. Data Records

Symantec records events in accordance with Section 15, Appendix D, Supplemental Baseline Requirements.

16. Data Security

Symantec implements a comprehensive security program in accordance with Section 16, Appendix D, Supplemental Baseline Requirements . In addition, Symantec requires actions by at least two trusted persons before creating an EV Code Signing Certificate. In addition: (1) not applicable. (2) not applicable. (3) Symantec CAs protect private keys in a FIPS 140-2 level 3 (or equivalent) crypto module as set forth in section 6.2.1 of this CPS. (4) Symantec ensures that the Subscribers private key is generated, stored and used in a crypto module that meets or exceeds the requirements of FIPS 140-2 level 2. Symantec ships the FIPS 140-2 level 2 crypto module along with necessary drivers to the Subscriber. The Subscriber installs the driver and visits the Symantec web page that generates keys only on a FIPS 140-2 level 2 device.

17. Audit
17.1 Eligible Audit Schemes
Symantec performs an annual WebTrust for Certification Authorities v2.0, or later, audit as set forth in section 8 of this CPS. Such audits will cover all CA obligations under the CA/Browser Forum Guidelines regardless of whether they are performed directly by Symantec or delegated to an RA or subcontractor.

17.2 Audit Period

See Section 17.1.

17.3 Audit Record

See Section 17.1.

- 127 -

17.4 Pre-Issuance Readiness Audit

Not applicable.

17.5 Regular Self-Audits

Symantec and Affiliates undergo self-audits to monitor adherence to its Certificate Policy and CPS requirements and strictly control its service quality on at least a quarterly basis against a randomly selected sample of the greater of one Certificate or at least 3% of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken. For all EV Code Signing Certificates where the Final Cross-Correlation and Due Diligence requirements of Section 11.12 of this Appendix is performed by an RA, Symantec strictly controls its service quality by performing ongoing self audits against a randomly selected sample of at least 6% of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken.

17.6 Auditor Qualification

A Qualified Auditor (as defined in Section 8.2 of this CPS) performs Symantecs annual audit.

17.7 Root CA Key Pair Generation

As specified in Section 17.7 of Appendix B1, EV SSL Certificates.

18. Liability and Indemnification

Symantec is subject to the liability and indemnification obligations as set forth in Section 18 of Appendix B1, EV SSL Certificates.

- 128 -

Appendix D
Supplemental Baseline Requirements for Issuance and Management of Publicly-Trusted Certificates
Reference: CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, www.cabforum.org . Table of Contents
1. 2. 3. 4. 5. 6. 7. Introduction Purpose References Definitions Abbreviations and Acronyms Conventions Certificate Warranties and Representations 7.1 By the CA 7.1.1 Certificate Beneficiaries 7.1.2 Certificate Warranties 7.2 By the Applicant 8. Community and Applicability 8.1 Compliance 8.2 Certificate Policies 8.3 Commitment to Conform 8.4 Trust Model 9. Certificate Content and Profile 9.1 Issuer Information 9.1.1 Issuer Common Name Field 9.1.2 Issuer Domain Component Field 9.2 Subject Information 9.2.1 Subject Alternate Name Extension (Required) 9.2.2 Subject Common Name Field (Optional) 9.2.3 Subject Domain Component Field (Optional) 9.2.4 Subject Organization Name Field (Optional) 9.2.5 Subject Country Name Field (Optional) 9.2.6 Other Subject Attributes 9.3 Certificate Policy Identification 9.3.1 Reserved Certificate Policy Identifiers 9.3.2 Root CA Certificates 9.3.3 Subordinate CA Certificate 9.3.4 Subscriber Certificate 9.4 Validity Period 9.5 Subscriber Public Key 9.6 Certificate Serial Number 9.7 Additional Technical Requirements 10. Certificate Application 10.1 Documentation Requirements 10.2 Certificate Request 10.2.1 General 10.2.2 Request and Certification 10.2.3 Information Requirements 10.2.4 Subscriber Private Key 10.3 Subscriber and Terms of Use Agreement 10.3.1 General 10.3.2 Agreement Requirements 11. Verification Practices

- 129 -

12. 13.

14.

15.

16.

17.

18.

11.1 Authorization by Domain Name Registrant 11.2 Verification of Subject Identity Information 11.2.1 Identity 11.2.2 DBA/Tradename 11.2.3 Authenticty of Certificate Request 11.2.4 Verification of Individual Applicant 11.2.5 Verification of Country 11.3 Age of Certificate Data 11.4 Denied List 11.5 High Risk Status 11.6 Data Source Accuracy Certificate Issuance by a Root CA Certificate Revocation and Status Checking 13.1 Revocation 13.1.1 Revocation Request 13.1.2 Certificate Problem Reporting 13.1.3 Investigation 13.1.4 Response 13.1.5 Reasons for Revocation 13.2 Certificate Status Checking 13.2.1 Mechanisms 13.2.2 Repository 13.2.3 Response Time 13.2.4 Deletion of Entries 13.2.5 OCSP Signing Employees and Third Parties 14.1 Trustworthiness and Competence 14.1.1 Identity and Background Verification 14.1.2 Training and Skill Level 14.2 Delegation of Functions 14.2.1 General 14.2.2 Compliance Obligation 14.2.3 Allocation of Liability 14.2.4 Enterprise RAs Data Records 15.1 Documentation and Event Logging 15.2 Events and Actions 15.3 Document Retention 15.3.1 Audit Log Retention 15.3.2 Retention of Documentation Data Security 16.1 Objectives 16.2 Risk Assessment 16.3 Security Plan 16.4 Business Continuity 16.5 System Security 16.6 Private Key Protection Audit 17.1 Eligible Audit Schemes 17.2 Audit Period 17.3 Audit Report 17.4 Pre-Issuance Readiness Audit 17.5 Audit of Delegated Functions 17.6 Auditor Qualifications 17.7 Key Generation Ceremony 17.8 Regular Quality Assessment Self Audits Liability and Indemnification 18.1 Liability to Subscribers and Relying parties 18.2 Indemnification of Application Software Suppliers 18.3 Root CA Obligations

- 130 -

1. INTRODUCTION
This Appendix articulates supplemental procedures to Symantecs STN CPS for issuing Organization Validated (OV) Certificates and Domain Validated (DV) Certificates in conformance with the Baseline Requirement for Publicly Trusted Certificates (Baseline Requirements). Additionally, certain sections in this Appendix are referenced from Symantecs Supplemental Procedures for the issuance of EV SSL Certificates (Appendix B1) and EV Code-Signing Certificates (Appendix C). Baseline Requirements are published by the CA Browser Forum at www.cabforum.org, to describe certain of the minimum requirements that a Certificate Authority (CA) must meet in order to issue Publicly Trusted Certificates. Symantecs OV and DV Certificates issued under the Supplemental Procedures in this Appendix are used for authenticating servers accessible through the Internet.

2. Purpose
The primary goal of these Requirements is to enable efficient and secure electronic communication, while addressing user concerns about the trustworthiness of Certificates. The Requirements also serve to inform users and help them to make informed decisions when relying on Certificates.

3. References
ETSI Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment General Requirements and Guidance, available at: http://www.etsi.org/deliver/etsi_ts/119400_119499/119403/01.01.01_60/ts_119403v010101p.pdf. ETSI TS 102 042 V2.1.1, Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates. FIPS 140-2, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001. ISO 21188:2006, Public key infrastructure for financial services -- Practices and policy framework. NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, http://csrc.nist.gov/publications/nistpubs/800-89/SP-800-89_November2006.pdf. RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels, Bradner, March 1997. RFC2527, Request for Comments: 2527, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, March 1999. RFC2560, Request for Comments: 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP M. Myers, et al, June 1999. RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, November 2003.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 2
RFC4366, Request for Comments: 4366, Transport Layer Security (TLS) Extensions, Blake-Wilson, et al, April 2006. RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments, A. Deacon, et al, September 2007. RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate

- 131 -

Revocation List (CRL) Profile, Cooper et al, May 2008. WebTrust for Certification Authorities Version 2.0, available at http://www.webtrust.org/homepagedocuments/ item27839.aspx. X.509v3 , ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks.

4. Definitions
Affiliate: A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity. Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request. Applicant Representative: A natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant: (i) who signs and submits, or approves a certificate request on behalf of the Applicant, and/or (ii) who signs and submits a Subscriber Agreement on behalf of the Applicant, and/or (iii) who acknowledges and agrees to the Certificate Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the CA. Application Software Supplier: A supplier of Internet browser software or other relying-party application software that displays or uses Certificates and incorporates Root Certificates. Attestation Letter: A letter attesting that Subject Information is correct written by an accountant, lawyer, government official, or other reliable third party customarily relied upon for such information. Audit Report: A report from a Qualified Auditor stating the Qualified Auditors opinion on whether an entitys processes and controls comply with the mandatory provisions of these Requirements. Certificate: An electronic document that uses a digital signature to bind a public key and an identity. Certificate Data: Certificate requests and data related thereto (whether obtained from the Applicant or otherwise) in the CAs possession or control or to which the CA has access. Certificate Management Process: Processes, practices, and procedures associated with the use of keys, software, and hardware, by which the CA verifies Certificate Data, issues Certificates, maintains a Repository, and revokes Certificates. Certificate Policy: A set of rules that indicates the applicability of a named Certificate to a particular community and/or PKI implementation with common security requirements. Certificate Problem Report: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates. Certificate Revocation List: A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the CA that issued the Certificates. Certification Authority: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs.

Forum Guideline

- 132 -

CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 3

Certification Practice Statement: One of several documents forming the governance framework in which Certificates are created, issued, managed, and used. Country: Either a member of the United Nations OR a geographic region recognized as a sovereign nation by at least two UN member nations. Cross Certificate: A certificate that is used to establish a trust relationship between two Root CAs. Delegated Third Party: A natural person or Legal Entity that is not the CA but is authorized by the CA to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein. Domain Authorization Document: Documentation provided by, or a CAs documentat ion of a communication with, a Domain Name Registrar, the Domain Name Registrant, or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service) attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace. Domain Name: The label assigned to a node in the Domain Name System. Domain Namespace: The set of all possible Domain Names that are subordinate to a single node in the Domain Name System. Domain Name Registrant: Sometimes referred to as the owner of a Domain Name, but more properly the person(s) or entity(ies) registered with a Domain Name Registrar as having the right to control how a Domain Name is used, such as the natural person or Legal Entity that is listed as the Registrant by WHOIS or the Domain Name Registrar. Domain Name Registrar: A person or entity that registers Domain Names under the auspices of or by agreement with: (i) the Internet Corporation for Assigned Names and Numbers (ICANN), (ii) a national Domain Name authority/registry, or (iii) a Network Information Center (including their affiliates, contractors, delegates, successors, or assigns). Effective Date: These Requirements come into force on 1 July 2012. Enterprise RA: An employee or agent of an organization unaffiliated with the CA who authorizes issuance of Certificates to that organization. Expiry Date: The Not After date in a Certificate that defines the end of a Certificates validity period. Fully-Qualified Domain Name: A Domain Name that includes the labels of all superior nodes in the Internet Domain Name System. Government Entity: A government-operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.). High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles

- 133 -

phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria. Internal Server Name: A Server Name (which may or may not include an Unregistered Domain Name) that is not resolvable using the public DNS. Issuing CA: In relation to a particular Certificate, the CA that issued the Certificate. This could be either a Root CA or a Subordinate CA. Key Compromise: A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, an unauthorized person has had access to it, or there exists a practical technique by which an unauthorized person may discover its value. A Private Key is also considered compromised if methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the specific method used to generate the Private Key was flawed.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 4
Key Generation Script: A documented plan of procedures for the generation of a CA Key Pair. Key Pair: The Private Key and its associated Public Key. Legal Entity: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a countrys legal system. Object Identifier: A unique alphanumeric or numeric identifier registered under the International Organization for Standardizations applicable standard for a specific object or object class. OCSP Responder: An online server operated under the authority of the CA and connected to its Repository for processing Certificate status requests. See also, Online Certificate Status Protocol. Online Certificate Status Protocol: An online Certificate-checking protocol that enables relying-party application software to determine the status of an identified Certificate. See also OCSP Responder. Private Key: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted with the corresponding Public Key. Public Key: The key of a Key Pair that may be publicly disclosed by the holder of the corresponding Private Key and that is used by a Relying Party to verify Digital Signatures created with the holder's corresponding Private Key and/or to encrypt messages so that they can be decrypted only with the holder's corresponding Private Key . Public Key Infrastructure: A set of hardware, software, people, procedures, rules, policies, and obligations used to facilitate the trustworthy creation, issuance, management, and use of Certificates and keys based on Public Key Cryptography. Publicly-Trusted Certificate: A Certificate that is trusted by virtue of the fact that its corresponding Root Certificate is distributed as a trust anchor in widely-available application software. Qualified Auditor: A natural person or Legal Entity that meets the requirements of Section 17.6 (Auditor Qualifications). Registered Domain Name: A Domain Name that has been registered with a Domain Name Registrar. Registration Authority (RA): Any Legal Entity that is responsible for identification and authentication of subjects

- 134 -

of Certificates, but is not a CA, and hence does not sign or issue Certificates. An RA may assist in the certificate application process or revocation process or both. When RA is used as an adjective to describe a role or function, it does not necessarily imply a separate body, but can be part of the CA. Reliable Data Source: An identification document or source of data used to verify Subject Identity Information that is generally recognized among commercial enterprises and governments as reliable, and which was created by a third party for a purpose other than the Applicant obtaining a Certificate. Reliable Method of Communication: A method of communication, such as a postal/courier delivery address, telephone number, or email address, that was verified using a source other than the Applicant Representative. Relying Party: Any natural person or Legal Entity that relies on a Valid Certificate. An Application Software Supplier is not considered a Relying Party when software distributed by such Supplier merely displays information relating to a Certificate. Repository: An online database containing publicly-disclosed PKI governance documents (such as Certificate Policies and Certification Practice Statements) and Certificate status information, either in the form of a CRL or an OCSP response. Requirements: This document. Reserved IP Address: An IPv4 or IPv6 address that the IANA has marked as reserved: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 5
Root CA: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates. Root Certificate: The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs. Subject: The natural person, device, system, unit, or Legal Entity identified in a Certificate as the Subject. The Subject is either the Subscriber or a device under the control and operation of the Subscriber. Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity Information does not include a domain name listed in the subjectAltName extension or the Subject commonName field. Subordinate CA: A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA. Subscriber: A natural person or Legal Entity to whom a Certificate is issued and who is legally bound by a Subscriber or Terms of Use Agreement. Subscriber Agreement: An agreement between the CA and the Applicant/Subscriber that specifies the rights and responsibilities of the parties. Technically Constrained Subordinate CA Certificate: A Subordinate CA certificate which uses a combination of Extended Key Usage settings and Name Constraint settings to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates.

- 135 -

Terms of Use: Provisions regarding the safekeeping and acceptable uses of a Certificate issued in accordance with these Requirements when the Applicant/Subscriber is an Affiliate of the CA. Trustworthy System: Computer hardware, software, and procedures that are: reasonably secure from intrusion and misuse; provide a reasonable level of availability, reliability, and correct operation; are reasonably suited to performing their intended functions; and enforce the applicable security policy. Unregistered Domain Name: A Domain Name that is not a Registered Domain Name. Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280. Validation Specialists: Someone who performs the information verification duties specified by these Requirements. Validity Period: The period of time measured from the date when the Certificate is issued until the Expiry Date. Wildcard Certificate: A Certificate containing an asterisk (*) in the left-most position of any of the Subject FullyQualified Domain Names contained in the Certificate.

5. Abbreviations and Acronyms

AICPA American Institute of Certified Public Accountants CA Certification Authority ccTLD Country Code Top-Level Domain CICA Canadian Institute of Chartered Accountants CP Certificate Policy CPS Certification Practice Statement CRL Certificate Revocation List DBA Doing Business As DNS Domain Name System FIPS (US Government) Federal Information Processing Standard

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 6
FQDN Fully Qualified Domain Name IM Instant Messaging IANA Internet Assigned Numbers Authority ICANN Internet Corporation for Assigned Names and Numbers ISO International Organization for Standardization NIST (US Government) National Institute of Standards and Technology OCSP Online Certificate Status Protocol OID Object Identifier PKI Public Key Infrastructure RA Registration Authority S/MIME Secure MIME (Multipurpose Internet Mail Extensions) SSL Secure Sockets Layer TLD Top-Level Domain TLS Transport Layer Security VOIP Voice Over Internet Protocol

6. Conventions
Terms not otherwise defined in these Requirements shall be as defined in applicable agreements, user manuals, Certificate Policies and Certification Practice Statements, of the CA. The key words MUST, MUST NOT, "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these Requirements shall be interpreted in accordance with RFC 2119.

- 136 -

7. Certificate Warranties and Representations

7.1 By the CA
By issuing a Certificate, the CA makes the Certificate Warranties listed in Section 7.1.2 to the Certificate Beneficiaries listed in 7.1.1.

7.1.1 Certificate Beneficiaries

Certificate Beneficiaries include, but are not limited to, the following: 1. The Subscriber that is a party to the Subscriber or Terms of Use Agreement for the Certificate; 2. All Application Software Suppliers with whom the Root CA has entered into a contract for inclusion of its Root Certificate in software distributed by such Application Software Supplier; and 3. All Relying Parties who reasonably rely on a Valid Certificate.

7.1.2 Certificate Warranties

The CA represents and warrants to the Certificate Beneficiaries that, during the period when the Certificate is valid, the CA has complied with these Requirements and its Certificate Policy and/or Certification Practice Statement in issuing and managing the Certificate.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 7
The Certificate Warranties specifically include, but are not limited to, the following: 1. Right to Use Domain Name or IP Address: That, at the time of issuance, the CA (i) implemented a procedure for verifying that the Applicant either had the right to use, or had control of, the Domain Name(s) and IP address(es) listed in the Certificates subject field and subj ectAltName extension (or, only in the case of Domain Names, was delegated such right or control by someone who had such right to use or control); (ii) followed the procedure when issuing the Certificate; and (iii) accurately described the procedure in the CAs Certificate Policy and/or Certification Practice Statement; 2. Authorization for Certificate: That, at the time of issuance, the CA (i) implemented a procedure for verifying that the Subject authorized the issuance of the Certificate and that the Applicant Representative is authorized to request the Certificate on behalf of the Subject; (ii) followed the procedure when issuing the Certificate; and (iii) accurately described the procedure in the CAs Certificate Policy and/or Certification Practice Statement; 3. Accuracy of Information: That, at the time of issuance, the CA (i) implemented a procedure for verifying the accuracy of all of the information contained in the Certificate (with the exception of the subject:organizationalUnitName attribute); (ii) followed the procedure when issuing the Certificate; and (iii) accurately described the procedure in the CAs Certificate Policy and/or Certification Practice Statement; 4. No Misleading Information: That, at the time of issuance, the CA (i) implemented a procedure for reducing the likelihood that the information contained in the Certificates subject:organizationalUnitName attribute would be misleading; (ii) followed the procedure when issuing the Certificate; and (iii) accurately described the procedure in the CAs Certificate Policy and/or Certification Practice Statement; 5. Identity of Applicant: That, if the Certificate contains Subject Identity Information, the CA (i) implemented a procedure to verify the identity of the Applicant in accordance with Sections 9.2.4 and 11.2; (ii) followed the procedure when issuing the Certificate; and (iii) accurately described the procedure in the CAs Certificate Policy and/or Certification Practice Statement; 6. Subscriber Agreement: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are Affiliated, the Applicant Representative acknowledged and accepted the Terms of Use; 7. Status: That the CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates; and 8. Revocation: That the CA will revoke the Certificate for any of the reasons specified in these

- 137 -

Requirements.

7.2 By the Applicant

The CA SHALL require, as part of the Subscriber or Terms of Use Agreement, that the Applicant make the commitments and warranties set forth in Section 10.3.2 of these Requirements, for the benefit of the CA and the Certificate Beneficiaries.

8. Community and Applicability

8.1 Compliance
The CA SHALL at all times: 1. Issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates; 2. Comply with these Requirements;

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 8
3. Comply with the audit requirements set forth in Section 17; and 4. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates. If a court or government body with jurisdiction over the activities covered by these Requirements determines that the performance of any mandatory requirement is illegal, then such requirement is considered reformed to the minimum extent necessary to make the requirement valid and legal. This applies only to operations or certificate issuances that are subject to the laws of that jurisdiction. The parties involved SHALL notify the CA / Browser Forum of the facts, circumstances, and law(s) involved, so that the CA/Browser Forum may revise these Requirements accordingly.

8.2 Certificate Policies

8.2.1 Implementation
The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements.

8.2.2 Disclosure
The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CAs selected audit scheme (see S ection 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647.

8.3 Commitment to Comply

The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version. The CA MAY fulfill this requirement by incorporating these Requirements directly into its Certificate Policy and/or Certification Practice Statements or by incorporating them by reference using a clause such as the following (which MUST include a link to the official version of these Requirements): [Name of CA] conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.

8.4 Trust model

- 138 -

The CA SHALL disclose all Cross Certificates that identify the CA as the Subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross Certificate at issue).

9. Certificate Content and Profile

9.1 Issuer Information
An Issuing CA SHALL populate the issuer field of each Certificate issued after the adoption of these Requirements in accordance with the following subsections.

9.1.1 Issuer Common Name Field

Certificate Field: issuer:commonName (OID 2.5.4.3) Required/Optional: Optional

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 9
Contents: If present in a Certificate, the Common Name field MUST include a name that accurately identifies the Issuing CA.

9.1.2 Issuer Domain Component Field

Certificate Field: issuer:domainComponent (OID 0.9.2342.19200300.100.1.25) Required/Optional: Optional. Contents: If present in a Certificate, the Domain Component field MUST include all components of the Issuing CAs Registered Domain Name in ordered sequence, with the most significant component, closest to the root of the namespace, written last.

9.1.3 Issuer Organization Name Field

Certificate Field: issuer:organizationName (OID 2.5.4.10) Required/Optional: Required Contents: This field MUST contain the name (or abbreviation thereof), trademark, or other meaningful identifier for the CA, provided that they accurately identify the CA. The field MUST NOT contain a generic designation such as Root or CA1.

9.1.4 Issuer Country Name Field

Certificate Field: issuer:countryName (OID 2.5.4.6) Required/Optional: Required Contents: This field MUST contain the two-letter ISO 3166-1 country code for the country in which the issuers place of business is located.

9.2 Subject Information

By issuing the Certificate, the CA represents that it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify that, as of the Certificates issuance date, all of the Subject Information was accurate. CAs SHALL NOT include a Domain Name in a Subject attribute except as specified in Sections 9.2.1 and 9.2.2 below

9.2.1 Subject Alternative Name Extension

Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the

- 139 -

Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 10

9.2.2 Subject Common Name Field

Certificate Field: subject:commonName (OID 2.5.4.3) Required/Optional: Deprecated (Discouraged, but not prohibited) Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificates subjectAltName extension (see Section 9.2.1).

9.2.3 Subject Domain Component Field

Certificate Field: subject:domainComponent (OID 0.9.2342.19200300.100.1.25) Required/Optional: Optional. Contents: If present, this field MUST contain a label from a Domain Name. The domainComponent fields for each Domain Name MUST be in a single ordered sequence containing all labels from the Domain name. The labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the label closest to the root is encoded first. The CA MUST ensure that the certificate is issued with the consent of, and according to procedures established by, the owner of each Domain Name.

9.2.4 Subject Distinguished Name Fields

a. Certificate Field: subject:organizationName (OID 2.5.4.10) Optional. Contents: If present, the subject:organizationName field MUST contain either the Subjects name or DBA as verified under Section 11.2. The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows Company Name Incorporated, the CA MAY use Company Name Inc. or Company Name. Because Subject name attributes for individuals (e.g. givenName (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by application software, the CA MAY use the subject:organizationName field to convey a natural person Subjects name or DBA. b. Certificate Field: Number and street: subject:streetAddress (OID: 2.5.4.9) Optional if the subject:organizationName field is present.

- 140 -

Prohibited if the subject:organizationName field is absent. Contents: If present, the subject:streetAddress field MUST contain the Subjects street address information as verified under Section 11.2. c. Certificate Field: subject:localityName (OID: 2.5.4.7) Required if the subject:organizationName field is present and the subject:stateOrProvinceName field is absent. Optional if the subject:organizationName and subject:stateOrProvinceName fields are present. Prohibited if the subject:organizationName field is absent.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 11
Contents: If present, the subject:localityName field MUST contain the Subjects locality information as verified under Section 11.2. If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX in accordance with Section 9.2.5, the localityName field MAY contain the Subjects locality and/or state or province information as verified under Section 11.2. d. Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8) Required if the subject:organizationName field is present and subject:localityName field is absent. Optional if subject:organizationName and subject:localityName fields are present. Prohibited if the subject:organizationName field is absent. Contents: If present, the subject:stateOrProvinceName field MUST contain the Subjects state or province information as verified under Section 11.2. If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX in accordance with Section 9.2.5, the subject:stateOrProvinceName field MAY contain the full name of the Subjects c ountry information as verified under Section 11.2.5. e. Certificate Field: subject:postalCode (OID: 2.5.4.17) Optional if the subject:organizationName field is present. Prohibited if the subject:organizationName field is absent. Contents: If present, the subject:postalCode field MUST contain the Subjects zip or postal information as verified under Section 11.2

9.2.5 Subject Country Name Field

Certificate Field: subject:countryName (OID: 2.5.4.6) Required if the subject:organizationName field is present. Optional if the subject:organizationName field is absent. Contents: If the subject:organizationName field is present, the subject:countryName MUST contain the two-letter ISO 3166-1 country code associated with the location of the Subject verified under Section 11.2. If the subject:organizationName field is absent, the subject:countryName field MAY contain the two-letter ISO 3166-1 country code associated with the Subject as verified in accordance with Section 11.2.5. If a Country is not represented by an official ISO 3166-1 country code, the CA MAY specify the ISO 3166-1 user-assigned code of XX indicating that an official ISO 3166-1 alpha-2 code has not been assigned.

9.2.6 Subject Organizational Unit Field

Certificate Field: subject:organizationalUnitName Optional. The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 11.2 and the Certificate also contains subject:organizationName, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 11.2.

Forum Guideline

- 141 -

CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 12

9.2.7 Subject Information Subordinate CA Certificates

By issuing a Subordinate CA Certificate, the CA represents that it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify that, as of the Certificates issuance date, all of the Subject Information was accurate.

9.2.8 Other Subject Attributes

All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA. Optional attributes MUST NOT contain metadata such as ., -, and (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.

9.3 Certificate Policy Identification

This section describes the content requirements for the Root CA, Subordinate CA, and Subscriber Certificates, as they relate to the identification of Certificate Policy.

9.3.1 Reserved Certificate Policy Identifiers

The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting compliance with these Requirements as follows: {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baselinerequirements( 2) domain-validated(1)} (2.23.140.1.2.1), if the Certificate complies with these Requirements but lacks Subject Identity Information that is verified in accordance with Section 11.2. If the Certificate asserts the policy identifier of 2.23.140.1.2.1, then it MUST NOT include organizationName, streetAddress, localityName, stateOrProvinceName, or postalCode in the Subject field. {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baselinerequirements( 2) subject-identity-validated(2)} (2.23.140.1.2.2), if the Certificate complies with these Requirements and includes Subject Identity Information that is verified in accordance with Section 11.2. If the Certificate asserts the policy identifier of 2.23.140.1.2.2, then it MUST also include organizationName, localityName, stateOrProvinceName (if applicable), and countryName in the Subject field.

9.3.2 Root CA Certificates

A Root CA Certificate SHOULD NOT contain the certificatePolicies extension.

9.3.3 Subordinate CA Certificates

A Certificate issued after the Effective Date to a Subordinate CA that is not an Affiliate of the Issuing CA: 1. MUST include one or more explicit policy identifiers that indicates the Subordinate CAs adherence to and compliance with these Requirements (i.e. either the CA/Browser Forum reserved identifiers or identifiers defined by the CA in its Certificate Policy and/or Certification Practice Statement) and 2. MUST NOT contain the anyPolicy identifier (2.5.29.32.0). A Certificate issued after the Effective Date to a Subordinate CA that is an affiliate of the Issuing CA: 1. MAY include the CA/Browser Forum reserved identifiers or an identifier defined by the CA in its Certificate Policy and/or Certification Practice Statement to indicate the Subordinate CAs compliance with these Requirements and 2. MAY contain the anyPolicy identifier (2.5.29.32.0) in place of an explicit policy identifier.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 13
A Subordinate CA SHALL represent, in its Certificate Policy and/or Certification Practice Statement, that all

- 142 -

Certificates containing a policy identifier indicating compliance with these Requirements are issued and managed in accordance with these Requirements.

9.3.4 Subscriber Certificates

A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the Issuing CA, in the Certificates certificatePolicies extension that indicates adherence to and compliance with these Requirements. CAs complying with these Requirements MAY also assert one of the reserved policy OIDs in such Certificates. The issuing CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these Requirements.

9.4 Validity Period

9.4.1 Subscriber Certificates
Subscriber Certificates issued after the Effective Date MUST have a Validity Period no greater than 60 months. Except as provided for below, Subscriber Certificates issued after 1 April 2015 MUST have a Validity Period no greater than 39 months. Beyond 1 April 2015, CAs MAY continue to issue Subscriber Certificates with a Validity Period greater than 39 months but not greater than 60 months provided that the CA documents that the Certificate is for a system or software that: (a) was in use prior to the Effective Date; (b) is currently in use by either the Applicant or a substantial number of Relying Parties; (c) fails to operate if the Validity Period is shorter than 60 months; (d) does not contain known security risks to Relying Parties; and (e) is difficult to patch or replace without substantial economic outlay.

9.5 Public Key

The CA SHALL reject a certificate request if the requested Public Key does not meet the requirements set forth in Appendix A or if it has a known weak Private Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys).

9.6 Certificate Serial Number

CAs SHOULD generate non-sequential Certificate serial numbers that exhibit at least 20 bits of entropy.

9.7 Technical Constraints in Subordinate CA Certificates via Name Constraints and EKU
For a Subordinate CA Certificate to be considered Technically Constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the Subordinate CA Certificate is authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension. If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName as follows:-

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 14
- 143 -

(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the Applicant has registered the dNSName or has been authorized by the domain registrant to act on the registrant's behalf in line with the verification practices of section 11.1. (b) For each iPAddress range in permittedSubtrees, the CA MUST confirm that the Applicant has been assigned the iPAddress range or has been authorized by the assigner to act on the assignee's behalf. (c) For each DirectoryName in permittedSubtrees the CA MUST confirm the Applicants and/or Subsidiarys Organizational name and location such that end entity certificates issued from the subordinate CA Certificate will be in compliancy with section 9.2.4 and 9.2.5. If the Subordinate CA Certificate is not allowed to issue certificates with an iPAddress, then the Subordinate CA Certificate MUST specify the entire IPv4 and IPv6 address ranges in excludedSubtrees. The Subordinate CA Certificate MUST include within excludedSubtrees an iPAddress GeneralName of 8 zero octets (covering the IPv4 address range of 0.0.0.0/0). The Subordinate CA Certificate MUST also include within excludedSubtrees an iPAddress GeneralName of 32 zero octets (covering the IPv6 address range of ::0/0). Otherwise, the Subordinate CA Certificate MUST include at least one iPAddress in permittedSubtrees. A decoded example for issuance to the domain and sub domains of example.com by organization :Example LLC, Boston, Massachusetts, US would be:X509v3 Name Constraints: Permitted: DNS:example.com DirName: C=US, ST=MA, L=Boston, O=Example LLC Excluded: IP:0.0.0.0/0.0.0.0 IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0 If the Subordinate CA is not allowed to issue certificates with dNSNames, then the Subordinate CA Certificate MUST include a zero-length dNSName in excludedSubtrees. Otherwise, the Subordinate CA Certificate MUST include at least one dNSName in permittedSubtrees.

9.8 Additional Technical Requirements

The CA SHALL meet the technical requirements set forth in Appendix A - Cryptographic Algorithm and Key RequirementsAppendix A - Cryptographic Algorithm and Key Requirements, and Appendix B Certificate Extensions Appendix B Certificate Extensions, and Appendix C User Agent Verification.

10. Certificate Application

10.1 Documentation Requirements
Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant: 1. A certificate request, which may be electronic; and 2. An executed Subscriber or Terms of Use Agreement, which may be electronic. The CA SHOULD obtain any additional documentation the CA determines necessary to meet these Requirements.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 15

10.2 Certificate Request

10.2.1 General

- 144 -

Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant a certificate request in a form prescribed by the CA and that complies with these Requirements. One certificate request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in Section 11.3, provided that each Certificate is supported by a valid, current certificate request signed by the appropriate Applicant Representative on behalf of the Applicant. The certificate request MAY be made, submitted and/or signed electronically.

10.2.2 Request and Certification

The certificate request MUST contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.

10.2.3 Information Requirements

The certificate request MAY include all factual information about the Applicant to be included in the Certificate, and such additional information as is necessary for the CA to obtain from the Applicant in order to comply with these Requirements and the CAs Certificate Policy and/or Certification Practice Statement. In cases where the certificate request does not contain all the necessary information about the Applicant, the CA SHALL obtain the remaining information from the Applicant or, having obtained it from a reliable, independent, third-party data source, confirm it with the Applicant. The CA SHALL establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant. Applicant information MUST include, but not be limited to, at least one Fully-Qualified Domain Name or IP address to be included in the Certificates SubjectAltName extension.

10.2.4 Subscriber Private Key

Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key. If the CA or any of its designated RAs generated the Private Key on behalf of the Subscriber, then the CA SHALL encrypt the Private Key for transport to the Subscriber. If the CA or any of its designated RAs become aware that a Subscribers Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.

10.2.5 Subordinate CA Private Key

Parties other than the Subordinate CA SHALL NOT archive the Subordinate CA Private Keys. If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA. If the Issuing CA becomes aware that a Subordinate CAs Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subordinate CA, then the Issuing CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.

10.3 Subscriber and Terms of Use Agreement

- 145 -

10.3.1 General
Prior to the issuance of a Certificate, the CA SHALL obtain, for the express benefit of the CA and the Certificate Beneficiaries, either: 1. The Applicants agreement to the Subscriber Agreement with the CA, or

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 16
2. The Applicants agreement to the Terms of Use agreement. The CA SHALL implement a process to ensure that each Subscriber or Terms of Use Agreement is legally enforceable against the Applicant. In either case, the Agreement MUST apply to the Certificate to be issued pursuant to the certificate request. The CA MAY use an electronic or "click-through" Agreement provided that the CA has determined that such agreements are legally enforceable. A separate Agreement MAY be used for each certificate request, or a single Agreement MAY be used to cover multiple future certificate requests and the resulting Certificates, so long as each Certificate that the CA issues to the Applicant is clearly covered by that Subscriber or Terms of Use Agreement.

10.3.2 Agreement Requirements

The Subscriber or Terms of Use Agreement MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties: 1. Accuracy of Information: An obligation and warranty to provide accurate and complete information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA; 2. Protection of Private Key: An obligation and warranty by the Applicant to take all reasonable measures to maintain sole control of, keep confidential, and properly protect at all times the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token); 3. Acceptance of Certificate: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy; 4. Use of Certificate: An obligation and warranty to install the Certificate only on servers that are accessible at the subjectAltName(s) listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber or Terms of Use Agreement; 5. Reporting and Revocation: An obligation and warranty to promptly cease using a Certificate and its associated Private Key, and promptly request the CA to revoke the Certificate, in the event that: (a) any information in the Certificate is, or becomes, incorrect or inaccurate, or (b) there is any actual or suspected misuse or compromise of the Subscribers Private Key associated with the Public Key included in the Certificate; 6. Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise. 7. Responsiveness: An obligation to respond to the CAs instructions concerning Key Compromise or Certificate misuse within a specified time period. 8. Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber or Terms of Use Agreement or if the CA discovers that the Certificate is being used to enable criminal activities such as phishing attacks, fraud, or the distribution of malware.

- 146 -

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 17

11. Verification Practices

11.1 Authorization 11.1.1 Authorization by Domain Name Registrant
For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant either is the Domain Name Registrant or has control over the FQDN by: 1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar; 2. Communicating directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar; 3. Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS records registrant, technical, or administrative field; 4. Communicating with the Domains administrator using an email address created by pre-pending admin, administrator, webmaster, hostmaster, or postmaster in the local part, followed by the at -sign (@), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN; 5. Relying upon a Domain Authorization Document; 6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or 7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described. Note: For purposes of determining the appropriate domain name level or Domain Namespace, the registerable Domain Name is the second-level domain for generic top-level domains (gTLD) such as .com, .net, or .org, or, if the Fully Qualified Domain Name contains a 2 letter Country Code Top-Level Domain (ccTLD), then the domain level is whatever is allowed for registration according to the rules of that ccTLD. If the CA relies upon a Domain Authorization Document to confirm the Applicants control over a FQDN, then the Domain Authorization Document MUST substantiate that the communication came from either the Domain Name Registrant (including any private, anonymous, or proxy registration service) or the Domain Name Registrar listed in the WHOIS. The CA MUST verify that the Domain Authorization Document was either (i) dated on or after the certificate request date or (ii) used by the CA to verify a previously issued certificate and that the Domain Names WHOIS record has not been modified since the previous certificates issuance. Note: FQDNs may be listed in Subscriber Certificates using dNSNames in the subjectAltName extension or in Subordinate CA Certificates via dNSNames in permittedSubtrees within the Name Constraints extension.

11.1.2 Authorization for an IP Address

For each IP Address listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant has control over the IP Address by: 1. Having the Applicant demonstrate practical control over the IP Address by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the IP

- 147 -

Address; 2. Obtaining documentation of IP address assignment from the Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC);

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 18
3. Performing a reverse-IP address lookup and then verifying control over the resulting Domain Name under Section 11.1.1; or 4. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant has control over the IP Address to at least the same level of assurance as the methods previously described. Note: IPAddresses may be listed in Subscriber Certificates using IPAddress in the subjectAltName extension or in Subordinate CA Certificates via IPAddress in permittedSubtrees within the Name Constraints extension.

11.1.3 Wildcard Domain Validation

Before issuing a certificate with a wildcard character (*) in a CN or subjectAltName of type DNS-ID, the CA MUST establish and follow a documented procedure that determines if the wildcard cha racter occurs in the first label position to the left of a registry-controlled label or public suffix (e.g. *.com, *.co.uk, see RFC 6454 Section 8.2 for further explanation). If a wildcard would fall within the label immediately to the left of a registry-controlled or public suffix, CAs MUST refuse issuance unless the applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue *.co.uk or *.local, but MAY issue *.example.com to Example Co.). Prior to September 1, 2013, each CA MUST revoke any valid certificate that does not comply with this section of the Requirements. Determination of what is registry-controlled versus the registerable portion of a Country Code Top Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a public suffix list such as http://publicsuffix.org/. If the process for making this determination is standardized by an RFC, then such a procedure SHOULD be preferred.

11.1.4 New gTLD Domains

CAs SHOULD NOT issue Certificates containing a new gTLD under consideration by ICANN. Prior to issuing a Certificate containing an Internal Server Name with a gTLD that ICANN has announced as under consideration to make operational, the CA MUST provide a warning to the applicant that the gTLD may soon become resolvable and that, at that time, the CA will revoke the Certificate unless the applicant promptly registers the domain name. Within 30 days after ICANN has approved a new gTLD for operation, as evidenced by publication of a contract with the gTLD operator on [www.ICANN.org] each CA MUST (1) compare the new gTLD against the CAs records of valid certificates and (2) cease issuing Certificates containing a Domain Name that includes the new gTLD until after the CA has first verified the Subscriber's control over or exclusive right to use the Domain Name in accordance with Section 11.1.

- 148 -

Within 120 days after the publication of a contract for a new gTLD is published on [www.icann.org], CAs MUST revoke each Certificate containing a Domain Name that includes the new gTLD unless the Subscriber is either the Domain Name Registrant or can demonstrate control over the Domain Name.

11.2 Verification of Subject Identity Information

If the Applicant requests a Certificate that will contain Subject Identity Information comprised only of the countryName field, then the CA SHALL verify the country associated with the Subject using a verification process meeting the requirements of Section 11.2.5 and that is described in the CAs Certificate Policy and/or Certification Practice Statement. If the Applicant requests a Certificate that will contain the countryName field and other Subject Identity Information, then the CA SHALL verify the identity of the Applicant, and the authenticity of the Applicant Representatives certificate request using a verification process meeting the requirements of this Section 11.2 and that is described in the CAs Certificate Policy and/or Certification Pr actice Statement. The CA SHALL inspect any document relied upon under this Section for alteration or falsification.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 19

11.2.1 Identity
If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicants address of existence or operation. The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following: 1. A government agency in the jurisdiction of the Applicants legal creation, existence, or recognition; 2. A third party database that is periodically updated and considered a Reliable Data Source; 3. A site visit by the CA or a third party who is acting as an agent for the CA; or 4. An Attestation Letter. The CA MAY use the same documentation or communication described in 1 through 4 above to verify both the Applicants identity and address. Alternatively, the CA MAY verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.

11.2.2 DBA/Tradename
If the Subject Identity Information is to include a DBA or tradename, the CA SHALL verify the Applicants right to use the DBA/tradename using at least one of the following: 1. Documentation provided by, or communication with, a government agency in the jurisdiction of the Applicants legal creation, existence, or recognition; 2. A Reliable Data Source; 3. Communication with a government agency responsible for the management of such DBAs or tradenames; 4. An Attestation Letter accompanied by documentary support; or 5. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.

- 149 -

11.2.3 Authenticity of Certificate Request

If the Applicant for a Certificate containing Subject Identity Information is an organization, the CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representatives certificate request. The CA MAY use the sources listed in section 11.2.1 to verify the Reliable Method of Communication. Provided that the CA uses a Reliable Method of Communication, the CA MAY establish the authenticity of the certificate request directly with the Applicant Representative or with an authoritative source within the Applicants organization, such as the Applicants main business offices, corporate offices, human resource offices, information technology offices, or other department that the CA deems appropriate. In addition, the CA SHALL establish a process that allows an Applicant to specify the individuals who may request Certificates. If an Applicant specifies, in writing, the individuals who may request a Certificate, then the CA SHALL NOT accept any certificate requests that are outside this specification. The CA SHALL provide an Applicant with a list of its authorized certificate requesters upon the Applicants verified written request.

11.2.4 Verification of Individual Applicant

If an Applicant subject to this Section 11.2 is a natural person, then the CA SHALL verify the Applicants name, Applicants address, and the authenticity of the certificate request.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 20
The CA SHALL verify the Applicants name using a legible copy, which discernibly shows the Applicants face, of at least one currently valid government-issued photo ID (passport, drivers license, military ID, national ID, or equivalent document type). The CA SHALL inspect the copy for any indication of alteration or falsification. The CA SHALL verify the Applicants address using a form of identification that the CA determines to be reliable, such as a government ID, utility bill, or bank or credit card statement. The CA MAY rely on the same governmentissued ID that was used to verify the Applicants name. The CA SHALL verify the certificate request with the Applicant using a Reliable Method of Communication.

11.2.5 Verification of Country

If the subject:countryName field is present, then the CA SHALL verify the country associated with the Subject using one of the following: (a) the IP Address range assignment by country for either (i) the web sites IP address, as indicated by the DNS record for the web site or (ii) the App licants IP address; (b) the ccTLD of the requested Domain Name; (c) information provided by the Domain Name Registrar; or (d) a method identified in Section 11.2.1. The CA SHOULD implement a process to screen proxy servers in order to prevent reliance upon IP addresses assigned in countries other than where the Applicant is actually located.

11.3 Age of Certificate Data

Section 9.4 limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in Section 11 to verify certificate information, provide that the CA obtained the data or document from a source specified under Section 11 no more than thirty-nine (39) months prior to issuing the Certificate.

- 150 -

11.4 Denied List

In accordance with Section 15.3.2, the CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests due to suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests.

11.5 High Risk Requests

The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificates approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.

11.6 Data Source Accuracy

Prior to using any data source as a Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification. The CA SHOULD consider the following during its evaluation: 1. The age of the information provided, 2. The frequency of updates to the information source, 3. The data provider and purpose of the data collection, 4. The public accessibility of the data availability, and 5. The relative difficulty in falsifying or altering the data. Databases maintained by the CA, its owner, or its affiliated companies do not qualify as a Reliable Data Source if the primary purpose of the database is to collect information for the purpose of fulfilling the validation requirements under Section 11.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 21

12. Certificate Issuance by a Root CA

Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation. Root CA Private Keys MUST NOT be used to sign Certificates except in the following cases: 1. Self-signed Certificates to represent the Root CA itself; 2. Certificates for Subordinate CAs and Cross Certificates; 3. Certificates for infrastructure purposes (e.g. administrative role certificates, internal CA operational device certificates, and OCSP Response verification Certificates); 4. Certificates issued solely for the purpose of testing products with Certificates issued by a Root CA; and 5. Subscriber Certificates, provided that: a. The Root CA uses a 1024-bit RSA signing key that was created prior to the Effective Date; b. The Applicants application was deployed prior to the Effective Date; c. The Applicants application is in active use by the Applicant or the CA uses a documented process to establish that the Certificates use is required by a substantial number of Relying Parties; d. The CA follows a documented process to determine that the Applicants application poses no known security risks to Relying Parties; and e. The CA documents that the Applicants application cannot be patched or replaced without substantial economic outlay.

13. Certificate Revocation and Status Checking

- 151 -

13.1 Revocation
13.1.1 Revocation Request
The CA SHALL provide a process for Subscribers to request revocation of their own Certificates. The process MUST be described in the CAs Certificate Policy or Certification Practice Statement. The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and related inquiries.

13.1.2 Certificate Problem Reporting

The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means.

13.1.3 Investigation
The CA SHALL begin investigation of a Certificate Problem Report within twenty-four hours of receipt, and decide whether revocation or other appropriate action is warranted based on at least the following criteria: 1. The nature of the alleged problem; 2. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 22
3. The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that she didnt receive the goods she ordered); and 4. Relevant legislation.

13.1.4 Response
The CA SHALL maintain a continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.

13.1.5 Reasons for Revoking a Subscriber Certificate

The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: 1. The Subscriber requests in writing that the CA revoke the Certificate; 2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; 3. The CA obtains evidence that the Subscribers Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (also see Section 10.2.4) or no longer complies with the requirements of Appendix A; 4. The CA obtains evidence that the Certificate was misused; 5. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber or Terms of Use Agreement; 6. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrants right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name); 7. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;

- 152 -

8. The CA is made aware of a material change in the information contained in the Certificate; 9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CAs Certificate Policy or Certification Practice Statement; 10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; 11. The CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate; 12. The CAs right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository; 13. The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for issuing the Certificate; 14. Revocation is required by the CAs Certificate Policy and/or Certification Practice Statement; or 15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

13.1.6 Reasons for Revoking a Subordinate CA Certificate

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 23
The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs: 1. The Subordinate CA requests revocation in writing; 2. The Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization; 3. The Issuing CA obtains evidence that the Subordinate CAs Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Appendix A, 4. The Issuing CA obtains evidence that the Certificate was misused; 5. The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with these Baseline Requirements or the applicable Certificate Policy or Certification Practice Statement; 6. The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading; 7. The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate; 8. The Issuing CAs or Subordinate CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository; 9. Revocation is required by the Issuing CAs Certificate Policy and/or Certification Practice Statement; or 10. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

13.2 Certificate Status Checking

13.2.1 Mechanisms
The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. If the Subscriber Certificate is for a high-traffic FQDN, the CA MAY rely on stapling, in accordance with [RFC4366], to distribute its OCSP responses. In this case, the CA SHALL ensure that the Subscriber staples the OCSP response for the Certificate in its TLS handshake. The CA SHALL enforce this requirement on the

- 153 -

Subscriber either contractually, through the Subscriber or Terms of Use Agreement, or by technical review measures implement by the CA.

13.2.2 Repository
The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates issued by the CA. For the status of Subscriber Certificates: 1. If the CA publishes a CRL, then the CA SHALL update and reissue CRLs at least once every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field; and 2. The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days. For the status of Subordinate CA Certificates:

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 24
1. The CA SHALL update and reissue CRLs at least (i) once every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate, and the value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field; and 2. The CA SHALL update information provided via an Online Certificate Status Protocol at least (i) every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate. Effective 1 January 2013, the CA SHALL support an OCSP capability using the GET method for Certificates issued in accordance with these Requirements.

13.2.3 Response Time

The CA SHALL operate and maintain its CRL and OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions.

13.2.4 Deletion of Entries

Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked Certificate.

13.2.5 OCSP Signing

OCSP responses MUST conform to RFC2560 and/or RFC5019. OCSP responses MUST either: 1. Be signed by the CA that issued the Certificates whose revocation status is being checked, or 2. Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked. In the latter case, the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC2560.

13.2.6 Response for nonissued certificates

If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status. The CA SHOULD monitor the responder for such requests as part of its security response procedures. Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 9.7 MUST NOT respond with a "good" status for such certificates.

13.2.7 Certificate Suspension

- 154 -

The Repository MUST NOT include entries that indicate that a Certificate is suspended.

14. Employees and Third Parties

14.1 Trustworthiness and Competence
14.1.1 Identity and Background Verification
Prior to the engagement of any person in the Certificate Management Process, whether as an employee, agent, or an independent contractor of the CA, the CA SHALL verify the identity and trustworthiness of such person.

14.1.2 Training and Skill Level

The CA SHALL provide all personnel performing information verification duties with skills-training that covers basic Public Key Infrastructure knowledge, authentication and vetting policies and procedures (including the CAs

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 25
Certificate Policy and/or Certification Practice Statement), common threats to the information verification process (including phishing and other social engineering tactics), and these Requirements. The CA SHALL maintain records of such training and ensure that personnel entrusted with Validation Specialist duties maintain a skill level that enables them to perform such duties satisfactorily. Validation Specialists engaged in Certificate issuance SHALL maintain skill levels consistent with the CAs training and performance programs. The CA SHALL document that each Validation Specialist possesses the skills required by a task before allowing the Validation Specialist to perform that task. The CA SHALL require all Validation Specialists to pass an examination provided by the CA on the information verification requirements outlined in these Requirements.

14.2 Delegation of Functions

14.2.1 General
The CA MAY delegate the performance of all, or any part, of Section 11 of these Requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 11. Before the CA authorizes a Delegated Third Party to perform a delegated function, the CA SHALL contractually require the Delegated Third Party to: 1) Meet the qualification requirements of Section 14.1, when applicable to the delegated function; 2) Retain documentation in accordance with Section 15.3.2; 3) Abide by the other provisions of these Requirements that are applicable to the delegated function; and 4) Comply with (a) the CAs Certificate Policy/Certification Practice Statement or (b) the Delegated Third Partys practice statement that the CA has verified complies with these Requirements. The CA SHALL verify that the Delegated Third Partys personnel involved in the issuance of a Certificate meet the training and skills requirements of Section 14 and the document retention and event logging requirements of Section 15. If a Delegated Third Party fulfills any of the CAs obligations under Section 11.5 (High Risk Requests), the CA SHALL verify that the process used by the Delegated Third Party to identify and further verify High Risk Certificate Requests provides at least the same level of assurance as the CAs own processes

- 155 -

14.2.2 Compliance Obligation

The CA SHALL internally audit each Delegated Third Partys compliance with these Requirements on an annual basis.

14.2.3 Allocation of Liability

For delegated tasks, the CA and any Delegated Third Party MAY allocate liability between themselves contractually as they determine, but the CA SHALL remain fully responsible for the performance of all parties in accordance with these Requirements, as if the tasks had not been delegated.

14.2.4 Enterprise RAs

The CA MAY designate an Enterprise RA to verify certificate requests from the Enterprise RAs own organization. The CA SHALL NOT accept certificate requests authorized by an Enterprise RA unless the following requirements are satisfied: 1. The CA SHALL confirm that the requested Fully-Qualified Domain Name(s) are within the Enterprise RAs verified Domain Namespace (see Section 7.1.2 para 1).

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 26
2. If the certificate request includes a Subject name of a type other than a Fully-Qualified Domain Name, the CA SHALL confirm that the name is either that of the delegated enterprise, or an Affiliate of the delegated enterprise, or that the delegated enterprise is an agent of the named Subject. For example, the CA SHALL NOT issue a Certificate containing the Subject name XYZ Co. on the authority of Enterprise RA ABC Co., unless the two companies are affiliated (see Section 11.1) or ABC Co. is the agent of XYZ Co. This requirement applies regardless of whether the accompanying requested Subject FQDN falls within the Domain Namespace of ABC Co.s Registered Domain Name. The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA.

15. Data Records

15.1 Documentation and Event Logging
The CA and each Delegated Third Party SHALL record details of the actions taken to process a certificate request and to issue a Certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved. The CA SHALL make these records available to its Qualified Auditor as proof of the CAs compliance with these Requirements.

15.2 Events and Actions

The CA SHALL record at least the following events: 1. CA key lifecycle management events, including: a. Key generation, backup, storage, recovery, archival, and destruction; and b. Cryptographic device lifecycle management events. 2. CA and Subscriber Certificate lifecycle management events, including: a. Certificate requests, renewal, and re-key requests, and revocation; b. All verification activities stipulated in these Requirements and the CAs Certification Practice Statement; c. Date, time, phone number used, persons spoken to, and end results of verification telephone calls; d. Acceptance and rejection of certificate requests; e. Issuance of Certificates; and f. Generation of Certificate Revocation Lists and OCSP entries.

- 156 -

3. Security events, including: a. Successful and unsuccessful PKI system access attempts; b. PKI and security system actions performed; c. Security profile changes; d. System crashes, hardware failures, and other anomalies; e. Firewall and router activities; and f. Entries to and exits from the CA facility. Log entries MUST include the following elements: 1. Date and time of entry; 2. Identity of the person making the journal entry; and

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 27
3. Description of the entry.

15.3 Retention
15.3.1 Audit Log Retention
The CA SHALL retain any audit logs generated after the Effective Date for at least seven years. The CA SHALL make these audit logs available to its Qualified Auditor upon request.

15.3.2 Documentation Retention

The CA SHALL retain all documentation relating to certificate requests and the verification thereof, and all Certificates and revocation thereof, for at least seven years after any Certificate based on that documentation ceases to be valid.

16. Data Security

16.1 Objectives
The CA SHALL develop, implement, and maintain a comprehensive security program designed to: 1. Protect the confidentiality, integrity, and availability of Certificate Data and Certificate Management Processes; 2. Protect against anticipated threats or hazards to the confidentiality, integrity, and availability of the Certificate Data and Certificate Management Processes; 3. Protect against unauthorized or unlawful access, use, disclosure, alteration, or destruction of any Certificate Data or Certificate Management Processes; 4. Protect against accidental loss or destruction of, or damage to, any Certificate Data or Certificate Management Processes; and 5. Comply with all other security requirements applicable to the CA by law.

16.2 Risk Assessment

The CAs security program MUST include an annual Risk Assessment that: 1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes; 2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and 3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.

16.3 Security Plan

Based on the Risk Assessment, the CA SHALL develop, implement, and maintain a security plan consisting of security procedures, measures, and products designed to achieve the objectives set forth above and to manage and control the risks identified during the Risk Assessment, commensurate with the sensitivity of the Certificate Data

- 157 -

and Certificate Management Processes. The security plan MUST include administrative, organizational, technical, and physical safeguards appropriate to the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST also take into account then-available technology and the cost of implementing the specific measures, and SHALL implement a reasonable level of security appropriate to the harm that might result from a breach of security and the nature of the data to be protected.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 28

16.4 Business Continuity

In addition, the CA SHALL document a business continuity and disaster recovery procedures designed to notify and reasonably protect Application Software Suppliers, Subscribers, and Relying Parties in the event of a disaster, security compromise, or business failure. The CA is not required to publicly disclose its business continuity plans but SHALL make the business continuity plan and security plan of Section 15.3 available to the CAs auditors upon request. The CA SHALL annually test, review, and update these procedures. The business continuity plan MUST include: 1. The conditions for activating the plan, 2. Emergency procedures, 3. Fallback procedures, 4. Resumption procedures, 5. A maintenance schedule for the plan; 6. Awareness and education requirements; 7. The responsibilities of the individuals; 8. Recovery time objective (RTO); 9. Regular testing of contingency plans. 10. The CAs plan to maintain or restore the CAs business operations in a timely manner following interruption to or failure of critical business processes 11. A requirement to store critical cryptographic materials (i.e., secure cryptographic device and activation materials) at an alternate location; 12. What constitutes an acceptable system outage and recovery time 13. How frequently backup copies of essential business information and software are taken; 14. The distance of recovery facilities to the CAs main site; and 15. Procedures for securing its facility to the extent possible during the period of time following a disaster and prior to restoring a secure environment either at the original or a remote site.

16.5 System Security1

The Certificate Management Process MUST include: 1. physical security and environmental controls; 2. system integrity controls, including configuration management, integrity maintenance of trusted code, and malware detection/prevention; 3. network security and firewall management, including port restrictions and IP address filtering; 4. user management, separate trusted-role assignments, education, awareness, and training; and 5. logical access controls, activity logging, and inactivity time-outs to provide individual accountability. The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance.

16.6 Private Key Protection

- 158 -

The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140 level 3 or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats. The CA SHALL implement physical and logical safeguards to prevent unauthorized certificate issuance. Protection of the Private Key outside the validated system or device specified above MUST consist of physical security, encryption, or a combination of both, implemented in a manner that prevents disclosure of the Private Key. The CA SHALL encrypt its Private Key with 1 The CA/Browser Forum will enact additional security requirements after the adoption of v1.0 of the Requirements.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 29
an algorithm and key-length that, according to the state of the art, are capable of withstanding cryptanalytic attacks for the residual life of the encrypted key or key part. The Private Key SHALL be backed up, stored, and recovered only by personnel in trusted roles using, at least, dual control in a physically secured environment.

17. Audit
Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with section 9.7 and audited in line with section 17.9 only, or Unconstrained and fully audited in line with all remaining requirements from section 17. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 basicConstraints extension, with the cA boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate.

17.1 Eligible Audit Schemes

The CA SHALL undergo an audit in accordance with one of the following schemes: 1. WebTrust for Certification Authorities v2.0; 2. A national scheme that audits conformance to ETSI TS 102 042; 3. A scheme that audits conformance to ISO 21188:2006; or 4. If a Government CA is required by its Certificate Policy to use a different internal audit scheme, it MAY use such scheme provided that the audit either (a) encompasses all requirements of one of the above schemes or (b) consists of comparable criteria that are available for public review. Whichever scheme is chosen, it MUST incorporate periodic monitoring and/or accountability procedures to ensure that its audits continue to be conducted in accordance with the requirements of the scheme. The audit MUST be conducted by a Qualified Auditor, as specified in Section 17.6.

17.2 Audit Period

The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration.

17.3 Audit Report

The Audit Report SHALL state explicitly that it covers the relevant systems and processes used in the issuance of all

- 159 -

Certificates that assert one or more of the policy identifiers listed in Section 9.3.1. The CA SHALL make the Audit Report publicly available. The CA is not required to make publicly available any general audit findings that do not impact the overall audit opinion. For both government and commercial CAs, the CA SHOULD make its Audit Report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, and if so requested by an Application Software Supplier, the CA SHALL provide an explanatory letter signed by the Qualified Auditor.

17.4 PreIssuance Readiness Audit

If the CA has a currently valid Audit Report indicating compliance with an audit scheme listed in Section 17.1, then no pre-issuance readiness assessment is necessary. If the CA does not have a currently valid Audit Report indicating compliance with one of the audit schemes listed in Section 17.1, then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-intime readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in Section 17.1. The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 30

17.5 Audit of Delegated Functions

If a Delegated Third Party is not currently audited in accordance with Section 17 and is not an Enterprise RA, then prior to certificate issuance the CA SHALL ensure that the domain control validation process required under Section 11.1 has been properly performed by the Delegated Third Party by either (1) using an out-of-band mechanism involving at least one human who is acting either on behalf of the CA or on behalf of the Delegated Third Party to confirm the authenticity of the certificate request or the information supporting the certificate request or (2) performing the domain control validation process itself. If the CA is not using one of the above procedures and the Delegated Third Party is not an Enterprise RA, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 17.1, that provides an opinion whether the Delegated Third Partys performance complies with either the Delegated Third Partys practice statement or the CAs Certificate Policy and/or Certification Practice Statement. If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions. The audit period for the Delegated Third Party SHALL NOT exceed one year (ideally aligned with the CAs audit). However, if the CA or Delegated Third Party is under the operation, control, or supervision of a Government Entity

- 160 -

and the audit scheme is completed over multiple years, then the annual audit MUST cover at least the core controls that are required to be audited annually by such scheme plus that portion of all non-core controls that are allowed to be conducted less frequently, but in no case may any non-core control be audited less often than once every three years.

17.6 Auditor Qualifications

The CAs audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills: 1. Independence from the subject of the audit; 2. The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see Section 17.1); 3. Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function; 4. (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ETSI TS 119 403, or accredited to conduct such audits under an equivalent national scheme, or accredited by a national accreditation body in line with ISO 27006 to carry out ISO 27001 audits; 5. (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust; 6. Bound by law, government regulation, or professional code of ethics; and 7. Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage.

17.7 Key Generation Ceremony

For Root CA Key Pairs created after the Effective Date that are either (i) used as Root CA Key Pairs or (ii) Key Pairs generated for a subordinate CA that is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL: 1. prepare and follow a Key Generation Script, 2. have a Qualified Auditor witness the Root CA Key Pair generation process or record a video of the entire Root CA Key Pair generation process, and 3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 31
For other CA Key Pairs created after the Effective Date that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD: 1. prepare and follow a Key Generation Script and 2. have a Qualified Auditor witness the Root CA Key Pair generation process or record a video of the entire Root CA Key Pair generation process. In all cases, the CA SHALL: 1. generate the keys in a physically secured environment as described in the CAs Certificate Policy and/or Certification Practice Statement; 2. generate the CA keys using personnel in trusted roles under the principles of multiple person control and split knowledge; 3. generate the CA keys within cryptographic modules meeting the applicable technical and business

- 161 -

requirements as disclosed in the CAs Certificate Policy and/or Certifi cation Practice Statement; 4. log its CA key generation activities; and 5. maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its Certificate Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.

17.8 Regular Quality Assessment Self Audits

During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its Certificate Policy, Certification Practice Statement and these Requirements and strictly control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken. Except for Delegated Third Parties that undergo an annual audit that meets the criteria specified in Section 16.3, the CA SHALL strictly control the service quality of Certificates issued or containing information verified by a Delegated Third Party by having a Validation Specialist employed by the CA perform ongoing quarterly audits against a randomly selected sample of at least the greater of one certificate or three percent of the Certificates verified by the Delegated Third Party in the period beginning immediately after the last sample was taken. The CA SHALL review each Delegated Third Partys practices and procedures to ensure that the Delegated Third Party is in compliance with these Requirements and the relevant Certificate Policy and/or Certification Practice Statement.

17.9 Regular Quality Assessment of Technically Constrained Subordinate CAs

During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CAs Certificate Policy and the Subordinate CAs Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA shall ensure all applicable Baseline Requirements are met.

18. Liability and Indemnification

18.1 Liability to Subscribers and Relying Parties
If the CA has issued and managed the Certificate in compliance with these Requirements and its Certificate Policy and/or Certification Practice Statement, the CA MAY disclaim liability to the Certificate Beneficiaries or any other third parties for any losses suffered as a result of use or reliance on such Certificate beyond those specified in the CA's Certificate Policy and/or Certification Practice Statement. If the CA has not issued or managed the Certificate in compliance with these Requirements and its Certificate Policy and/or Certification Practice Statement, the CA

- 162 -

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 32
MAY seek to limit its liability to the Subscriber and to Relying Parties, regardless of the cause of action or legal theory involved, for any and all claims, losses or damages suffered as a result of the use or reliance on such Certificate by any appropriate means that the CA desires. If the CA chooses to limit its liability for Certificates that are not issued or managed in compliance with these Requirements or its Certificate Policy and/or Certification Practice Statement, then the CA SHALL include the limitations on l iability in the CAs Certificate Policy and/or Certification Practice Statement.

18.2 Indemnification of Application Software Suppliers

Notwithstanding any limitations on its liability to Subscribers and Relying Parties, the CA understands and acknowledges that the Application Software Suppliers who have a Root Certificate distribution agreement in place with the Root CA do not assume any obligation or potential liability of the CA under these Requirements or that otherwise might exist because of the issuance or maintenance of Certificates or reliance thereon by Relying Parties or others. Thus, except in the case where the CA is a government entity, the CA SHALL defend, indemnify, and hold harmless each Application Software Supplier for any and all claims, damages, and losses suffered by such Application Software Supplier related to a Certificate issued by the CA, regardless of the cause of action or legal theory involved. This does not apply, however, to any claim, damages, or loss suffered by such Application Software Supplier related to a Certificate issued by the CA where such claim, damage, or loss was directly caused by such Application Software Suppliers software displaying as not trustworthy a Certificate that is still valid, or displaying as trustworthy: (1) a Certificate that has expired, or (2) a Certificate that has been revoked (but only in cases where the revocation status is currently available from the CA online, and the application software either failed to check such status or ignored an indication of revoked status).

18.3 Root CA Obligations

The Root CA SHALL be responsible for the performance and warranties of the Subordinate CA, for the Subordinate CAs compliance with these Requirements, and for all liabilities and indemnification obligati ons of the Subordinate CA under these Requirements, as if the Root CA were the Subordinate CA issuing the Certificates.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 33

Appendix A Cryptographic Algorithm and Key Requirements (Normative)

Certificates MUST meet the following requirements for algorithm type and key size. (1) Root CA Certificates Validity period beginning on or before 31 Dec 2010 Validity period beginning after

- 163 -

31 Dec 2010 Digest algorithm MD5 (NOT RECOMMENDED), SHA-1, SHA-256, SHA-384 or SHA512 SHA-1*, SHA-256, SHA-384 or SHA-512 Minimum RSA modulus size (bits) 2048** 2048 ECC curve NIST P-256, P-384, or P-521 NIST P-256, P-384, or P-521 Minimum DSA modulus and divisor size (bits) L= 2048, N= 224 or L= 2048, N= 256, L= 2048, N= 224 or L= 2048, N= 256 L= 2048, N= 224 or L= 2048, N= 256, L= 2048, N= 224 or L= 2048, N= 256 (2) Subordinate CA Certificates Validity period beginning on or before 31 Dec 2010 and ending on or before 31 Dec 2013 Validity period beginning after 31 Dec 2010 or ending after 31 Dec 2013 Digest algorithm SHA-1, SHA-256, SHA-384 or SHA512 SHA-1*, SHA-256, SHA-384 or SHA-512 Minimum RSA modulus size (bits) 1024 2048 ECC curve NIST P-256, P-384, or P-521 NIST P-256, P-384, or P-521 Minimum DSA modulus and divisor size (bits) L= 2048, N= 224 or L= 2048, N= 256, L= 2048, N= 224 or L= 2048, N= 256 L= 2048, N= 224 or L= 2048, N= 256, L= 2048, N= 224 or L= 2048, N= 256 (3) Subscriber Certificates Validity period ending on or before 31 Dec 2013 Validity period ending after 31 Dec 2013 Digest algorithm

- 164 -

SHA1*, SHA-256, SHA-384 or SHA512 SHA1*, SHA-256, SHA-384 or SHA-512 Minimum RSA modulus 1024 2048

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 34
size (bits) ECC curve NIST P-256, P-384, or P-521 NIST P-256, P-384, or P-521 Minimum DSA modulus and divisor size (bits) L= 2048, N= 224 or L= 2048, N= 256, L= 2048, N= 224 or L= 2048, N= 256 L= 2048, N= 224 or L= 2048, N= 256, L= 2048, N= 224 or L= 2048, N= 256 * SHA-1 MAY be used with RSA keys until SHA-256 is supported widely by browsers used by a substantial portion of relying-parties worldwide. ** A Root CA Certificate issued prior to 31 Dec. 2010 with an RSA key size less than 2048 bits MAY still serve as a trust anchor for Subscriber Certificates issued in accordance with these Requirements. L and N (the bit lengths of modulus p and divisor q, respectively) are described in the Digital Signature Standard, FIPS 186-3 (http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf). (4) General requirements for public keys RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. Additionally, the public exponent SHOULD be in the range between 216+1 and 2256-1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89]. DSA: Although FIPS 800-57 says that domain parameters may be made available at some accessible site, compliant DSA certificates MUST include all domain parameters. This is to insure maximum interoperability among relying party software. The CA MUST confirm that the value of the public key has the unique correct representation and range in the field, and that the key has the correct order in the subgroup. [Source: Section 5.3.1, NIST SP 800-89]. ECC: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.5 and 5.6.2.6, respectively, NIST SP 80056A].

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 35

Appendix B Certificate Extensions (Normative)

This appendix specifies the requirements for Certificate extensions for Certificates generated after the Effective

- 165 -

Date.

(1) Root CA Certificate

Root Certificates MUST be of type X.509 v3. A. basicConstraints This extension MUST appear as a critical extension. The cA field MUST be set true. The pathLenConstraint field SHOULD NOT be present. B. keyUsage This extension MUST be present and MUST be marked critical. Bit positions for keyCertSign and cRLSign MUST be set. If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set. C. certificatePolicies This extension SHOULD NOT be present. D. extendedKeyUsage This extension MUST NOT be present.

(2) Subordinate CA Certificate

Subordinate CA Certificates MUST be of type X.509 v3. A. certificatePolicies This extension MUST be present and SHOULD NOT be marked critical. certificatePolicies:policyIdentifier (Required) The following fields MAY be present if the Subordinate CA is not an Affiliate of the entity that controls the Root CA. certificatePolicies:policyQualifiers:policyQualifierId (Optional) id-qt 1 [RFC 5280]. certificatePolicies:policyQualifiers:qualifier:cPSuri (Optional) HTTP URL for the Root CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the CA. B. cRLDistributionPoints This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CAs CRL service. C. authorityInformationAccess With the exception of stapling, which is noted below, this extension MUST be present. It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CAs OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the Issuing CAs certificate (accessMethod = 1.3.6.1.5.5.7.48.2). See Section 13.2.1 for details.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 36
The HTTP URL of the Issuing CAs OCSP responder MAY be omitted, provided that the Subscriber staples the OCSP response for the Certificate in its TLS handshakes [RFC4366]. D. basicConstraints This extension MUST be present and MUST be marked critical. The cA field MUST be set true. The pathLenConstraint field MAY be present. E. keyUsage This extension MUST be present and MUST be marked critical. Bit positions for keyCertSign and cRLSign MUST be set. If the Subordinate CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set. F. nameConstraints (optional) If present, this extension SHOULD be marked critical*. * Non-critical Name Constraints are an exception to RFC 5280 (4.2.1.10), however, they MAY be used until the Name Constraints extension is supported by Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide. G. extkeyUsage (optional) For Subordinate CA Certificates to be Technically constrained in line with section 9.8, then either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present**. Other values MAY be present.

- 166 -

If present, this extension SHOULD be marked non-critical. ** Generally Extended Key Usage will only appear within end entity certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate CAs MAY include the extension to further protect relying parties until the use of the extension is consistent between Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide.

(3) Subscriber Certificate

A. certificatePolicies This extension MUST be present and SHOULD NOT be marked critical. certificatePolicies:policyIdentifier (Required) A Policy Identifier, defined by the issuing CA, that indicates a Certificate Policy asserting the issuing CA's adherence to and compliance with these Requirements. The following extensions MAY be present: certificatePolicies:policyQualifiers:policyQualifierId (Recommended) id-qt 1 [RFC 5280]. certificatePolicies:policyQualifiers:qualifier:cPSuri (Optional) HTTP URL for the Subordinate CA's Certification Practice Statement, Relying Party Agreement or other pointer to online information provided by the CA. B. cRLDistributionPoints This extension MAY be present. If present, it MUST NOT be marked critical, and it MUST contain the HTTP URL of the CAs CRL service. See Section 13.2.1 for details.

Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 37
C. authorityInformationAccess With the exception of stapling, which is noted below, this extension MUST be present. It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CAs OCSP responder (accessMeth od = 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the Issuing CAs certificate (accessMethod = 1.3.6.1.5.5.7.48.2). See Section 13.2.1 for details. The HTTP URL of the Issuing CAs OCSP responder MAY be omitted provided that the Subscriber staples OCSP responses for the Certificate in its TLS handshakes [RFC4366]. D. basicConstraints (optional) If present, the cA field MUST be set false. E. keyUsage (optional) If present, bit positions for keyCertSign and cRLSign MUST NOT be set. F. extKeyUsage (required) Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present. Other values SHOULD NOT be present.

(4) All Certificates

All other fields and extensions MUST be set in accordance with RFC 5280. The CA SHALL NOT issue a Certificate that contains a keyUsage flag, extendedKeyUsage value, Certificate extension, or other data not specified in this Appendix B unless the CA is aware of a reason for including the data in the Certificate. CAs SHALL NOT issue a Certificate with: (a) Extensions that do not apply in the context of the public Internet (such as an extendedKeyUsage value for a service that is only valid in the context of a privately managed network), unless: i. such value falls within an OID arc for which the Applicant demonstrates ownership, or ii. the Applicant can otherwise demonstrate the right to assert the data in a public context; or (b) semantics that, if included, will mislead a Relying Party about the certificate information verified by the CA (such as including extendedKeyUsage value for a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance).

Forum Guideline

- 167 -

CA / Browser Forum Baseline Requirements, v. 1.1.6 (as of 29 July 2013) 38

- 168 -

Appendix D: History of Changes

History of changes: version 3.8.14 (Dec 2013)

Description
Change of expiration date for 1024bit certificates Updated exception language for Affiliate PC CAs

Section & Changes made

Section 6.1.5 Changed date to January 31, 2014 Section 6.3.2 Added Customer CAs and changed last date for exception to be applied to December 31, 2013.

History of changes: version 3.8.13 (Nov 2013)

Description
Section 1 Introduction 6.1.5 Key sizes 7.1 Certificate Profile 7.1.2.1 Key Usage Appendix B1 Appendix D

Section & Changes made

Identified conformity to CABF Baseline Requirements Added clarity regarding subscriber certificates under 2048bit will have EKU without server auth flag and designated OID Added clarity regarding subscriber certificates under 2048bit will have EKU without server auth flag and designated OID Authorization of certificates 2048bit and less in length to be used within closed eco systems Updated Extended Validation Guidelines to version 1.4.3 Updated Baseline Requirements to version 1.1.6

History of changes: version 3.8.12 (Feb 2013)

Description
Addition of new Roots Clarification of Audit log processing procedure. Addition of Mozilla IDN Verification requirements

Section & Changes made

Section 6.1.5 Added G4, G6 & G7 PCAs Section 5.4.2 Clarification of Audit log processing procedure. Section 3.2.2 Added procedure for verification of IDNs to detect cases of homographic spoofing of IDNs.

History of changes: version 3.8.11 (Jan 2013)

Description
Re-alignment with CABF EV v1.4 Guidelines

Section & Changes made

Updated Appendix B1 all sections to match re-structured CABF Guidelines. Updated Appendix C (EV CodeSigning) for cross-references to & from Appendix B1. Created Appendix D (Baseline for OV & DV Certs) for cross-references to & from Appendix B1. CPS updated throughout with references to Appx B1, C & D as required for CABF procedures.

History of changes: version 3.8.10

Description
Addition of 2048 DSA Roots Addition of Private Class 3 Admin hierarchy

Section & Changes made

6.1.5 Key Sizes Symantecs seventh generation (G7) PCAs have 2048 bit DSA key pairs. 1.1 Overview Symantec Infrastructure CAs, and Symantec Administrative CAs1 supporting the Symantec Trust Network

Unless specifically noted within this CPS, Private CAs and hierarchies managed by Symantec are outside the scope of this CPS2. The CAs managed by Affiliates are also outside the scope of this CPS. Footnote: [1] Symantec operates both public and private/internal Class 3 hierarchies within the scope of this CPS. The Class 3 Internal CA hierarchy is distinguished by a private PCA and the specified OID value as stipulated in section 1.2 of the CP. The private PCA certificate is configured to explicitly exclude Server Authentication and Code-Signing from the certificate intended purposes. 1.3.1 Certification Authorities

- 169 -

Description

Section & Changes made

Symantec also operates the Symantec Class 3 Internal Administrator CA hierarchy limited to Symantec for internal administrative uses. Symantec also operates the Symantec Universal Root Certification Authority and the Symantec ECC Universal Root Certification Authority. The Universal Root CAs issue Class 3 and selected Class 2 Subordinate CAs. Symantec enterprise customers may operate their own CAs as subordinate CAs to a public STN PCA. 3.1.1 Naming CN = Persona Not Validated for Class 1 Individual Certificat es 4.9.3.1 Revocation Request Non-Enterprise customers shall communicate a revocation request in accordance with CPS 3.4.

CN attribute value for Class 1 individual certificates Revocation requests for nonenterprise customers do not communicate via the Enterprise Administrator. History of changes: version 3.8.9

Description
All updates reflecting compliance with CABF Requirements for EV Code Signing Certificates, v1.4. Routine maintenance

Section & Changes made

Appendix C. Section 1.4.1.2, Table 2 added CS certificates to Class 3 EV Certificates category Section 3.2.2, Table 6 added additional procedures for EV-CS certificates & H/W protected EV-CS Certificates Section 1, page 1, added footnote clarifying/defining organizational certificates Removed Secure Server CA & Secure Server ID sections 1.3.1, 3.1.1, 6.3.2.1, Appx A definition Removed ASB Cert sections 2.1, 3.1.1, 4.9.1, 4.9.3.1, Appx A definition Corrected TGV protocol to TGV Service in section 7.3 Change for Re-branded Symantec Repository URL throughout www.symantec.com/about/profile/policies/repository.jsp Changed to affirmative language: Symantec confirms instead of CA shall confirm in sections 3.2.2.1, 4.1.2.2, 4.9.3.2, 4.9.7.1, 4.9.9.1, 6.1.5.1, 6.3.2.1, 6.5.1.1, 7.1.2.2.1, Clarified the reference to Policy OIDs: the corresponding policy identifier identified in section 1.2 of the STN CP in section 7.1.6.1

History of changes: version 3.8.8

Description
All updates reflecting compliance with CABF Requirements for DV and OV certificates, Effective July 1, 2012. History of changes: version 3.8.7

Section & Changes made

Throughout document. See PWG Approval Mapping Matrix for STN CP & CPS for detailed changes.

Description
Clarification of Universal Root restricted to only Class 3 and selected Class 2 certificates. Customization requirement clarified for customer that performs their own RA services. Log processing improvement added. Updated BCP with migration to Symantec Corp Extend the validity period of s/w certs from 2 to 3

Section & Changes made

1.3.1 Symantec also operates the Symantec Universal Root Certification Authority and the Symantec ECC Universal Root Certification Authority. The Universal Root CAs are not defined under a particular certificate Class, and may issue Class 3 and selected Class 2 any class of Subordinate CAs. 3.1.1 footnote added: OU= Authenticated by Symantec
1 1

An affiliate or customer that contracts to perform the RA services shall indicate the name of the organization performing the Subscriber authentication. 5.4.2 The CA system and audit logs are continuously monitored to provide real time alerts of examined on at least a weekly basis for significant security and operational events. 5.7.4 Replaced former VeriSign BCP description for the Symantec BCP description.. 6.3.2

- 170 -

Description
years before requiring renewal/rekey.

Section & Changes made

Certificate Issued by: Online CA to End-user Individual Subscriber Validity Period Normally up to 2 3 years, but under the conditions described below, up to 6 years29 under the conditions described below with no option to renew or re-key. After 6 years new enrollment is required.

Certificates issued by CAs to end-user Subscribers may have Operational Periods longer than two three years, up to six years, if the following requirements are met: Protection of the Subscriber key pairs in relation to its operational environment for Organizational Certificates, operation within the enhanced protection of a data center and for Individual Certificates, the Subscribers key pairs reside on a hardware token, such as a smart card,

History of changes: version 3.8.6

Description
The exception for extending validity of legacy 1024-bit CA keys beyond 14 yrs & limited to a maximum validity to August 31, 2012 and only available until Dec 31, 2011.

Section & Changes made

6.1.5 The Symantec Standard for minimum key sizes is the use of key pairs equivalent in strength to 2048 bit RSA for PCAs and CAs. [1] CA trust is extended to Symantecs first and second generation (G1 and G2) legacy Trusted Roots with 1024 bit RSA key pairs for support of customer legacy platforms and 1024-bit RSA end-entity certificates may be issued with expiration on or before December 31, 2011. Additional individual exceptions may be permitted for affiliates of Symantec Corporation operating the Processing Center software capabilities in accordance with section 6.3.2 with prior approval to preserve business continuity of legacy applications beyond 2011. 6.3.2 In terms of Section 6.3.2 of the STN CP, the Symantec PMA has approved an exception to extend a limited number CAs beyond the specified limits, in order to ensure uninterrupted PKI services during CA key pair migration. This exception can be applied to affiliates of Symantec Corporation operating the Processing Center software capabilities for infrastructure and Admin CAs only that are not associated with CAs issuing SSL certificates. This exception may not be used to extend a CAs validity beyond a 13 14 year total validity to a maximum of April 30, 2014 August 31, 2014, and shall not be made available after April 30, 2011 December 31, 2011

History of changes: version 3.8.5

Description
Transition from VeriSign to Symantec including: naming, URLs, email addresses. DN names within legacy certs now represent the new owner.

Section & Changes made

Throughout document, Naming: VeriSign Inc to Symantec Corporation VeriSign Trust Network(VTN) to Symantec Trust Network (STN) URLs: from verisign.com to symauth.com Email address: from verisign.com to symantec.com Section 3.1.1 While the STN is now owned by Symantec Corporation (see Acquisition Notice on p ii) legacy certificates have been issued indicating the former owner name and brand. Such legacy certificates that indicate the Organization (O) as VeriSign Inc. and Organizational Unit (OU) as VeriSign Trust Network now represent Symantec Corporation and the Symantec Trust Network. Section 3.1.1 OU = No organization affiliation (for code signing certificates issued to individuals) CN = Persons name (for individual Certificates or code-signing certificates issued to individuals). Section 3.1.1 added footnotes.

Changes for authentication permitting code-signing certificates for individuals DN naming for Class 2 certificates issued for internal Symantec purposes

Organization (O) = Symantec Corporation for OCSP Responder and optionally for 8 individual Certificates that do not have an organization affiliation.
8

In the case of the Symantec Corporation organization, under certain approved cases for Class 2 certificates, the O value may additionally include a suffix containing internal information used for internal purposes. Symantec attests that the organization name in the format Symantec Corporation <suffix> (e.g., Symantec Corporation Build 5315) shall accurately represent the legal entity Symantec Corporation.

29

If 6-year end-user subscriber certificates are issued, the online CA certificates operational period will be 10 years with no option to renew. CA re-key will be required after 5 years.

- 171 -

Description

Section & Changes made 9 Organizational Unit (OU) = Text to describe the type of Certificate
9

Discontinuing selfrevocation in the Magnum release.

Clarified the conditions for revoking the recovered key. Removed the restriction to only Symantec RAs. Requirement applies to all.

The exception for extending CA validity beyond 13 yrs is limited to a maximum of April 30, 2014. Removed statement on EAL-4 certification of the PC software.

Updates to EKUs and their corresponding criticality.

Change to BasicConstraints setting for Subscriber certs.

Under certain approved cases, Class 2 certificates may be issued for internal purposes. Such certificates shall contain the Symantec organization name in the DN and an OU value reflecting the inherent lack of trust in the certificate for usage other than the intended internal purpose. Section 3.4. Having the Subscriber for certain certificate types submit the Subscribers Challenge Phrase (or the equivalent thereof), and revoking the Certificate automatically if it matches the Challenge Phrase (or the equivalent thereof) on record. (Note that this option may not be available to all customers.) Section 4.9.2 Individual Subscribers can request the revocation of their own individual Certificates through an authorized representative of Symantec or an RA. Section 4.12.1 Revoke the Subscribers Key pair prior to recovering the encryption key under certain circumstances such as to discontinue the use of a lost certificate. Section 6.2.9 Symantec RA private keys (used for authentication to the RA application) are deactivated upon system log off. Symantec RAs are required to log off their workstations when leaving their work area. Section 6.4.2: Symantec RAs are required to store their Administrator/RA private keys in encrypted form using password protection and their browsers high security option. Section 6.3.2 the Symantec PMA has approved an exception to extend a limited number CAs beyond the specified limits, in order to ensure uninterrupted PKI services during CA key pair migration. This exception may not be used to extend a CAs validity beyond a 13 year total validity to a maximum of April 30, 2014, and shall not be made available after April 30, 2011. Section 6.5.2 A version of Symantecs core Processing Center software has satisfied the EAL 4 assurance requirements of ISO/IEC 15408-3:1999, Information technology - Security techniques -- Evaluation criteria for IT security -- Part 3: Security assurance requirements, based on an independent laboratorys Common Criteria evaluation of the software against the Symantec Processing Center Security Target. Symantec may, from time to time, evaluate new releases of the Processing Center software under the Common Criteria. No stipulation. Section 7.1.2.1 Table 6 is removed as well as the sentence introducing the table. Section 7.1.2.5 Table 7 is removed as well as the sentence introducing the table. Section 7.1.2.4. End-user Subscriber Certificates BasicConstraints extension shall have the CA field set to FALSE shall be populated with a value of an empty sequence. The criticality field of this extension shall be set to TRUE for CA Certificates, but otherwise set to false may be set to TRUE or FALSE for end-user Subscriber Certificates.

History of changes: version 3.8.4

Description
Correction for publishing Class 3 certificates depending on usage.

Section & Changes made

Section 2.2, Table 3: Certificate Type End-User Subscriber Certificates with exceptions for certain Class 3 Certificates depending on usage. Publication Requirements Optionally published and available to Relying Parties through query functions in the VeriSign Repository at https://digitalid.verisign.com/services/client/index.html and query of the LDAP directory server at directory.Symantec.com, except for Class 3 SSL and Code Signing Certificates which are available through query functions in the VeriSign Repository at https://digitalid.verisign.com/services/server/search.htm.

Section 4.9.9: Certificate status information is available though web-based query functions accessible through the VeriSign Repository at https://digitalid.verisign.com/services/client/index.html (for Individual Certificates) and https://digitalid.verisign.com/services/server/search.htm (for SSL and Code Signing Server and Developer Certificates). Section 7.1.2.3

Exception for excluding

- 172 -

Description
email address in subjAltName for Public Lite accounts Updated policy to delete all descriptions of the planned transition on or before 31 Dec 2010. Added individual exceptions identified by footnote.

Section & Changes made

The subjectAltName extension of X.509 Version 3 Certificates are populated in accordance with RFC 5280 with the exception of those issued under Public Lite accounts which may optionally exclude the email address in SubjAltName. The criticality field of this extension shall be set to FALSE. 6.1.5 Key Sizes The Symantec Standard for minimum key sizes is the use of key pairs equivalent in strength to 2048 bit RSA for PCAs and CAs15. Symantecs first and second generation (G1 and G2) PCAs and CAs have 1024 bit RSA key pairs and Symantecs third and fifth generation (G3 and G5) PCAs have 2048 bit RSA key pairs. The signing of all Classes of Symantec Certificates using RSA key pairs shall transition to roots with a minimum 2048 bit (or equivalent) key size no later than December 31, 2013. Symantec recommends the use of issues a minimum key size equivalent in strength to 2048 bit RSA for RAs and end entity certificates key pairs. Symantec will phase out all 1024-bit RSA by December 31, 2013. Footnote added for exceptions: 15 CA trust is extended to Symantecs first and second generation (G1 and G2) legacy Trusted Roots with 1024 bit RSA key pairs for support of customer legacy platforms and 1024-bit RSA end-entity certificates may be issued with expiration on or before December 31, 2011. Additional individual exceptions may be permitted with prior approval to preserve business continuity of legacy applications. Appendix B2 (EV Certificates)

Root, Subordinate CA & Subscriber Certificates now each reflect the following: Certificates issued on or before 31 Dec 2010 Digest algorithm SHA-1 SHA-1*, SHA-256, SHA-384 or SHA-512 RSA 2048 bit or 2048 bit 2048 bit ECC 256 or 384 bits 256 or 384 bits *SHA-1 should shall be used until SHA-256 is supported widely by browsers used by a majority of Relying Parties worldwide. Section 6.3.2 Updates for CAs identified in exceptions Removed CL3 Organizational VIP Device CA that is no longer in service. Symantec operates the Symantec Class 3 Organizational VIP Device CA. Organizational endentity certificates issued by this CA may have a validity period beyond 3 years and up to a maximum of 5 years in circumstances where: The certificate key pair is stored in hardware, and Symantec has authenticated the Organization in terms of this CPS, and When used to protect a server using SSL/TLS, the server is only accessible via a private network or intranet. Added CL 3 Onsite Enterprise Admin CA G2 as exception with >10 years lifetime (footnote #17) The VeriSign Onsite Administrator CA-Class 3, Class 3 Secure Server Operational Administrator CA and Class 3 OnSite Enterprise Administrator CA G2 have a validity beyond 10 years to support legacy systems and shall be revoked when appropriate Changes for Auto-Renew 6-year certificate lifetimes and 6-year certificate lifetimes for Enterprise & Client PKI: DN re-authentication occurs at intervals but without a cert re-key event. DN re-authentication occurs at intervals but without a cert renewal event. 2 new conditions for cert revocation for Auto-Renew process. The online issuing CA of 6year certificates must have 10-yr validity period. CAs with 10-year lifetimes must be re-keyed after 5 years. Re-enrollment of the End entity certificate is required Section 3.3.1 In particular, for subsequent re-key requests for retail Class 3 Organizational SSL Certificates, Symantec re-authenticates the Organization name and domain name included in the certificate at intervals described in section 6.3.2. Section 4.6.3 In particular, for subsequent renewal requests for retail Class 3 Organizational SSL Certificates, Symantec re-authenticates the Organization name and domain name included in the certificate at intervals described in section 6.3.2. Section 4.9.1 An end-user Subscriber Certificate is revoked if (2 bullets added) The Subscriber identity has not been successfully re-verified in accordance with section 6.3.2, The Subscriber has not submitted payment when due, Section 6.3.2, in Table 8 & footnote #18 Certificate Issued By: Validity Period: Offline intermediate CA Generally 5 years but up to 10 years after renewal 18 to online CA 18 If 6 5-year end-user subscriber certificates are issued, the online CA certificates operational period will be 10 years with no option to renew. CA re-key will be required after 5 years. In Table 8 & footnote #19

- 173 -

Description
at end of a 6-yr certificate validity period. CAs with 10-year lifetimes must be re-keyed after 5 years.

Section & Changes made

Validity Period: Normally up to 2 years, but under the conditions described below, up to 6 5 years19 under the conditions described below with no option to renew or re-key. After 6 years new enrollment is required. 19 If 6 5-year end-user subscriber certificates are issued, the online CA certificates operational period will be 10 years with no option to renew. CA re-key will be required after 5 years. Section 6.3.2 in Table 8 & footnote #20 Certificate Issued By: Validity Period: Online CA to End-user Normally up to 6 5 years20 under the conditions Organizational described below with no option to renew or re-key. Subscriber After 6 years new enrollment is required.
20

Certificate Issued By: Online CA to End-user Individual Subscriber

Certificates with 6-yr lifetime must be re-verified after 3 years.

Clarify restrictions that are applicable to Certificates issued with 6-year lifetimes

At a minimum, the Distinguished Name of 4, and 5 year validity SSL certificates issued with a validity of more than 3 years is re-verified after three years from date of certificate issuance. With the exception of the VeriSign Automated Administration certificate, Organizational end-entity certificates used solely to support the operation of a portion of the VTN may be issued with a validity period of 5 year and up to a maximum of 10 years after renewal. Section 6.3.2 Certificates issued by CAs to end-user Subscribers may have Operational Periods longer than two years, up to five six years, if the following requirements are met: The Certificates are individual Certificates, Protection of the Subscriber key pairs in relation to its operational environment for Organization Certificates, operation with the enhanced protection of a data center and for Individual Certificates, the Subscribers key pairs reside on a hardware token, such as a smart card, Subscribers are required to undergo re-authentication at least every 3 years 25 months under Section 3.2.3, Subscribers shall prove possession of the private key corresponding to the public key within the Certificate at least every 25 months under Section 3.2.3, If a Subscriber is unable to complete re-authentication procedures successfully or is unable to prove possession of such private key when required by the foregoing, the CA shall revoke the Subscribers Certificate.

History of changes: version 3.8.3

Description
Updated Trademarks Notices page & added Acquisition Notice. Changes to identify Symantec Corporation acquisition & ownership of the VTN CA services.

Section & Changes made

Page ii. Throughout document: Corporate owner & contact information changed to Symantec Corporation CA names and VTN branding continues to reflect the VeriSign name until such time that re-branding can occur. Sections 9.2.2, 9.14, 9.13.2 & 9.4.1 Sections 6.2.8.2, 6.2.8.3 & Appendix A Section 3.2.6 footnote Section 7.3 Section 6.3.2, footnote #16

Changes to Governing law & Assets & Privacy Plan in accord with Symantec ownership. Removed VeriSign Roaming Services which is EOL Removed reference to Certificate Interoperability Service (CIS) which is EOL Clarification of TGV services Clarified Symantec approval required for exceptions to certificate validity periods History of changes: version 3.8.2

Description
Changes to describe CA transitions, Key Sizes & Universal Roots RSA:

Section & Changes made

1.3.1 Certificate Authorities VeriSign also operates the VeriSign Universal Root Certification Authority and the VeriSign ECC Universal Root Certification Authority. The VeriSign Universal Root CAs are Certification Authority is not defined under a particular certificate Class, and may issue any class of Subordinate CA. 6.1.5 Key Sizes Key pairs shall be of sufficient length to prevent others from determining the key pairs private key

- 174 -

Description
Roots & CAs are transitioning to 2048 as of 31 Dec 2013. EV certs are transitioning to 2048 as of 31 Dec 2010. RAs & EE are recommended to generate 2048 but 1024 will continue to be approved. But all 1024 RSA will phased out by 31 Dec 2013.

Section & Changes made

using cryptanalysis during the period of expected utilization of such key pairs. The current VeriSign Standard for minimum key sizes is the use of key pairs equivalent in strength to 10242048 bit RSA for PCAs and CAs, except for the legacy Secure Server CA whose key pair is 1000 bit RSA. VeriSigns first and second generation (G1 and G2) PCAs and CAs have 1024 bit RSA key pairs and Symantecs third and fifth generation (G3 and G5) PCAs have 2048 bit RSA key pairs. The signing of all Classes of VeriSign Certificates using RSA key pairs shall transition to roots with a minimum 2048 (or equivalent) key size no later than December 31, 2013. VeriSign recommends the use of a minimum key size equivalent in strength to 2048 bit RSA for RAs and end entity certificates key pairs. VeriSign will continue to approve certain end entity certificates generated with a key pair size of less than 2048 bit RSA but will phase out all 1024-bit RSA by December 31, 2013. VeriSign recommends that Registration Authorities and end user Subscribers generate 1024 bit RSA key pairs. Verisign may not approve certain end entity certificates generated with a key pair size of 512 bit or less. VeriSigns ECC Universal Root CA and fourth generation (G4) Class 3 PCA has 384 bit ECC. All Classes of VeriSign PCAs and CAs, and RAs and end entity certificates use either SHA-1 or SHA-2 for digital signature hash algorithm and certain versions of VeriSign Processing Center support the use of SHA-256, SHA-384 and SHA-512 encryption algorithms in end-entity Subscriber Certificates. 6.3.2 Certificate Operational Periods & Key Pair Usage Periods Table 4: PCA self-signed (1024 bit RSA) - Up to 30 years PCA self-signed (1024 bit RSA) - Up to 30 years PCA self-signed (256 bit ECC) - Up to 30 years PCA self-signed (384 bit ECC) - Up to 30 years And: VeriSign also operates the "VeriSign Class 3 International Server CA", Thawte SGC CA and the "Class 3 Open Financial Exchange CA-G2" which are online CAs signed by a PCA. The validity of these CAs may exceed the validity periods described in Table 8 above to ensure continued interoperability of certificates offering SGC and OFX capability. 7.1.3 Algorithm Object Identifiers sha256withRSAEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11} ecdsa-with-Sha256 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-X962(10045) signatures(4) ecdsa-with-SHA2 (3) 2} ecdsa-with-Sha384 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-X962(10045) signatures(4) ecdsa-with-SHA2 (3) 3} sha-1WithRSAEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5} md5WithRSAEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4} md2WithRSAEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2} Either sha-1WithRSAEncryption or sha-256WithRSAEncryption shall be given strong preference is used over md5WithRSAEncryption.** md2WithRSAEncryption is no longer used to sign end entity certificates, but is used to sign CRLs for certain legacy CA and End-User Subscriber Certificates. Footnote added: **md5WithRSAEncryption is used only with prior approval to preserve business continuity of legacy applications. 7.2 CRL Profile Signature Algorithm - Algorithm used to sign the CRL. VeriSign CRLs are signed using the sha1WithRSAEncryption (OID: 1.2.840.113549.1.1.5) or md5WithRSAEncryption (OID: 1.2.840.113549.1.1.4) in accordance with RFC 3279. (See CP 7.1.3) Appendix B2 ECC 224, 233, 256 or 283 384 bits 4.12 Key Escrow and Recovery Enterprise customers using Managed PKI Key Management Service (KMS) can escrow copies of the private keys of Subscribers whose Certificate Applications they approve. The enterprise customer may use KMS operated either out of the enterprises premises or VeriSigns secure data center. If operated out of the enterprises premises, VeriSign does not store copies of Subscriber private keys but nevertheless plays an important role in the Subscriber key recovery process. 4.12.2 Session Key Encapsulation and Recovery Policy Practices

ECC: 384 bit ECC CL3PCA-G4 is the Universal Root.

Algorithms: -Sha1&256 with RSA -Sha256&384 with ECC -md5 only under prior agreement -No md2

Remote Hosted KMS KMS provides option for customer to host the KMS & KMD on their own premises.

- 175 -

Description

Section & Changes made

Private keys are stored in the Key Manager database on the enterprise premises in encrypted form. Each Subscribers private key is individually encrypted with its own triple-DES symmetric key. A Key Escrow Record (KER) is generated, then the triple-DES key is combined with a random session key to form a session key mask (MSK)generated in hardware and destroyed. Only tThe resulting masked session key (MSK) together with the certificate request information is securely sent and stored in the Managed PKI database at VeriSign. The KER (containing the end users private key) and the individual random session key mask are stored in the Key Manager database on the enterprise premises. The Managed PKI database is operated out of VeriSigns secure data center. The enterprise customer may choose to operate the Key Manager database either on the enterprises premis es or out of VeriSigns secure data center. Recovery of a private key and digital certificate requires the Managed PKI administrator to securely log on to the Managed PKI Control Center, select the appropriate key pair to recover and click a recover hyperlink. Only after an approved administrator clicks the recover link is the MSK for that key pair returned from the Managed PKI database operated out of VeriSigns secure data center . The Key Manager retrieves and decrypts the session key from the KMD and combines it with the MSK to combines the MSK with the random session key mask and regenerates the triple-DES key which was used to originally encrypt the private key, allowing recovery of the end users private key. As a final step, an encrypted PKCS#12 file is returned to the administrator and ultimately distributed to the end user. Removed footnote #15: In Limited circumstances, and only when expressly authorized through an Enterprise Service Agreement, VeriSign may host an Enterprises Key Management Service and associated escrowed private keys. 5.2.2 Number of Persons Required per Task Other manual operations such as the validation and issuance of Class 3 Certificates, not issued by an automated validation and issuance system, require the participation of at least 2 Trusted Persons, or a combination of at least one trusted person and an automated validation and issuance process. Manual operations for Key Recovery may optionally require the validation of two (2) authorized Administrators. 5.2.4 Roles Requiring Separation of Duties Roles requiring Separation of duties include (but are not limited to) the validation of information in Certificate Applications; the acceptance, rejection, or other processing of Certificate Applications, revocation requests, recovery requests or renewal requests, or enrollment information; 3.2.3 Auth of Individual Identity Class 3 Administrator certificates shall also include authentication of the organization and a confirmation from the organization of the identity employment and authorization of the person to act as Administrator. Footnote #5: Confirmation of the identity employmentand authorization of the person enrolling for the Administrator certificate for the service named as Administrator in the Certificate Application. Explicitly added SAN to list of extensions for Subscriber certs: SubjectAltName: If present is populated in accordance with RFC5280 and criticality is set to FALSE Corrected the name of the Policy Authority for NF SSP CA.

Correction to ID Proofing of Class 3 Administrator (need not be employees)

Appendix B3 Section 3.2.3

History of changes: version 3.8.1

Section
Section 6.3.2 footnote 20 Appendix B1 Section 8 Appendix B1 Section 22(d)(3) Appendix B1 Section 25

Description
Added: With the exception of the VeriSign Automated Administration certificate Updated maximum validity period from one year to thirteen months Created section 22(d)(3) Deleted: Before renewing an EV Certificate, VeriSign performs all authentication and verification tasks required by the Guidelines and this procedure to ensure that the renewal request is properly authorized by the Applicant and that the information displayed in the EV Certificate is still accurate and valid. Replaced this paragraph with content consistent with published errata to the EV Guidelines. Also included a definition of renewal consistent with the Guidelines. Added: (f) extKeyUsage

AppendixB3 Section 3

- 176 -

Appendix B1-B4 and throughout document History of changes: version 3.8

Replaced all references to RFC 3280 with RFC 5280

Section
Section 6.3.2 table 8

Description
Updated validity period for Online CA to End-Entity Organizational Subscriber from 3 to 5 years. Fn 17. updated fn to include the Class 3 Secure Server Operational Administrator CA Fn 20. Added a footnote that At a minimum, the Distinguished Name of four and five year validity SSL certificates is reverified after three years from date of certificate issuance

History of changes: version 3.7

Section
Section 1.3.1

Description
Added: VeriSign also operates the VeriSign Universal Root Certification Authority. The VeriSign Universal Root Certification Authority is not defined under a particular certificate Class, and may issue any class of Subordinate CA. Deleted: VeriSign also operates the VeriSign Class 3 International Server CA which is an online CA signed by a PCA. The validity of this CA may exceed the validity periods described in Table 8 above in order to meet certain contractual obligations with browser vendors regarding the use of SGC/step up technology, and ensure continued interoperability of certificates offering this capability. Added : VeriSign also operates the "VeriSign Class 3 International Server CA" and the "Class 3 Open Financial Exchange CA - G2" which are online CAs signed by a PCA. The validity of these CAs may exceed the validity periods described in Table 8 above to ensure continued interoperability of certificates offering SGC and OFX capability. Deleted: Affected CAs shall not be extended beyond December 31, 2010 in terms of this exception Added: This exception may not be used to extend a CAs validity beyond a 13 year total validity, and shall not be made available after April 30, 2011. Added Footnote: Certificate validity periods may be extended beyond the limits set in Section 6.3.2 for certificates using stronger encryption algorithms or key lengths are used, e.g. the use of SHA 2 or ECC algorithms and/or the use of 2048 bit or larger keys. Added two algorithms: 1. sha256withRSAEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11} 2. ecdsa-with-Sha384 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-X962(10045) signatures(4) ecdsa-with-SHA2 (3) 3}

Section 6.3.2

Section 6.3.2

Section 6.3.2

Section 7.1.3

Appendix B1 Section 16 (a) Appendix B1 Section 5 Appendix B1 Section 6(a)3 table 1 Appendix B1 Section 14 Appendix B1 Section 19 Appendix B4 Definitions

Updated to allow for verification of address of a or a Parent/Subsidiary Company Added Non-Commercial Entity Subjects Added: Non-Commercial Entities: V1.0, Clause 5.(3) Added: Government Entities and Non-Commercial Entities Added Prior Equivalent Authority Updated Appendix A4 in line with published errata to the EV Guidelines Added: "Country": "Sovereign State": "International Organization": Parent Company Updated Subsidiary Company to be a majority owned and not a wholly owned company.

History of changes: version 3.6

Section
Section 4.1.2.1

Description
Changed " demonstrating possession of the private key corresponding to the public key delivered to VeriSign." to "demonstrating possession and/or exclusive control of the private key corresponding to the public key delivered to VeriSign. "

- 177 -

Section 6.1.1

Section 6.2.5

Section 6.3.2

Changed " For ACS Application IDs, VeriSign generates a key pair on behalf of the Subscriber using a random numbers seed generated on a cryptographic module that meets the requirements of FIPS 140-1 level 3. " To "For ACS Application IDs, VeriSign generates a key pair on behalf of the Subscriber using a random numbers seed generated on a cryptographic module that, at a minimum, meets the requirements of FIPS 140-1 level 3. " Deleted: "When VeriSign CA key pairs reach the end of their validity period, such CA key pairs will be archived for a period of at least 5 years. Archived CA key pairs will be securely stored using hardware cryptographic modules that meet the requirements of this CPS. Procedural controls prevent archived CA key pairs from being returned to production use. Upon the end of the archive period, archived CA private keys will be securely destroyed in accordance with this CPS." Added "In terms of Section 6.3.2 of the VTN CP, the VeriSign PMA has approved an exception to extend a limited number CAs beyond the specified limits, in order to ensure uninterrupted PKI services during CA key pair migration. Affected CAs shall not be extended beyond December 31, 2010 in terms of this exception. " Update "VeriSign Certificates conform to (a) ITU-T Recommendation X.509 (1997): Information Technology Open Systems Interconnection - The Directory: Authentication Framework, June 1997 and (b) RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, April 2002 (RFC 5280)." To "VeriSign Certificates conform generally to (a) ITU-T Recommendation X.509 (1997): Information Technology Open Systems Interconnection - The Directory: Authentication Framework, June 1997 and (b) RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, April 2002 (RFC 5280)." Deleted "Note: Although the nonRepudiation bit is not set in the KeyUsage extension, VeriSign nonetheless supports nonrepudiation services for these Certificates. The nonRepudiation bit is not required to be set in these Certificates because the PKI industry has not reached a consensus as to what the nonRepudiation bit means. Until such a consensus emerges, the nonRepudiation bit will not be meaningful for potential Relying Parties. Moreover, the most commonly used applications do not recognize the nonRepudiation bit. Therefore, setting the bit will not help Relying Parties make a trust decision. Consequently, this CPS requires that the nonRepudiation bit be cleared, although it may be set in the case of dual key pair signature Certificates issued through Managed PKI Key Manager" Added: "Note: The nonRepudiation bit is not required to be set in these Certificates because the PKI industry has not yet reached a consensus as to what the nonRepudiation bit means. Until such a consensus emerges, the nonRepudiation bit might not be meaningful for potential Relying Parties. Moreover, the most commonly used applications do not always respect the nonRepudiation bit. Therefore, setting the bit might not help Relying Parties make a trust decision. Consequently, this CPS does not require that the nonRepudiation bit be set. It may be set in the case of dual key pair signature Certificates issued through Managed PKI Key Manager, or as otherwise requested. Any dispute relating to non-repudiation arising from the use of a digital certificate is a matter solely between the Subscriber and the Relying Party(s). VeriSign shall incur no liability in relation thereto." Added footnote: "The nonRepudiation bit may also be referred to as ContentCommitment in Digital Certificates in accordance with the X.509 standard." Updated Jurisdiction from Santa Clara County, California to Fairfax County, Virginia Updated Governing Law from State of California to Commonwealth of Virginia

Section 7.1

Section 7.1.2.1

Section 9.13.2 Section 9.14

History of changes: version 3.5 Section 6.2.5 Deleted: When VeriSign CA key pairs reach the end of their validity period, such CA key pairs will be archived for a period of at least 5 years. Archived CA key pairs will be securely stored using hardware cryptographic modules that meet the requirements of this CPS. Procedural controls prevent archived CA key pairs from being returned to production use. Upon the end of the archive period, archived CA private keys will be securely destroyed in accordance with this CPS. Added: Upon expiration of a VeriSign CA Certificate, the key pair associated with the certificate will be securely retained for a period of at least 5 years using hardware cryptographic modules that meet the requirements of this CPS. These CA key pairs shall not be used for any signing events after their expiration date, unless the CA Certificate has been renewed in terms of this CPS. Section 6.2.10 Deleted: At the conclusion of a VeriSign CAs operational lifetime, one or more copies of the CA private key are archived in accordance with CPS 6.2.5. Remaining copies of the CA private key are securely destroyed. In addition, archived CA private keys are securely destroyed at the conclusion of their archive periods. CA key destruction activities require the participation of multiple trusted individuals. Added: End user Subscriber Certificates that are renewals of existing subscriber certificates may have a longer validity period (up to 3 months). Updated Online CA to End-Entity Organizational Subscriber to reflect a validity Normally up to 3 years. Clarification added that an OU pointing to a Relying party Agreement in the Subject name is optional as long as

Section 6.3.2 Section 6.3.2 table 8 Section 7.1.4

- 178 -

Section 9.8 Definitions Appendix B1-B4

the Relying Party Agreement is linked to from the Policyextension. Updated Liability Caps for Netsure to $50,000 US to $250,000 US. From $1,000 US to $1,000,000.00 US NetSure Protection Plan: Updated definition with correct CPS Section reference. Added: Principal Individual, Subsidiary Company, Registration Agency Updated EV procedures in line with Version 1.0 of the EV Guidelines issued by the CA/Browser Forum.

History of changes: version 3.4 Section 1.1 Added Footnote: Authenticated Content Signing Certificates (ACS) are issued by a non-VTN CA. However, reference is made to these certificates in certain sections of this VeriSign CPS, for ACS customers to understand certain procedural differences used for these certificates. Section 3.2.3 Added Verification requirements for Shared Service Provider Certificates for non federal entities : The identity Table 7 of the Certificate Subscriber is verified substantially in compliance with the requirements of the X.509 Certificate Policy for the US Department of Homeland Security Public Key Infrastructure (PKI) Section 3.3.1 Added a response from a verified e-mail address for the Corporate Contact as an alternative to a challenge phrase Section 4.6.3 Added a response from a verified e-mail address for the Corporate Contact as an alternative to a challenge phrase Section 4.9.7 Deleted: CRLs for CA Certificates shall be issued at least quarterly Added: CRLs for CA Certificates shall be issued at least annually Section 6.3.2 Added: VeriSign also operates the VeriSign Class 3 International Server CA which is an online CA signed by a PCA. The validity of this CA may exceed the validity periods described in Table 8 above in order to meet certain contractual obligations with browser vendors regarding the use of SGC/step up technology, and ensure continued interoperability of certificates offering this capability. Section 7.1.2.1 Updated to specify that: The criticality field of the KeyUsage extension is generally set to TRUE for CA certificates and may be set to either TRUE, or FALSE for end entity Subscriber certificates. Section 7.1.2.1Updated CA Criticality from False to True Table 10 Section 9.3.3 Added: VeriSign secures private information from compromise and disclosure to third parties. Definitions Deleted Affiliate Audit Program Guide History of changes: version 3.3 Section 1 Added: This CPS conforms to the Internet Engineering Task Force (IETF) RFC 3647 for Certificate Policy and Certification Practice Statement construction. Section 1.4.1.2 Added: High Assurance with Extended Validation Table 2 Added: High assurance with extended validation certificates are Class 3 certificates issued by VeriSign in Section 1.4.1.3 conformance with the Guidelines for Extended Validation Certificates. Section 2.2 Added: End-User Subscriber Certificates issued by VeriSign Class 3 Organizational VIP Device CA are not Table 3 available through public query. Section 3.1.1 Added: EV SSL certificate content and profile requirements are discussed in Section 6 of Appendix B3 to this CPS. Section 3.2.2 Added: VeriSigns procedures for issuing Extended Validation SSL Certificates are described in Appendix B1 Table 6 to this CPS. Section 3.2.6 Added footnote: Customers of VeriSigns Certificate Interoperability Service (CIS) are encouraged, but not required, to have their own CPS under the Certificate Interoperability Service (CIS) CP Supplement, but in all cases must comply with VeriSigns Certificate Interoperability Service (CIS) CP Supplement, published in the VeriSign Repository Section 3.3.1 Deleted: In particular, for subsequent renewal requests for retail Class 3 Organizational certificates, VeriSign reauthenticates the Organization name and domain name included in the certificate. In circumstances where: Added: In particular, for subsequent re-key requests for retail Class 3 Organizational certificates through www.verisign.com, VeriSign reauthenticates the Organization name and domain name included in the certificate. In circumstances where: Deleted: In particular, for subsequent renewal requests for Class 3 Organizational certificates, VeriSign reauthenticates the Organization name and domain name included in the certificate. In circumstances where: Added: In particular, for subsequent renewal requests for retail Class 3 Organizational certificates through www.verisign.com, VeriSign reauthenticates the Organization name and domain name included in the certificate. In circumstances where:... Section 4.9.7 Section 6.3.2 Added footnote:CRLs for the VeriSign Class 3 Organizational VIP Device CA are only issued whenever a certificate issued by that CA is revoked. Added: VeriSign operates the VeriSign Class 3 Organizational VIP Device CA. Organizational end -entity certificates issued by this CA may have a validity period beyond 3 years and up to a maximum of 5 years in circumstances where:

Section 4.6.3

- 179 -

Section 6.3.2 fn 16 Section 7.1.2 Section 7.1.8

The certificate key pair is stored in hardware, and VeriSign has authenticated the Organization in terms of this CPS and When used to protect a server using SSL/TLS, the server is only accessible via a private network or intranet. Deleted: The Distinguished name of these Certificates shall be re-authenticated by VeriSign at least every 25months. Added: EV SSL certificate extension requirements are described in Appendix B3 to this CPS. Deleted: Where the Certificate Policies extension is used, Certificates contain the object identifier for the Certificate Policy corresponding to the appropriate Class of Certificate as set forth in Section 1.2 of the VTN CP. For legacy Certificates issued prior to the publication of the VTN CP which include the Certificate Policies extension Certificates refer to the VeriSign CPS and/or the Relying party Agreement. Added: VeriSign generally populates X.509 Version 3 VTN Certificates with a policy qualifier within the Certificate Policies extension. Generally, such Certificates contain a CPS pointer qualifier that points to the applicable Relying Party Agreement or the VeriSign CPS. In addition, some Certificates contain a User Notice Qualifier which points to the applicable Relying Party Agreement. Added: VeriSigns limitation of liability for EV certificates is further described in Section 37 of Appendix B1 to this CPS. Deleted: They shall also include the following liability caps limiting VeriSigns and the Affiliates damages concerning a specific Certificate Added: They shall also include the following liability caps limiting VeriSigns damages concerning a specific Certificate Added definition for Extended Validation Added Appendix B: Supplemental Validation Procedures for Extended Validation SSL Certificates Added Appendix C: Minimum Cryptographic Algorithm and Key Sizes for EV Certificates Added Appendix D: EV Certificates Required Certificate Extensions

o o o

Section 9.8 Section 9.8

Definitions Appendix B Appendix C Appendix D

History of changes: version 3.2 (Effective date May 01, 2006) General Corrected typographical errors Section 1.4.1.2 Added TLS as an appropriate use for organization certificates. (Table 2) Section 3.2.3 Amended Class 3 Administrator certificates shall also include authentication of the organization and a confirmation from the organization of the employment and authorization of the person to act as Administrator. to say The authentication of Class 3 Administrator certificates is bas ed on authentication of the organization and a confirmation from the organization of the employment and authorization of the person to act as Administrator Section 3.3.1 and Specified that it is the Corporate Contact and Technical Contact information that must remain unchanged for an Section 4.6.3 automatically issued renewal. Section 3.3.1 and Added: section 4.6.3 In particular, for subsequent renewal requests for Class 3 Organizational certificates, VeriSign reauthenticates the Organization name and domain name included in the certificate. In circumstances where The challenge phrase is correctly used for the subsequent renewal certificate and: The certificate Distinguished Name has not been changed, and The Corporate and Technical Contact information remains unchanged from that which was previously verified, VeriSign will not have to reconfirm by telephone, confirmatory postal mail, or comparable procedure to the Certificate Applicant certain information about the organization, that the organization has authorized the Certificate Application, and that the person submitting the Certificate Application on behalf of the Certificate Applicant is authorized to do so. Section 7.2 Removed reference to RFC 5280 Section 7.2.1 Added that Version 2 CRLs conform with the requirements of RFC 5280. Section 9.2.1 Updated from: Enterprise Customers shall maintain a commercially reasonable level of insurance coverage for errors and omissions, either through an errors and omissions insurance program with an insurance carrier or a self-insured retention. This insurance requirement does not apply to governmental entities. VeriSign maintains such errors and omissions insurance coverage. to: Enterprise Customers are encouraged to maintain a commercially reasonable l evel of insurance coverage for errors and omissions, either through an errors and omissions insurance program with an insurance carrier or a self-insured retention. VeriSign maintains such errors and omissions insurance coverage. Section 9.2.3 Updated Section title from Insurance or Warranty Coverage for End-Entities to Extended Warranty Coverage Section 9.2.3 Replaced the following content: The NetSure Protection Plan is an extended warranty program that applies within VeriSigns Subdomain of the VTN. Where it applies, the NetSure Protection Plan provides Subscribers receiving with protection against accidental occurrences such as theft, corruption, loss, or unintentional disclosure of the Subscribers private key (corresponding to the public key in the Certificate), as well as impersonation and certain loss of use of the Subscribers Certificate. The NetSure Protection Plan also provides protection to Relying Parties when they rely

- 180 -

on Certificates covered by the NetSure Protection Plan. NetSure is a program provided by VeriSign and backed by insurance obtained from commercial carriers. For general information concerning the NetSure Protection Plan, and a discussion of which Certificates are covered by it, see http://www.verisign.com/netsure. The protections of the NetSure Protection Plan are also offered, for a fee, to Enterprise Customers of VeriSign. They can obtain protections under the NetSure Protection Plan subject to the terms of an appropriate agreement for this service. This service not only extends the protections of the NetSure Protection Plan to the Subscribers whose Certificate Applications are approved by the Enterprise Customer, it also extends these protections to the Enterprise Customer itself. For example, if a Managed PKI Customer approves a Certificate Application of an employee of the Managed PKI Customer, who uses the Certificate for the business purposes of the Managed PKI Customer, and if the Subscribers actions cause a loss, the real party bearing the loss may be the Managed PKI Customer in its role as the Subscribers employer. If covered by the NetSure Protection Plan, the Managed PKI Customer may submit a claim for the loss sustained because of the Subscribers actions. With: The NetSure Protection Plan is an extended warranty program that provides VeriSign SSL and code signing certificate subscribers with protection against loss or damage that is due to a defect in VeriSigns issuance of the certificate or other malfeasance caused by VeriSigns negligence or breach of its contractual obligations, provided that the subscriber of the certificate has fulfilled its obligations under the applicable service agreement. For general information concerning the NetSure Protection Plan, and a discussion of which Certificates are covered by it, see http://www.verisign.com/netsure History of changes: version 3.1 (Included December 01, 2005) Section 2.3 Changed reference to Section 8 to Section 9.12 Section 4.5.2 Updated to include the following language: Relying Party is solely responsible to investigate whether reliance on a digital signature performed by an end-user Subscriber Certificate prior to revocation of a Certificate in the Certificate chain is reasonable. Any such reliance is made solely at the risk of the Relying party. Section 4.12.1 Made the list of requirements for key recovery a VeriSign recommendation Section 6.2.1 Deleted For other CAs, VeriSign uses hardware cryptographic modules that are certified at or meet the requirements of at least FIPS 140-1 Level 2 Section 9.2.2 Updated URL to VeriSign SEC filings: http://www.verisign.com/verisign-inc/vrsn-investors/secfilings/index.html

- 181 -