Certificate Practice Statement
1. Introduction
1.1. Overview
This document is the Certification Practice Statement (CPS) of the University of York. It describes rules and procedures used by University of York for operating its CA, and applies to all University of York PKI Participants, including Assurers, Members, and the University of York itself.
1.2. Document name and identification
This document is the Certification Practice Statement (CPS) of the University of York. The CPS also fulfills the role of the Certificate Policy (CP) for each class of certificate.
The document is structured according to Chokhani, et al, RFC3647, chapter 4. All headings derive from that Chapter.
OID assigned to this document: 1.3.6.1.4.1.12335.2.1.1.1.2 whose components have the meaning given below
- 1.3.6.1.4.1.12335.2.1.1.1.2 PKI Certificate Practice Statement
- 1.3.6.1.4.1.12335.2.1.1.1 General Policy
- 1.3.6.1.4.1.12335.2.1.1 Production
- 1.3.6.1.4.1.12335.2.1 Whole Organisation
- 1.3.6.1.4.1.12335.2 PKI Certificate Policies
- 1.3.6.1.4.1.12335 Registered to the University of York
- 1.3.6.1.4.1 - IANA-registered Private Enterprises
- 1.3.6.1.4 - Internet Private
- 1.3.6.1 - OID assignments from 1.3.6.1 - Internet
- 1.3.6 - US Department of Defense
- 1.3 - ISO Identified Organization
- 1 - ISO assigned OIDs
Subsequent revisions to this CPS may have new OID assignments.
The CPS is an authoritative document, and rules other documents except where explicitly deferred to. See also 1.5.1 Organisation Administering the Document.
1.3. PKI participants
1.3.1. Certification authorities
The CA is legally operated by the University of York. It provides PKI services to staff, students and associates of the University of York. The University Of York CA does not issue or sign certificates other than for services provided by the University of York or its associated companies or departments.
The University of York does not issue certificates to external intermediate CAs under the present CPS.
1.3.2. Registration authorities
The RA Operators are responsible for verifying Subscribers’ identities and approving their certificate requests. RA Operators do not issue certificates. The list of RAs is available on the University of York CA website.
1.3.3. Subscribers
The University of York CA issues user, host, service and code signing certificates. Subscribers eligible for certification from the University of York CA must be:
- Users (Staff, students, associates and visitors of the University of York).
- Computers (hosts)
- Services (host applications).
- Code Signing (verification of ownership)
1.3.4. Relying parties
All entities that use public keys of certificates, issued by the University of York CA for signature verification and/or encryption, will be considered as relying parties.
1.3.5. Other participants
No stipulation.
1.4. Certificate usage
1.4.1 Appropriate certificate uses
Personal certificates can be used to authenticate a user that would like to benefit from the University of York resources. Host certificates can be used to identify computers that have tasks related to the University of York activities. Service certificates can be used to recognize the host applications and data or communication encryption (TLS). In addition, it is permissible to use certificates for code signing.
1.4.2. Prohibited certificate uses
No stipulation.
1.5. Policy administration
1.5.1 Organization administering the document.
IT Services
University of York
Heslington
York
YO10 5DD
Phone: +44 1904 323838
Email: itsupport@york.ac.uk
1.6 Definitions and acronyms
- CA Certification Authority
- CP/CPS Certificate Policy/Certification Practice Statement
- CRL Certificate Revocation List
- DNS Domain Name System
- FQDN Fully Qualified Domain Name
- HTTP Hypertext Transfer Protocol
- IANA Internet Assigned Numbers Authority IP Internet Protocol
- OCSP Online Certificate Status Protocol
- OID Object Identifier
- PKI Public Key Infrastructure
- RA Registration Authority
- RFC Request For Comment
- S/MIME Secure / Multipurpose Internet Mail Extensions
- SSL Secure Sockets Layer
- URL Uniform Resource Locator
- USB Universal Serial Bus
2. Publication and repository responsibilities
2.1. Repositories
- The University of York CA operates online repositories that contain:
- The University of York CA root certificate.
- The University of York Issuing certificates.
- Certificate Revocation Lists (periodically updated).
- A copy of the most recent version of this CPS.
- A list of current operational Registration Authorities.
2.2. Publication of certification information
The University of York publishes:
- A repository of CRLs. OCSP responders are in operation.
- The root certificate and intermediate certificates.
The University of York does not expressly publish information on issued certificates. However, due to the purpose of certificates, and the essential public nature of names and email addresses, all information within certificates is presumed to be public and published, once issued.
2.3. Time or frequency of publication
Root and Intermediate Certificates are made available on issuance.
CRLs are made available on issuance or revocation.
2.4. Access controls on repositories
Information published in the repository portion of the University of York website is publicly-accessible information. Read only access to such information is unrestricted.
3. Identification and authentication
3.1. Naming
3.1.1. Types of names
The subject names for the certificate applicants shall follow the X.509.v3 registered identifier standard and be compliant with RFC5280.
3.1.2. Need for names to be meaningful
The subject name must represent the Subscriber in a way that is easily understandable by humans and must have a reasonable association with the authenticated name of the Subscriber. Each host certificate must be linked to a single network entity.
3.1.3. Anonymity or pseudonymity of subscribers
University of York CA will neither issue nor sign pseudonymous or anonymous certificates.
3.1.4. Rules for interpreting various name forms
See section 3.1.1.
3.1.5. Uniqueness of names
Uniqueness of names within certificates is not guaranteed. Each certificate has a unique serial number which maps to a unique account, and thus maps to a unique member.
Domain names and email address can only be registered to one member.
3.1.6. Recognition, authentication, and role of trademarks
No stipulation.
3.2. Initial identity verification
3.2.1. Method to prove possession of private key
University of York uses industry-standard techniques to prove the possession of the private key.
3.2.2. Authentication of individual identity
An individual can become a user of the University of York CA services by registering with the University of York. As part of the registration process they have to supply information to enable the University of York to validate their identity.
3.2.3. Authentication of organization identity
The University of York CAs only provides certificates for the University of York or its associated companies or departments. If additional validation is required, the person or persons who represent a department or part of the university which is applying for the certificate will be contacted.
3.2.4. Non-verified subscriber information
No stipulation.
3.2.5. Validation of authority
No stipulation.
3.2.6. Criteria for interoperation
No stipulation.
3.3. Re-key requests
Prior to the expiration of an existing Certificate, it is necessary for the Subscriber to obtain a new Certificate to maintain continuity of Certificate usage. Subscribers have the option of generating a new Key Pair to replace the expiring Key Pair (technically defined as "rekey") or of creating a new CSR for an existing Key Pair (technically defined as "renewal"), depending on their preferences and the capabilities and restrictions of the Subscriber's key generation tools. For purposes of this CPS, both a "rekey" and "renewal" as defined above will be treated as a renewal Certificate. New certificate information submitted for renewal Certificates are subject to the same authentication steps outlined in this CPS as apply to initial issuance of a Certificate.
3.4. Revocations requests
Via a support call to IT Services as detailed under section (1.5.1).
4. Certificate life-cycle operational requirements
4.1. Certificate application
4.1.1. Who can submit a certificate application
Any member or associate of the University of York may submit certificate applications.
4.2. Certificate application processing
4.2.1. Authentication
All the certificate applications will be authenticated and validated by the University of York CA and RAs as stated in section 3.2.3.
4.2.2. Verifying control
If the certificate request does not meet one or more of the criteria in 4.1.1, it will be rejected.
4.2.3. Options available
No stipulation.
4.2.4. Client certificate procedures
No stipulation.
4.2.5. Server certificate procedures
No stipulation.
4.2.6. Code-signing certificate procedures
No stipulation.
4.2.7. Organisation domain verification
No stipulation.
4.3. Certificate issuance
4.3.1. CA actions during certificate issuance
- Key Sizes. Members may request RSA certificates using at least a 2048 bit key length.
- Algorithms. University of York CA currently only supports the RSA algorithm for X.509 keys. X.509 signing uses the SHA-256 message digest algorithm.
- Process for Issuance: The University of York verifies the source of a certificate request before issuance. After issuance completes, the certificate is stored in a database and provided to the Subscriber.
4.3.2. Notification to subscriber by the CA of issuance of certificate
No stipulation.
4.4. Certificate acceptance
4.4.1. Conduct constituting certificate acceptance
There is no need for the user to explicitly accept the certificate. In case the potential user rejects the certificate, the certificate has to be revoked and made again.
4.4.2. Publication of the certificate by the CA
The University of York does not currently publish the issued certificates in any repository.
4.4.3. Notification of certificate issuance by the CA to other entities
If the RA has handled the communication with the Subscriber, then it will be notified of the certificate issuance. There are no other external entities that are notified about issued certificates.
4.5. Key pair and certificate usage
4.5.1. Subscriber usage and responsibilities
Subscribers should use keys only for their proper purpose, as indicated by the certificate, or by wider agreement with others.
4.5.2. Relying party usage and responsibilities
Relying Parties must verify that the Certificate is valid by examining a Certificate Revocation List ("CRL") before initiating a transaction involving such Certificate. The University of York does not accept responsibility for reliance on a fraudulently obtained Certificate or a Certificate that is on the CRL. 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. The University of York 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 (eg, if Digital Signature is not enabled then the certificate may not be relied upon for validating a Subscriber’s signature).
- 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 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.
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.6. Certificate renewal
A certificate can be renewed at any time. The procedure of certificate renewal is the same as for the initial certificate issuance.
4.7. Certificate re-key
See Section 3.3.
4.8. 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 Subscriber's public key). Certificate modification is considered a Certificate Application in terms of Section 4.1.
4.9. Certificate revocation and suspension
4.9.1. Circumstances for revocation
Certificates may be revoked under the following circumstances:
- Those that are required for operation of the CA service.
- As initiated by the Subscriber through a request to IT Services as detailed in section 1.5.1.
- As initiated in an emergency action by an IT support team member. E.g. if an account looks like it has been compromised.
- Where the Subscriber is in breach of the terms of use of a certificate.
- Where a Subscriber is no longer a member of the university or when a Subscriber’s account or associated equipment has been compromised.
- If an RA reasonably determines that a Publisher Certificate is being used in a manner that compromises the trust status of relying parties.
4.9.2. Who can request revocation
Subscribers and members of IT Services as detailed in section 1.5.1.
4.9.3. Procedure for revocation request
As initiated by the Subscriber through a request to IT Services as detailed in section 1.5.1.
4.9.4. Revocation request grace period
No stipulation.
4.9.5. Time within which CA must process the revocation request
No stipulation.
4.9.6. Revocation checking requirement for relying parties
Each revoked certificate is recorded in a certificate revocation list (CRL). Relying Parties must check a certificate against the most recent CRL issued, in order to validate the certificate for the intended reliance.
4.9.7. CRL issuance frequency (if applicable)
A new CRL is issued after every certificate revocation.
4.9.8. Maximum latency for CRLs (if applicable)
The maximum latency between revocation and issuance of the CRL is 10 days.
4.9.9. On-line revocation/status checking availability
OCSP is available at http://ocsp.york.ac.uk/ and http://onboard.york.ac.uk
CRLs are available via http://pki.york.ac.uk/
4.9.10. On-line revocation checking requirements
A Relying Party must check the status of a certificate on which they wish to rely.
4.9.11. Other forms of revocation advertisements available
None.
4.9.12. Special requirements re key compromise
Subscribers are obliged to revoke certificates at the earliest opportunity.
4.9.13. Circumstances for suspension
Certificates may be suspended prior to revocation if we do not have all the facts required to perform revocation.
4.9.14. Who can request suspension
As listed in section 4.9.2
4.9.15. Procedure for suspension request
An internal procedure exists for the temporary suspension of a user certificate.
4.9.16. Limits on suspension period
Not stipulated.
4.10. Certificate status services
The status of certificates is available via CRL and OCSP websites as listed in 4.9.9
4.10.1. Operational characteristics
OCSP is available at http://ocsp.york.ac.uk/ and http://onboard.york.ac.uk
4.10.2. Service availability
Certificate Status Services are available 24x7 without scheduled interruption.
4.10.3. Optional features
No stipulation.
4.11. End of subscription
Certificates include expiry dates.
4.12. Key escrow and recovery
4.12.1. Key escrow and recovery policy and practices
University of York CA does not generate nor escrow Subscriber keys.
4.12.2. Session key encapsulation and recovery policy and practices
No stipulation.
5. Facility, management and operational controls
5.1. Physical controls
5.1.1 Site location and construction
The University of York CA operates in controlled and protected rooms located in the University of York.
5.1.2 Physical access
Physical access to the University of York CA is restricted to authorized personnel only.
5.1.3. Power and air conditioning
The University CA facility is equipped with primary and backup:
- Power systems to ensure continuous, uninterrupted access to electric power
- Heating/ventilation/air conditioning systems to control temperature and relative humidity.
5.1.4. Water exposures
The University of York has taken reasonable precautions to minimize the impact of water exposure to University of York systems.
5.1.5. Fire prevention and protection
The University of York has taken reasonable precautions to minimize the impact of fire exposure to University of York systems.
5.1.6. Media storage
Backups are to be stored on removable storage media including a safe offsite location.
5.1.7. Waste disposal
Physically media are that are no longer needed are destroyed before disposal.
5.1.8. Off-site backup
Offsite backup is used for storing the information required in order to re-constitute the Root CA.
5.2. Procedural controls
5.2.1. Trusted roles
Access is limited to the following groups on both the Root CA and issuing CAs:
- CA Administrators
- CA Certificate Management
- CA Auditors
5.2.2. Number of persons required per task
The University of York CA operates to the principles of dual control. All tasks relating to the root CA require a minimum of two persons.
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.
- Trusted persons can be members of:
- Senior managers in IT Services
- Members of the IT Security Team
- Members of IT Services
Well recognized forms of identification are used (eg, passports and driver's licenses).
5.2.4. Roles requiring separation of duties
Issuing and Root CAs shall enforce role separation either by the CA equipment or procedurally or by both means. Individual CA personnel are specifically designated to the roles defined in Section 5.2.1 above.
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.
5.3.1. Qualifications, experience, and clearance requirements
The University of York 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.
5.3.2. Background check procedures
Prior to commencement of employment in a Trusted Role, the University of York conducts background checks which include the following:
- confirmation of previous employment,
- check of professional reference,
- confirmation of identification.
5.3.3. Training requirements
No stipulation.
5.3.4. Retraining frequency and requirements
No stipulation.
5.3.5. Job rotation frequency and sequence
No stipulation.
5.3.6. Sanctions for unauthorized actions
Appropriate disciplinary actions are taken for unauthorized actions or other violations of the University of York's 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.
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 University of York employees in a comparable position. Independent contractors and consultants who have not completed or passed the background check procedures specified in CPS Section 5.3.2 are permitted access to the University of York 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
The University of York provides its employees the requisite training and other documentation needed to perform their job responsibilities competently and satisfactorily.
5.4. Audit logging procedures
5.4.1 Types of events recorded
Audit log files shall be generated for all events relating to the security and services of the Issuing CA. Where possible, the security audit logs shall be automatically collected. Where this is not possible, a logbook, paper form, or other physical mechanism shall be used. All security audit logs, both electronic and non-electronic, shall be retained and made available during compliance audits. Issuing CAs should ensure all events relating to the lifecycle of Certificates are logged in a manner to ensure the traceability to a person in a trusted role for any action required for CA services. At a minimum, each audit record includes the following (either recorded automatically or manually) elements:
- The type of event;
- The date and time the event occurred;
- Success or failure where appropriate;
- The identity of the entity and/or operator that caused the event;
- The identity to which the event was targeted; and
- The cause of the event.
5.4.2 Frequency of processing log
Audit logs should be reviewed periodically for any evidence of malicious activity and following each important operation.
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 in accordance with Section 5.1.6
5.4.5 Audit log backup procedures
See Section 5.4.3
5.4.6 Audit collection system (internal vs external)
No stipulation.
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
No stipulation.
5.4.9 Archive collection system (internal or external)
No stipulation.
5.4.10 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.5. Records archival
5.5.1 Types of records archived
The University of York archives the following type of records:
- Certificate application information
- Certificate lifecycle information eg, revocation, rekey and renewal application information
5.5.2 Retention period for archive
Records shall be retained for at least 2 years after any certificate based on that documentation ceases to be valid.
5.5.3 Protection of archive
The University of York 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
No stipulation.
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)
No stipulation.
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
Lifetime of University of York CA is 10 years and the lifetime of an intermediate CA is 5 years. The lifetime of end entity certificates is from 1 to 27 months. The CA's private keys are changed periodically; from that time on, the new key will be valid in order to sign new certificates or CRL lists of new certificates. The overlap of the old and new key must be at least one year. The older but still valid certificate must be available to verify old signatures and its private key must be used to sign CRLs until all the certificates signed using the associated key have expired or been revoked.
5.7. Compromise and disaster recovery
5.7.1 Incident and compromise handling procedures
Backup copies of essential business and CA information are made routinely. In general, back-ups are performed daily on-site for online systems, offline systems are backed up less frequently due to this fact.
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 IT Services (details found in 1.5.1). Appropriate escalation, incident investigation, and incident response will ensue as per the University of York’s Information Security Incident Management Policy as listed under the following website:
- https://www.york.ac.uk/about/departments/support-and-admin/information-services/information-policy/index/
5.7.3 Entity private key compromise procedures
In the event of the Compromise of one or more of the University of York Root or intermediate Key(s) (including the CA Certificates), the University of York shall promptly notify all Subscribers via e-mail and notify Relying Parties and others via the CRL and additional notices posted under www.york.ac.uk and shall revoke all Certificates issued with such University of York Root Key or Intermediate(s).
5.7.4 Business continuity capabilities after a disaster
The University of York systems are redundantly configured and where possible are distributed across geographic locations to allow for disaster recovery.
5.8. CA or RA termination
In the event of operational termination, the Roots (including Intermediates) and all private user information will be secured. Existing valid certificates will be revoked, and any Intermediate and Root CAs revoked. User information will be securely destroyed.
6. Technical security controls
6.1. Key pair generation and installation
6.1.1. Key pair generation
CA Key Pair generation is performed by multiple trained and trusted individuals using secure systems and processes that provide for the security and required cryptographic strength for the keys that are generated. 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 University of York management.
At a minimum, the cryptographic modules used for key generation and storage meet the requirements of FIPS 140-2 level 3. The Root Keys for each CA Certificate are generated and are stored in hardware and are backed up but not escrowed.
6.1.2. Subscriber private key security
Not Applicable
6.1.3. Public key delivery to certificate issuer
Applicants can make user/host/service certificate requests as described in section 4.1
6.1.4. CA public key delivery to relying parties
The CA root certificates are distributed by these means:
Published on the website of the University of York at http://pki.york.ac.uk
6.1.5. Key sizes
For a user or host certificate the key size is at least 2048 bits for RSA. The University of York CA RSA key size is 4096 bits.
6.1.6. Public key parameters generation and quality checking
No stipulation.
6.1.7. Key usage purposes
Keys may be used for authentication, non-repudiation, data encipherment, message integrity and session establishment. The CAs private key is only used for signing certificates and CRLs.
6.2. Private key protection and cryptographic module engineering controls
6.2.1. Cryptographic module standards and controls
For issuing Root CA key pair generation and Root CA private key storage, the University of York uses hardware cryptographic modules that, at a minimum, are certified at or meet the requirements of FIPS 140-2 Level 3.
6.2.2 Private key (n out of m) multi-person control
Multi-Person Control CA Key Pair generation is performed by multiple trained and trusted individuals using secure systems and processes that provide for the security and required cryptographic strength for the keys that are generated. All CA Key Pairs are generated in pre-planned key generation ceremonies. 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 University of York management. The CA 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.
6.2.3 Private key escrow
The Root Keys for each CA Certificate are not escrowed.
6.2.4 Private key backup
University of York CA Key Pairs are maintained in a trusted and highly secured environment with backup procedures.
6.2.5 Private key archival
When University of York 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 offline media. Procedural controls will 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.
6.2.6 Private key transfer into or from cryptographic module
Private key transfer into or from a cryptographic module is performed in secure fashion in accordance to manufacturing guidelines of the module.
6.2.7 Private key storage on cryptographic module
Private key storage on cryptographic modules is secure in accordance to manufacturing guidelines of module.
6.2.8 Method of activating private key
No stipulation.
6.2.9 Method of deactivating private key
No stipulation.
6.2.10 Method of destroying private key
No stipulation.
6.2.11 Cryptographic module rating
See Section 6.2.1.
6.3 Other aspects of key pair management
No stipulation.
6.3.1. Public key archival
No stipulation.
6.3.2. Certificate operational periods and key pair usage periods
A Certificate's period of validity typically begins on the date the Certificate is issued (or such later date as specified in the Certificate), and ends on the date and time it expires as noted in the Certificate unless the Certificate is revoked before its expiration. 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.
6.4. Activation data
No stipulation.
6.5. Computer security controls
The University of York performs all CA and RA functions using trustworthy systems.
6.5.1 Specific computer security technical requirements
The University of York requires the use of passwords that have a minimum character length and a combination of alphanumeric and special characters. The University of York requires that passwords be changed on a periodic basis.
6.5.2 Computer security rating
No stipulation.
6.6. Life cycle technical controls
6.6.1 System development controls
No stipulation.
6.6.2 Security management controls
No stipulation.
6.6.3 Life cycle security controls
No stipulation.
6.7. Network security controls
No stipulation.
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
7.1.1. Version number(s)
Issued X.509 certificates are of v3 form.
7.1.2. Certificate extensions
Issuing CAs shall issue Certificates in compliance with RFC 5280 and applicable best practice. With the exception that the name constraints set on the University of York Issuing CA(s) are not marked as critical due to interoperability issues.
7.1.3. Algorithm object identifiers
No stipulation.
7.1.4. Name forms
Refer to 3.1.1.
7.1.5. Name constraints
Refer to 3.1.1.
7.1.6. Certificate policy object identifier
Certificates issued in accordance with this document may include the OID 1.3.6.1.4.1.12335.2.
7.1.7. Usage of policy constraints extension
No stipulation.
7.1.8. Policy qualifiers syntax and semantics
No stipulation.
7.1.9. Processing semantics for the critical certificate policies extension
No stipulation.
7.2. CRL profile
7.2.1. Version number(s)
Issuing CAs shall issue Version 2 CRLs in compliance with RFC 5280.
7.2.2. CRL and CRL entry extensions
No stipulation.
7.3. OCSP profile
OCSP responders conform to the Lightweight OCSP Profile RFC 5019
7.3.1. Version number(s)
No stipulation.
7.3.2. OCSP extensions
No stipulation.
8. Compliance audit and other assessments
8.1 Frequency and circumstances of assessment
Compliance Audits are conducted at least every 2.5 years. Audits are conducted over unbroken sequences of audit periods with each period no longer than 2.5 years duration.
8.2. Identity/qualifications of assessor
Systems Auditors. University of York uses business systems auditors with broad experience across the full range of business, information systems and security fields.
8.3. Assessor's relationship to assessed entity
Specific internal restrictions on audit personnel:
Must be assured by University of York Assurers and must be background checked.
Must not have been active in any of the three defined admin roles within the CA:
- Administrators
- Operators
- Backup Operators
An Auditor may convene an audit team. The same restrictions apply in general to all members of the team, but may be varied. Any deviations must be documented and approved by the University of York IT Services Management
8.4. Topics covered by assessment
No stipulation.
8.5. Actions taken as a result of deficiency
No stipulation.
8.6. Communication of results
No stipulation.
9. Other business and legal matters
9.1. Fees
No stipulation.
9.2. Financial responsibility
No stipulation.
9.2.1. Insurance coverage
No stipulation.
9.2.2. Other assets
No stipulation.
9.2.3. Insurance or warranty coverage for end-entities
No stipulation.
9.3. Confidentiality of business information
9.3.1. Scope of confidential information
No stipulation.
9.4. Privacy of personal information
No stipulation.
9.4.1. Privacy plan
No stipulation.
9.4.2. Information treated as private
No stipulation.
9.4.3. Information not deemed private
To the extent that information is put into an issued certificate, that information is not deemed private, as it is expected to be published by the Subscriber as part of routine use of the certificate. Such information generally includes Names, domains, email addresses, and certificate serial numbers.
9.4.4. Responsibility to protect private information
The University of York takes privacy seriously. Any privacy issue may be referred to dispute resolution via the contact information provided in 1.5.1.
9.4.5. Notice and consent to use private information
Unless where otherwise stated in this CPS, the applicable Privacy Statement 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
The University of York shall be entitled to disclose Confidential/Private Information if, in good faith, the University of York believes that:
- disclosure is necessary in response to court orders 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.
9.4.7. Other information disclosure circumstances
No stipulation.
9.5. Intellectual property rights
The following are the property of University of York:
- This CPS;
- Policies and procedures supporting the operation of the University of York PKI Services;
- Certificates and CRLs issued by University of York PKI Services managed CAs;
9.6. Representations and warranties
9.6.1 CA representations and warranties
No stipulation.
9.6.2 RA representations and warranties
No stipulation.
9.6.3 Subscriber representations and warranties
No stipulation.
9.6.4 Relying party representations and warranties
No stipulation.
9.7. Disclaimers of warranties
No stipulation.
9.8. Limitations of liability
No stipulation.
9.9. Non-related persons
No stipulation.
9.10. Indemnities
No stipulation.
9.11. Term and termination
9.11.1. Term
No stipulation.
9.11.2. Termination
No stipulation.
9.11.3. Effect of termination and survival
No stipulation.
9.12. Individual notices and communications with participants
No stipulation.
9.13. Amendments
No stipulation.
9.14. Dispute resolution provisions
No stipulation.
9.15. Governing law
The governing law is that of England and Wales.
9.16. Compliance with applicable law
No stipulation.
9.17. Force majeure
No stipulation.
9.18. Miscellaneous provisions
No stipulation.
9.19. Force majeure
No stipulation.
---This is the end of the Policy---