VTCA CP Updates

X.509 Certificate Policy
For The
Virginia Polytechnic Institute and State University
Certification Authorities May 13, 2004
Amended September 19, 2006 OBJECT IDENTIFIER 1.3.6.1.4.1.6760.5.2.1.1.1 Release 1.0 Version 1.0

X.509 Certificate Policy
For The
Virginia Polytechnic Institute and State University
Certification Authorities May 13, 2004
Amended ?, 2009 OBJECT IDENTIFIER* 1.3.6.1.4.1.6760.5.2.1.1.1 Release 1.0 Version 2.0

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.

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.

1. Section 6.7Change made 9/19/06Removed: "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."

Add all changes for Migration Project here!

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.

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 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 http://www.pki.vt.edu/VirginiaTech/cp. A digitally signed copy of the CP may be found at http://www.pki.vt.edu/VirginiaTech/cp/signed/

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 http://www.pki.vt.edu/rootca/cp/index.html.

No Stipulation.

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.

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.

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.

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 24061

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 24061

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

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.

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 suspended PKC. Such a request MUST be sent to a VTCA during the period of validity of the PKC to be restored.

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.

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.

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.

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

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

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

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

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 

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 certicate 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>

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

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