VTCA Middleware CPS Updates

X.509 Certification Practice Statement for the Middleware  Certification Authority
April 11, 2006
OBJECT IDENTIFIER 1.3.6.1.4.1.6760.5.2.3.4.1
Release 1.0, Version 0.0

X.509 Certification Practice Statement for the Middleware  Certification Authority
April 11, 2006
Ammended June 10, 2009
OBJECT IDENTIFIER 1.3.6.1.4.1.6760.5.2.3.4.1
Release 1.0, Version 2.0

Add all changes for Migration Project here!

The VTCA Root CA has digitally signed a copy of the VTCA CP, using SHA-1 with RSA encryption and its primary PKC signing key http://www.pki.vt.edu/rootca/cp/index.html. The digitally signed copy of this MCA CPS is available online at http://www.pki.vt.edu/vtmw/cps/.

The MCA has a copy of the VTCA CP and CPS which has been 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.

• A digitally signed copy of the VTCA CP(Certificate Policy) is available at http://www.pki.vt.edu/rootca/cp.
• A digitally signed copy of the MCA CPS(Certification Practice Statement)  is available at http://www.pki.vt.edu/vtmw/cps.

The MCA serves two primary communities:
• the Middleware Services Server community which consists of server applications that provide services to the Middleware Services Client community
• the Middleware Services Client community which consumes those services offered by the Middleware Services Server community
The MCA also provides certificates for the RA administrators of the MCA. The MCA does NOT issue a PKC to any entity that is not included in the defined communities. A Relying Party assumes that the holder of a PKC issued by the MCA has a relationship to one of the communities defined in this CPS.

The MCA serves two primary communities:
• the Middleware Services Server community which consists of server applications that provide services to the Middleware Services Client community
• the Middleware Services Client community which consumes those services offered by the Middleware Services Server community
The MCA does NOT issue a PKC to any entity that is not included in the defined communities. A Relying Party assumes that the holder of a PKC issued by the MCA has a relationship to one of the communities defined in this CPS.

Information Resource Management is the Registration Authority for the MCA.

Identity Management Services is the Registration Authority for the MCA.

A PKC issued by the MCA to Middleware Services Server community members is used to identify the server to both server and client community member entities and to ensure data confidentiality and integrity during transport to server and client community members.
A PKC issued by the MCA to Middleware Services Client community members is used to identify the client to server community member entities, to ensure data confidentiality during transport to server community members, and to ensure data integrity during transport to server community members.
A PKC issued by the MCA to a natural person is used to identify an RAA. Only Relying Parties that accept in its entirety without any limitations (financial or otherwise) the VTCA CP and this CPS can make use of a PKC issued by the MCA.
The table below summarizes the recommended applicability of PKCs at each of the five levels of assurance covered by this document. The requirements for each Level of Assurance (LOA) are specified later in this document. PKCs issued by the MCA will have assurance levels of Test or Medium.

A PKC issued by the MCA to Middleware Services Server community members is used to identify the server to both server and client community member entities and to ensure data confidentiality and integrity during transport to server and client community members.
A PKC issued by the MCA to Middleware Services Client community members is used to identify the client to server community member entities, to ensure data confidentiality during transport to server community members, and to ensure data integrity during transport to server community members.
Only Relying Parties that accept in its entirety without any limitations (financial or otherwise) the VTCA CP and this CPS can make use of a PKC issued by the MCA.
The table below summarizes the recommended applicability of PKCs at each of the five levels of assurance covered by this document. The requirements for each Level of Assurance (LOA) are specified later in this document. PKCs issued by the MCA will have assurance levels of Test or Medium.

Questions about interpretation of this CPS are directed in writing to Information Resource Management. Concerns about possible abuse of this CPS, are directed in writing to the Virginia Tech Public Key Infrastructure Policy Management Authority (VTPKI PMA).       
Information Resource Management 1700 Pratt Dr. Blacksburg, VA 24060

Questions about interpretation of this CPS are directed in writing to Identity Management Services. Concerns about possible abuse of this CPS, are directed in writing to the Virginia Tech Public Key Infrastructure Policy Management Authority (VTPKI PMA).       
Identity Management Services 1700 Pratt Dr. Blacksburg, VA 24060

In addition to the obligations stipulated in the VTCA CP a Subscriber MUST:
• read and agree to the terms and conditions of this CPS
• read and agree to the Usage Terms and Conditions for the Middleware Service with which the PKC is to be used
• notify Information Resource Management immediately upon either suspected or known compromise of the private key associated with a PKC issued by the MCA

In addition to the obligations stipulated in the VTCA CP a Subscriber MUST:
• read and agree to the terms and conditions of this CPS
• read and agree to the Usage Terms and Conditions for the Middleware Service with which the PKC is to be used
• notify Identity Management Services immediately upon either suspected or known compromise of the private key associated with a PKC issued by the MCA

Interpretation of this CPS is the responsibility of the PMA and Information Resource Management.

Interpretation of this CPS is the responsibility of the PMA and Identity Management Services.

The CN component of a Subject name in a PKC issued by the MCA is directly representative of the application or natural person to which the PKC is issued.

The CN component of a Subject name in a PKC issued by the MCA is directly representative of the application to which the PKC is issued.

The Subject name for a Digital Processing Entity PKC must be in the following format:
CN = <application identifier>,
OU = <serial number assigned at PKC issuance>,
OU = < Middleware-Server or Middleware-Client>,
O = Virginia Polytechnic Institute and State University,
L = Blacksburg
S = Virginia,
C = US,
DC = vt,
DC = edu

The Subject name for a natural person entity PKC must be in the following format:
CN = <name of natural person>,
OU = Employee,
DC = vt,
DC = edu
The community designation is Middleware-Server for those belonging to the Middleware Services Server community or Middleware-Client for those belonging to the Middleware Services Client community. The community designation is Employee for those belonging to the Middleware RAA community.

The Subject name for a Digital Processing Entity PKC must be in the following format:
CN = <application identifier>,
SN=<A unique number assigned by the CA, only in Middleware-Client certificates>,
OU = <department name>,
OU = < Middleware-Server or Middleware-Client or Middleware-Server-with-saltr>,
O = Virginia Polytechnic Institute and State University,
L = Blacksburg,
ST = Virginia,
DC = vt,
DC = edu,
C=US
The community designation is Middleware-Server for those belonging to the Middleware Services Server community or Middleware-Client/Middleware-Server-with-saltr for those belonging to the Middleware Services Client community.

The Subject name in a PKC refers to a unique and identifiable digital processing entity or person. Including the serial number that is assigned by the CA ensures the uniqueness of the Subject name. A unique Subject name is not reused.

The Subject name in a PKC refers to a unique and identifiable digital processing entity. The accuracy of the DN details is checked by the registration authority using identification information provided during the enrollment process.  A subscriber's DN must be unique and must not be assigned to different subscribers. Only when a subscriber possesses a number of certificates with different key uses can a DN appear several times, although the respective serial numbers of the issuing CA always remain unique.

IRM will verify that the person listed as department head is the head of department, as claimed. IRM confirms any designations with the department head. Once signatures are on file, IRM will verify signatures associated with requests.

 IMS will verify that the person listed as department head is the head of department, as claimed. IMS confirms any designations with the department head. Once signatures are on file, IMS will verify signatures associated with requests.

The MCA will revoke PKCs after receiving a valid revocation request. IRM will also initiate revocation when the departmental unit that has requested the certificate is no longer an identifiable university unit.

The MCA will revoke PKCs after receiving a valid revocation request. IMS will also initiate revocation when the departmental unit that has requested the certificate is no longer an identifiable university unit.

Certificate Revocation Requests are accepted from any one of the following:
• the Subscriber
• the Subscriber's department head
• IRM

Certificate Revocation Requests are accepted from any one of the following:
• the Subscriber
• the Subscriber's department head
• IMS

A Certificate Revocation Request is initiated through:
• submission of the online CRR form that contains the Certificate Revocation
Identification Number (CRIN) from the CSR
• the hardcopy CRR form signed by the appropriate department head
• creation of the CRR by the RAA on behalf of the subscriber
The MCA RAA approves and digitally signs the CRR. All Revocation Requests should be
processed by the RAA immediately upon receipt. The CAA revokes the certificate and issues a
new CRL within two business days of approval by the RAA.

A Certificate Revocation Request is initiated through:

• Users email IMScerts@vt.edu and request the certificate be revoked.
• Users include the certificate common name and serial number in their revocation request.
• The MCA RAA approves the CRR. All Revocation Requests should be processed by the RAA immediately upon receipt.
• When approved, the CA immediately revokes the certificate and issues a new CRL within two business days of approval by the RAA.

Online Revocation/Status Checking is not available.

Online Revocation/Status Checking is available.

The audit logs are consolidated and reviewed on a regular basis by IRM.

The audit logs are consolidated and reviewed on a regular basis by IMS.

Access to audit logs is controlled by IRM, and access is restricted to authorized employees only.

Access to audit logs is controlled by IMS, and access is restricted to authorized employees only.

