X.509 Certificate Policy
For The
TSCP Bridge Certification Authority (TBCA)
Version 2
August 26, 2014
Signature Page
Shauna Russell Signed using a Digitally Signed Email 8/26/2014
______
Chair, TSCP Policy Management AuthorityDATE
Revision History
Document Version / Document Date / Revision Details0.1 / 23 May 2013 / NA, Initial draft derived from FBCA CP 2.26
1.0 / 24 March 2014 / Clarifications resulting from reconciliationof CPS to CP compliance review results
2.0 / 26 August 2014 / PMA Approved Version 2 - includes 26 v.1.1 Draft changes needed to comply with the Federal Bridge CPWG comments
Table of Contents
1.INTRODUCTION
1.1Overview
1.1.1Certificate Policy (CP)
1.1.2Relationship between the CP & CPS
1.1.3Relationship between the TBCA CP and the Entity CP
1.1.4Scope
1.1.5Interaction with PKIs External to TSCP, Inc.
1.2Document Identification
1.3PKI Entities
1.3.1PKI Authorities
1.3.1.1TSCP Inc. (TSCP)
1.3.1.2Program Management Office (TPMO)
1.3.1.3TSCP Policy Management Authority (TPMA)
1.3.1.4TSCP Policy Working Group (TPWG)
1.3.1.5TSCP Operations Authority (TOA)
1.3.1.6Entity Certification Authority (Entity CA)
1.3.1.7Entity Principal Certification Authority (PCA)
1.3.1.8Entity PKI Policy Management Authority (PMA)
1.3.1.9TSCP Bridge Certification Authority (TBCA)
1.3.1.10Certificate Status Servers (CSS)
1.3.2Registration Authority (RA)
1.3.3Card Management System (CMS)
1.3.4Subscribers
1.3.5Affiliated Organizations
1.3.6Relying Parties
1.3.7Other Participants
1.3.7.1Trusted Agent
1.3.7.2Additional Participants
1.4Certificate Usage
1.4.1Appropriate Certificate Uses
1.4.2Prohibited Certificate Uses
1.5Policy Administration
1.5.1Organization administering the document
1.5.2Contact Person
1.5.3Person Determining Certification Practices Statement Suitability for the Policy
1.5.4CPS Approval Procedures
1.5.5Waivers
1.6Definitions and acronyms
2.PUBLICATION & REPOSITORY RESPONSIBILITIES
2.1repositories
2.1.1Repository Obligations
2.2PUBLICATION of certification information
2.2.1Publication of Certificates and Certificate Status
2.2.2Publication of CA Information
2.2.3Interoperability
2.3Frequency of Publication
2.4access controls on repositories
3.Identification & Authentication
3.1Naming
3.1.1Types of Names
3.1.2Need for Names to Be Meaningful
3.1.3Anonymity or Pseudonymity of Subscribers
3.1.4Rules for Interpreting Various Name Forms
3.1.5Uniqueness of Names
3.1.6Recognition, Authentication, & Role of Trademarks
3.1.7Name Claim Dispute Resolution
3.2INITIAL Identity Validation
3.2.1Method to Prove Possession of Private Key
3.2.2Authentication of Organization Identity
3.2.3Authentication of Individual Identity
3.2.3.1Initial Identity Proofing of Human Subscribers
3.2.3.2Human Subscriber Identity Proofing via Antecedent Relationship
3.2.3.3Human Subscriber Re-Proofing following loss, damage, or key compromise
3.2.3.4Identity Proofing Human Subscribers For Role-based Certificates
3.2.3.5Authentication of Devices
3.2.4Non-verified Subscriber Information
3.2.5Validation of Authority
3.2.6Criteria for Interoperation
3.3Identification and authentication for re-key requests
3.3.1Identification and Authentication for Routine Re-key
3.3.2Identification and Authentication for Re-key after Revocation
3.4Identification and authentication for revocation request
4.Certificate Life-Cycle
4.1Application
4.1.1Submission of Certificate Application
4.1.2Enrollment Process and Responsibilities
4.2Certificate Application Processing
4.2.1Performing Identification and Authentication Functions
4.2.2Approval or Rejection of Certificate Applications
4.2.3Time to Process Certificate Applications
4.3CERTIFICATE Issuance
4.3.1CA Actions during Certificate Issuance
4.3.2Notification to Subscriber of Certificate Issuance
4.4CERTIFICATE Acceptance
4.4.1Conduct constituting certificate acceptance
4.4.2Publication of the Certificate by the CA
4.4.3Notification of Certificate Issuance by the CA to other entities
4.5key pair and certificate Usage
4.5.1Subscriber Private Key and Certificate Usage
4.5.2Relying Party Public key and Certificate Usage
4.6Certificate Renewal
4.6.1Circumstance for Certificate Renewal
4.6.2Who may request Renewal
4.6.3Processing Certificate Renewal Requests
4.6.4Notification of new certificate issuance to Subscriber
4.6.5Conduct constituting acceptance of a Renewal certificate
4.6.6Publication of the Renewal certificate by the CA
4.6.7Notification of Certificate Issuance by the CA to other entities
4.7Certificate Re-Key
4.7.1Circumstance for Certificate Re-key
4.7.2Who may request certification of a new public key
4.7.3Processing certificate Re-keying requests
4.7.4Notification of new certificate issuance to Subscriber
4.7.5Conduct constituting acceptance of a Re-keyed certificate
4.7.6Publication of the Re-keyed certificate by the CA
4.7.7Notification of certificate issuance by the CA to other Entities
4.8CERTIFICATE Modification
4.8.1Circumstance for Certificate Modification
4.8.2Who may request Certificate Modification
4.8.3Processing Certificate Modification Requests
4.8.4Notification of new certificate issuance to Subscriber
4.8.5Conduct constituting acceptance of modified certificate
4.8.6Publication of the modified certificate by the CA
4.8.7Notification of certificate issuance by the CA to other Entities
4.9Certificate Revocation & Suspension
4.9.1Circumstances for Revocation
4.9.2Who Can Request Revocation
4.9.3Procedure for Revocation Request
4.9.4Revocation Request Grace Period
4.9.5Time within which CA must Process the Revocation Request
4.9.6Revocation Checking Requirements for Relying Parties
4.9.7CRL Issuance Frequency
4.9.8Maximum Latency of CRLs
4.9.9On-line Revocation/Status Checking Availability
4.9.10On-line Revocation Checking Requirements
4.9.11Other Forms of Revocation Advertisements Available
4.9.12Special Requirements Related To Key Compromise
4.9.13Circumstances for Suspension
4.9.14Who can Request Suspension
4.9.15Procedure for Suspension / Un-Suspension Request
4.9.16Limits on Suspension Period
4.10Certificate Status Services
4.10.1Operational Characteristics
4.10.2Service Availability
4.10.3Optional Features
4.11End Of Subscription
4.12Key Escrow & Recovery
4.12.1Key Escrow and Recovery Policy and Practices
4.12.2Session Key Encapsulation and Recovery Policy and Practices
5.Facility Management & Operations Controls
5.1Physical Controls
5.1.1Site Location & Construction
5.1.2Physical Access
5.1.2.1Physical Access for CA Equipment
5.1.2.2Physical Access for RA Equipment
5.1.2.3Physical Access for CSS Equipment
5.1.2.4Physical Access for CMS Equipment
5.1.3Power and Air Conditioning
5.1.4Water Exposures
5.1.5Fire Prevention & Protection
5.1.6Media Storage
5.1.7Waste Disposal
5.1.8Off-Site backup
5.2Procedural Controls
5.2.1Trusted Roles
5.2.1.1Administrator
5.2.1.2Officer
5.2.1.3Auditor
5.2.1.4Operator
5.2.1.5Registration Authority
5.2.1.6CSS Roles
5.2.1.7CMS Roles
5.2.2Number of Persons Required per Task
5.2.3Identification and Authentication for Each Role
5.2.4Separation of Roles
5.3Personnel Controls
5.3.1Background, Qualifications, Experience, & Security Clearance Requirements
5.3.2Background Check Procedures
5.3.3Training Requirements
5.3.4Retraining Frequency & Requirements
5.3.5Job Rotation Frequency & Sequence
5.3.6Sanctions for Unauthorized Actions
5.3.7Independent Contractor Requirements
5.3.8Documentation Supplied To Personnel
5.4Audit Logging Procedures
5.4.1Types of Events Recorded
5.4.2Frequency of Processing Log
5.4.3Retention Period for Audit Logs
5.4.4Protection of Audit Logs
5.4.5Audit Log Backup Procedures
5.4.6Audit Collection System (internal vs. external)
5.4.7Notification to Event-Causing Subject
5.4.8Vulnerability Assessments
5.5Records Archive
5.5.1Types of Events Archived
5.5.2Retention Period for Archive
5.5.3Protection of Archive
5.5.4Archive Backup Procedures
5.5.5Requirements for Time-Stamping of Records
5.5.6Archive Collection System (internal or external)
5.5.7Procedures to Obtain & Verify Archive Information
5.6Key Changeover
5.7Compromise & Disaster Recovery
5.7.1Incident and Compromise Handling Procedures
5.7.2Computing Resources, Software, and/or Data Are Corrupted
5.7.3Private Key Compromise Procedures
5.7.4Business Continuity Capabilities after a Disaster
5.8CA, CMS, CSS & RA Termination
6.Technical Security Controls
6.1Key Pair Generation & Installation
6.1.1Key Pair Generation
6.1.2Private Key Delivery to Subscriber
6.1.3Public Key Delivery to Certificate Issuer
6.1.4CA Public Key Delivery to Relying Parties
6.1.5Key Sizes
6.1.6Public Key Parameters Generation and Quality Checking
6.1.7Key Usage Purposes (as per X.509 v3 key usage field)
6.2Private Key Protection & CryptoGraphic Module Engineering Controls
6.2.1Cryptographic Module Standards & Controls
6.2.2Private Key Multi-Person Control
6.2.3Private Key Escrow
6.2.4Private Key Backup
6.2.4.1Backup CA Private Signature Key
6.2.5Private Key Archival
6.2.6Private Key Transfer into or from a Cryptographic Module
6.2.7Private Key Storage on Cryptographic Module
6.2.8Method of Activating Private Keys
6.2.9Methods of Deactivating Private Keys
6.2.10Method of Destroying Private Keys
6.2.11Cryptographic Module Rating
6.3Other Aspects Of Key Management
6.3.1Public Key Archival
6.3.2Certificate Operational Periods/Key Usage Periods
6.4Activation Data
6.4.1Activation Data Generation & Installation
6.4.2Activation Data Protection
6.4.3Other Aspects of Activation Data
6.5Computer Security Controls
6.5.1Specific Computer Security Technical Requirements
6.5.2Computer Security Rating
6.6Life-Cycle Security Controls
6.6.1System Development Controls
6.6.2Security Management Controls
6.6.3Life Cycle Security Ratings
6.7Network Security Controls
6.8Time Stamping
7.Certificate, CRL, And OCSP Profiles Format
7.1Certificate Profile
7.1.1Version Numbers
7.1.2Certificate Extensions
7.1.3Algorithm Object Identifiers
7.1.4Name Forms
7.1.5Name Constraints
7.1.6Certificate Policy Object Identifier
7.1.7Usage of Policy Constraints Extension
7.1.8Policy Qualifiers Syntax & Semantics
7.1.9Processing Semantics for the Critical Certificate Policy Extension
7.2CRL Profile
7.2.1Version Numbers
7.2.2CRL Entry Extensions
7.3OCSP Profile
7.3.1Version Number
7.3.2OCSP Extensions
8.Compliance Audit & Other Assessments
8.1Frequency Of Audit Or Assessments
8.2Identity & Qualifications Of Assessor
8.3Assessor’s Relationship To Assessed Entity
8.4Topics Covered By Assessment
8.5Actions Taken As A Result Of Deficiency
8.6Communication Of Results
9.Other Business & Legal Matters
9.1Fees
9.1.1Certificate Issuance/Renewal Fees
9.1.2Certificate Access Fees
9.1.3Revocation or Status Information Access Fee
9.1.4Fees for other Services
9.1.5Refund Policy
9.2Financial Responsibility
9.2.1Insurance Coverage
9.2.2Other Assets
9.2.3Insurance/warranty Coverage for End-Entities
9.3Confidentiality Of Business Information
9.4Privacy Of Personal Information
9.4.1Privacy Plan
9.4.2Information treated as Private
9.4.3Information not deemed Private
9.4.4Responsibility to Protect Private Information
9.4.5Notice and Consent to use Private Information
9.4.6Disclosure Pursuant to Judicial/Administrative Process
9.4.7Other Information Disclosure Circumstances
9.5Intellectual Property Rights
9.5.1Property Rights in Certificates and Revocation Information
9.5.2Property Rights in the CPS
9.5.3Property Rights in Names
9.5.4Property Rights in Keys
9.6Representations & Warranties
9.6.1CA Representations and Warranties
9.6.2RA Representations and Warranties
9.6.3Subscriber Representations and Warranties
9.6.4Relying Parties Representations and Warranties
9.6.5Representations and Warranties of Affiliated Organizations
9.6.6Representations and Warranties of other Participants
9.7Disclaimers Of Warranties
9.8Limitations of Liability
9.9Indemnities
9.9.1Indemnification by Entity CA
9.9.2Indemnification by Relying Party
9.10Term & Termination
9.10.1Term
9.10.2Termination
9.10.3Effect of Termination and Survival
9.11Individual Notices & Communications With participants
9.12Amendments
9.12.1Procedure for Amendment
9.12.2Notification Mechanism and Period
9.12.3Circumstances under which OID must be changed
9.13Dispute Resolution Provisions
9.14Governing Law
9.15Compliance With Applicable Law
9.16Miscellaneous Provisions
9.16.1Entire agreement
9.16.2Assignment
9.16.3Severability
9.16.4Enforcement (Attorney Fees/Waiver of Rights)
9.16.5Force Majeure
9.17Other Provisions
10.CERTIFICATE, CRL, AND OCSP PROFILES
10.1TBCA to PCA cross Certificate
10.2PCA to TBCA Cross Certificate
10.3TBCA to another Bridge Cross Certificate
10.4another Bridge To TBCA Cross Certificate
10.5Self-signed Root Certificate / Trust anchor
10.6Policy ca or issuing CA Certificate
10.7human Subscriber identity certificate
10.8human Subscriber Signature certificate
10.9human Subscriber encryption certificate
10.10id-pivi-cardauth certificate
10.11id-pivi-contentsigner certificate
10.12Code signer certificate
10.13Device subscriber certificate
10.14Role Signature certificate
10.15role encryption certificate
10.16OCSP Responder certificate
10.17PKCS 10 request format
10.18FULL CRL PROFILE
10.19Distribution point CRL PROFILE
10.20OCSP REQUEST PROFILE
10.21OCSP RESPONSE PROFILE
10.22Extended key usage
11.PKI REPOSITORY PROFILES
11.1protocol
11.2AUTHENTICATION
11.3NAMING
11.4Object Class
11.5Attributes
12.SMARTCARD PROFILES
12.1PIV-I Smartcard PROFILE
13.BIBLIOGRAPHY
14.ACRONYMS & ABBREVIATIONS
15.GLOSSARY
16.ACKNOWLEDGEMENTS
1. INTRODUCTION
This Certificate Policy (CP) defines multiple assurance levels for use by the TSCP Bridge Certification Authority (TBCA) to facilitate interoperability between the TBCA and other Entity PKI domains. The level of assurance refers to the strength of the binding between the public key and the individual whose subject name is cited in the certificate, the mechanisms used to control the use of the private key, and the security provided by the PKI itself.
The TBCA enables interoperability among Entity PKI domains in a peer-to-peer fashion. The TBCA issues certificates only to those CAs designated by the Entity operating that PKI (called “Principal CAs”). The TBCA may also issue certificates to individuals who operate the TBCA. The TBCA certificates issued to Principal CAs act as a conduit of trust.
Any use of or reference to this TBCA CP outside the purview of the TBCA is completely at the using party’s risk. An Entity shall not assert the TBCA CP OIDs in any certificates the Entity CA issues, except in the policyMappingsextension establishing an equivalency between a TBCA OID and an OID in the Entity CA’s CP.
This TBCA CP is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) RFC 3647, Certificate Policy and Certification Practices Framework.
The terms and provisions of this TBCA CP shall be interpreted under and governed by applicable Delaware law.
1.1Overview
1.1.1Certificate Policy (CP)
TBCA certificates contain a registered certificate policy object identifier (OID), which may be used by a Relying Party to decide whether a certificate is trusted for a particular purpose. The OID corresponds to a specific level of assurance established by this Certificate Policy (CP) which shall be available to Relying Parties. Each certificate issued by the TBCA will assert the appropriate level of assurance in the certificatePolicies extension.
1.1.2Relationship between the CP & CPS
A CP states what assurance can be placed in a certificate issued by the CA. The Certification Practices Statement (CPS) states how the CA establishes that assurance. A CPS shall be more detailed than the CP with which it aligns.
1.1.3Relationship between the TBCA CP and the Entity CP
The TPMA maps Entity CP(s) to one or more of the levels of assurance in the TBCA CP. The relationship between these CPs and the TBCA CP is asserted in CA certificates issued by the TBCA in the policyMappings extension.
1.1.4Scope
The TBCA exists to facilitate trusted electronic business transactions across industry, State, and international boundaries. The generic term “entity” applies equally to organizations, Federal or otherwise, owning or operating PKI domains. As used in this CP, Entity PKI or Entity CA may refer to an organization’s PKI, a PKI provided by a commercial service, or a bridge CA serving a community of interest.
1.1.5Interaction with PKIs External to TSCP, Inc.
The TBCA will extend interoperability only when it is beneficial to the members of TSCP, Inc or Governments who participate with TSCP, Inc.
1.2Document Identification
There are multiple levels of assurance in this Certificate Policy, which are defined in subsequent sections. Each level of assurance has an Object Identifier (OID), to be asserted in certificates issued by the TBCA. Entity Principal CAs may assert these OIDs in policyMappings extensions of certificates issued to the TBCA. The TBCA policy OIDs are a sub-assignment of TSCP, Inc’s Private Enterprise Number (PEN) registered in the IANA PEN Registry. The PEN sub-assignment is allocated to TBCA policy OID as follows:
Table 1 - TBCA Certificate Policies
id-tscp OBJECT IDENTIFIER / ::= { 1.3.6.1.4.1.38099}id-security OBJECT IDENTIFIER / ::= { id-tscp 1 }
id-pki / ::= { id-security 1 }
id-tscp-certificate-policies / ::= { id-pki 1 }
id-Medium / ::= { tscp-certificate-policies 1 }
id-MediumHardware / ::= { tscp-certificate-policies 2 }
id-Medium-CBP / ::= { tscp-certificate-policies 3 }
id-MediumHardware-CBP / ::= { tscp-certificate-policies 4 }
id-PIVI / ::= { tscp-certificate-policies 5 }
id-PIVI-CardAuth / ::= { tscp-certificate-policies 6 }
id-PIVI-ContentSigning / ::= { tscp-certificate-policies 7 }
id-SHA1-Medium / ::= { tscp-certificate-policies 8 }
id-SHA1-MediumHardware / ::= { tscp-certificate-policies 9 }
id-SHA1-Medium-CBP / ::= { tscp-certificate-policies 10 }
id-SHA1-MediumHardware-CBP / ::= { tscp-certificate-policies 11 }
The requirements associated with all assurance levels with a prefix of id-SHA1 (e.g. id-SHA1-Medium) are identical to the corresponding assurance level without the SHA1 prefix(e.g. id-Medium) except that the SHA-1 algorithm shall be used in favor of SHA-2 to generate PKI objects such as CRLs and OCSP responses.
The requirements associated with an assurance level with a CBP suffix (e.g. id-Medium-CBP) are identical to those defined for the corresponding assurance level without the suffix (e.g. id-Medium) with the exception of personnel security requirements (see Section 5.3.1).
The requirements associated with the id-MediumHardware assurance level are identical to those defined for the id-Medium assurance level with the exception of subscriber cryptographic module requirements (see Section 6.2.1).
The requirements associated with the id-PIVI and id-PIVI-Content Signing assurance levels are identical to the id-MediumHardwareassurance level except where specifically noted.
In addition, the id-PIVI-ContentSigningassurance level is reserved for certificates used by the Card Management System (CMS) to sign the PIV-I card security objects.
An Entity CA may request a ‘pass-through’ policy OIDs to be asserted in a cross-certificate issued to them by the TBCA.
1.3PKI Entities
The following are roles relevant to the administration and operation of the TBCA.
1.3.1PKI Authorities
1.3.1.1TSCP Inc. (TSCP)
TSCP, Inc. is a nonprofit 501(c)(6), tax-exempt trade association incorporated in the State of Delaware and is led by its Chief Executive Officer. TSCP, Inc. is ultimately accountable for its PKI bridging services.
1.3.1.2Program Management Office (TPMO)
The TSCP PMO operates under the authority of TSCP’s Chief Executive Officer. The TPMO is responsible for:
- Overseeing the activities of the TSCP Policy Management Authority (TPMA) and TSCP Operations Authority (TOA),
- Legally obligating TSCP, Inc. to relevant contracts, policies, and PKI Bridge Service Agreements (PBSAs) or similar agreements with cross-certified Entities,
- Approving TBCA CPS, and
- Promoting the use of TSCP, Inc.’s federated PKI bridging services.
In particular, this CP was established under the authority of and with the approval of the TPMO.
1.3.1.3TSCP Policy Management Authority (TPMA)
The TPMA is chartered by and under the authority of the TSCP PMO. The TPMA owns this policy and represents the interest of TSCP, Inc. The TPMA is responsible for:
- Authoring and maintaining this CP, including revisions
- Authoring and maintaining the methodology for cross-certification,
- Accepting applications from Entities desiring to interoperate using the TBCA,
- Approving cross-certification of Entities, and
- After an Entity is authorized to cross-certify with the TBCA, ensuring continued conformance of that Entity with applicable requirements as a condition for allowing continued interoperability using the TBCA.
1.3.1.4TSCP Policy Working Group (TPWG)
The TPWG provides policy coordination and analysis services in support of the TPMO, TPMA, and TOA. The TPWG is responsible for the following:
- Analyzing and reviewing the TBCA CPS and TBCA audit results
- Analyzing change requests for this CP
- Recommending CP Change requests to the TPMA, TPMO, and TOA
- Performing analysis and coordination services according to the cross-certification methodology. The results of such services are reports and recommendations to the TPMA and TPMO who makes approval decisions.
- Performing analysis and coordination services for incident handling, disaster recovery, change control, and business continuity scenarios
1.3.1.5TSCP Operations Authority (TOA)
The TOA is the organization that operates and maintains the TBCA on behalf of TSCP, Inc., according to this CP. The TSCP Operations Authority is led by TSCP’s VP of Operations who is principally responsible for the proper operation of the TBCA.
1.3.1.6Entity Certification Authority (Entity CA)
A CA that acts on behalf of an Entity, and is under the operational control of an Entity. The term ‘Entity CA’ refers to the Entity PCA as well as the Entity Subordinate CAs (SCAs) under the PCA that come under the jurisdiction of a TSCP PBSA or similar agreement. The Entity may be an organization, corporation, or community of interest.
1.3.1.7Entity Principal Certification Authority (PCA)
A Principal CA is an Entity CA within a PKI that has been designated to cross-certify directly with the TBCA (e.g., through the exchange of cross-certificates). The Principal CA issues either end-entity certificates, or CA certificates to other Entity or external party CAs, or both. Where the Entity operates a hierarchical PKI, the Principal CA is typically the Entity Root CA. Where the Entity operates a mesh PKI, the Principal CA may be any CA designated by the Entity for cross-certification with the TBCA.
It should be noted that an Entity may request that the TBCA cross-certify with more than one CA within the Entity; that is, an Entity may have more than one Principal CA. Additionally, this CP may refer to CAs that are “subordinate” to the Principal CA. The use of the term “subordinate CA” shall encompass any CA under the control of the Entity that has a certificate issued to it by the Entity Principal CA or any CA subordinate to the Principal CA, whether or not the Entity employs a hierarchical or other PKI architecture.
1.3.1.8Entity PKI Policy Management Authority (PMA)
Entity PKIs (including other Bridges) that are cross certified with the TBCA shall identify an individual or group that is responsible for maintaining the entity PKI CP and for ensuring that all Entity PKI components (e.g., CAs, CSSs, CMSs, RAs) are operated in compliance with the entity PKI CP. This body is referred to as Entity PKI Policy Management Authority (PMA) within this CP.
1.3.1.9TSCP Bridge Certification Authority (TBCA)
The TBCA is the CA operated by the TOA that is authorized by the TPMA and TPMO to create, sign, and issue public key certificates to Principal CAs. As operated by the TOA, the TBCA is responsible for all aspects of the issuance and management of a certificate including:
- Control over the registration process,
- The identification and authentication process,
- The certificate manufacturing process,
- Publication of certificates,
- Revocation of certificates,
- Re-key of TBCA signing material, and
1.3.1.10Certificate Status Servers (CSS)
PKIs may optionally include an authority that provides status information about certificates on behalf of a CA through online transactions. In particular, PKIs may include OCSP responders to provide online status information. Such an authority is termed a Certificate Status Server (CSS). Where the CSS is identified in certificates as an authoritative source for revocation information, the operations of that authority are considered within the scope of this CP. Examples of CSS that fall within the scope of this CP include: