X.509 Certificate Policy For The Virginia Polytechnic Institute and State University Certification Authorities

Transcription

1 X.509 Certificate Policy For The Virginia Polytechnic Institute and State University Certification Authorities May 13, 2004 Amended March 16, 2011 OBJECT IDENTIFIER Release 1.0 Version 3.0 i

2 Identification and Validation of this Policy This Certificate Policy (CP) has been assigned the global Object Identifier (OID) A Virginia Tech Certificate Authority (VTCA) MAY NOT SIGN ANY PUBLIC KEY CERTIFICATE (PKC) OR OTHER DOCUMENT THAT ASSERTS BY REFERENCE TO THIS OID ITS CONFORMANCE TO THIS CERTIFICATE POLICY UNLESS ALL ASPECTS OF ITS MANAGEMENT AND OPERATION CONFORM COMPLETELY WITH THE REQUIREMENTS CONTAINED HEREIN. Minor modifications will be indicated by a suffix to this OID. Any significant changes to this policy, as determined by the Policy Management Authority (PMA) (see Section 1.4.1), will result in a document with a different OID assignment. A copy of this document SHALL be digitally signed by the chairman of the VTPKI-PMA who has the primary responsibility for approving policies/standards of the Virginia Tech Public Key Infrastructure (PKI) and the related Certificate Authorities operating within it. The signed document SHALL be available online at the location specified by certificates issued under this policy (see Section 7.1.8). Identification: Virginia Polytechnic Institute and State University ; VPI&SU; Virginia Tech Data Universal Number System: ii

3 Table of Contents 1. INTRODUCTION OVERVIEW Certificate Policy (CP) Relationship Between the CP and the CPS Interoperation with CAs External to this Policy Domain Relationship Between a Bridge CP and this CP IDENTIFICATION COMMUNITY AND APPLICABILITY PKI Authorities Registration Authorities End Entities Applicability CONTACT DETAILS Specification Administration Organization Contact Person Person Determining Certification Practice Statement Suitability for the Policy GENERAL PROVISIONS OBLIGATIONS CA Obligations RA Obligations Subscriber Obligations Relying Party Obligations Repository Obligations LIABILITY CA Liability RA Liability FINANCIAL CONSIDERATIONS Fiduciary Relationships Administrative Processes INTERPRETATION AND ENFORCEMENT Governing Law Severability, Survival, Merger, Notice Dispute Resolution Procedures Section Headings FEES Certificate Issuance or Renewal Fees Certificate Access Fees Revocation or Status Information Access Fees Fees for Other Services such as Policy Information Refund Policy PUBLICATION AND REPOSITORY Publication of CA Information Frequency of Publication iii

4 2.6.3 Access Controls Repositories COMPLIANCE AUDIT Frequency of Entity Compliance Audit Identity/Qualifications of Auditor Auditor's Relationship to Audited Party Topics Covered by Audit Actions taken as a result of deficiency Communication of Results CONFIDENTIALITY Types of Information to be Kept Confidential Types of Information Not Considered Confidential Disclosure of Certificate Revocation Information Release to Law Enforcement Officials Release as Part of Civil Discovery Disclosure upon Subscriber's Request Other Information Release Circumstances INTELLECTUAL PROPERTY RIGHTS IDENTIFICATION AND AUTHENTICATION INITIAL REGISTRATION Types of Names Need for Names to be Meaningful Rules for Interpreting Various Name Forms Uniqueness of Names Name Claim Dispute Resolution Procedure Recognition, Authentication and Role of Trademarks Method to Prove Possession of Private Key Authentication of Organization Identity Authentication of Individual Identity Authentication of Component Identities CERTIFICATE RENEWAL, UPDATE, AND ROUTINE REKEY Certificate Rekey Certificate Renewal Certificate Update OBTAINING A NEW CERTIFICATE AFTER REVOCATION REVOCATION REQUEST OPERATIONAL REQUIREMENTS APPLICATION FOR A CERTIFICATE Delivery of Public Key for Certificate Issuance CERTIFICATE ISSUANCE Delivery of Subscriber's Private Key to Subscriber CERTIFICATE ACCEPTANCE CERTIFICATE SUSPENSION AND REVOCATION iv

5 4.4.1 Circumstances for Revocation of a Certificate Who Can Request Revocation of a Certificate Procedure for Revocation Request Revocation Request Grace Period Suspension Who Can Request Suspension Procedure for Suspension Request Limits on Suspension Period Certificate Authority Revocation Lists / Certificate Revocation Lists CARL/CRL Issuance Frequency CARL/CRL Checking Requirements Online Revocation / Status Checking Availability Online Revocation Checking Requirements Other Forms of Revocation Advertisements Available Checking Requirements for Other Forms of Revocation Advertisements Special Requirements Related to Key Compromise SECURITY AUDIT PROCEDURE Types of Events Recorded Frequency of Processing Data Retention Period for Security Audit Data Protection of Security Audit Data Security Audit Data Backup Procedures Security Audit Collection System (Internal vs. External) Notification to Event Causing Subject Vulnerability Assessments RECORDS ARCHIVAL Types of Events Archived Retention Period for Archive Protection of Archive Archive Backup Procedures Requirements for Time-Stamping of Records Archive Collection System (Internal or External) Procedures to Obtain and Verify Archive Information KEY CHANGEOVER COMPROMISE AND DISASTER RECOVERY Computing Resources, Software, and/or Data Are Corrupted Compromise Recovery Disaster Recovery CA Signature Keys Are Revoked CA Signature Keys Are Compromised Secure Facility Impaired after a Disaster CA TERMINATION PHYSICAL, PROCEDURAL AND PERSONNEL SECURITY CONTROLS PHYSICAL CONTROLS FOR THE VTCA OR AUTHORIZED CA Site Location and Construction Electrical Power v

6 5.1.3 Water Exposures Fire Prevention and Protection Media Storage Waste Disposal Offsite Backup PROCEDURAL CONTROLS FOR THE VTCA Trusted Roles Certification Authority Administrator Registration Authority Administrator (RAA) Other Trusted Roles Number of Persons Required Per Task Identification and Authentication for Each Role PERSONNEL CONTROLS Background, Qualifications, Experience, and Security Clearance Requirements Background Check Procedures Training Requirements Retraining Frequency and Requirements Job Rotation Frequency and Sequence Sanctions for Unauthorized Actions Contracting Personnel Requirements Documentation Supplied to Personnel TECHNICAL SECURITY CONTROLS KEY PAIR GENERATION AND INSTALLATION Key Pair Generation by the VTCA Private Key Delivery to Subscriber Public Key Delivery to Certificate Issuer VTCA Public Key Availability Key Sizes Public Key Parameters Generation Parameter Quality Checking Hardware/Software Subscriber Key Pair Generation Key Usage Purposes (as per X.509 v3) PRIVATE KEY PROTECTION Standards for Cryptographic Module CA Private Key Multi-Person Control Key Escrow of CA Private Signature Key Escrow of End Entity Decryption Keys Private Key Backup Backup of CA Private Signature Key Backup of End Entity Private Signature Key Private Key Archival Private Key Entry into Cryptographic Module Method of Activating Private Keys Methods of Deactivating Private Keys Method of Destroying Subscriber Private Signature Keys OTHER ASPECTS OF KEY PAIR MANAGEMENT Public Key Archival Usage Periods for the Public and Private Keys ACTIVATION DATA vi

7 6.4.1 Activation Data Generation and Installation Activation Data Protection Other Aspects of Activation Data COMPUTER SECURITY CONTROLS Specific Computer Security Technical Requirements Computer Security Rating LIFE CYCLE TECHNICAL CONTROLS System Development Controls Security Management Controls Life Cycle Security Ratings NETWORK SECURITY CONTROLS CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS CERTIFICATE AND CARL/CRL PROFILES CERTIFICATE PROFILE Version Numbers Certificate Extensions Algorithm Object Identifiers Name Forms Name Constraints Certificate Policy Object Identifier Usage of Policy Constraints extension Policy Qualifiers Syntax and Semantics Processing Semantics for the Critical Certificate Policy Extension Certificate Serial Numbers CARL/CRL PROFILE Version Numbers CARL and CRL Entry Extensions OCSP Services SPECIFICATION ADMINISTRATION SPECIFICATION CHANGE PROCEDURES PUBLICATION AND NOTIFICATION POLICIES Amendments Generally Urgent Amendments Exception Assent to Amendments Maintenance of Prior Versions CPS APPROVAL PROCEDURES WAIVERS BIBLIOGRAPHY GLOSSARY ACKNOWLEDGEMENTS vii

8 1. Section 6.7 Change made 9/19/06 RECORD OF CHANGES Removed: The Virginia Tech Root and Subordinate CA equipment SHALL be implemented using a stand-alone (offline) configuration. Added: The Virginia Tech Root CA equipment SHALL be implemented using a stand-alone (offline) configuration. Subordinate CA equipment MAY be implemented using either an on-line or off-line configuration. 2. Cover Page Change made 7/7/09 Removed: Amended September 19, 2006 OBJECT IDENTIFIER Release 1.0 Version 1.0 Added: Amended July 7, 2009 OBJECT IDENTIFIER* Release 1.0 Version Identification and Validation of this Policy Change made 7/7/09 Removed: A copy of this document SHALL be digitally signed using SHA-1 with RSA encryption and the private key associated with the authority certificate of a VTCA operating under this policy. Added: A copy of this document SHALL be digitally signed by the chairman of the VTPKI- PMA who has the primary responsibility for approving policies/standards of the Virginia Tech Public Key Infrastructure (PKI) and the related Certificate Authorities operating within it. 4. Section 1.1 OVERVIEW Change made 7/7/09 Removed: Any PKC issued by a VTCA MUST contain a valid reference to the applicable CP. This CP may be referenced only if a VTCA is in compliance with all aspects of this CP. Added: Any authority PKC issued by a VTCA MUST contain a valid reference to the applicable CP. This CP may be referenced only if a VTCA is in compliance with all aspects of this CP. 5. Section 1.2 IDENTIFICATION Change made 7/7/09 Removed: Each PKC issued by a VTCA MUST reference an Object Identifier (OID) that identifies this CP document. The PKC MUST also include an OID indicating the Level of Assurance (LOA) that applies to that PKC. How this is to be achieved is described in the remainder of this section with further detail provided in the associated CPS document.. A copy of this CP may be found at A digitally signed copy of the CP may be found at viii

9 Added: Each authority PKC issued by a VTCA MUST reference an Object Identifier (OID) that identifies this CP document. End entity PKCs SHOULD include an OID indicating the Level of Assurance (LOA) that applies to that PKC. How this is to be achieved is described in the remainder of this section with further detail provided in the associated CPS document.. This CP and a digitally signed copy of it may be found at 6. Section Interoperation with CAs External to this Policy Domain Change made 7/7/09 Removed: No Stipulation. Added: The Virginia Tech Root CA may interoperate with CAs external to this policy domain for the sole purpose of having thevirginia Tech Root Certificate signed by an external CA. The VT PKI PMA must explicitly approve anyexternal CA signature. 7. Section Specification Administration Organization Change made 7/7/09 Removed: The Policy Management Authority (PMA) for this CP MUST be identified by postal address, office location, and other contact information in the applicable CPS. The Policy Management Authority (PMA) is appointed by the Vice President for Information Technology who reports to the President. Added: The Policy Management Authority (PMA) for this CP MUST be identified by postal address, office location, and other contact information in the applicable CPS. The Policy Management Authority (PMA) is appointed by the Vice President for Information Technology/Chief Information Officer (VPIT/CIO) who reports to the President. 8. Section Contact Person Change made 7/7/09 Removed: Questions about interpretation of this CP should be directed to Information Resource Management. Concerns about possible abuse of this CP, should be directed in writing to the Virginia Tech Public Key Infrastructure Policy Management Authority (VTPKI PMA). Information Resource Management 1700 Pratt Dr. Blacksburg, VA ix

10 Chair, VTPKI PMA 1700 Kraft Dr. Suite 2000 Blacksburg, VA Added: Questions about interpretation of this CP should be directed to Identity Management Services. Concerns about possible abuse of this CP, should be directed in writing to the Virginia Tech Public Key Infrastructure Policy Management Authority (VTPKI PMA). Identity Management Services 1700 Pratt Dr. Blacksburg, VA Chair, VTPKI PMA 1700 Pratt Dr. Blacksburg, VA , Section CA Obligations Change made 7/7/09 Removed: A VTCA SHALL NOT issue any PKC with a Level of Assurance higher than that in its authority PKC. not issuing more than one PKC with the same public key unless the Subject entity is the same in all instances Added: Delete this sentence: "A VTCA SHALL NOT issue any PKC with a Level of Assurance higher than that in its authority PKC." The specifics of LOA implemenatation are defined in the associated CPS documents. Delete this bullet: "not issuing more than one PKC with the same public key unless the Subject entity is the same in all instances" The EJBCA does not check to see if a public key is being reused. Key management is the responsibility of the user. 10. Section 3.3 OBTAINING A NEW CERTIFICATE AFTER REVOCATION Change made 7/7/09 Removed: A public key with an associated PKC which has been revoked for private key compromise MUST NOT be recertified. The public key MAY be recertified if the PKC was merely suspended. In the latter case, identification of the Subject MAY be accomplished with the same procedure indicated in section 3.1 for initial registration, or by using a digitally signed request using the x

11 suspended PKC. Such a request MUST be sent to a VTCA during the period of validity of the PKC to be restored. Added: A public key with an associated PKC which has been revoked for private key compromise MUST NOT be recertified. The Subscriber is responsible for rekeying when submitting a new certificate signing request to insure that when the new PKC is created, it has a new, different public key (corresponding to a new, different private key) and a different serial number is assigned by the CA. 11. Section 3.4 REVOCATION REQUEST Change made 7/7/09 Removed: A VTCA MUST accept as a revocation request an appropriate message digitally signed with the PKC to be revoked as long as it is still valid and not already revoked or suspended. The same procedures adopted for Subject identity during initial registration MAY also be used. Alternative procedures MAY be supported but MUST be detailed in the relevant CPS. Added: A VTCA MUST accept as appropriate, a revocation request sent as a digitally signed message which specifies the PKC to be revoked. The same procedures adopted for Subject identity during initial registration MAY also be used. Alternative procedures MAY be supported but MUST be detailed in the relevant CPS. 12. Section 4.2 CERTIFICATE ISSUANCE Change made 7/7/09 Removed: Upon receiving the request, a VTCA SHALL: verify the authority of the requestor build and sign a certificate, if all certificate requirements have been met (in the case of an RA, have the VTCA sign the certificate) send the certificate to the user The certificate request MAY contain an already built ("to be signed") certificate. This certificate SHALL NOT be signed until all verifications and modifications, if any have been completed to a VTCA's satisfaction. If a certificate request is denied, then a VTCA SHALL NOT sign the requested certificate, and will work with the RA to resolve the problem. While the user may do most of the data entry, it is the responsibility of a VTCA to verify the information is correct and accurate. This may be accomplished either through a system approach linking databases containing personnel information or through personal contact with the program's attribute authority (as put forth in the applicable CPS). xi

12 Added: Upon receiving the request, a VTCA SHALL: - verify the authority of the requestor - approve the certificate request if all the requirements have been met and notify the requestor - deny the certificate request if it does not meet requirements 13. Section Certification Authority Administrator (CAA) Change made 7/7/09 Removed: The Certification Authority Administrator (CAA) role and the corresponding procedures a CAA will follow shall be defined in detail in the applicable CPS. Primarily, a CAA's responsibilities are: certificate generation and revocation CRL generation certificate profile, certificate template, and audit parameter configuration certificate issuance for a VTCA administrator account VTCA key generation and backup Added: The Certification Authority Administrator (CAA) role and the corresponding procedures a CAA will follow shall be defined in detail in the applicable CPS. Primarily, a CAA's responsibilities are: Certificate profile, certificate template, and audit parameter configuration Develop VTCA key generation and backup procedures Assignment of VTCA security privileges and access controls of users Install and configure new CA software releases Startup/Shutdown of the VTCA 14 Section Registration Authority Administrator (RAA) Change made 7/7/09 Removed: The Registration Authority Administrator (RAA) role and the corresponding procedures a RAA will follow shall be defined in detail in the applicable CPS. Primarily, an RAA's responsibilities are: acceptance of subscription, certificate change, certificate revocation/suspension and key recovery requests verification of an applicant's identity transmission of applicant information to the Virginia Tech certification authority reception and distribution of subscriber certificates publication of CRLs and certificates xii

13 Added: The Registration Authority Administrator (RAA) role and the corresponding procedures a RAA will follow shall be defined in detail in the applicable CPS. Primarily, an RAA's responsibilities are: acceptance of subscription, certificate change, certificate revocation/suspension and key recovery requests verification of an applicant's identity transmission of applicant information to the Virginia Tech certification authority reception and distribution of subscriber certificates <delete this bullet, the subscriber downloads their certificate immediately after their enrollment request has been approved> publication of CRLs and certificates <delete this bullet, publication of CRLs is done automatically, certificates can be published automatically to LDAP if needed> 15. Section Other Trusted Roles Change made 7/7/09 Removed: A VTCA SHALL, in its CPS, define other trusted roles to which shall be allocated responsibilities that ensure the proper, safe, and secure operation of a VTCA's equipment and procedures. These responsibilities include: initial configuration of the system, including installation of applications, initial setup of new accounts, and configuration of the initial host and network interface. creation of devices to support recovery from catastrophic system loss performance of system backups, software upgrades, and recovery secure storage and distribution of the backups and upgrades to an offsite location changing the host or network interface configuration performance of proper system shutdown as required assignment of security privileges and access controls of users performance of archive and delete functions of the audit log and other archive data reviewing audit logs and performing compliance audits To ensure system integrity, the CAA and RAA SHALL be prohibited from performing these responsibilities. Those who perform these responsibilities for a certification authority within the VTPKI SHALL NOT be a CAA or an RAA in the same domain. A VTCA SHALL maintain lists, including names, organizations, and contact information, of those who act in these trusted roles, and SHALL make them available during compliance audits Added: A VTCA SHALL, in its CPS, define other trusted roles to which shall be allocated responsibilities that ensure the proper, safe, and secure operation of a VTCA's equipment and procedures. These responsibilities include: initial configuration of the operating system, including installation of applications, initial setup of new accounts, and configuration of the initial host and network interface. xiii

14 creation of devices to support recovery from catastrophic system loss performance of system backups, software upgrades, and recovery secure storage and distribution of the backups and upgrades to an offsite location changing the host or network interface configuration performance of proper system shutdown as required <delete this bullet, it is done by both CAA and Operating Systems support staff> assignment of operating system security privileges and access controls of host user accounts performance of archive and delete functions of the operating system audit log and other archive data reviewing audit logs and performing compliance audits To ensure system integrity, the RAA/CAA SHALL be prohibited from performing these responsibilities. Those who perform these responsibilities for a certification authority within the VTPKI SHALL NOT be an RAA/CAA in the same domain. A VTCA SHALL maintain lists, including names, organizations, and contact information, of those who act in these trusted roles, and SHALL make them available during compliance audits 16. Cover page Change made March 16, 2011 Removed: X.509 Certificate Policy For The Virginia Polytechnic Institute and State University Certification Authorities May 13, 2004 Amended July 7, 2009 OBJECT IDENTIFIER Release 1.0 Version 2.0 Added: X.509 Certificate Policy For The Virginia Polytechnic Institute and State University Certification Authorities May 13, 2004 Amended March 16, 2011 OBJECT IDENTIFIER Release 1.0 Version INTRODUCTION Change made March 16, 2011 xiv

15 Removed: The VTCAs that comprise the VTPKI are part of a Public Key Infrastructure (PKI) hierarchy consisting of a Root CA and one or more Subordinate CA(s). This CP applies to the Virginia Tech Root CA and all of the Subordinate CAs within the VTPKI hierarchy. Any VTCA for which the Virginia Tech Root CA signs an authority certificate MUST adopt this CP or one that is consistent with all of the requirements of this CP as determined by the Policy Management Authority for the VTPKI. Added: The VTCAs that comprise the VTPKI are defined by independent Self Signed Root and Global Root CA hierarchies. Each Root CA hierarchy consists of one or more Subordinate CA(s). This CP applies to both Virginia Tech Root CA hierarchies and all of the Subordinate CAs within each hierarchy. Any VTCA for which the Virginia Tech Self Signed Root or Global Root CA signs an authority certificate MUST adopt this CP or one that is consistent with all of the requirements of this CP as determined by the Policy Management Authority for the VTPKI PKI Authorities Change made March 16, 2011 Removed: The Virginia Tech Root CA MAY issue a PKC with certificate issuance rights ( authority PKC ) to another VTCA and in that case the Authorized Subordinate VTCA assumes the role of a CA under this CP. For all purposes under this CP, the Authorized Subordinate CA SHALL conform to, and operate under, this CP. Added: A Virginia Tech Root CA MAY issue a PKC with certificate issuance rights ( authority PKC ) to another VTCA and in that case the Authorized Subordinate VTCA assumes the role of a CA under this CP. For all purposes under this CP, the Authorized Subordinate CA SHALL conform to, and operate under, this CP Need for Names to be Meaningful Change made March 16, 2011 Removed: In the case where the Virginia Tech Root CA certifies another Authorized Subordinate CA within its policy domain, the Virginia Tech Root Authorizing CA MUST impose restrictions on the name space that MAY be used by the Authorized Subordinate CA that are at least as restrictive as its own name constraints. Added: In the case where a Virginia Tech Root CA certifies another Authorized Subordinate CA within its policy domain, the Virginia Tech Root Authorizing CA MUST impose restrictions on the name space that MAY be used by the Authorized Subordinate CA that are at least as restrictive as its own name constraints Uniqueness of Names Change made March 16, 2011 Removed: The Virginia Tech Root CA and Authorized Subordinate CAs SHALL document in their respective CPSs: What name forms will be used. How the Virginia Tech Root CA and Authorized Subordinate CAs will interact to ensure this is accomplished. xv

16 How the Virginia Tech Root CA and Authorized Subordinate CAs will allocate names within the Community to guarantee name uniqueness among current and past Subscribers (e.g., if "Joe Smith" leaves a Community, and a new, different "Joe Smith" enters the Community, how these two people will be provided unique Subject names). Added: A Virginia Tech Root CA and Authorized Subordinate CAs SHALL document in their respective CPSs: What name forms will be used. How a Virginia Tech Root CA and Authorized Subordinate CAs will interact to ensure this is accomplished. How a Virginia Tech Root CA and Authorized Subordinate CAs will allocate names within the Community to guarantee name uniqueness among current and past Subscribers (e.g., if "Joe Smith" leaves a Community, and a new, different "Joe Smith" enters the Community, how these two people will be provided unique Subject names) Certificate Update Change made March 16, 2011 Removed: When the Virginia Tech Root CA updates its private signature key and thus generates a new public key, the Virginia Tech Root CA SHALL notify all Authorized Subordinate or cross certified CAs, and SHOULD make a best effort to notify any Subscribers that rely on the VTCA's PKC, that it has been changed. For self signed ("root") PKCs, such PKCs SHALL be made available online along with separately retrievable verification information to enable a relying party to verify that it has received a valid copy of the new root PKC. Added: When a Virginia Tech Root CA updates its private signature key and thus generates a new public key, the Virginia Tech Root CA SHALL notify all Authorized Subordinate or cross certified CAs, and SHOULD make a best effort to notify any Subscribers that rely on the VTCA's PKC, that it has been changed. For self signed or globally trusted ("root") PKCs, such PKCs SHALL be made available online along with separately retrievable verification information to enable a relying party to verify that it has received a valid copy of the new root PKC Compromise Recovery Change made March 16, 2011 Removed: If the VTCA is the Virginia Tech Root CA, the trusted self signed certificate MUST be removed from each Relying Party application, and a new one distributed via secure out of band mechanisms. The Virginia Tech Root CA SHALL describe its approach to reacting to a Root CA key compromise in their CPSs. Added: If the VTCA is a Virginia Tech Root CA, the trusted self signed certificate MUST be removed from each Relying Party application, and a new one distributed via secure out of band mechanisms. A Virginia Tech Root CA SHALL describe its approach to reacting to a Root CA key compromise in their CPSs. xvi

17 CA Private Key Multi Person Control Change made March 16, 2011 Removed: The Virginia Tech Root CA of the VTPKI SHALL implement M of N authentication.( M number of persons from N total number of persons). Added: A Virginia Tech Root CA of the VTPKI SHALL implement M of N authentication.( M number of persons from N total number of persons) NETWORK SECURITY CONTROLS Change made March 16, 2011 Removed: The Virginia Tech Root CA equipment SHALL be implemented using a stand-alone (offline) configuration. Added: The equipment of a Virginia Tech Root CA SHALL be implemented using a stand-alone (offline) configuration GLOSSARY Removed: VTPKI: Virginia Tech Public Key Infrastructure refers to the Virginia Tech Root CA and all of the Subordinate CAs within the PKI hierarchy. Added: VTPKI: Virginia Tech Public Key Infrastructure refers collectively to the Self Signed Root and Global Virginia Tech Root CAs and all of the Subordinate CAs within each PKI hierarchy. xvii

18 1. INTRODUCTION This Certificate Policy (CP) statement defines the terms and conditions under which a Virginia Polytechnic Institute and State University (hereinafter Virginia Tech) Certificate Authority (VTCA) operating within the Virginia Tech Public Key Infrastructure (VTPKI) issues Public Key Certificates (PKC) that reference the policy object identifier (OID) for this CP MUST operate. Operation includes management of the PKCs it issues and management of its own infrastructure. The term "issues" in this context refers to the process of digitally signing with the private key associated with its authority certificate a structured digital object conforming to the ISO X.509, version 3 or compatible PKC format. One or more companion Certification Practice Statement(s) (CPS) MUST be defined for each Virginia Tech Certification Authority VTCA operating under this CP. Such a statement MUST articulate how a VTCA implements the provisions of this policy. The VTCAs that comprise the VTPKI are defined by independent Self Signed Root and Global Root CA hierarchies. Each Root CA hierarchy consists of one or more Subordinate CA(s). This CP applies to both Virginia Tech Root CA hierarchies and all of the Subordinate CAs within each hierarchy. Any VTCA for which the Virginia Tech Self Signed Root or Global Root CA signs an authority certificate MUST adopt this CP or one that is consistent with all of the requirements of this CP as determined by the Policy Management Authority for the VTPKI. This CP is structured in accordance with RFC 2527 [1]. Within this document the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" are to be interpreted as in RFC 2119 [2]. Acronyms ABADSG CA CAA CARL CN CP CPS CRIN CRL American Bar Association Digital Signature Guideline Certification Authority Certification Authority Administrator Certificate Authority Revocation List Common Name Certificate Policy Certification Practice Statement Certificate Revocation Identification Number Certificate Revocation List - 1 -

19 DES DN DPE DSA/DSS EDI FIPS PUB IETF IMS ISO ITU LOA NIST NSA OCSP OID PIN PKC PKCS Data Encryption Standard Distinguished Name Digital Processing Entity Digital Signature Algorithm / Digital Signature Standard Electronic Data Interface (US) Federal Information Processing Standard Publication Internet Engineering Task Force Identity Management Services International Standards Organization International Telecommunications Union Level of Assurance National Institute of Standards and Technology National Security Agency Online Certificate Status Protocol Object Identifier Personal Identification Number Public Key Certificate Public Key Certificate Standard PKI Public Key Infrastructure X.509 PMA PKIX RA RAA RFC Policy Management Infrastructure Public Key Authority Registration Authority Registration Authority Administrator (IETF) Request For Comments - 2 -

20 RSA SHA-1 S/MIME SSL TCP/IP TLS UPS URI URL URN VTCA VTPKI WWW Rivest-Shimar-Adleman Secure Hash Algorithm Secure Multipurpose Internet Mail Extension Secure Sockets Layer Transmission Control Protocol/Internet Protocol Transport Layer Security Uninterrupted Power Supply Uniform Resource Identifier Uniform Resource Locator Uniform Resource Name Virginia Tech Certification Authority Virginia Tech Public Key Infrastructure World Wide Web 1.1 OVERVIEW This CP defines a set of requirements that helps to determine the viability and applicability of a PKC issued by a conforming VTCA to the University community of users, subject entities, and/or class of applications. This CP MAY be used by a PKC Relying Party to help in deciding whether a certificate and the information therein and the binding of that information to the Subject are sufficiently trustworthy for a particular application. Any authority PKC issued by a VTCA MUST contain a valid reference to the applicable CP. This CP may be referenced only if a VTCA is in compliance with all aspects of this CP. Each VTCA MUST make available its own CPS(s) in order to provide information to potential clients of a VTCA and Relying Parties about the underlying technical, procedural and legal foundations which are not otherwise specified in this policy. The PMA may delegate any administrative responsibilities of a VTCA on condition that compliance with the current provisions in this CP are maintained

