|
NSF Middleware Initiative Draft
|
David Wasley University of California Office of the President (UCOP) |
|
Copyright © 2002 by UCAID and/or the respective authors |
|
|
Comments to: mw-cp-comments@internet2.edu |
October 17, 2002 |
|
Development of this document was supported with funding from EDUCAUSE, Internet2, and the NSF Middleware Initiative (Cooperative Agreement No. ANI-0123937). | |
For The
<institution name>
<date>
OBJECT IDENTIFIER _____________________
Identification and Validation of this Policy
This Certificate Policy has been assigned the global Object Identifier (OID) shown on the cover page. A CA MAY NOT SIGN ANY PUBLIC KEY CERTIFICATE OR OTHER DOCUMENT THAT ASSERTS BY REFERENCE TO THIS OID ITS CONFORMANCE TO THIS CERTIFICATE POLICY UNLESS ALL ASPECTS OF ITS MANAGEMENT AND OPERATION CONFORM COMPLETELY WITH THE REQUIREMENTS CONTAINED HEREIN.
Minor modifications will be indicated by a suffix to this OID. Any significant changes to this policy, as determined by the Policy Management Authority (see Section 1.4.1), will result in a document with a different OID assignment.
This Policy contains definitions for certificate Levels of Assurance (LOA) that have been assigned global Object Identifiers for use in certificate policy and policy mapping extension fields (see Section 1.2). [TBR: These might be defined in the CPS instead of here.] These are:
|
"Test" level of assurance |
__________________ |
|
"Rudimentary" level of assurance |
__________________ |
|
"Basic" level of assurance |
__________________ |
|
"Medium" level of assurance |
__________________ |
|
"High" level of assurance |
__________________ |
Minor changes to this policy SHALL NOT change the meaning of these LOA OIDs. If changes in this policy result in new definitions of the LOA, then new OIDs will be assigned.
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 the CA operating under this policy. The signed document SHALL be available on-line at the location specified by certificates issued under this policy (see Section 7.1.8).
Table of Contents
1.1.2 Relationship Between the CP and the CPS
1.1.3 Interoperation with CAs External to this Policy Domain
1.1.3.1 Relationship Between a Bridge CP and this CP
1.3 COMMUNITY AND APPLICABILITY
1.3.2 Registration Authorities
1.4.1 Specification administration organization
1.4.3 Person determining Certification Practice Statement suitability for the policy
2.1.4 Relying Party Obligations
2.3.1 Indemnification by Relying Parties and subscribers
2.3.3 Administrative processes
2.4 INTERPRETATION AND ENFORCEMENT 10
2.4.2 Severability of Provisions, Survival, Merger, and Notice
2.4.3 Dispute resolution procedures
2.5.1 Certificate issuance or renewal fees
2.5.3 Revocation or status information access fees
2.5.4 Fees for other services such as policy information
2.6 PUBLICATION AND REPOSITORY
2.6.1 Publication of CA Information
2.6.2 Frequency of Publication
2.7.1 Frequency of Compliance Audit
2.7.2 Identity/Qualifications of Compliance Auditor
2.7.3 Compliance Auditor's Relationship to Audited Party
2.7.4 Topics Covered by Compliance Audit
2.7.5 Actions taken as a result of deficiency
2.8.1 Types of information to be kept confidential
2.8.2 Types of information not considered confidential
2.8.3 Disclosure of certificate revocation information
2.8.4 Release to law enforcement officials
2.8.5 Release as part of civil discovery
2.8.6 Disclosure upon Subscriber's request
2.8.7 Other information release circumstances
2.9 INTELLECTUAL PROPERTY RIGHTS
3. IDENTIFICATION AND AUTHENTICATION
3.1.2 Need for names to be meaningful16
3.1.3 Rules for interpreting various name forms
3.1.5 Name claim dispute resolution procedure
3.1.6 Recognition, authentication and role of trademarks
3.1.7 Method to prove possession of private key
3.1.8 Authentication of organization identity
3.1.9 Authentication of Individual Identity
3.1.10 Authentication of Component Identities
3.2 CERTIFICATE RENEWAL, UPDATE, AND ROUTINE RE‑KEY
3.3 OBTAINING A NEW CERTIFICATE AFTER REVOCATION
4.1 APPLICATION FOR A CERTIFICATE
4.1.1 Delivery of public key for certificate issuance
4.2.1 Delivery of Subscriber's private key to Subscriber
4.4 CERTIFICATE SUSPENSION AND REVOCATION
4.4.1 Circumstances for revocation of a certificate
4.4.2 Who can request revocation of a certificate
4.4.3 Procedure for revocation request
4.4.4 Revocation Request Grace Period 26
4.4.6 Who can request suspension
4.4.7 Procedure for suspension request
4.4.8 Limits on suspension period
4.4.9 Certificate Authority Revocation Lists / Certificate Revocation Lists
4.4.9.1 CARL/CRL Issuance Frequency
4.4.10 CARL/CRL Checking requirements
4.4.11 On-line Revocation / Status checking availability
4.4.12 On-line revocation checking requirements
4.4.13 Other forms of revocation advertisements available
4.4.14 Checking requirements for other forms of revocation advertisements
4.4.15 Special requirements related to key compromise
4.5.1 Types of Events Recorded
4.5.2 Frequency of processing data
4.5.3 Retention period for security audit data
4.5.4 Protection of security audit data
4.5.5 Security Audit data backup procedures
4.5.6 Security Audit collection system (internal vs. external)
4.5.7 Notification to event-causing subject
4.5.8 Vulnerability Assessments
4.6.1 Types of events archived
4.6.2 Retention period for archive
4.6.4 Archive backup procedures
4.6.5 Requirements for time-stamping of records
4.6.6 Archive collection system (internal or external)
4.6.7 Procedures to obtain and verify archive information
4.8 COMPROMISE AND DISASTER RECOVERY
4.8.1 Computing resources, software, and/or data are corrupted
4.8.2 CA signature keys are revoked
4.8.3 CA signature keys are compromised
4.8.4 Secure Facility Impaired after a Disaster
4.9 CA TERMINATION
5. PHYSICAL, PROCEDURAL AND PERSONNEL SECURITY CONTROLS
5.1 PHYSICAL CONTROLS FOR THE CA OR AUTHORIZED CA
5.1.1 Site location and construction 41
5.1.5 Fire Prevention and Protection. 43
5.2 PROCEDURAL CONTROLS FOR THE CA 43
5.2.2 Number of Persons Required Per Task
5.2.3 Identification and Authentication for Each Role
5.3.1 Background, Qualifications, Experience, and Security Clearance Requirements
5.3.2 Background Check Procedures
5.3.4 Retraining Frequency and Requirements
5.3.5 Job Rotation Frequency and Sequence
5.3.6 Sanctions for Unauthorized Actions
5.3.7 Contracting Personnel Requirements
5.3.8 Documentation Supplied to Personnel
6. TECHNICAL SECURITY CONTROLS
6.1 KEY PAIR GENERATION AND INSTALLATION
6.1.1 Key Pair Generation by the CA
6.1.2 Private Key Delivery to Subscriber
6.1.3 Public Key Delivery to Certificate Issuer
6.1.4 CA Public Key Availability
6.1.6 Public Key Parameters Generation
6.1.7 Parameter Quality Checking
6.1.8 Hardware/Software Subscriber Key Pair Generation
6.1.9 Key Usage Purposes (as per X.509 v3 Key Usage Field)
6.2.1 Standards for Cryptographic Module
6.2.2 CA Private Key Multi-Person Control
6.2.3 Key Escrow of CA Private Signature Key
6.2.3.1 Escrow of End-Entity Decryption Keys
6.2.4.1 Backup of CA Private Signature Key
6.2.4.2 Backup of End-Entity Private Signature Key
6.2.6 Private Key Entry into Cryptographic Module
6.2.7 Method of Activating Private Keys
6.2.8 Methods of Deactivating Private Keys
6.2.9 Method of Destroying Subscriber Private Signature Keys
6.3 OTHER ASPECTS OF KEY-PAIR MANAGEMENT
6.3.2 Usage Periods for the Public and Private Keys
6.4.1 Activation Data Generation and Installation
6.4.2 Activation Data Protection
6.4.3 Other Aspects of Activation Data
6.5 COMPUTER SECURITY CONTROLS
6.5.1 Specific Computer Security Technical Requirements
6.5.2 Computer Security Rating
6.6 LIFE-CYCLE TECHNICAL CONTROLS
6.6.1 System Development Controls
6.6.2 Security Management Controls
6.6.3 Life Cycle Security Ratings
6.8 CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS
7. CERTIFICATE AND CARL/CRL PROFILES
7.1.3 Algorithm Object Identifiers
7.1.6 Certificate policy object identifier
7.1.7 Usage of Policy Constraints extension
7.1.8 Policy qualifiers syntax and semantics
7.1.9 Processing semantics for the critical certificate policy extension
7.1.10 Certificate Serial Numbers
7.2.2 CARL and CRL entry extensions
8. SPECIFICATION ADMINISTRATION
8.1 SPECIFICATION CHANGE PROCEDURES 59
8.2 PUBLICATION AND NOTIFICATION POLICIES
8.2.2 Urgent Amendments Exception
8.2.4 Maintenance of Prior Versions
RECORD OF CHANGES
|
CHANGE NUMBER |
DATE OF CHANGE |
DATE RECEIVED |
DATE ENTERED |
SIGNATURE OF PERSON ENTERING CHANGE |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This Certificate Policy (CP) statement defines the terms and conditions under which a Certificate Authority (CA) that issues Public Key Certificates (PKC) that reference the policy object identifier (OID) for this CP MUST operate. Operation includes management of the PKCs it issues and management of its own infrastructure. The term "issues" in this context refers to the process of digitally signing with the private key associated with its authority certificate a structured digital object conforming to the ISO X.509, version 3 or compatible PKC format.
One or more companion Certification Practice Statement(s) (CPS) MUST be defined for each CA operating under this CP. Such a statement MUST articulate how the CA implements the provisions of this policy.
The CA MAY be stand-alone or it MAY be part of a Public Key Infrastructure (PKI) hierarchy. In the latter case, any CA for which this CA signs an authority certificate MUST adopt this CP or one that is consistent with all of the requirements of this CP as determined by the Policy Management Authority for this CA.
This CP is structured in accordance with RFC 2527 [1]. Within this document the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" are to be interpreted as in RFC 2119 [2].
This CP defines a set of requirements that helps to determine the viability and applicability of a PKC issued by a conforming CA to its community of users, subject entities, and/or class of applications.
This CP MAY be used by a PKC Relying Party to help in deciding whether a certificate and the information therein and the binding of that information to the Subject are sufficiently trustworthy for a particular application.
Any PKC issued by a CA MUST contain a valid reference to the applicable CP. This CP may be referenced only if the CA is in compliance with all aspects of this CP.
Each CA MUST make available its own CPS(s) in order to provide information to potential clients of the CA and Relying Parties about the underlying technical, procedural and legal foundations which are not otherwise specified in this policy.
A CA MAY delegate any of its responsibilities under this CP to another Person, provided the CA remains responsible for conformance with all provisions of this CP and associated CPS(s).
By relying on information contained in a PKC issued by this CA, the Relying Party is agreeing with the provisions and stipulations of this CP and the associated CPS under which the PKC was issued.
Any CA that intends to refer to this CP in a PKC that it issues MUST digitally sign a copy of this document, using SHA-1 with RSA encryption and its primary PKC signing key, and make the signed copy available on-line as specified in Section 1.2.
This CP states what assurance can be placed in a certificate issued by the CA. The associated CPS states how the CA establishes that assurance.
The CA MAY issue a cross-certification PKC to an unrelated CA but only after PMA review of the other CA’s CP and a mutually agreed upon mapping of the Levels of Assurance as defined by this CP and the other CA’s CP. Such agreement MUST take into account all of the relevant requirements and conditions of use as specified in the two CPs. The mapping of Levels of Assurance between this CP and the other CA CP SHALL be specified in the PolicyMappings fields of the cross-certification PKC.
The BasicConstraints fields in any cross-certification PKC SHOULD be set to constrain resulting trust paths to no more levels than can be warranted by the PMA. The BasicConstraints fields in any cross-certification PKC also SHOULD be set to constrain naming in any PKCs issued by the certified CA to that which the PMA deems acceptable.
The CA MAY accept a cross-certification PKC from an unrelated Certificate Authority provided that the Subject name and public key in that PKC are identical to those in the CA’s authority PKC.
The CA SHALL NOT issue a cross-certification PKC to a Bridge CA unless the conditions in section 1.1.3 are met. In addition, operation of the Bridge CA with respect to additional cross-certifications MUST be consistent with all of the relevant requirements and conditions specified in this CP for the Levels of Assurance included in the cross-certification PKC PolicyMappings fields. The PMA is responsible for reviewing the operation of any such Bridge CA and ensuring that such mapping is appropriate.
The base of the Object Identifier (OID) MUST be registered under the ANSI (or equivalent) arc. Sub-arcs SHALL be defined for both this CP itself and for the different LOAs defined by this CP. OIDs also SHOULD be assigned to all associated CPSs referencing this CP.
When referencing this CP as governing a PKC, the OID given on the cover page SHALL be used in addition to any textual description. If this CP is changed in any substantive way, a new CP OID SHALL be assigned for the new version.
There are five LOAs covered by this CP as defined in subsequent sections. It is the intent of this CP for these LOAs to map directly to the Federal PKI (FPKI) Policy Authority LOAs.
The LOA asserted in any PKC issued by the CA SHALL be indicated by the OID in the CertPolicyID field in the PKC. The LOA OIDs for this CP are defined on the first page. The LOA OIDs SHOULD be defined under a general LOA sub-arc as follows:
Test ::= { LOA 1 }
Rudimentary ::= { LOA 2 }
Basic ::= { LOA 3 }
Medium ::= { LOA 4 }
High ::= { LOA 5 }
The CPSuri extension field in a PKC asserting one of these LOAs MUST point to an on-line copy of the CPS that implements that LOA, digitally signed as specified in Section 1.1.1. That CPS in turn MUST identify explicitly by an appropriate OID the CP to which it is conforming and specify how a Relying Party may obtain a copy of that CP. It SHOULD also include a URI pointing to an on-line, digitally signed copy of that CP.
Subsequent revisions of this CP SHALL have a new OID assignment under the same OID arc. Minor revisions MAY be indicated by a suffix appended to the OID given on the cover page to this CP. The Level of Assurance (LOA) identifiers represent abstractions and SHALL remain the same unless or until new LOAs are required.
The CA MUST include in any CPS a definition of the Communities to which the CA will issue a PKC. The CA SHOULD NOT issue a PKC to any Person or other entity that is not included in one of the Communities. A Relying Party SHOULD NOT assume that the holder of a PKC issued by this CA has any particular relationship to any of the communities defined in the CPS unless explicitly stated in the CPS that such an assumption is warranted.
The CA MUST include in any CPS a definition of the applicability or any restrictions on the use of any resulting PKC. Such applicability MUST be indicated in the appropriate PKC fields, e.g. KeyUsage. A Relying Party MUST respect any applicability limitations indicated in the PKC.
A CA MAY issue a PKC with certificate issuance rights (“authority PKC”) to another CA and in that case the so Authorized CA assumes the role of a CA under this CP. The authority PKC SHOULD contain policy mapping extension defining how the LOAs of the authorizing CA correspond to the LOAs of the authorized CA, to the extent that they do. Naming and path length constraints also MAY be indicated as described in Section 1.1.3. For all purposes under this CP, the Authorized CA SHALL conform to, and operate under, this CP.
The PMA for this CA SHALL have oversight responsibility for the operation of the Authorized CA to ensure its conformance with this CP. This CA MAY delegate any of its responsibilities to a PMA associated with the Authorized CA, provided that this CA remains responsible for conformance with all provisions of this CP.
A CA operating at Basic or lower LOA SHOULD NOT issue authority PKCs.
The function of a Registration Authority (RA) is to verify the credentials that establish the binding between a Person or other entity that is the Subject of a PKC and the Subject's Public/Private Key Pair that is associated with that PKC and approve the issuance of a PKC for that Subject. The CA MAY perform the function of a Registration Authority or the CA MAY delegate some or all of the RA functions to one or more other organizations or functional units. The CA remains responsible for conformance with all provisions of this CP and associated CPS(s). Any RA so delegated MUST have a signed agreement with the CA affirming the authority and obligations of both parties.
The end entities that may be the Subject of a PKC issued under this policy can be (1) a natural person representing himself or herself, (2) an organization that is defined as part of the Community and is represented by a natural person authorized to act for that organization, or (3) a digital processing entity (e.g., a computer, a router or a defined application program or system), that is capable of performing cryptographic operations and that is owned or operated by an organization that is as part of the Community and that is represented by a natural person authorized to act for that organization ("PKC Sponsor"). In the latter case, the method of verification of the authorization of the person acting on behalf of the digital processing entity SHALL be set forth in the CPS.
PKCs issued by a CA MAY be used for any application, provided that the uses are within the limitations imposed by the CPS or as indicated in the PKC itself.
However, only Relying Parties that accept in its entirety this CP and that accept in their entirety any limitations (financial or otherwise) contained in the PKC itself MAY make use of a PKC issued by this CA.
If a Subscriber wishes to have any limitations (financial or otherwise) on transactions authenticated by the PKCs that are not contained in the PKC itself, that Subscriber MUST have a signed agreement with each Relying Party agreeing to such limitations. Any Relying Party that wants to make use of a PKC issued by this CA to authenticate transactions of significant financial value or otherwise of import to the Relying Party SHOULD have a signed agreement with the Subscriber stating any specific limitations.
The table below summarizes the recommended applicability of PKCs at each of the five levels of assurance covered by this CP.
|
Assurance Level |
Applicability |
|
Test |
This level is used for interoperability testing. It is solely used for this purpose and conveys no assurance information. |
|
Rudimentary |
This level provides the lowest degree of assurance concerning identity of the Subject. One of the primary functions of this level is to provide data integrity to the information being signed. This level is relevant to environments in which the risk of malicious activity is considered to be low. It may not be suitable for transactions requiring reliable authentication. It is generally insufficient for transactions requiring strong confidentiality, but may be used for this where certificates having higher levels of assurance are unavailable. |
|
Basic |
This level provides a basic level of assurance relevant to environments where there are risks and consequences of data compromise, but they are not considered to result in significant negative consequences. It is assumed at this security level that users are not likely to be malicious. |
|
Medium |
This level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud. |
|
High |
This level is appropriate for use where the threats to data are high, or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk. |
Questions about interpretation of this CP and associated CPSs, or concerns about possible abuse of this CP SHALL be directed in writing to the PMA identified under section 1.4.1.
The Policy Management Authority (PMA) for this CP MUST be identified by postal address, office location and other contact information in the applicable CPS.
Intentionally left blank.
The PMA is responsible for reviewing and approving with an authorized signature any proposed CPS that is to be associated with this CP.
This section defines the responsibilities of each party involved in the issuance and use of PKCs issued by the CA. These responsibilities bear on any potential liability that might be associated with a CA operating under this CP as a result of use of an issued PKC. Relying Parties MUST understand the provisions of this section.
Each party to the issuance and use of a PKC has an obligation to perform certain duties as detailed in this section. By accepting an issued PKC, a Subscriber accepts the obligations described hereunder. By making use of a PKC issued by this CA, a Relying Party is accepting its obligations hereunder.
The CA MUST operate a certification authority service in accordance with all provisions of this CP and any associated CPS(s). Its obligations include:
(1) Accepting certification requests and issuing PKCs according to a published CPS, including:
(a) verifying the necessary credentials of each Person requesting a certificate and verifying the binding of those credentials to the Subject;
(b) validating the connection between a public/private key pair and the requester's identity including a suitable proof of possession method;
(c) ensuring notification of the Subscriber regarding its obligations and responsibilities;
(d) ensuring to the best of its ability that any additional information to be included in the issued PKC is accurate and appropriately associated with the Subject;
(e) issuing a PKC based on the authenticated Subscriber's request and published PKC profiles;
(f) sending notification of PKC issuance to the Subscriber;
(g) making issued PKCs available on-line as required in section 2.6.1;
(h) logging all transactions and recording the unique identifying marks of any associated credentials.
(2) Accepting certificate revocation requests and effecting certificate revocation or suspension, as defined in section 4.4 including:
(a) accepting and authenticating revocation requests according to the procedures contained in this CP and associated CPS(s);
(b) authenticating Subscribers or other parties requesting that a PKC be revoked and confirming that they are authorized to make such a request;
(c) making any resulting certificate revocation information publicly available;
(d) logging all transactions and recording the unique identifying marks of any associated credentials.
(3) The CA MUST NOT issue more than one PKC with the same public key unless the Subject entity is the same in all instances.
A CA that issues a PKC to a Subscriber MUST have explicit authorization from that Subscriber to do so. The CA MUST respect any restrictions or limitations on Subject names, path length, and/or policy mapping as specified in its authority PKC and/or written agreement with its authorizing CA. A CA SHALL NOT issue any PKC with a Level of Assurance higher than that in its authority PKC.
An RA functional unit MAY be delegated by a CA any or all of the responsibilities under section 2.1.1 subsections (1)(a) through (d) and (h) and (2)(a) and (b) under this CP. An RA so delegated MUST do the following in addition to the responsibilities specifically delegated by the CA:
(1) confirm to the CA in a secure manner the validation of the connection between a public/private key pair and the requester's identity including the successful use of a suitable proof of possession method;
(2) adhere to the CPS(s) and the written agreement made with the CA.
A Subscriber MUST:
(1) read and agree to the terms and conditions under which the CA issues PKCs;
(2) present legitimate credentials as required by the CPS for the PKC to be issued;
(3) appropriately protect the private key associated with an issued PKC. Specific requirements are stated in the CPS for the PKC to be issued. Some types of PKCs MAY require that the private key be put in escrow;
(4) notify the CA immediately upon either suspected or known compromise of the private key associated with a PKC issued by the CA.
Relying Parties MUST understand and accept this CP and associated CPS(s) before making use of any PKC issued by the CA. Relying Parties MUST check a PKC’s revocation status when verifying a PKC with a level of assurance of Basic or higher issued by this CA. Relying Parties MUST NOT use any PKC issued by this CA for purposes that are proscribed by the PKC contents or this CP or associated CPS(s). Relying Parties MUST be aware of and abide by all rules, regulations and statutes applicable to all information contained in a PKC. For example, if a PKC Subject is a student registered at the institution issuing the PKC, the Relying Party may have obligations to treat information in the PKC according to the requirements of the Family Educational Rights and Privacy Act (FERPA).
The CA SHALL make available on-line as soon as reasonably possible copies of all PKCs issued, unless a PKC is specifically made confidential per section 2.8 of this CP or the associated CPS. Access control mechanisms SHALL be implemented when needed to protect repository information as described in Section 2.6.3. All information in the Repository that is not otherwise digitally signed SHALL be digitally signed by the CA or its delegated functional unit(s).
The CA SHALL make available its primary authority PKC and any additional authority PKCs in which it is named as the Subject in the repository. In addition, the CA SHOULD make available all primary authority PKCs of CAs above it in the PKC hierarchy as well as all other authority PKCs that name any of those CAs as Subjects.
The CA SHALL make available on-line certificate revocation information according to the issuance requirements in 4.4.9.1 and other relevant public information as soon as is reasonably possible.
For CAs operating at the Basic LOA or higher, the Repository for the above SHALL be designed for high availability, including replicated platforms and redundant network connections, and operated in a highly robust and secure manner.
At a minimum, the CA SHOULD post the public information of the Repository to an x.500 or Lightweight Directory Access Protocol (LDAP) server system. Such information MAY also be accessible through other mechanisms. The specific access protocols SHALL be defined in any CPS associated with this CP.
The CA Group disclaims all warranties and obligations of any type, including any warranty of merchantability, any warranty of fitness for a particular purpose, and any warranty of the accuracy of information provided, and further disclaims any and all liability for negligence and lack of reasonable care with respect to all PKCs issued by it. The CA Group shall not incur liability for representations of information contained in any PKC. Without limiting the generality of the foregoing, the CA Group accepts no liability of any sort if a Relying Party fails to fulfill its obligations as stated herein.
Liability, if any, SHALL be limited to actual monetary damages.
In no event shall the CA Group be liable for any indirect, special, incidental, or consequential damages, or for any loss of profits, loss of data, or other indirect, consequential, or punitive damages, arising from or in connection with the use, delivery, license, performance, or nonperformance of certificates, digital signatures, or any other transactions or services offered or contemplated by this CPS, even if the CA Group has been advised of the possibility of such damages.
In no event will the aggregate liability of the CA Group to all parties (including without limitation a Subscriber, an applicant, a recipient, or a Relying Party) exceed $1,000. This limitation on damages applies to loss and damages of all types, including but not limited to direct, compensatory, indirect, special, consequential, exemplary, or incidental damages incurred by any person, including without limitation a Subscriber, an applicant, a recipient, or a Relying Party, that are caused by reliance on or use of a certificate the CA Group issues, manages, uses, suspends or revokes, or a certificate that expires. This limitation on damages applies as well to liability under contract, tort, and any other form of liability claim. The liability cap on each certificate shall be the same regardless of the number of digital signatures, transactions, or claims related to such certificate. In the event the liability cap is exceeded, the available liability cap shall be apportioned first to the earliest claims to achieve final dispute resolution, unless otherwise ordered by a court of competent jurisdiction. In no event shall the CA Group be obligated to pay more than the aggregate liability cap for each certificate, regardless of the method of apportionment among claimants to the amount of the liability cap.
Intentionally left blank.
The CA Group assumes no financial responsibility with respect to use or management of any issued PKC.
Intentionally left blank.
Intentionally left blank.
Administrative processes pertaining to this CP SHALL be described in the CPS.
Interpretation of this CP or any associated CPS(s) is the responsibility of the PMA.
Operation of this CA SHALL conform to the laws governing the jurisdiction in which the CA is legally formed. Notwithstanding anything to the contrary in this CP, if the laws of any state of the United States or the law of the United States governing a Subscriber (including but not limited to any laws related to choice of law) ("Subscriber Governing Laws") forbid the inclusion of specific provisions of this CP, then with respect to that Subscriber only, the specific provision of this CP shall be deemed null and void as if not included at all. However, wherever possible within the letter and spirit of the Subscriber Governing Laws, rather than causing a provision of this CP to be null and void pursuant to the prior sentence, all Subscriber Governing Laws will be interpreted in such a way as to achieve the letter and spirit of this CP. Where a conflict cannot be resolved between this CP and a Subscriber Governing Law, that Subscriber Governing Law shall prevail.
Should it be determined that one section of this CP is incorrect or invalid, the other sections of this CP shall remain in effect.
The PMA SHALL have the exclusive authority to resolve any disputes associated with the use of the PKCs issued by the CA. If a dispute regarding interpretation of provisions in this CP arises between two CAs that issue PKCs referencing this CP's OID and that obtain their authority to issue PKCs from the same Authorizing CA, all such disputes SHALL be resolved by the PMA identified in the Authorizing CA's CP.
Headings used throughout this CP are for convenience only and SHALL NOT affect the interpretation of this CP.
The CA will determine all fees, if any, to be imposed.
Fees MAY be imposed for issuance or renewal of PKCs by the CA. Such fees MUST be agreed to by the payer prior to issuance or renewal of the PKC. If fees are imposed but not paid within 60 days of notification to the payer, the issued PKC MAY be revoked.
Fees SHALL NOT be charged for on-line access to copies of PKCs issued by this CA and held in its Repository or for on-line access to the authority certificate for this CA.
Fees MAY be charged for other forms of access to issued PKCs.
Fees SHALL NOT be charged for certificate revocation or for on-line access to certificate revocation or status information. Fees MAY be charged for other forms of access to certificate revocation or status information.
Fees SHALL NOT be charged for any on-line form of access to this CP or any associated CPS.
Fees are not refundable. Fees charged but not paid are still due regardless of the status of the PKC or service request.
All information about CA operation and PKCs issued SHALL be available on-line, except as indicated in this section 2.6. Each PKC issued SHALL include information sufficient to locate this on-line Repository.
A CA SHALL make available on-line and MAY make available in other forms:
• this CP and any CPS(s) under which it operates,
• its authority PKC(s) and other PKCs as described in Section 2.1.5.
• all issued PKCs except those PKCs of Subscribers that explicitly request that their PKC not be made publicly available,
• signed certificate revocation and other certificate status information.
The CPS referenced by the CPSuri in the PKC SHALL define how a Relying Party can locate and retrieve the rest of the above information.
PKCs SHALL be made available as part of the issuing process except as provided in Section 2.6.1. This process MUST be described in associated CPS(s).
The frequency of certificate revocation publication is specified in 4.4.9.
Changes to this CP or its associated CPS(s) SHALL be published as soon as they are approved. Previous versions SHALL remain available on-line for at least 180 days beyond the latest expiration date of any PKC that references that CP or CPS. Archived copies of all CPs under which the CA has ever issued a PKC SHOULD be kept indefinitely, or as may be required by law (see Section 8.2.4).
There SHALL NOT be limitations on access to this CP, CPS(s) or certificate revocation information. There MAY be limitations on access to PKCs, for example to prevent bulk acquisition of data such as e-mail addresses.
Repositories MUST be operated in a reliable and secure manner as detailed in CPS(s). The primary Repository SHALL be replicated to at least one on-line secondary Repository in order to increase its availability. Repository contents MUST be replicated off-line for disaster recovery and independent validation purposes. See section 2.1.5.
For a CA operating at the Basic LOA or higher, the operation of the CA SHALL be audited periodically for conformance with this CP and all associated CPS(s) by independent and knowledgeable third parties. CAs operating at the Test or Rudimentary LOA SHOULD conduct internal audits regularly as defined in Section 2.7.1. CAs that have delegated any part of their responsibility to a different functional unit are responsible for ensuring a proper audit of the operation of those functional units. In addition, if the CA derives its authority PKC from an Authorizing CA, that Authorizing CA MAY review any compliance audit for conformance with the Authorizing CA's CP at any time upon reasonable prior notification.
The CA and Authorized CAs SHALL be subject to a periodic compliance audit that is no less frequent than once per calendar year for CAs operating at High or Medium levels of assurance, and no less than once every two calendar years for those operating at the Basic level of assurance. CAs operating at the Rudimentary level of assurance SHOULD be subject to an internal audit at least annually. There is no audit frequency requirement for CAs operating at the Rudimentary level of assurance.
An Authorizing CA has the right to require periodic and aperiodic compliance audits or inspections of Authorized CA operations to validate that the subordinate entities are operating in accordance with the security practices and procedures described in their respective CPS.
The auditor SHALL have specific knowledge of the operation of a CA and experience performing audits of CA operation. If no such auditor can be found after a reasonable effort has been made, then an auditor with knowledge and experience performing audits of business data processing centers MAY perform the CA audit. The audit report MUST note and explain this exception to the requirements of this CP.
The external auditor SHALL be legally independent of the audited CA. The audit fees, if any, SHALL be paid by the CA.
The PMA MAY determine that the CA is not complying with its obligations set forth in this CP. When such a determination is made, the PMA MAY direct the CA to cease operation, or MAY direct that other corrective actions be taken which would allow operation to continue. Procedures for this purpose SHALL be published by the PMA.
When the compliance auditor finds a discrepancy between how the conforming CA is designed or is being operated or maintained, and the requirements of this CP, the following actions SHALL be performed:
• The compliance auditor SHALL note the discrepancy;
• The compliance auditor SHALL promptly notify the PMA of the discrepancy. If the discrepancy is judged by the PMA to be severe in nature (that is, it is determined to be a "material discrepancy" relative to the applicable requirements), the PMA SHALL include that finding in its notification to the CA.
• The party responsible for correcting the discrepancy SHALL determine what further notifications or actions are necessary pursuant to the requirements of this CP, and then proceed to make such notifications and take such actions without delay.
Depending upon the nature and severity of the discrepancy, and how quickly it can be corrected, the PMA MAY decide to halt temporarily operation of the CA, or take other actions it deems appropriate. Procedures for making and implementing such determinations will be developed by the PMA.
The CA collects and stores information from Subjects of a PKC that may be personally identifying. These data MUST be processed in a way that ensures privacy and other protections according to the laws applicable to the CA, as specified in section 2.4.1.
All information presented to the CA that is not included in a resulting PKC or certificate revocation record issued by the CA is considered confidential and SHALL NOT be released by the CA to third parties without the Subscriber's authorization; unless such a release is required by a legal authority of competent jurisdiction.
Information included in published PKCs or certificate revocation records issued by the CA is not considered confidential except as may be required by law.
When a PKC is revoked, a reason code SHALL be included in the certificate revocation record for the action. This reason code is not considered confidential and MAY be shared with all other users and Relying Parties. However, other details concerning the revocation SHALL NOT be disclosed unless required by a legal authority of competent jurisdiction or permitted elsewhere in this CP.
The CA SHALL NOT disclose confidential PKC or PKC-related information to any third party, except when required by a legal authority of competent jurisdiction under a duly issued warrant or subpoena or as might be required by the laws applicable to the CA, as specified in section 2.4.1.
The CA SHALL NOT disclose confidential PKC or PKC-related information to any third party, except when required by a legal authority of competent jurisdiction under a duly issued warrant or subpoena or as might be required by the laws applicable to the CA, as specified in section 2.4.1.
The CA MAY release Subscriber's confidential information upon validation of a request signed by Subscriber.
Intentionally left blank.
The CA MUST NOT claim any intellectual property rights with respect to issued PKCs. If any Subject’s private key is escrowed, ownership of and all rights to that key remain with the Subject.
Any party MAY make use of any or all of the language in this CP or associated CPS(s) providing that appropriate attribution is included.
The validity of a PKC for use as a digital credential is dependent heavily upon the validity of the credentials offered during initial verification of the Subject. The CA MUST ensure proper binding between the Subject of a PKC and the credentials provided by the Subscriber or the Subject’s agent during the registration process, as detailed in the applicable CPS. Similar assurance MUST be obtained when renewing or revoking an issued PKC.
In addition, if contents of an issued PKC constitute a direct link to records in a supplemental database containing additional attributes of the Subject, the binding between the Subject and any such database entries MUST be verified before the PKC is issued or renewed. Details of this verification MUST be described in the applicable CPS.
The CPS(s) associated with this CP SHALL detail how initial registration is performed. Specific requirements MUST be given for each type of PKC issued by the CA, including the types of credentials to be presented by the applicant, how they are verified, and how the resulting PKC is bound to a private key in the Subscriber's possession. A Relying Party must be able to assess whether the level of assurance and security required for each step in the initial registration process results in a PKC of sufficient trustworthiness for its intended use.
If a Subject name is present in a PKC issued by the CA, it SHOULD be reasonably relevant to the Subject. It need not be unique, depending on the nature and intended use of the PKC as defined in the CPS. For example, a Subject name MAY be an abstract object assigned to the class of entities, such as "student," of which the Subject is a member. A Subject name MUST NOT be misleading such that a Relying Party reasonably might assume that the Subject is a physical entity other than the actual holder of the PKC.
The CA SHALL be able to generate and sign PKCs that contain an X.500 Distinguished Name (DN); the X.500 DN MAY also contain domain component (DC=) elements. Where DNs are required, Subscribers SHALL have their DN specified by the CA. PKCs MAY additionally assert an alternate name form, subject to requirements set forth below intended to ensure name uniqueness. The table below describes the naming requirements that apply to each level of assurance.
|
Test |
To be established by the PMA (will depend upon testing circumstances) |
|
Rudimentary |
Non-Null Subject Name, or Null Subject Name if Alternative Subject Name is populated and marked critical |
|
Basic |
Non-Null Subject Name, and optional Alternative Subject Name that is marked non-critical |
|
Medium |
X.500 Distinguished Name, and optional Alternative Subject Name that is marked non-critical |
|
High |
X.500 Distinguished Name, and optional Alternative Subject Name that is marked non-critical |
The CPS defines whether a PKC will contain Subject names that are meaningful. Meaningful in this context means that the name can be interpreted to refer to a defined class of entities. A class that, by definition, includes only a single entity becomes an identity credential for the Subject.
When DNs are used, it is preferable that the common name represent the Subject in a way that is easily understandable for humans. For people, this typically will be a legal name. For equipment, this MAY be a model name and serial number, or an application process (e.g., Organization X Mail List or Organization Y Multifunction Interpreter). However, the DN for human Subjects MAY also be a pseudonym (for example, a large number) as long as it respects name space uniqueness requirements.
In the case where a CA certifies another Authorized CA within that policy domain, the Authorizing CA MUST impose restrictions on the name space that MAY be used by the Authorized CA that are at least as restrictive as its own name constraints.
The CA MUST detail in the CPS(s) the rules for interpreting various name forms used in the PKCs it issues.
The Subject name in a PKC MUST refer to a unique, identifiable entity or class of entities. The Subject name, if present and meaningful, MUST have the same meaning and interpretation whenever that distinguished name is included in a PKC issued by the CA.
The CA and Authorized CAs SHALL document in their respective CPSs:
• What name forms will be used,
• How the CA and Authorized CAs will interact to ensure this is accomplished, and
• How the CA and Authorized CAs will allocate names within the Community to guarantee name uniqueness among current and past Subscribers (e.g., if "Joe Smith" leaves a Community, and a new, different "Joe Smith" enters the Community, how these two people will be provided unique Subject names).
The Subscriber SHALL NOT request, and the CA SHALL NOT knowingly issue, a PKC in which the distinguished name is composed solely of trademarks; however the CA MAY issue a PKC in which the distinguished name is composed solely of trademarks registered to the CA Group.
In the case where a key is generated directly on the applicant's physical key store, or in a key generator that without human intervention transfers the key to the applicant's physical key store, then the applicant is deemed to be in possession of the private key at the time of generation or transfer. If the applicant is not in possession of the physical key store when the key is generated, then the physical key store SHALL be delivered to the Subscriber via a method verifiable by a receipt signed by that Subscriber.
For all assurance levels, when keyed physical key stores are delivered to Subscribers, the delivery SHALL be accomplished in a way that ensures that the correct key stores and activation data are provided to the correct Subscribers. The CA MUST maintain a record of validation for receipt of the physical key store by the Subscriber.
Any mechanism that includes a shared secret (e.g., a password or PIN) SHALL be used only for "basic" or lower LOA PKCs. If such a mechanism is employed, it SHALL be designed to provide a reasonable degree of assurance that the applicant and the CA are the only recipients of this shared secret.
See also Section 6.1.1 Key Pair Generation by the CA.
Requests for PKCs wherein the Subject is the name of an organization SHALL include the legal name of the organization, the organization's principal address, documentation of the existence of the organization, and identification of the Chief Executive Officer of the organization. The CA SHALL verify the information, in addition to the authenticity of the requesting representative and the representative's authorization to act in the name of the organization.
The CA MUST ensure strong binding between the PKC applicant and any attributes of identity that are to be asserted by the PKC. The specific documents required and the method of their verification MUST be detailed in the CPS(s) associated with this CP.
The CA and Authorized CAs SHALL record the process that was followed for issuance of each PKC. Process information MAY depend upon the certificate level of assurance and SHALL be addressed in the appropriate CPS. The process documentation and authentication requirements SHALL include the following, depending upon the level of assurance as set forth below:
• The identity of the person performing the identification;
• A signed declaration by that person that he or she verified the identity of the Subscriber as required by the applicable certificate policy;
• A unique identifying number from the ID of the verifier and, if in-person identity proofing is done, from the two forms of photo ID provided by the applicant;
• The date and time of the verification;
• A declaration of identity signed by the applicant using a handwritten signature. If in-person identity proofing is done, this SHALL be performed in the presence of the person performing the identity authentication.
For All Levels: Where photo ID document serial numbers or other identifying information is required in the table below, such numbers or information MUST be recorded to an archive at the time the registration is made. This record SHALL be retained for at least 12 months after the expiration of the associated PKC.
The table below summarizes the identification requirements for each level of assurance. A Relying Party MUST take into account the potential risk associated with accepting the PKC as a reliable credential.
|
Assurance Level |
Identification Requirements |
|
Test |
To be established by the PMA (will depend upon test circumstances) |
|
Rudimentary |
No in-person identification requirement; applicant may apply and receive a PKC by providing personally identifying information that only the RA and the Subject should know. |
|
Basic |
Identity may be established by in-person appearance before a Registration Authority for the CA or Trusted Agent; or comparison of user-supplied information (obtained and/or checked electronically, through other trusted means (such as the U.S. mail), or in-person) to a database; or by attestation of a supervisor, or administrative or information security officer, or a person certified by a state or Federal institution as being authorized to confirm identities (such as notaries public) who uses a stamp, seal or other mechanism to authenticate their identity confirmation |
|
Medium |
Identity established by in-person appearance before the Registration Authority for the CA, Trusted Agent or an entity certified by a State or Federal institution as being authorized to confirm identities (such as notaries public) who uses a stamp, seal or other mechanism to authenticate their identity confirmation Credentials required are either one Federal Government-issued Picture I.D., or two Non-Federal Government I.D.s, one of which SHALL be a photo I.D. (e.g., Drivers License) |
|
High |
Identity established by in-person appearance before the Registration Authority for the CA or Trusted Agent Credentials required are either one Federal Government-issued Picture I.D., or two nonFederal Government I.D.s, one of which SHALL be a photo I.D. (e.g., Drivers License) |
Some computing and communications components (routers, firewalls, servers, etc.) MAY be named as PKC Subjects. In such cases, the component MUST have a PKC Sponsor. The PKC Sponsor is responsible for providing the following registration information:
• Equipment identification
• Equipment public key(s)
• Equipment attributes and authorizations (if any are to be included in the PKC)
• Contact information to enable the CA to communicate with the PKC Sponsor when required
The registration information SHALL be verified to an assurance level commensurate with the certificate assurance level being requested. Acceptable methods for performing this authentication and integrity checking include, but are not limited to:
• Verification of digitally signed messages sent from the PKC Sponsor (using certificates of equivalent or greater assurance than that being requested).
• In person registration by the PKC Sponsor, with the identity of the PKC Sponsor confirmed in accordance with the requirements of Section 3.1.9.
Renewal of an issued PKC SHALL only be performed by the same CA that issued it and MUST be performed while the prior PKC is still valid. Renewal MAY be based on a digitally signed request using the still-valid PKC without in-person identification as required in section 3.1.
Renewal SHOULD require generation of a new key pair. However, if the renewal occurs within three years of the original date of issuance of the first issued PKC to include the public key, and the key is at least 1,024 bits long, then the same public key MAY be included in the renewal PKC.
The longer and more often a key is used, the more susceptible it is to loss or discovery. Therefore, it is important that a Subscriber periodically obtains new keys and re-establishes its identity. Re-keying a PKC means that a new PKC is created that has the same characteristics and level as the old one, except that the new PKC has a new, different public key (corresponding to a new, different private key); a different serial number; and MAY be assigned a different validity period.
Subscribers SHALL identify themselves for purpose of re-keying as required in the table below.
|
Assurance Level |
Routine Rekey Identity Requirements for Subscriber Signature and Encryption Certificates |
|
Test |
To be determined by the PMA |
|
Rudimentary |
Identity may be established through use of current signature key |
|
Basic |
Identity MAY be established through use of current signature key, except that identity SHALL be reestablished through initial registration process at least once every 15 years from the time of initial registration |
|
Medium |
Identity MAY be established through use of current signature key, except that identity SHALL be established through initial registration process at least once every nine years from the time of initial registration |
|
High |
Identity MAY be established through use of current signature key, except that identity SHALL be established through initial registration process at least once every three years from the time of initial registration |
Renewing a PKC means creating a new PKC with the same name, key, and other information as the old one, but a new, extended validity period and a new serial number. PKCs MAY be renewed in order to reduce the size of the certificate revocation database. A PKC MAY be renewed if the public key has not reached the end of its validity period, the associated private key has not been compromised, and the Subject name and attributes are unchanged. Thus, a CA MAY choose to create a PKC good for one year, renew it twice (each for a one year period), then re-key at the end of the third year.
Updating a PKC means creating a new PKC that has the same or a different key, a different serial number, and differs in one or more other fields, from the old PKC. For example, a CA MAY choose to update a PKC of a Subscriber whose characteristics have changed (e.g., has just received a medical degree). The old PKC may or may not be revoked, but MUST NOT be further re-keyed, renewed, or updated.
Further, if a human Subject's name changes (e.g., due to marriage), then proof of the name change MUST be provided to the CA in order for an updated PKC which includes the new name to be issued.
Finally, when a CA updates its private signature key and thus generates a new public key, the CA SHALL notify all Authorized or cross-certified CAs, and SHOULD make a best effort to notify any Subscribers that rely on the CA's PKC, that it has been changed. For self-signed ("root") PKCs, such PKCs SHALL be made available on-line along with separately retrievable verification information to enable a relying party to verify that it has received a valid copy of the new “root” PKC. The CPS SHALL define how this is accomplished.
A public key whose associated PKC has been revoked for private key compromise MUST NOT be re-certified. The public key MAY be re-certified 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 the CA during the period of validity of the PKC to be restored.
The CA 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.
This section specifies requirements imposed upon entities involved in the certification and certificate revocation process.
Procedures to apply for a certificate are found in the CPS.
Public keys MUST be delivered to the CA in a way that binds the applicant's verified identification to the public key. For all levels of assurance, this binding MAY be accomplished using cryptography. If cryptography is used, it MUST be at least as strong as that employed in certificate issuance. Additionally, for Medium and Basic Assurance, this binding MAY also be accomplished using non-cryptographic physical and procedural mechanisms. These mechanisms MAY include, but are not limited to, floppy disk (or other storage medium) sent via registered mail or courier, or by delivery of a token to a certificate issuer for local key generation at the point of certificate issuance or request. For Rudimentary Assurance, no trusted delivery mechanism is required. For Test Assurance, the mechanism SHALL be defined by the CA. In all cases, the method used for public key delivery MUST be set forth in a CPS.
In those cases where public/private key pairs are generated by the CA or Authorized CA on behalf of the Subscriber, the CA or Authorized CA (respectively) SHALL implement secure mechanisms to ensure that the token on which the public/private key pair is held is securely sent to the proper Subscriber. The CA or Authorized CA (respectively) SHALL also implement procedures to ensure that the token is not activated by an unauthorized entity.
Upon receiving a request from an applicant for a PKC, the conforming CA MUST respond in accordance with the requirements set forth in this CP and applicable CPS.
The PKC request MAY contain an already built ("to-be-signed") PKC. This PKC MUST NOT be signed until its contents are verified according to the process set forth in this CP and applicable CPS.
While the Subscriber MAY do most of the data entry, it is still the responsibility of the CA to verify that the information is correct and accurate. This MAY be accomplished through a system approach linking trusted databases containing personnel information, other equivalent authenticated mechanisms, or through personal contact with the Subscriber. If databases are used to confirm Subscriber information, then these databases MUST be protected from unauthorized modification to a level commensurate with the level of assurance of the certificate being sought.
Anyone who is not the Subscriber SHALL NOT under any circumstances have knowledge of or control over a private key that is to be used by a Subscriber for digital signatures or authentication. Except as described in Section 6.2.3.1, the key pair to be associated with a Subject named in a PKC issued by the CA SHALL be generated by the Subscriber or as otherwise described in Section 3.1.7. A private key will be generated and remain within the cryptographic boundary of the cryptographic module under control of the Subscriber. Since the Subscriber generates the keys, there is no need for the CA to deliver the private key to the Subscriber. Accountability for the location and state of the private key SHALL be the responsibility of the Subscriber as described in the CPS.
For Medium and High Assurance levels, a Subscriber SHALL be required to legally sign a document defining the requirements and obligations of the Subscriber with respect to protection of the private key and use of the PKC before being issued the PKC. For Basic Assurance level, the Subscriber SHALL be required to acknowledge his or her obligations respecting protection of the private key and use of the PKC before being issued the PKC. For Rudimentary or Test Assurance level, there are no requirements for this acknowledgement.
As soon as possible after a PKC is accepted, it SHALL be published in an appropriate on-line directory and made available to Subscribers and Relying Parties upon request, as described in section 2.1.5.
A CA is also responsible for maintaining and making available certification revocation information, herein referred to as a CRL. Such information MUST be made available in the form of a complete list of all revoked but unexpired certificates and MAY be made available via a network protocol such as the Online Certificate Status Protocol (OCSP). A CA SHALL NOT issue a revocation for a PKC it has not issued. It need not issue a revocation for a PKC that has already expired. Any revocation entry for a PKC that expires MAY be removed from all CRLs. CAs operating at the Test or Rudimentary LOA SHOULD but are not required to support certificate revocation.
A PKC SHALL be revoked when the binding between the Subject and the Subject's public key contained within a PKC is no longer considered valid within the Level of Assurance indicated. Examples of circumstances that invalidate the binding include:
• Identifying information in the PKC becomes invalid;
• The Subscriber, issuing CA, or Authorizing CA (if any) can be shown to have violated, or is strongly suspected of violating, the requirements of this CP or applicable CPS;
• The private key has been or is suspected of having been compromised, or has been lost, stolen, or destroyed in a fashion where there is potential for compromise or loss of control over the use of the private key.
Additionally, a Subscriber MAY always request the revocation of his or her PKC directly. Whenever any of the above circumstances occur, the associated PKC SHALL be revoked and notification placed on the CRL. Revocation notices SHALL be included on all new publications of the certificate status information until the associated PKCs expire.
The process for requesting revocation of a Subscriber PKC issued by the CA SHALL be set forth in this CP or applicable CPS.
In addition, revocation normally will proceed if:
• A CA receives sufficient evidence of compromise or loss of the Subscriber's corresponding private key, or
• An authenticated request is made to the CA by the Subscriber, or
• The CPS under which the PKC was issued states that a Relying Party can assume the Subject is a member of a particular Community and the CA receives sufficient evidence that the Subscriber is no longer a member of that Community.
A request to revoke a PKC SHALL identify the PKC to be revoked, explain the reason for revocation, and enable the request to be authenticated (e.g., digitally or manually signed).
Authentication of PKC revocation requests is important to prevent malicious revocation of PKCs by unauthorized parties. In particular, if the revocation is being requested for reason of key compromise or suspected fraudulent use, then the Subscriber's revocation request MUST so indicate. For signed requests from the PKC Subject, verification of the signature is sufficient.
Upon receipt of a valid revocation request, the CA SHALL revoke the certificate by placing its serial number and other identifying information on a CARL/CRL and then posting the CARL/CRL in the CA Repository, in addition to any other revocation mechanisms used.
When revocation of a PKC issued by the CA or an Authorized CA is required, it SHALL be done within the time limits specified in the table below. The CPS MAY set forth emergency procedures for the CA to use to effect immediate revocation of a PKC when appropriate.
|
Assurance Level |
Revocation Time Period |
|
Test |
Established by the PMA |
|
Rudimentary |
Established by the PMA |
|
Basic |
Within 6 hours |
|
Medium |
Within 2 hours |
|
High |
Within 30 minutes |
Revocation SHALL take effect upon the publication of status information (identifying the reason for the revocation, which may include loss, compromise, or termination of employment) within the time limits as specified in the table above (starting from the time the request is authenticated or sufficient evidence of compromise or loss is received). A revocation notice regarding a PKC that is revoked SHALL remain in the CRL until the PKC expires and for one additional CRL issuance cycle beyond that point. A revocation notice MAY be removed from the second CRL issued after the corresponding PKC expires.
There is no revocation grace period for the revocation of PKCs issued under this CP.
Suspension SHALL NOT be used by the CA.
Not applicable.
Not applicable.
Not applicable.
CAs operating at the Basic LOA or higher SHALL issue Certification Authority Revocation Lists (CARLs) and Certificate Revocation Lists (CRL). CAs operating at the Test or Rudimentary LOA MAY issue CRLs as defined by their PMA and documented in their CPS(s).
CARLs and CRLs SHALL be issued periodically, even if there are no changes to be made, to ensure timeliness of information. Certificate status information MAY be issued more frequently than the issuance frequency described below. The CA SHALL ensure that superseded PKC status information is removed from the Repository upon posting of the more recent status information.
PKC status information SHALL be published not later than the next scheduled update. This will facilitate the local caching of PKC status information for off-line or remote (laptop) operation. The CA SHALL coordinate with the Repository to which it posts PKC status information to reduce latency between creation and availability.
The following table provides CARL/CRL issuance requirements.
|
Assurance Level |
CARL/CRL Issuance Frequency for CAs |
CARL/CRL Issuance for CAs (Loss or Compromise of Private Key) |
|
As defined by the PMA |
As defined by the PMA |
|
|
Rudimentary |
As defined by the PMA and documented in the CPS |
As defined by the PMA and documented in the CPS |
|
Basic |
At least once each week |
Within 24 Hours of Notification |
|
Medium |
At Least Once Each Day |
Within 24 Hours of Notification |
|
High |
At Least Once Each Day |
Within 6 Hours of Notification |
In addition to download access to CARL/CRLs, conforming CAs and Relying Party client software MAY optionally support on-line status checking with a documented protocol such as the On‑line Certificate Status Protocol (OCSP). Client software using on‑line status checking need not obtain or process file based CARL/CRLs. The CPS will specify when and under what circumstances the CA will provide on-line status checking of issued PKCs.
If the CA supports OCSP, it is still the responsibility of the Relying Party to determine when to make use of it, as described in section 4.4.10.
Intentionally left blank.
Intentionally left blank.
Intentionally left blank.
Audit log files SHALL be generated for all events relating to the security of the CA or Authorized CAs. 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. The security audit logs for each auditable event defined in this section SHALL be maintained in accordance with Section 4.6.2.
All security auditing capabilities of the CA or Authorized CA operating system and PKI CA applications required by this CP SHALL be enabled. As a result, most of the events identified in the table below SHALL be automatically recorded. Auditing capabilities relevant to Test Assurance level are not described below. At a minimum, each audit record SHALL include the following (either recorded automatically or manually for each auditable event):
• The type of event
• The date and time the event occurred
• A success or failure indicator when executing the CA or Authorized CA's signing process
• A success or failure indicator when performing certificate revocation
• Identity of the entity and/or operator of the CA or Authorized CA that caused the event.
• Message from any source requesting an action by the CA or Authorized CA is an auditable event. The message MUST include message date and time, source, destination and contents.
|
Auditable Event |
Rudimentary |
Basic |
Medium |
High |
|
SECURITY AUDIT |
|
|
|
|
|
Any changes to the Audit parameters, e.g., audit frequency, type of event audited |
|
X |
X |
X |
|
Any attempt to delete or modify the Audit logs |
|
X |
X |
X |
|
Obtaining a third-party time-stamp |
|
X |
X |
X |
|
|
|
|
|
|
|
IDENTIFICATION AND AUTHENTICATION |
|
|
|
|
|
Successful and unsuccessful attempts to assume a role |
|
X |
X |
X |
|
The value of maximum authentication attempts is changed |
|
X |
X |
X |
|
Maximum authentication attempts unsuccessful authentication attempts occur during user login |
|
X |
X |
X |
|
An Administrator unlocks an account that has been locked as a result of unsuccessful authentication attempts |
|
X |
X |
X |
|
An Administrator changes the type of authenticator, e.g., from password to biometrics |
|
X |
X |
X |
|
|
|
|
|
|
|
LOCAL DATA ENTRY |
|
|
|
|
|
All security-relevant data that is entered in the system |
|
X |
X |
X |
|
|
|
|
|
|
|
REMOTE DATA ENTRY |
|
|
|
|
|
All security-relevant messages that are received by the system |
|
X |
X |
X |
|
|
|
|
|
|
|
DATA EXPORT AND OUTPUT |
|
|
|
|
|
All successful and unsuccessful requests for confidential and security-relevant information |
|
X |
X |
X |
|
|
|
|
|
|
|
KEY GENERATION |
|
|
|
|
|
Whenever the CA or Authorized CA generates a key. (Not mandatory for single session or one-time use symmetric keys) |
X |
X |
X |
X |
|
|
|
|
|
|
|
PRIVATE KEY LOAD AND STORAGE |
|
|
|
|
|
The loading of Component private keys |
X |
X |
X |
X |
|
All access to certificate Subject private keys retained by the CA or Authorized CA if the CA supports key escrow services |
X |
X |
X |
X |
|
|
|
|
|
|
|
TRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE |
|
|
|
|
|
All changes to the trusted public keys, including additions and deletions |
X |
X |
X |
X |
|
|
|
|
|
|
|
SECRET KEY STORAGE |
|
|
|
|
|
The manual entry of secret keys used for authentication |
|
|
X |
X |
|
|
|
|
|
|
|
PRIVATE AND SECRET KEY EXPORT |
|
|
|
|
|
The export of private and secret keys (keys used for a single session or message are excluded) |
X |
X |
X |
X |
|
|
|
|
|
|
|
CERTIFICATE REGISTRATION |
|
|
|
|
|
All certificate requests |
X |
X |
X |
X |
|
|
|
|
|
|
|
CERTIFICATE REVOCATION |
|
|
|
|
|
All certificate revocation requests |
|
X |
X |
X |
|
|
|
|
|
|
|
CERTIFICATE STATUS CHANGE APPROVAL |
|
|
|
|
|
The approval or rejection of a certificate status change request |
|
X |
X |
X |
|
|
|
|
|
|
|
CA OR AUTHORIZED CA CONFIGURATION |
|
|
|
|
|
Any security-relevant changes to the configuration of the CA or Authorized CA |
|
X |
X |
X |
|
|
|
|
|
|
|
ACCOUNT ADMINISTRATION |
|
|
|
|
|
Roles and users are added or deleted |
X |
X |
X |
X |
|
The access control privileges of a user account or a role are modified |
X |
X |
X |
X |
|
|
|
|
|
|
|
CERTIFICATE PROFILE MANAGEMENT |
|
|
|
|
|
All changes to the certificate profile |
X |
X |
X |
X |
|
|
|
|
|
|
|
REVOCATION PROFILE MANAGEMENT |
|
|
|
|
|
All changes to the revocation profile |
|
X |
X |
X |
|
|
|
|
|
|
|
CERTIFICATE REVOCATION LIST PROFILE MANAGEMENT |
|
|
|
|
|
All changes to the certificate revocation list profile |
|
X |
X |
X |
|
|
|
|
|
|
|
MISCELLANEOUS |
|
|
|
|
|
Installation of the Operating System |
|
X |
X |
X |
|
Installation of the CA or Authorized CA |
|
X |
X |
X |
|
Installing hardware cryptographic modules |
|
|
X |
X |
|
Removing hardware cryptographic modules |
|
|
X |
X |
|
Destruction of cryptographic modules |
|
X |
X |
X |
|
System Startup |
|
X |
X |
X |
|
Logon Attempts to CA or Authorized CA Apps |
|
X |
X |
X |
|
Receipt of Hardware / Software |
|
|
X |
X |
|
Attempts to set passwords |
|
X |
X |
X |
|
Attempts to modify passwords |
|
X |
X |
X |
|
Backing up CA or Authorized CA internal database |
|
X |
X |
X |
|
Restoring CA or Authorized CA internal database |
|
X |
X |
X |
|
File manipulation (e.g., creation, renaming, moving) |
|
|
X |
X |
|
Posting of any material to a Repository |
|
|
X |
X |
|
Access to CA or Authorized CA internal database |
|
|
X |
X |
|
All certificate compromise notification requests |
|
X |
X |
X |
|
Loading tokens with certificates |
|
|
X |
X |
|
Shipment of Tokens |
|
|
X |
X |
|
Zeroizing tokens |
|
X |
X |
X |
|
Rekey of the CA or Authorized CA |
X |
X |
X |
X |
|
Configuration changes to the CA server involving: |
|
|
|
|
|
Hardware |
|
X |
X |
X |
|
Software |
|
X |
X |
X |
|
Operating System |
|
X |
X |
X |
|
Patches |
|
X |
X |
X |
|
Security Profiles |
|
|
X |
X |
|
|
|
|
|
|
|
PHYSICAL ACCESS / SITE SECURITY |
|
|
|
|
|
Personnel Access to location of CA or Authorized CA |
|
|
X |
X |
|
Access to the CA or Authorized CA server |
|
|
X |
X |
|
Known or suspected violations of physical security |
|
X |
X |
X |
|
|
|
|
|
|
|
ANOMALIES |
|
|
|
|
|
Software Error conditions |
|
X |
X |
X |
|
Software check integrity failures |
|
X |
X |
X |
|
Receipt of improper messages |
|
|
X |
X |
|
Misrouted messages |
|
|
X |
X |
|
Network attacks (suspected or confirmed) |
|
X |
X |
X |
|
Equipment failure |
X |
X |
X |
X |
|
Electrical power outages |
|
|
X |
X |
|
Uninterruptible Power Supply (UPS) failure |
|
|
X |
X |
|
Obvious and significant network service or access failures |
|
|
X |
X |
|
Violations of Certificate Policy |
X |
X |
X |
X |
|
Violations of Certification Practice Statement |
X |
X |
X |
X |
|
Resetting Operating System clock |
|
X |
X |
X |
Audit logs SHALL be reviewed as specified in the table below. All significant events SHALL be explained in an audit log summary. In addition to statistical sampling as required, such reviews SHALL include verifying that the log has not been tampered with and then briefly inspecting all log entries, with a more thorough investigation of any alerts or irregularities noted in the logs. Actions taken as a result of these reviews SHALL be documented.
|
Test |
As defined by the PMA |
|
Rudimentary |
Only required for cause |
|
Basic |
Only required for cause |
|
Medium |
At least once every two months Statistically significant set of security audit data generated by CAs since the last review SHALL be examined (where the confidence intervals for each category of security audit data are determined by the security ramifications of the category and the availability of tools to perform such a review), as well as a reasonable search for any evidence of malicious activity |
|
High |
At least once per month Statistically significant set of security audit data generated by CAs since the last review SHALL be examined (where the confidence intervals for each category of security audit data are determined by the security ramifications of the category and the availability of tools to perform such a review), as well as a reasonable search for any evidence of malicious activity |
100% of security audit data generated by the CA since the last review SHALL be examined.
Audit logs SHALL be retained on-site for at least two months as well as being retained in the manner described below. The individual who removes audit logs from the CA or Authorized CA system SHALL be different from any of the individuals who, in combination, manage the CA or an Authorized CA signature key.
• only authorized people have read access to the logs;
• only authorized people may archive or delete audit logs; and,
• audit log entries are not modified.
The entity performing audit log archive need not have modify access, but procedures MUST be implemented to protect archived data from deletion or destruction prior to the end of the audit log retention period (note that deletion requires modification access). Audit logs SHALL be moved to a safe, secure storage location separate from the CA equipment.
Audit logs and audit summaries SHALL be backed up at least monthly. A copy of the audit log SHALL be sent off-site at least once a month.
The audit record collection process SHALL NOT be done by or under the control of the CA or Authorized CA. Audit record collection processes SHALL be invoked at system startup, and cease only at system shutdown. Should it become apparent that an automated audit record collection system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, then the PMA SHALL determine whether to suspend CA operation, or Authorized CA operation respectively, until the problem is remedied.
Intentionally left blank.
Intentionally left blank.
Records archiving is REQUIRED only for any CA operating at the Basic or higher LOA.
CA or Authorized CA archive records SHALL be sufficiently detailed to verify the proper operation of the CA or Authorized CA, and the validity of any PKC (including those revoked or expired) issued by the CA or Authorized CA.
At a minimum, the following data SHALL be recorded for archive in accordance with each assurance level.
|
Data To Be Archived |
Rudimentary |
Basic |
Medium |
High |
|
CA authority certificate |
X |
X |
X |
X |
|
Certification Practice Statement |
X |
X |
X |
X |
|
Contractual obligations |
X |
X |
X |
X |
|
Initial and periodic snapshots of the CA system and equipment configuration |
|
X |
X |
X |
|
Significant modifications and/or updates to system or configuration |
|
X |
X |
X |
|
Certificate requests |
X |
X |
X |
X |
|
Revocation requests |
|
X |
X |
X |
|
Subscriber identity Authentication data as per Section 3.1.9 |
|
X |
X |
X |
|
Documentation of receipt and acceptance of PKCs and associated tokens, if applicable |
|
X |
X |
X |
|
All PKCs issued or published |
X |
X |
X |
X |
|
Record of CA or subordinate CA Re-key |
X |
X |
X |
X |
|
All CARLs and CRLs issued and/or published |
|
X |
X |
X |
|
All Audit Logs |
X |
X |
X |
X |
|
Other data or applications to verify archive contents |
|
X |
X |
X |
|
Documentation required by compliance auditors |
|
X |
X |
X |
The minimum retention period for archived CA data is identified below.
|
Assurance Level |
Retention Period |
|
Test |
As defined by the PMA |
|
Rudimentary |
7 Years & 6 Months |
|
Basic |
7 Years & 6 Months |
|
Medium |
10 Years & 6 Months |
|
High |
20 Years & 6 Months |
If the original media cannot retain the data for the required period, a mechanism to periodically transfer the archived data to new media SHALL be defined by the archive site. Applications required to process the archive data SHALL also be maintained for as long as necessary as determined by the CA.
An unauthorized user SHALL NOT be permitted to write to, modify, or delete the archive. Archived records MAY be moved to another medium when authorized by the PMA. The contents of the archive SHALL NOT be released except as determined by the PMA or as required by law. Records of individual transactions MAY be released upon request of the Subscriber involved in the transaction. Archive media SHALL be stored in a safe, secure storage facility separate from the CA itself.
Intentionally left blank.
Intentionally left blank.
Intentionally left blank.
Each applicable CPS used by the CA SHALL include procedures for how to create, verify, package, transmit, and store the CA's archive information
To minimize risk from compromise of a CA's private signing key, that key SHOULD be changed periodically; and from that time on, only the new key will be used for certificate signing purposes. The older, but still valid, PKC will be available to verify old signatures until all of the PKCs signed using the associated private key also have expired. If the old private key is to be used to sign CRLs that contain certificates signed with that key, then the old key MUST be protected and retained as well.
The CA's signing key SHALL have a validity period of five years, and its corresponding certificate SHALL have a validity period of eight years. All values are in years.
|
Assurance Level |
|
|
Test |
As defined by the PMA |
|
Rudimentary |
5 / 8 |
|
Basic |
5 / 8 |
|
Medium |
5 / 8 |
|
High |
5 / 8 |
If CA equipment is damaged or rendered inoperative, but the CA signature keys are not destroyed, the CA operation SHALL be reestablished as quickly as possible, giving priority to the ability to generate certificate status information.
If the CA cannot issue a revocation prior to the time specified in the next update field of its currently valid CARL/CRL, then the PMA SHALL be immediately and securely notified. The PMA SHALL determine whether to revoke the authority certificate issued to any Authorized CA. The CA SHALL re-establish revocation capabilities as quickly as possible in accordance with procedures set forth in the applicable CPS. The CA SHALL immediately and securely advise the PMA in the event of a disaster where the CA installation is physically damaged and all copies of the CA signature keys are destroyed.
If a CA's signature keys are compromised or lost (such that compromise is possible even though not certain):
• The PMA SHALL be immediately and securely notified so that the Authorizing CA or CAs from whom a cross certification certificate has been issued MAY issue revocations for any authority or cross-certificates issued to the CA;
• The CAs that have issued PKCs to the affected CA SHALL immediately publish a CARL revoking the affected CA's PKC as set forth above;
• A new CA key pair SHALL be generated by the CA in accordance with procedures set forth in the applicable CPS;
• New CA authority PKCs SHALL be acquired or generated by the CA and made available in the Repository immediately;
• New cross-certificates SHALL be acquired and issued by the CA also in accordance with the applicable CPS; and
• All Subscribers SHALL be required to recertify following the initial identification procedures defined in section 3.1 and the CPS.
The CA SHALL investigate and report to the PMA what caused the compromise or loss and what measures have been taken to preclude recurrence.
In the case of a disaster whereby the CA installation is physically damaged and all copies of the CA signature key are destroyed as a result, the PMA SHALL be immediately and securely notified, and the PMA SHALL take whatever action it deems appropriate. The CA installation SHALL then be completely rebuilt, by reestablishing the CA equipment, generating new private and public keys, acquiring a new authority certificate, and re-issuing all authority PKCs to Authorized CAs. Relying Parties may decide of their own volition whether to continue to use PKCs signed with the destroyed private key pending reestablishment of CA operation with new PKCs.
In the event of termination of the CA operation, PKCs signed by the CA SHALL be revoked and the PMA SHALL continue operation of the Repository and include in the Repository notice of the termination of the CA. Prior to CA termination, the CA SHALL provide archived data to a PMA approved archival facility.
In the event that an Authorized CA terminates operation, the CA SHALL ensure that any authority PKCs issued to that Authorized CA have been revoked.
The CA SHALL impose physical security requirements that provide similar levels of protection as those specified below.
CA equipment SHALL be protected from unauthorized access while the cryptographic module is installed. The CA SHALL implement physical access controls to reduce the risk of equipment tampering even when the cryptographic module is not installed. These security mechanisms SHALL be commensurate with the level of threat in the CA equipment environment.
The location and construction of the facility housing the CA equipment SHALL be consistent with facilities used to house high value, sensitive information. The site location and construction, when combined with other physical security protection mechanisms such as guards and intrusion sensors, SHALL provide robust protection against unauthorized access to the CA equipment and records.
The CA equipment SHALL always be protected from unauthorized access. These security mechanisms SHALL be commensurate with the level of threat in the equipment environment. At a minimum, the CA MUST be operated and controlled in accordance with the requirements below pertaining to the highest assurance level PKC to be issued.
The physical security requirements pertaining to CAs that issue Rudimentary or Basic assurance PKCs are:
• Ensure no unauthorized access to the hardware is permitted;
• Ensure all removable media and paper containing sensitive plain‑text information is stored in secure containers.
In addition to those requirements, the following requirements SHALL apply to CAs that issue Medium or High assurance PKCs:
• The facility SHALL be manually or electronically monitored for unauthorized intrusion at all times;
• The facility SHALL maintain an access and egress log and ensure that it is inspected concurrently with the security audits required in section 4.5 at the frequency specified in 4.5.2.
Physical security requirements pertaining to CAs at the Test Assurance level SHALL be commensurate with the risks associated with their use.
Removable cryptographic modules SHALL be inactivated prior to storage. When not in use, removable cryptographic modules and activation information used to access or enable cryptographic modules for the CA or equipment SHALL be placed in secure containers. Activation data SHALL be recorded and stored in a manner commensurate with the security afforded the cryptographic module. Activation data SHALL NOT be stored with the cryptographic module.
A security check of the facility housing the CA equipment for a CA operating at the Basic Assurance level or higher SHALL occur if the facility is to be left unattended. At a minimum, the check SHALL verify the following:
• The equipment is in a state appropriate to the current mode of operation (e.g., that cryptographic modules are in place when "open", and secured when "closed"; and that all equipment other than the Repository is shut down);
• Any security containers are properly secured;
• Physical security systems (e.g., door locks, vent covers) are functioning properly; and
• The area is secured against unauthorized access.
A person or group of persons SHALL be made explicitly responsible for making such checks. When a group of persons is responsible, a log identifying the person performing a check at each instance SHALL be maintained. If the facility is not continuously attended, the last person to depart SHALL initial a sign‑out sheet that indicates the date and time, and asserts that all necessary physical protection mechanisms are in place and activated.
The CA SHALL operate with an uninterruptible power source sufficient to allow its orderly shutdown in the event primary electrical power is lost.
Intentionally left blank.
Intentionally left blank.
CA media SHALL be stored so as to protect it from accidental damage (water, fire, electromagnetic). Media that contains audit, archive, or backup information SHALL be duplicated, encrypted, and stored in a location separate from the CA.
Intentionally left blank.
For the CA operating at the Basic Assurance level or higher, system backups, sufficient to recover from system failure, SHALL be made on a periodic schedule as described in the applicable CPS. Backups are to be performed, encrypted, and stored off-site not less than once per week at a location separate from the CA equipment. Only the latest backup need be retained. The backup SHALL be stored at a site with physical and procedural controls commensurate to that of the operational CA.
The requirements of this Section of the CP are described in terms of four roles:
Administrator -- authorized to install, configure, and maintain the CA; establish and maintain user accounts; configure profiles and audit parameters; generate component keys; and perform any manual operations required for the issuance of PKCs.
Officer -- authorized to request or approve PKCs or PKC revocations, e.g. is the RA.
Auditor -- authorized to view and maintain audit logs.
Operator -- authorized to perform system backup and recovery.
These roles may be fulfilled by one or more individuals, as described in the following sections.
The administrator role is responsible for:
• installation, configuration, and maintenance of the CA;
• establishing and maintaining CA system accounts;
• configuring certificate profiles or templates and audit parameters, and;
• generating and backing up CA keys.
If manual intervention is required in order to issue a PKC, the Administrator performs that function.
The officer role is responsible for approving the issuance of PKCs, that is:
• registering new Subscribers and requesting the issuance of PKCs;
• verifying the identity of Subscribers and accuracy of information included in PKCs;
• approving the issuance of PKCs;
• requesting or approving the revocation of PKCs.
Typically the Officer has no direct access to the CA physical hardware.
The auditor role is responsible for:
• reviewing, maintaining, and archiving audit logs;
• performing or overseeing internal compliance audits to ensure that the CA is operating in accordance with the applicable CPS.
Typically the Auditor has no direct access to the CA physical hardware.
The operator role is responsible for the routine operation of the CA equipment and operations such as system backups and recovery or changing recording media.
Role separation may be enforced either by the CA equipment, or procedurally, or by both means.
The separation of roles for the CA SHALL be as follows:
|
Assurance Level |
Role Separation Rules |
|
Test |
Intentionally left blank. |
|
Rudimentary |
A CA operating at the Rudimentary LOA SHOULD implement the role separation defined under Basic below. |
|
Basic |
Individual CA personnel SHALL be specifically designated to the four roles defined in Section 5.2.1 above. Individuals MAY assume more than one role, however, a given individual SHALL NOT assume both the Officer and Administrator roles. One individual MAY be both the Officer and the Auditor. One individual MAY be both the Administrator and Operator. |
|
Medium |
Individual CA personnel SHALL be specifically designated to the four roles defined in Section 5.2.1 above. Individuals MAY assume more than one role, however, individuals who assume an Officer role MAY NOT assume an Administrator or Auditor role. The CA system SHALL authenticate its users with PKCs that it issues or causes to be issued and SHALL ensure that no user, however they might be identified in their PKC, can assume both an Officer and either an Administrator or Auditor role. |
|
High |
Individual CA personnel SHALL be specifically designated to the four roles defined in Section 5.2.1 above. Individuals MAY assume only one of the Officer, Administrator, and Auditor roles, but any individual MAY assume the Operator role. The CA system SHALL authenticate its users with PKCs that it issues or causes to be issued and SHALL ensure that no user, however they might be identified in their PKC, can: · Assume both the Administrator and Officer roles. · Assume both the Administrator and Auditor roles. · Assume both the Auditor and Officer roles. |
The incumbent of a CA role SHALL NOT perform its own auditor function. If the Officer is also the Auditor, then periodic audits SHALL be performed by a third party.
For tasks that represent significant security risks, such as activating the root signing key of a CA hierarchy, at least 2 individuals from an authorized group of no more than 4 individuals SHALL be required.
At all assurance levels other than Test of Rudimentary, an individual MUST identify and authenticate him/herself before being permitted to perform any actions set forth above for any role. The identity of individuals that are assigned to each role MUST be kept in read-only storage when accessible to the CA platform and MUST only be modifiable by an off-line device. For example, the list could be stored on CDROM that is created on an off-line system. Copies of the list SHALL be kept in backup storage as described in Section 5.1.8.
All persons filling trusted roles SHALL be selected on the basis of loyalty, trustworthiness, and integrity. The requirements governing the qualifications, selection and oversight of individuals who operate, manage, oversee, and audit the CA SHALL be set forth in the applicable CPS.
Intentionally left blank.
All personnel performing duties with respect to the operation of the CA SHOULD receive comprehensive training. Such training MUST be provided for personnel associated with a CA operating at the Basic, Medium, or High LOA. For a CA operating at the Medium or High LOA, there SHOULD be periodic verification that personnel skill levels reflect successful completion of this training. Training SHALL be conducted in the following areas:
|
Area |
Operating Level of Assurance of the CA |
||||
|
Test |
Rud. |
Basic |
Med. |
High |
|
|
CA security principles and mechanisms |
|
|
√ |
√ |
√ |
|
All PKI software versions in use on the CA system |
|
√ |
√ |
√ |
√ |
|
All PKI duties they are expected to perform |
|
√ |
√ |
√ |
√ |
|
Disaster recovery and business continuity procedures. |
|
|
√ |
√ |
√ |
Intentionally left blank.
The PMA SHALL take appropriate administrative and disciplinary actions against personnel who have performed actions involving the CA or its Repository not authorized in this CP or the applicable CPS.
Contractor personnel employed to perform functions pertaining to the CA SHALL meet the same set of requirements described in this section 5.3.
In addition, such personnel SHALL be bonded to a level appropriate to the risks that their misfeasance or malfeasance might incur.
At a minimum, the CA SHALL make available to its personnel the certificate policies it supports (including this CP), relevant parts of the applicable CPS, and any relevant institutional policies. Documentation SHALL be maintained identifying all personnel who received training and the level of training completed.
Cryptographic keys for the authority certificates used by the CA SHALL be generated in FIPS 140 validated cryptographic modules with the possible exception of the PKC used to issue "Test" certificates. The modules SHALL meet or exceed Security Level 1 (for Rudimentary), Security Level 2 (for Basic or Medium), or Security Level 3 (for High). Requirements for Test Assurance SHALL be defined by the CA.
Cryptographic keys for end-entity certificates SHALL be generated by the end-entity, not by the CA, except possibly in the case of keys to be used for data encryption where escrow of the private key is required (see Section 6.2.3.1). Except as defined in section 6.2.3.1, the end-entity SHALL NOT reveal their private key(s) to the CA or any other entity.
In most cases CA Subscribers will generate their own key pairs and thus will not require delivery of their private key. Whenever keys are generated by an entity other than the Subscriber (see Section 6.2.3.1), delivery of the private key to the Subscriber shall be effected in such a manner that no entity other than the key generating agent, the escrow agent (if any) and the Subscriber have access to an unencrypted version of the private key at any time. Only the escrow agent (if any) and the Subscriber may retain copies of the private key. For Basic or higher LOA PKCs, the Subscriber must sign a receipt for the private key and prove possession of it. This MAY be accomplished by using the private key to digitally sign a receipt for its delivery. If used, the procedure to implement the requirements of this section MUST be documented in the CPS.
Public keys SHALL be delivered to the certificate issuer in an authenticated manner set forth in the applicable CPS. This is usually accomplished by means of an electronic certificate request message from the CA, but it also MAY be done through other secure mechanisms. Alternative mechanisms MAY include, but are not limited to, floppy disk (or other storage medium) sent via registered mail or courier. If off-line means are used, they SHALL include identity checking as set forth in this CP and SHALL also ensure that proof of possession of the corresponding private key is accomplished.
The CA SHALL post a copy of its authority certificate, and a copy of any CA authority PKC that it signs, to its public Repository. In addition, the CA SHOULD post to its Repository a copy of any cross-certificate that it signs and any cross-certificate issued to it by another CA.
Key sizes MUST be commensurate with the risk that they might be compromised during the validity period of the certificate or any document signed with the private key. Based on current and projected technology, 1024 bit keys should be reasonably safe through the year 2015. Based on current and projected technology, signing keys used by a CA MUST be at least 1024 bits in length. However, PKCs signed with 1024-bit keys SHOULD NOT be given a validity period beyond the year 2015. The signing key used by the principal CA in a hierarchy MUST be at least 2048 bits in length.
All FIPS-approved signature algorithms SHALL be considered acceptable. All PKCs issued by the CA SHOULD use at least 1024 bit RSA or DSA (or better) with Secure Hash Algorithm version 1 (SHA-1) (or better) in accordance with FIPS 186 [the most current revision].
If the PMA determines that the security of a particular algorithm might be compromised, it MAY require the CA to revoke the affected PKCs.
Use of SSL, TLS, or another protocol providing similar security SHALL require at a minimum triple-DES or equivalent NIST approved algorithm for the symmetric key, and 1024 bit (or better) RSA, DSA, or equivalent NIST approved algorithm for the asymmetric keys.
Public key parameters prescribed in the Digital Signature Standard (DSS) SHALL be generated in accordance with FIPS 186-2.
When generating key pairs, parameter quality checking (including testing for prime numbers) SHALL be performed in accordance with FIPS 186-2, Appendix 2, or a more stringent test if specified by the CPS.
For Subscribers, software or hardware SHALL be used to generate pseudo-random numbers, key pairs and symmetric keys, as set forth in the table below. Any pseudo-random numbers used for key generation material SHALL be generated by a FIPS approved method.
|
Assurance Level |
Key Generation Mechanism |
|
Test |
As defined by the PMA |
|
Rudimentary |
Software or Hardware |
|
Basic |
Software or Hardware |
|
Medium |
Software or Hardware but Hardware is RECOMMENDED |
|
High |
Hardware only |
The use of a specific key pair is determined by the key usage extension in the associated X.509 certificate.
No bits are set to one (1) in the Key Usage field except as follows. Public keys that are bound into PKCs MAY be certified for use in verifying digital signatures or encrypting, but not both, except as specified below. In particular, PKCs to be used for digital signatures (including authentication) SHALL have the digitalsignature bit set. Such PKCs asserting a Basic or higher LOA MAY also set the nonrepudiation bit except as prohibited below. PKCs to be used for data encryption SHALL have the dataencryption bit set. CA authority PKCs SHALL have two key usage bits set: cRLSign and CertSign. This restriction is not intended to prohibit use of protocols (like the Secure Sockets Layer (SSL)) that provide authenticated connections using key management certificates.
Test, Rudimentary, Basic and Medium Assurance Level PKCs MAY include a single key for use with encryption and signature in support of legacy Secure Multipurpose Internet Mail Extensions (S/MIME) applications. Such "dual-use" PKCs SHALL be generated and managed in accordance with their respective signature PKC requirements, except where otherwise noted in this CP. Such "dual-use" PKCs SHALL NOT assert the nonrepudiation key usage bit, and SHALL NOT be used for authenticating data that will be verified on the basis of the dual-use PKC at a future time.
PKCs for which the private key is escrowed (see Section 6.2.3.1) SHALL NOT have the nonrepudiation bit set.
CAs at all levels of assurance SHOULD ensure that Subscribers who require both encryption capability and digital signature capability possess two different key pairs, one for data encryption and one for digital signature and authentication.
The relevant standard for cryptographic modules is Security Requirements for Cryptographic Modules [latest version of FIPS 140 series]. The CA MAY determine that other comparable validation, certification, or verification standards are sufficient. These standards will be published in the CPS. Cryptographic modules SHALL be validated to the FIPS 140-1 level identified in this section, or validated, certified, or verified to more stringent requirements as published in the CPS.
The table below summarizes the requirements for cryptographic modules.
|
Assurance Level |
FIPS 140-1 |
Certification Authority Crypto Module |
Subscriber |
Registration Authority Crypto Module |
|
N/A |
Defined by the PMA |
N/A |
Defined by the PMA |
|
|
N/A |
Level 1 (Hardware or Software) |
N/A |
Level 1 (Hardware or Software) |
|
|
Basic |
Required |
Level 2 (Hardware or Software) |
Level 1 |
Level 1 (Hardware or Software) |
|
Medium |
Required |
Level 2 (Hardware) |
Level 1 |
Level 2 (Hardware) |
|
High |
Required |
Level 3 (Hardware) |
Level 2 |
Level 2 (Hardware) |