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