21 By relying on information contained in a PKC issued by a VTCA, the Relying Party is agreeing with the provisions and stipulations of this CP and the associated CPS under which the PKC was issued Certificate Policy (CP) Any VTCA that intends to refer to this CP in a PKC that it issues MUST digitally sign a copy of this document, using SHA-1 with RSA encryption and its primary PKC signing key, and make the signed copy available online as specified in Section Relationship Between the CP and the CPS This CP states what assurance can be placed in a certificate issued by the VTCA. The associated CPS states how the VTCA establishes that assurance Interoperation with CAs External to this Policy Domain The Virginia Tech Root CA may interoperate with CAs external to this policy domain for the sole purpose of having the Virginia Tech Root Certificate signed by an external CA. The VT PKI PMA must explicitly approve any external CA signature Relationship Between a Bridge CP and this CP No Stipulation. 1.2 IDENTIFICATION Each authority PKC issued by a VTCA MUST reference an Object Identifier (OID) that identifies this CP document. End entity PKCs SHOULD also include an OID indicating the Level of Assurance (LOA) that applies to that PKC. How this is to be achieved is described in the remainder of this section with further detail provided in the associated CPS document The base of the Object Identifier (OID) MUST be registered under the ANSI (or equivalent) arc. Sub arcs SHALL be defined for both this CP itself and for the different LOAs defined by this CP. OIDs also SHOULD be assigned to all associated CPSs referencing this CP. When referencing this CP as governing a PKC, the OID given on the cover page SHALL be used in addition to any textual description. If this CP is changed in any substantive way, a new CP OID SHALL be assigned for the new version. There are five Levels of Assurance (LOAs) covered by this CP as defined in subsequent sections. It is the intent of this CP for these LOAs to map directly to the Federal PKI (FPKI) Policy Authority LOAs. The LOA asserted in any PKC issued by the VTCA SHALL be indicated by the OID in the CertPolicyID field in the PKC. The LOA OIDs for this CP are defined in the associated CPS document of each VTCA CP. The CPS URI extension field in a PKC asserting one of these LOAs MUST point to an online copy of the CPS that implements that LOA. The CPS should include a URI pointing to an online digitally signed copy of the CPS as specified in Section That CPS - 4 -

22 in turn MUST identify explicitly by an appropriate OID the CP to which it is conforming and specify how a Relying Party may obtain a copy of that CP. It SHOULD also include a URI pointing to an online, digitally signed copy of that CP. Subsequent major revisions of this CP SHALL have a new OID assignment under the same OID arc. Minor revisions MAY be indicated by a suffix appended to the OID given on the cover page to this CP. The Level of Assurance (LOA) identifiers represent abstractions and SHALL remain the same unless or until new LOAs are required. This CP and a digitally signed copy of it may be found at The object identifier for this CP statement is COMMUNITY AND APPLICABILITY A VTCA MUST include in its CPS a definition of the Communities to which the VTCA will issue a PKC. The VTCA SHOULD NOT issue a PKC to any individual or other entity that is not included in one of the Communities. A Relying Party may not assume that the holder of a PKC issued by this VTCA has any particular relationship to any of the communities defined in the CPS unless explicitly stated in the CPS that such an assumption is warranted. A VTCA MUST include in any CPS a definition of the applicability or any restrictions on the use of any resulting PKC. Such applicability MUST be indicated in the appropriate PKC fields, e.g. Key Usage. A Relying Party MUST respect any applicability limitations indicated in the PKC PKI Authorities A Virginia Tech Root CA MAY issue a PKC with certificate issuance rights ( authority PKC ) to another VTCA and in that case the Authorized Subordinate VTCA assumes the role of a CA under this CP. For all purposes under this CP, the Authorized Subordinate CA SHALL conform to, and operate under, this CP. The PMA for the VTPKI SHALL have oversight responsibility for the operation of the Authorized Subordinate CA to ensure its conformance with this CP. A VTCA MAY delegate any of its responsibilities to a PMA associated with the Authorized Subordinate CA, provided that the VTCA remains responsible for conformance with all provisions of this CP. A VTCA operating at Basic or lower LOA does not have the authority to issue authority PKCs Registration Authorities The function of a Registration Authority (RA) is to verify the credentials that establish the binding between an individual or other entity that is the Subject of a PKC and the Subject's Public/Private Key Pair that is associated with that PKC and approve the issuance of a PKC for that Subject. A VTCA MAY perform the function of a Registration Authority. A VTCA remains responsible for conformance with all provisions of this CP and associated CPS(s)

23 1.3.3 End Entities The end entities that may be the Subject of a PKC issued under this policy can be (1) a natural person representing himself or herself, (2) an organization that is defined as part of the Community and is represented by a natural person authorized to act for that organization, or (3) a digital processing entity (e.g., a computer, a router or a defined application program or system), that is capable of performing cryptographic operations and that is owned or operated by an organization that is as part of the Community and that is represented by a natural person authorized to act for that organization ("PKC Sponsor"). In the latter case, the method of verification of the authorization of the person acting on behalf of the digital processing entity SHALL be set forth in the CPS Applicability PKCs issued by a VTCA MAY be used for any application, provided that the uses are within the limitations imposed by the CPS or as indicated in the PKC itself. However, only Relying Parties that accept in its entirety this CP and that accept in their entirety any limitations (financial or otherwise) contained in the PKC itself MAY make use of a PKC issued by a VTCA If a Subscriber wishes to have any limitations (financial or otherwise) on transactions authenticated by the PKCs that are not contained in the PKC itself, that Subscriber MUST have a signed agreement with each Relying Party agreeing to such limitations. Any Relying Party that wants to make use of a PKC issued by a VTCA to authenticate transactions of significant financial value or otherwise of import to the Relying Party SHOULD have a signed agreement with the Subscriber stating any specific limitations. The table below summarizes the recommended applicability of PKCs at each of the five levels of assurance covered by this CP. Assurance Level Test Rudimentary Applicability This level is used for interoperability testing. It is solely used for this purpose and conveys no assurance information. This level provides the lowest degree of assurance concerning identity of the Subject. One of the primary functions of this level is to provide data integrity to the information being signed. This level is relevant to environments in which the risk of malicious activity is considered to be low. It may not be suitable for transactions requiring reliable authentication. It is generally insufficient for transactions requiring strong confidentiality, but may be used when certificates having higher levels of assurance are unavailable