The MCA audit log is backed up on the same schedule as the rest of the data on the MCA host using a backup utility (vtBackup) which was developed at Virginia Tech. Backup audit logs of the MCA are protected against unauthorized viewing, modification, or deletion by encrypting the backup and storing it in a separate secure physical location offsite from the MCA host.
The audit logs for the Middleware RA are backed up using the central IT Legato Networker network backup service for the host on which the RA resides.

The MCA audit log is backed up on the same schedule as the rest of the data on VTCA servers using VT Information Systems and Computing network backup service providing:

• Scheduled daily backup of server files and directories
• Offsite storage in compliance with computing standards
• Restoration of files as needed

Archived records are protected against unauthorized viewing, modification, and deletion by using cryptographic protection and offsite storage in a physically secure and trustworthy location. The cryptographic protection is implemented using a 512 bit DES3 symmetric key that is unique to each backup instance. The DES3 symmetric key is then encrypted using 4096 bit RSA public key encryption.

Archived records are protected against unauthorized viewing, modification, and deletion by using offsite storage in a physically secure and trustworthy location. The offsite backup location provides the following key features:

• Storage in a secure, fire resistant Vault Room.
• A stable, secure storage environment: The room is maintained at a constant 70 degrees and 35% - 55% humidity. It's secured with intrusion alarms and motion detectors.
• Controlled access: The interior door to the building remains locked at all times. After admittance to the building, access to the Vault Room can only be obtained with the use of a valid VT ID card entered into the cipher lock.
• Enhanced fire protection: Constructed with a concrete floor, and walls, the Vault Room is rated to withstand as a minimum three hours of fire. Additionally the entire building has an automated fire suppression system and a fire alarm wired into the campus police office.

Daily backups created with vtBackup serve as archives for the Middleware CA application. The backups created with Legato Networker serve as archives for the Middleware RA application.

 Daily backups created using the network backup service provided by Information Systems and Computing serve as archives for the Middleware CA application.

On request by the auditors, IRM will authorize Operations Center personnel to retrieve media containing archived information from the offsite storage location. To view the CA archive, it must be decrypted. The private key needed to decrypt the symmetric key used to encrypt the backups is stored on removable media labeled "Backup Encryption RSA Key Pair" at the offsite storage location. A duplicate copy of the private key is stored on a BIO drive kept in a locked file cabinet in the eProvisioning office area.

On request by the auditors, IMS will authorize Operations Center personnel to retrieve media containing archived information from the offsite storage location. 

The encrypted backup media of the MCA are stored in an offsite physically secure and
trustworthy location.

The backup media of the MCA are stored in an offsite physically secure and trustworthy location. 

In the event of a system failure, there are sufficient backups that can be used to restore the MCA system. These backups are made on a daily schedule using the vtBackup utility and maintained for a period of 90 days. The daily backups are incremental with the exception of full backups which are done on the first day of each month, The most recent 14 daily backups are stored at a secure offsite location which can only be accessed by authorized personnel.

In the event of a system failure there are sufficient backups that can be used to restore the MCA system. Full monthly, weekly differential, and daily incremental backups are created durinng normal daily scheduled backups by the Information Systems and Computing network backup service. The backup media of the MCA are stored in an offsite physically secure and trustworthy location.

The Middleware Certification Authority Administrator (CAA) role is appointed by the Office of the Vice President for Information Technology. The CAA's responsibilities are:
• certificate generation and revocation
• CRL generation
• electronic certificate issuance for a MCA RAA
• administration of the MCA hardware security module

The Certification Authority Administrator (CAA) role is appointed by the Office of the Vice President for Information Technology. 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 is constituted by IRM. The RAA's responsibilities are:

The Registration Authority Administrator (RAA) role is constituted by IMS. The RAA's responsibilities are:

Standard extensions, when populated, are described in an appropriate Certificate Profile.
PKCs issued from the MCA have the following values in their Key Usage field:
• digital signature
• non repudiation
• key encipherment
• data encipherment
PKCs issued to members of the Middleware Services Client community have a value of Client Authentication (1.3.6.1.5.5.7.3.2) in the PKC's Enhanced Key Usage field.
PKCs issued to members of the Middleware Services Server community will have a value of Server Authentication (1.3.6.1.5.5.7.3.1) in the PKC's Enhanced Key Usage field.

Standard extensions, when populated, are described in Certificate Profiles published at:http://www.pki.vt.edu/vtmw/cps

No additional stipulations.

Add section 7.2.2 above - this section is missing from the CPS.

OCSP is supported but not currently implemented.

An OCSP (Online Certificate Status Protocol)responder service is available.