24 Basic Medium High This level provides a basic level of assurance relevant to environments where there are risks and consequences of data compromise, but they are not considered to result in significant negative consequences. It is assumed at this security level that users are not likely to be malicious. This level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud. This level is appropriate for use where the threats to data are high, or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk. 1.4 CONTACT DETAILS Questions about interpretation of this CP and associated CPSs, or concerns about possible abuse of this CP SHALL be directed in writing to the PMA identified under section Specification Administration Organization The Policy Management Authority (PMA) for this CP MUST be identified by postal address, office location, and other contact information in the applicable CPS. The Policy Management Authority (PMA) is appointed by the Vice President for Information Technology /Chief Information Officer (VPIT/CIO) who reports to the President. The PMA will have, at a minimum, decision making representation from university administration, academic colleges, and university Internal Audit department, as well as advisory individuals with expertise in PKI Contact Person Questions about interpretation of this CP should be directed to Identity Management Services. Concerns about possible abuse of this CP, should be directed in writing to the Virginia Tech Public Key Infrastructure Policy Management Authority (VTPKI PMA). Identity Management Services 1700 Pratt Dr. Blacksburg, VA

25 Chair, VTPKI PMA 1700 Pratt Dr. Blacksburg, VA Person Determining Certification Practice Statement Suitability for the Policy The PMA is responsible for reviewing and approving with an authorized signature any proposed CPS that is to be associated with this CP. 2. GENERAL PROVISIONS This section defines the responsibilities of each party involved in the issuance and use of PKCs issued by a VTCA. These responsibilities bear on any potential responsibility that might be associated with a VTCA operating under the CP as a result of use of an issued PKC. Relying Parties MUST understand the provisions of this section. 2.1 OBLIGATIONS Each party to the issuance and use of a PKC has an obligation to perform certain duties as detailed in this section. By accepting an issued PKC, a Subscriber accepts the obligations described hereunder. By making use of a PKC issued by a VTCA, a Relying Party is accepting its obligations hereunder CA Obligations A VTCA must operate a certification authority service in accordance with all provisions of this CP and any associated CPS(s). Its obligations include: Accepting certification requests and issuing PKCs according to a published CPS Accepting certificate revocation requests and effecting certificate revocation or suspension, as defined in section 4.4 A VTCA that issues a PKC to a Subscriber MUST have explicit authorization to do so. A VTCA MUST adhere to any restrictions or limitations specified in its authority PKC and/or written agreement with the authorizing Virginia Tech Root CA RA Obligations A subset of the responsibilities in may be delegated to an RA in accordance with the applicable CPS. In addition, an RA MUST also: Confirm to a VTCA in a secure manner the validation of the connection between a public/private key pair and the requester s identity including the successful use of a suitable proof of possession method Adhere to the CPS(s) and the written agreement made with a VTCA Subscriber Obligations A Subscriber MUST: Read and agree to the terms and conditions under which a VTCA issues PKCs - 8 -

26 Present legitimate credentials as required by the CPS for the PKC to be issued Protect the private key associated with an issued PKC. Specific requirements are stated in the CPS for the PKC to be issued. Some types of PKCs MAY require that the private key be put in escrow Notify a VTCA immediately upon either suspected or known compromise of the private key associated with a PKC issued by that VTCA Relying Party Obligations Parties who rely upon the certificates issued under a policy defined in this document are REQUIRED to: Use the certificate for the purpose for which it was issued, as indicated in the certificate information Ensure the certificate is of the required assurance level, as indicated in the certificate information Check each certificate for validity prior to reliance Establish trust in a VTCA that issued the certificates they are about to use by verifying the chain of certificates at root of which a trusted VTCA exists Be aware of and abide by all rules, regulations and statues applicable to all information contained in a PKC A relying party who is found to have acted in a manner inconsistent with these obligations SHALL have no claim against Virginia Tech in the event of a dispute Repository Obligations A Repository is responsible for maintaining a secure system for storing and retrieving Virginia Tech Certificates, a current copy of this Policy, information relevant to Virginia Tech Certificates, and for providing information regarding the status of Virginia Tech Certificates as valid or invalid for the use of any Relying Party. 2.2 LIABILITY CA Liability The CA Group disclaims all warranties and obligations of any type, including any warranty of merchantability, any warranty of fitness for a particular purpose, and any warranty of the accuracy of information provided, and further disclaims any and all liability for negligence and lack of reasonable care with respect to all PKCs issued by it. The CA Group shall not incur liability for representations of information contained in any PKC. Without limiting the generality of the foregoing, the CA Group accepts no liability of any sort if a Relying Party fails to fulfill its obligations as stated herein