Skip Maine state header navigation
Abstract
This document defines the Certification Policies and Practices in accordance with the X.509 standard under which the State of Maine will operate its Certification Authorities in support of the PKI project.
 |
Prepared by |
State of Maine
Office of Information Technology
This page intentionally left blank.
Certification Policies and Practices Statement
1.1.1 Roles and Responsibilities
1.3 Community and Applicability
1.3.1 Certification Authorities
1.3.2 Registration Authorities
1.3.4.3 Prohibited Applications
2.1.1 Warranties and Limitations
2.2.4 Relying Party Obligations
2.3.1 Indemnification by Relying Parties
2.4 Interpretations and Enforcement
2.4.2 Severability, Survival, Merger, 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 Repositories
2.6.1 Publication of CA Information
2.6.2 Frequency of Publication
2.7.1 Frequency of Entity Compliance Audit
2.7.2 Identity/Qualifications of Auditor
2.7.3 Auditor’s Relationship to Audited Party
2.7.5 Actions Taken as a Result of Deficiency
2.7.6 Communication of Results
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/Suspension Information
2.8.4 Release to Law Enforcement Officials
2.8.5 Release as Part of Civil Discovery
2.9 Intellectual Property Rights
3. Identification and Authentication
3.1.2 Need for Names to be Meaningful
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
4.1.1 Delivery of Subscriber's public key to certificate issuer
4.2.2 CA public key delivery to users
4.4.1 Circumstances for revocation
4.4.1.1 Who can request a revocation
4.4.1.2 Procedure for Revocation Request
4.4.1.3 Revocation Grace Period
4.4.2 Certificate Revocation Lists
4.4.2.1 CRL issuance frequency
4.4.2.2 CRL checking requirements
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
4.5.7 Notification to event-causing subject
4.5.8 Vulnerability assessments
4.6.4 Archive backup procedures
4.6.5 Archive collection system
4.6.6 Procedures to obtain archive information
4.8 Compromise and Disaster Recovery
5. Physical, Procedural, and Personnel Security Controls
5.2.2 Number of Persons Required per Task
5.2.3 Identification and Authentication for Each Role
5.3 Personnel Security Controls
5.3.1 Personnel Security Controls for Certification Authority
5.3.2 Personnel Security Controls for Registration Authority
5.3.3 Personnel Security Controls for End-Entities
6. Technical Security Controls
6.1 Key Pair Generation and Installation
6.1.2 Private and Public Key Delivery to Entity
6.1.3 CA Public Key Delivery to Users
6.2.1 Standards for Cryptographic Module
6.2.2 Private Key Multi-person Control
6.2.3 Private Key Escrow, Backup and Recovery
6.2.4 Private Key Activation and Entry into Cryptographic Module
6.2.5 Method of Deactivating Private Key
6.2.6 Method of Destroying Private Key
6.3 Other Aspects of Key Pair Management
6.3.2 Usage Periods for the Public and Private Keys
6.5 Computer Security Controls
6.6 Lifecycle Security Controls
7. Certificate and CRL Profile
8. Specification Administration
8.1 SPECIFICATION CHANGE PROCEDURES
8.2 Publication And Notification Policies
8.3 CPS and External Policy Approval Procedures
|
Date |
Author |
Version |
Change Reference |
|
8/28/2007 |
Brian Komar |
1.0 |
Document Created. |
|
8/29/2007 |
Brian Komar |
1.1 |
Updates based on phone meeting |
|
11/05/2007 |
Michael Pomerleau |
1.2 |
Updates CERTS team members & meetings of security staff. |
|
11/18/2007 |
Michael Pomerleau |
1.3 |
Updates from reviews. |
|
11/20/2007 |
Michael Pomerleau |
1.3 |
Provisionally Adopted by OIT Leadership |
|
11/27/2007 |
Michael Pomerleau |
1.4 |
Change to 4.1.1 Circumstances for revocation. |
|
11/28/2007 |
Michael Pomerleau |
1.4 |
Adopted by Maine OIT CIO Richard B. Thompson |
The X.509 standard defines a certificate policy as "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements". An X.509 Version 3 certificate may contain an indication of certificate policy, which may be used by a certificate user to decide whether or not to trust a certificate for a particular purpose.
The concept of a Certification Practices Statement (CPS) was developed by the American Bar Association (ABA) in its Digital Signature Guidelines (ABA Guidelines) and is defined as a "statement of the practices, which a certification authority employs in issuing certificates." Most organizations that operate certification authorities will document their own practices in a CPS or similar statements. The CPS is one of the organization's means of protecting itself and positioning its business relationships with subscribers and other entities.
State of Maine Government has combined its certification policies and practices into one CPS.
This Certification Policies and Practices Statement describes the policies and practices of the Certification Authorities (CA) operated by State of Maine Government. This CPS is applicable to all entities that have relationships with the State of Maine Government CAs, including end users; cross certified CAs, and Registration Authorities (RAs). This CPS provides those entities with a clear statement of the practices and responsibilities of the State of Maine Government CAs, as well as the responsibilities of each entity in dealing with State of Maine Government CAs.
The following definitions are used in this document:
CA Certification Authority
CIO Chief Information Officer
CMA Certificate Management Authority
CMCS COMSEC Material Control System
CNSS Committee for National Security Systems
COMSEC Communications Security
CONOP Concept of Operations (document)
CP Certificate Policy
CPM Certification Policy Management group
CPS Certification Policies and Practice Statement
CRL Certificate Revocation List
CTO Chief Technology Officer
DACL Discretionary Access Control List
DAA Designated Approving Authority
DN Distinguished Name
DSA Digital Signature Algorithm
DSS Digital Signature Standard
EISD Enterprise Information Security Director
FIPS Federal Information Processing Standard
FPKI (US) Federal Public Key Infrastructure
GS-General Schedule (Federal civilian level)
GUID Globally Unique Identifier
KRA Key Recovery Agent
ME Maine
OID Object Identifier
PIN Personal Identification Number
PKCS Public Key Certificate Standard
PKI Public Key Infrastructure
RA Registration Authority
RDN Relative Distinguished Name
RSA Rivest, Shamir, Adleman (encryption algorithm)
S/MIME Secure Multipurpose Internet Mail Extensions
SOM State of Maine
The primary source is CNSS Instruction 4009, National Information Systems Security Glossary; other sources were used if CNSS 4009 had no entry for the term, or if another source gave a definition more appropriate to PKI. If no reference is given, the definition is ad hoc.
access Ability to make use of any information system (IS) resource. [CNSS4009]
access control Process of granting access to information system resources only to authorized users, programs, processes, or other systems. [CNSS4009]
Activation Data - Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g., a PIN).
applicant The Subscriber is sometimes also called an "applicant" after applying to a certification authority for a certificate, but before the certificate issuance procedure is completed. [ABADSG footnote 32]
archive Long-term, physically separate storage.
audit Independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies, or procedures. [CNSS4009]
audit data Chronological record of system activities to enable the reconstruction and examination of the sequence of events and changes in an event. [CNSS4009, "audit trail"]
authentication Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information. [CNSS4009]
backup Copy of files and programs made to facilitate recovery if necessary. [CNSS4009]
binding Process of associating two related elements of information. [CNSS4009]
biometric A physical or behavioral characteristic of a person.
Certification Authority (CA) Administrator Information Technology administrators responsible for the operation of Root, Policy and Issuing CA services that deliver certificate services.
Certification Policy Management (CPM) group A body established to oversee the creation and update of Certificate Policies, review Certification Practice Statements, review the results of CA audits for policy compliance, evaluate non-domain policies for acceptance within the domain, and generally oversee and manage the PKI certificate policies.
Certification Authority (CA) An authority trusted by one or more users to create and assign certificates. [ISO9594-8]
Certificate A digital representation of information which at least (1) identifies the certification authority issuing it, (2) names or identifies its Subscriber, (3) contains the Subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the certification authority issuing it. [ABADSG]
Certification Policies and Practices Statement (CPS) - A document containing both the rules that indicate the applicability of a certificate to a particular community and/or class of application with common security requirements, as well as the practices that a certification authority employs in issuing certificates.
certificate-related information Information such as a Subscriber's postal address that is not included in a certificate, but that may be used by a CA in certificate management.
client (application) A system entity, usually a computer process acting on behalf of a human user, that makes use of a service provided by a server.
compromise Disclosure of information to unauthorized persons, or a violation of the security policy of a system in which unauthorized intentional or unintentional disclosure, modification, destruction, or loss of an object may have occurred. [CNSS4009]
confidentiality Assurance that information is not disclosed to unauthorized entities or processes. [CNSS4009]
cryptographic module The set of hardware, software, firmware, or some combination thereof that implements cryptographic logic or processes, including cryptographic algorithms, and is contained within the cryptographic boundary of the module. [FIPS1401]
cryptoperiod Time span during which each key setting remains in effect. [CNSS4009]
dual use certificate A certificate that is intended for use with both digital signature and data encryption services.
e-commerce The use of network technology (especially the Internet) to buy or sell goods and services
encryption certificate A certificate containing a public key that is used to encrypt or decrypt electronic messages, files, documents, or data transmissions, or to establish or exchange a session key for these same purposes. The process of storing protecting and escrowing the private component of the key pair associated with the encryption certificate is sometimes referred to as key management.
End entity - An entity that is a subscriber, a relying party, or both.
firewall Gateway that limits access between networks in accordance with local security policy. [CNSS4009]
Information System Security Analyst Person responsible to the designated approving authority for ensuring the security of an information system throughout its lifecycle, from design through disposal.
insider threat An entity with authorized access that has the potential to harm an information system through destruction, disclosure, modification of data, and/or denial of service. integrity Protection against unauthorized modification or destruction of information. [CNSS4009]
intellectual property Useful artistic, technical, and/or industrial information, knowledge or ideas that convey ownership and control of tangible or virtual usage and/or representation.
intermediate CA A CA that is subordinate to another CA, and has a CA subordinate to itself.
Issuing CA In a hierarchical PKI, the CA responsible for issuing certificates in accordance with set policies to computers, users and services within security domain.
key escrow The retention of the private component of the key pair associated with a Subscriber’s encryption certificate to support key recovery.
key exchange The process of exchanging public keys (and other information) in order to establish secure communication.
key generation material Random numbers, pseudo-random numbers, and cryptographic parameters used in generating cryptographic keys.
Local Registration Authority (LRA) A type of Registration Authority with responsibility for a local community.
non-repudiation Assurance that the sender is provided with proof of delivery and that the recipient is provided with proof of the sender's identity so that neither can later deny having processed the data. [CNSS4009]
Office of Information Technology (OIT) The Information Technology organization responsible for delivering computer and data processing services to State government.
Offline Not connected to the State of Maine production network, and instead connected to a physically isolated network.
Online Connected to the State of Maine production network.
outside threat An unauthorized entity from outside the domain perimeter that has the potential to harm an Information System through destruction, disclosure, modification of data, and/or denial of service.
physically isolated network A network that has no electronic connection to individuals outside a physically controlled space.
PKI Sponsor Fills the role of a Subscriber for non-human system components or organizations that are named as public key certificate subjects, and is responsible for meeting the obligations of Subscribers as defined throughout this document.
Policy CA In a hierarchical PKI, the CA whose policies govern the certificate services offered within the security domain.
privacy State in which data and system access is restricted to the intended user community and target recipient(s).
Public Key Infrastructure (PKI) Framework established to issue, maintain, and revoke public key certificates.
Registration authority (RA) - An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA).
Root CA In a hierarchical PKI, the CA whose public key serves as the most trusted datum (i.e., the beginning of trust paths) for a security domain.
re-key (a certificate) To change the cryptographic key that is being used in a cryptographic system application.
Relying Party A recipient of a certificate who acts in reliance on those certificates and/or digital signatures verified using those certificates. In this document, the terms "certificate user" and "relying party" are used interchangeably.
renew (a certificate) The act or process of extending the validity of the data binding asserted by a public key certificate by issuing a new certificate.
repository A trustworthy system for storing and retrieving certificates or other information relevant to certificates. [ABADSG]
risk An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result.
risk tolerance The level of risk an entity is willing to assume in order to achieve a potential desired result.
server A system entity that provides a service in response to requests from clients.
signature certificate A public key certificate that contains a public key intended for verifying digital signatures rather than encrypting data or performing any other cryptographic functions.
subordinate CA In a hierarchical PKI, a CA whose certificate signing key is certified by another CA, and whose activities are constrained by that other CA. (see superior CA)
Subscriber An entity that (1) is the subject named or identified in a certificate issued to such an entity, and (2) holds a private key that corresponds to a public key listed in that certificate. [ABADSG]. superior CA In a hierarchical PKI, a CA who has certified the certificate signing key of another CA, and who constrains the activities of that CA. (see subordinate CA)
system equipment configuration A comprehensive accounting of all system hardware and software types and settings.
technical non-repudiation The contribution public key mechanisms make to the provision of technical evidence supporting a non-repudiation security service.
threat Any circumstance or event with the potential to cause harm to an information system in the form of destruction, disclosure, adverse modification of data, and/or denial of service. [CNSS4009]
trust list Collection of Trusted Certificates used by relying parties to authenticate other certificates.
Trusted Agent (TA) Entity authorized to act as a representative of a Certificate Management Authority in performing Subscriber identity validation during the registration process. Trusted Agents do not have automated interfaces with Certification Authorities.
Trusted Certificate A certificate that is trusted by the Relying Party on the basis of secure, authenticated delivery. The public keys included in Trusted Certificates are used to start certification paths. Also known as a "trust anchor."
Trusted Timestamp A digitally signed assertion by a trusted authority that a specific digital object existed at a particular time.
two person control Continuous surveillance and control of positive control material at all times by a minimum of two authorized individuals, each capable of detecting incorrect and/or unauthorized procedures with respect to the task being performed and each familiar with established security and safety requirements. [CNSS4009]
update (a certificate) The act or process by which data items bound in an existing public key certificate, especially authorizations granted to the subject, are changed by issuing a new certificate.
zeroize A method of erasing electronically stored data by altering the contents of the data storage so as to prevent the recovery of the data. [FIPS1401]
State of Maine Government has a Certification Policy Management (CPM) group which is responsible for the selection/definition of certificate policies for the organization, approval of any cross-certification agreements with external CAs and review of this CPS to ensure consistency with industry and State of Maine Government corporate best practices. The CPM group is comprised of representatives from the Executive, Judicial, Legislative branches of State government and the Constitutional Officers. See the attached Memorandum of Understanding (MOU) between the State of Maine Government branches and constitutional offices for details regarding the CPM groups Governance Structure and Procedures.
The State of Maine Government OIT Enterprise Information Security Director (EISD) leads a Certificate Services Operations group that is responsible for interpretation of the certificate policies, creation and management of the CPS, and the correct operation of the State of Maine Government Public Key Infrastructure (PKI). Contact information for this entity is provided in section 1.4 below.
The State of Maine Government OIT Chief Technology Officer (CTO) is directly responsible for the day to day running of the PKI. This includes the CA Administrator (CAA) who interface with the system mainly for CA functions and the Certificate Managers who interface with the system mainly for Registration Authority (RA) functions.
This CPS is called the “State of Maine X.509 Certification Policies and Practices Statement”.
The State of Maine Government CAs issue certificates for use in the verification of digital signatures and certificates for use in encryption.
There are three levels of assurance in this policy, defined in subsequent sections. Each level of assurance is assigned an Object Identifier (OID), which is asserted in any certificate issued by a CA, where the CA complies with the certificate policy stipulations.
The OID registered by State of Maine Government for certificate policies are:
{iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) State of Maine Government (29494) PKI Policies (509) Certificate Policies (2)} = 1.3.6.1.4.1.29494.509.2.X
State of Maine Government-Rudimentary Assurance ID ::={id-certificate-policy 1}
State of Maine Government-Basic Assurance ID::={id-certificate-policy 2}
State of Maine Government-Medium Assurance ID::={id-certificate-policy 3}
State of Maine Government-High Assurance ID::={id-certificate-policy 4}
Table 0.1 Policy OID table
|
Certificate Policy |
Object Identifier (OID) |
Certificate Policy URL |
|
State of Maine Rudimentary |
1.3.6.1.4.1.29494.509.2.1 |
http://pki.maine.gov/Policies/rudimentary.html |
|
State of Maine Basic |
1.3.6.1.4.1.29494.509.2.2 |
http://pki.maine.gov/Policies/basic.html |
|
State of Maine Medium |
1.3.6.1.4.1.29494.509.2.3 |
http://pki.maine.gov/Policies/medium.html |
|
State of Maine High |
1.3.6.1.4.1.29494.509.2.4 |
http://pki.maine.gov/Policies/high.html |
The State of Maine Government PKI is established using the Microsoft family of products.
In the Microsoft architecture the CA is represented by an Offline Root CA, one or more offline Policy CAs, and at least one online Enterprise Issuing CA. The main administrative interface to Microsoft PKI is the MMC plug-in for Certificate Management. State of Maine Government administrators, who have special sets of privileges, to perform the CAA and RA functions in the State of Maine Government PKI, use this interface. These roles and associated privileges are:
n Certification Authority (CA) Administrator
· set the security policy for the CA, and alter it;
· add and delete other PKI management roles;
· authorize sensitive operations, such as adding and deleting CA Administrators, Certificate Managers and Recovery Agents;
· manage cross-certification agreements and issue, update and revoke cross-certificates;
n Certificate Manager:
· revoke user certificates;
· issue certificates
· Extract archived private keys from the CA database
n Registration Authority (RA)
· Performs identity validation for State of Maine Government Medium Assurance and State of Maine Government High Assurance certificates
· Combined with the Certificate Manager role.
n Auditor
· Define PKI auditing events
· Verify processes to maintain Windows Security event log and CA audit log entries for the life of the CA are reviewed by OIT Security Analysts
· Verify separation of duties as defined in this CPS is implemented
n Backup Operator
· Backup Certificate Services
· Restore Certificate Services
n Key Recovery Agents (KRA):
· Recover encrypted private keys provided by certificate managers from the CA database
· May not serve as CA Administrator or Certificate Manager.
State of Maine Government operates a three-tier CA hierarchy, which issues user , computer and service certificates to all State of Maine Government full-time employees, as well as to some part-time employees, contractors, vendors and business partners on an as required basis. State of Maine Government CA will issue cross-certificates to CAs operated by business partner, supplier and customer organizations as required to support State of Maine Government business processes and approved by the State of Maine Government CA.
Where necessary, this CPS distinguishes the different users and roles accessing Microsoft PKI for CA functions. Where this distinction is not required, the CA is used to refer to the total CA entity, including the software and its operations.
In this PKI, the Registration Authority (RA) is an integral function with online access to the Microsoft Issuing Certificate Authority. The OIT EISD is responsible for RA functions in this PKI for State of Maine Government including the processing of Medium Assurance and High Assurance certificates. Day to day operation of the RA is carried out by Certificate Managers from the Client Technologies and Enterprise Application Services. The RA makes use of Human Resources (HR) as an agent to verify the identity of end-entities. In this CPS, the OIT Security Analysts are responsible for verifying the identity or credentials of certificate requestors, and the Certificate Managers are responsible for implementing those requests within the CAs. and together comprise the RA functions,
End-entities in this PKI include all State of Maine Government full-time employees and some part-time employees, contractors, business partners, computers, and network devices. All end-entities are issued certificates by the State of Maine Government CA and as such are certificate subjects.
In addition, end-entities may use certificates issued by the State of Maine Government CA to encrypt information for, and verify the digital signatures of, other end-entities (within this CA domain as well as cross-certified domains). As such, end-entities are also relying parties in this PKI.
In this CPS, the term PKI user is used to represent users in general including their roles as subscribers (certificate subjects) and relying parties. No end-entities are only certificate subjects and no end-entities are only relying parties in the State of Maine Government infrastructure. Where separation of these roles is required in this CPS, the term subscriber is used to refer to a user as a certificate subject, while relying party is used to refer to a PKI user verifying certificates issued by this CA.
This CPS is applicable to all certificates issued by State of Maine Government CA. The practices described in the CPS apply to the issuance and use of certificates and Certificate Revocation Lists (CRLs) for users within the State of Maine Government CA domain as well as to the issuance and use of certificates for external cross-certified CAs.
The level of assurance associated with a public key certificate is an assertion by a CA of the degree of confidence that a Relying Party may reasonably place in the binding of a Subscriber's public key to the identity and privileges asserted in the certificate. Level of assurance depends on the proper registration of Subscribers and the proper generation and management of the certificate and associated private keys, in accordance with the stipulations of this policy. Personnel, physical, procedural, and technical security controls contribute to the assurance level of the certificates issued by a certificate management system.
This section contains definitions for the three levels of assurance implemented by State of Maine Government and guidance for their application.
State of Maine Government Basic Assurance.
To meet the State of Maine Government Basic Assurance certificate policy, the subject of the certificate must have been vetted by a hiring authority, such as the State Bureau of Human Resources, where as a minimum, the subject’s name, date of birth, address and other personal identifying information (e.g. social security number) was verified as prerequisite to the OIT account creation process. The subject’s knowledge of the associated user account and password is required for the automated issuance of the certificate. A certificate that uses the State of Maine Government Basic Assurance certificate policy is not intended for purchases or non-repudiation. The certificate may be used to prove that the original content is not modified, or that the user has access to any data encrypted with the private key.
The following certificate templates implement the State of Maine Government Basic Assurance certificate policy OID:
n State of Maine Government Email Signing
n State of Maine Government Email encryption
n State of Maine Government EFS
n State of Maine Government Wireless authentication and encryption
State of Maine Government Medium Assurance
To meet the State of Maine Government Medium Assurance certificate policy, the subject of the certificate must be identified in a face-to-face interview with the Registration Authority or its agent (e.g. OIT Security Analysts), where the subject presents photo identification. The photo identification must be one piece of federal-issued photo identification or two non-Federal government IDs, of which one shall be photo identification. with signature such as the State of Maine Government badge,
The registration authority (RA) will record the identification before issuing the certificate. The database is protected to ensure that the privacy information is protected.
A State of Maine Government Medium Assurance certificate and related private key are stored on the hard disk in the user’s profile. If export is enabled for these private keys, it is the responsibility of the subject to protect the private key material from theft.
The following certificates use the class
n Key Recovery Agent
n State of Maine Government EFS Recovery Agent
n State of Maine Government Enrollment Agent
To allow the verification of the subject, each of these certificate requests is pended until the RA verifies the identity of the subject.
State of Maine Government High Assurance
To meet the State of Maine Government High Assurance certificate policy, the subject of the certificate must be identified in a face-to-face interview with the Registration Authority or its agent (e.g. OIT Security Analysts), where the subject presents photo identification. The photo identification must be one piece of federal-issued photo identification or two non-Federal government IDs, of which one shall be photo identification. with signature such as the State of Maine Government badge,
The local registration authority (RA) will record the identification before issuing the certificate. The database is protected to ensure that the privacy information is protected.
A State of Maine Government High Assurance certificate and related private key are stored on a two-factor hardware device, such as a smart card. A smart card prevents export of the associated private key, and requires both access to the smart card and knowledge of the smart card’s PIN to access the private key.
The following certificates use the class
n State of Maine Government Initial Smart Card
n State of Maine Government Smart Card
n State of Maine Government Code Signing
To allow the verification of the subject, each of these certificate requests is pended until the RA verifies the identity of the subject.
This certificate policy supported by the State of Maine Government CA, and covered by this CPS, identifies the suitable applications (see below) for the policy.
In general terms, the combination of this policy and the associated certificates, can be used to protect State of Maine Government sensitive data including:
n Information provided to State of Maine Government by its business partners and subject to the terms of State of Maine Government's standard non-disclosure agreement;
n Product planning, design, development and testing documentation;
n Project and budget planning, tracking and reporting;
n Authentication information including user accounts and associated passwords;
n Personnel information including position, salary, benefits, health;
n Investment and analytical knowledge stored in data warehouses;
n Electronic messages and transactions including, but not limited to, EDI, e-mail, Web servers, etc.
All network, file and email applications utilizing encryption and digital signature security services are approved for use under this CPS.
Only wireless network applications utilizing encryption for use with certificate services are currently authorized for deployment under this CPS.
Certificates issued under this CA are to be used for official State of Maine business and any other application or use of them is prohibited under this CPS.
This CPS is administered by the State of Maine Government PKI Operational Authority and is based on the policies established by the State of Maine Government PKI Policy Authority.
The contact details for this CPS and PKI are:
Enterprise Information Security Director
Office of Information Technology
145 State House Station
Augusta, ME 04333-0145
As the CA and RA functions are both provided by State of Maine Government, the liability issues related to both functions are combined in this CPS.
State of Maine Government warrants and promises to:
n Provide certification and repository services consistent with the certificate policies identified in section 1.2 of this CPS and with this CPS itself;
n Perform the authentication and identification procedures for the certificate policies identified in section 1.3.4.2 of this CPS and the procedures defined in section 3 of this CPS;
n Provide key management services including certificate issuance, publication, revocation, and update in accordance with the certificate policies referenced in section 1.3.4.2 of this CPS and with this CPS;
n Comply with all provisions in section 2 of this CPS and legal provisions in the certificate policy referenced in section 1.3.4.2 of this CPS.
State of Maine Government is not liable for any loss:
n of CA or RA service due to war, natural disasters or other uncontrollable forces;
n incurred between the time a certificate is revoked and the next scheduled issuance of a CRL;
n due to unauthorized use of certificates issued by the State of Maine Government and use of certificates and this CPS;
n caused by fraudulent or negligent use of certificates and/or CRLs issued by the State of Maine Government CA;
n due to disclosure of the certificate subjects name contained within certificates and revocation lists.
n And The State of Maine claims immunity under the Tort Act, which limits all claims.
A non-State of Maine subscriber or entity, relying parties, RAs and cross-certified CAs will have no claim against the State of Maine arising from or relating to any certificate issued by the State of Maine Government CA or the CMA’s determination to terminate a certificate. The State of Maine is not liable for any losses, including direct or indirect, incidental, consequential, special, or punitive damages.
No stipulation - this section intentionally left blank.
The State of Maine Government CA is obliged to:
n Provide CA services on a 7 day per week, 24 hour per day basis in accordance with the policies and processes described in this CPS;
n Issue certificates to State of Maine Government employees, contractors and business partners, and to other CAs, in accordance with the certificate policies referenced in section 1.2 of this CPS as well as the procedures and practices described in this CPS;
n Revoke certificates, which are issued by this CA, upon receipt of a valid request to do so from either the subscriber who is the subject of the certificate to be revoked, an RA or the CA itself, in accordance with the stipulations of the relevant certificate policy as well as those in section 2.8.3 of this CPS;
n Issue and publish CRLs on a regular schedule as per section 4.4 of this CPS;
n Notify subscribers that certificates have been issued to them or that their digital signature verification certificate has been revoked;
n Notify others (e.g., relying parties) of certificate issuance/revocation by provision of access to certificates and CRLs in the State of Maine Government PKI repository.
The State of Maine Government RA is obliged to verify the accuracy and authenticity of the information provided by subscribers at the time of application for a certificate.
n The RA may make use of the following Trusted Agents in providing this verification on behalf of the State of Maine Government CA:
n The State of Maine Government, Bureau of Human Resources (HR), to verify the data on employees by comparing it with information in the employee database
n The State of Maine Government, Bureau of Purchases, to verify the data on contractors by comparing it with information in the State of Maine database repository, and
n The State of Maine Government Business Unit Managers, to verify the identity of subscribers and to the authenticity of subscriber information.
OIT operates the only RA and retains sole access to the PKI system for registration of subscribers. However, OIT may delegate the subscriber authentication (to verify that subscribers are who they say they are) and authorization (to approve the subscribers' use of this service) parts of the RA function to Human Resources, Purchases and Business Unit Managers who act as Trusted Agents. OIT EISD maintains the list of Trusted Agents and may, at its discretion, periodically check any and all information against the HR or Accounting & Payroll databases.
For all State of Maine Government associate and business partner subscribers, the State of Maine Government Business Unit Manager in the local office may perform the identity verification portions of the RA function. The State of Maine Government Business Unit Manager has the authority and responsibility to authorize OIT to deliver a digital certificate to such subscribers. This Manager notifies OIT of the subscriber's registration information, start date, and end date (if known) so that the subscriber can be set up in advance. The subscriber is enabled on the start date, unless otherwise notified by the Manager. If an end date is supplied, the subscriber will be disabled on that date, unless otherwise notified by the Business Unit Manager. The Manager retains the responsibility for notifying OIT of a need to revoke of a certificate and of any changes to the subscriber's information or status. If the associate or business partner relationship is terminated, the Business Unit Manager must notify OIT within 24 hours.
In the case of contractor and vendor subscribers, the State of Maine Government Business Unit Manager in the local office may perform the identity verification portions of the RA function. The subscriber must appear in person to this Manager with two pieces of identification (e.g., valid driver's license, company business card, State of Maine Government-issued badge) at the time of application for a certificate. The State of Maine Government Business Unit Manager has the authority to authorize OIT to deliver a digital certificate to such subscribers and to specify a validity period. The Business Unit Manager retains the responsibility for notifying OIT of a need to revoke of a certificate and of any changes to the subscriber's information or status. If the business relationship with the subscriber is terminated, the Manager must notify OIT within 24 hours.
In the State of Maine Government CA domain all PKI users are both subscribers and relying parties.
In this CA domain, PKI users, as subscribers, are obligated to:
n Make true representation at all times to both the State of Maine Government CA and RA regarding information in their certificates and other identification and authentication information;
n Use certificates exclusively for legal and authorized State of Maine business
n Protect their private decryption key and private signing key by storing them either on their hard drive protected by a password or other PC security mechanism, or on a disk and storing that disk separately from their computer when not in use;
n Protect their user password, by not writing it down or by storing a written copy in a locked file to which only that user has access;
n Inform OIT within 72 hours of a change to any information included in their certificate or certificate application request;
n Inform OIT within 1 hour of detecting a suspected compromise of one/both of their private keys;
n Read, sign and return the Subscriber Agreement Form upon receipt of the software and digital certificate.
In the State of Maine Government CA domain all PKI users are both subscribers and relying parties. In this CA domain, PKI users, as relying parties, are obligated to:
n Restrict reliance on certificates issued by the State of Maine Government CA to appropriate uses for those certificates, in accordance with this CPS;
n Verify certificates, including use of CRLs, in accordance with the certification path validation procedure specified in ITU-T Rec. X.509:1997 I ISO/IEC 9594-8 (1997), taking into account any critical extensions;
n Trust and make use of certificates only if a valid certificate chain is established between the relying party and the certificate subject.
No stipulation - this section intentionally left blank
Issuance of certificates by State of Maine Government CA and assistance in that issuance by State of Maine Government RA does not make State of Maine Government or its CA or RA an agent, fiduciary, trustee, or other representative of subscribers or relying parties.
Applicable federal and State laws govern the operation of the State of Maine Government CA.
Severance or merger may result in changes to the scope, management and/or operations of this PKI. In such an event, this CPS may require modification as well. Changes to the operations will occur in a manner consistent with the administrative requirements stipulated in section 8 of this CPS, either event will result in a key update for of all PKI users within the current scope of State of Maine Government.
Within the State of Maine Government CA domain, disputes between PKI users, one of which acts in the role of a subscriber and the other which acts in the role of a relying party, or between users and the CA or RA, must be reported to State of Maine Government OIT EISD for resolution.
No direct fees will be assessed by the State of Maine Government CA. Inter-business unit cost recovery between the OIT operating the CA service and the other business units within State of Maine Government are consistent with cost recovery for other OIT-provided services. In cross-certification agreements with business partner organizations, the costs are expected to balance naturally between State of Maine Government and the business partner organization. Any exceptions, which may result in additional fees for any of the services outlined in this section and its subsections, will be addressed in the specific cross-certification agreement itself and are outside the scope of this CPS.
No stipulation - this section intentionally left blank.
No stipulation - this section intentionally left blank.
No stipulation - this section intentionally left blank.
No stipulation - this section intentionally left blank.
No stipulation - this section intentionally left blank.
This detailed CPS is not published publicly, but a high level subset is available on the State of Maine Government Intranet for access by State of Maine Government employees. Paper copies are made available to CAs with cross-certification agreements in place with the following PKI information that is published in the State of Maine Government directory:
n All encryption public key certificates issued by the State of Maine Government CA to PKI users;
n All cross-certificates issued by the State of Maine Government CA to the CAs of business partner organizations;
n All revocations of PKI user public key certificates performed by the State of Maine Government CA;
n All revocations of cross-certificates performed by the State of Maine Government CA.
The specific directory entries used to publish this PKI information in the State of Maine Government directory, and the associated schema definitions, are outlined in the subsections below. The definitions include standard schema elements as defined in the X.500 Series of Recommendations (1997 edition) as well as some enhancements defined using the tools provided by the X.500 Series of Recommendations for that purpose.
This CPS is reissued and published in accordance with the policy defined in section 8 of this CPS.
Certificates are published in the directory as they are issued.
CRLs are published in the directory as they are issued. The frequency of CRL issuance is discussed in section 4.4.2.1 of this CPS.
All employees, contractors and business partners of State of Maine Government, who have been issued certificates by the State of Maine Government CA, have access to the version of this CPS on the State of Maine Government Intranet.
All CAs of State of Maine Government's business partner organizations with whom this CA has cross-certification agreements will be provided with paper copies of this CPS.
With respect to the PKI information published in the directory, the State of Maine Government PKI CA Administrators, Certificate Managers and subscribers will have sufficient access permissions on entries to appropriately allow them to:
n For CA entries:
· Add, modify and delete all PKI attributes in its own directory entry and to
· Add, modify and delete all values of these attributes.
n For CRL distribution point entries:
· Create, modify and delete entries of structural object class CRL-Distribution-Point immediately subordinate to its own entry and to
· Add, modify and delete all attributes, and all values of the PKI attributes.
n For PKI user entries:
· Add and delete user attributes of all entries representing prospective users and to
· Add, modify and delete the attribute user Certificate and all values of that attribute to/from these entries.
The repository for this CA is provided by Active Directory. The protocol used to access the directory is the Lightweight Directory Access Protocol (LDAP) version 2, as specified in Internet RFC 1777. LDAP v2 over TCP transport, as defined in Section 3.1 of RFC 1777 is used.
When conveyed in LDAP requests and results, attributes defined in X.500 are encoded using string representations defined in RFC 1778, "The String Representation of Standard Attribute Syntaxes". These string encodings were based on the attribute definitions from X.500 (1988). Thus, the string representations of:
n User Certificate (RFC 1778 section 2.25)
n CA Certificate (RFC 1778 section 2.26)
n Certificate Revocation List, (RFC 1778 section 2.28), and
n Cross Certificate Pair, (RFC 1778 section 2.29)
Since this PKI uses version 3 certificates and version 3 revocation lists, as defined in X.509 (1997), the RFC 1778 string encoding of these attributes is inappropriate. For this reason, these attributes are encoded using syntax similar to the syntax Undefined from section 2.1 of RFC 1778: values of these attributes are encoded as if they were values of type OCTET STRING, with the string value of the encoding being the DER-encoding of the value itself.
An audit of the State of Maine Government PKI operations is performed annually.
The Audit Department of the State of Maine Government, which is responsible for all audits of State of Maine Government processes, provides for the execution of the annual audits. The Audit Department may delegate this role to the Bureau of Accounts & Controls and review the results.
The internal auditor (State of Maine Government Accounts & Controls), State Auditor (State of Maine Government Audit Dept) and the audited party (OIT) are separate business units within the State of Maine Government corporate structure.
The annual audit investigates the operations of the CA and RA functions of the State of Maine Government PKI to ensure their compliance with this CPS and with other applicable PKI procedures. Some areas of focus for these audits include, but are not limited to:
Management of the service, e.g., user authentication and registration, security administration access control, configuration management, exception reporting and review, contingency planning
n operations, e.g., trouble calls, system backup
n software functionality, e.g., key management
n hardware platform, e.g., secure operating system, robustness
n physical security, e.g., computer room access
There are three possible actions to be taken as a result of identification of a deficiency:
n continue to operate as usual
n continue to operate but at a lower assurance level
n suspend operation
If a deficiency is identified, the State of Maine Government Certification Policy Management (CPM) group, with input from the auditor, will determine which of these actions to take.
If action a or b is taken, the State of Maine Government CPM is responsible for ensuring that corrective actions are taken within 30 days from final issuance of the report. At that time, or earlier if agreed by the CPM and auditor, the audit team will reassess. If, upon reassessment, corrective actions have not been taken, the CPM in conjunction with the auditor will determine if more severe action (e.g., action c above) is required.
If action c is taken, all certificates issued by the State of Maine Government CA, including end-user certificates and CA cross-certificates, are revoked prior to suspension of the service. The State of Maine Government EISD is responsible for reporting the status of corrective action to the auditors on a weekly basis. The CPM and auditor together will determine when the reassessment is to occur. Upon reassessment, if the deficiencies are deemed to have been corrected, the
State of Maine Government CA will resume service and new certificates will be issued to PKI users and other external CAs, depending on conditions specified in individual cross-certification agreements.
Results of the annual audit are provided to the State of Maine Government CPM, Chief Information Officer (CIO), as well as the CTO and EISD. In the case of action (b), the State of Maine Government CPM will determine if PKI users need to be informed of the action. In the case of action (c), the State of Maine Government CPM will ensure all PKI users are informed of the action. Communication to users to inform them of any deficiency and action is performed via email.
Cross-certification agreements set up with business partner organizations may also dictate that cross-certified CAs are informed of any deficiencies. Unless specified in a particular cross-certification agreement, no communication of the audit results will occur outside State of Maine Government. Should external cross-certified CAs need to be informed, the State of Maine Government EISD will communicate the necessary information to the contact point in each of the cross-certified CA domains.
All information that is not considered by the State of Maine Government CPM to be public domain information is to be kept confidential. Some specifics are addressed in the subsections below.
Each PKI user's private signing key is confidential to that user. The CAA and RA are not provided any access to those keys.
Information held in audit trails is considered confidential to State of Maine Government and shall not be released outside the State of Maine, unless required by law.
Personal and state government information held by the State of Maine Government CA and RA, other than that which is explicitly published as part of a certificate, CRL or this CPS is considered confidential and shall not be released unless required by law.
Generally the results of annual audits are kept confidential, with exceptions as outlined in section 2.7 of this CPS.
Information included in certificates and CRLs issued by the State of Maine Government CA is not considered confidential.
Information in the certificate policies supported by this CA, and identified in section 1.2 of this CPS, is not considered confidential.
Information in this CPS itself is not considered confidential, however State of Maine Government policy requires that it only be made available to users of this PKI, including those in cross-certified CA domains.
Confidentiality of information in the State of Maine Government Certification directory is dependent on the particular data items and applications. Confidentiality of relevant information in the directory is achieved through the use of access controls.
When the State of Maine Government CA revokes a certificate, a revocation reason is included in the CRL entry for the revoked certificate. This revocation reason code is not considered confidential and can be shared with all other users and relying parties. However, no other details concerning the revocation are normally disclosed.
As the State of Maine Government CA does not suspend certificates, disclosure of suspension information is outside the scope of this CPS.
As with other services within State of Maine Government, the State of Maine Government CA will comply with legal requirements to release information to law enforcement officials, consistent with State of Maine Government policy.
The State of Maine Government CA will release this CPS as authorized by law.
Certificates and CRLs issued by the State of Maine Government CA are the property of State of Maine Government.
The Distinguished Names (DNs) used to represent entities within the State of Maine Government CA domain in the Active directory and in certificates issued to end-entities within that domain, all include a Relative Distinguished Name (RDN) for State of Maine Government and as such are the property of State of Maine Government.
With respect to the CA system, the software, including any related copyright, trademark, and patent rights, is owned by Microsoft and will remain the sole and exclusive property of Microsoft.
Sections 3.1.1 - 3.1.4 of this CPS cover names within State of Maine Government only. Cross certificates are issued to CAs, identified by their DN, however the value of those names and responsibility for them is outside the scope of this CPS.
Names for certificate issuers and certificate subjects are of the X.500 Distinguished Name (DN) form. “State of Maine Government” is a registered object name in accordance with ANSI, the U.S. national registration authority. A single naming hierarchy is established within State of Maine Government as outlined below.
Certificates may contain other name forms, such as User Principal Names (UPN) or RFC 822 Names, but these names must be included in the Subject Alternative Name attribute of the certificate, rather than the Subject attribute.
The value of the common Name attribute used in naming State of Maine Government employees and contractors is when ever possible the name by which the Associate is registered with the State of Maine Government Bureau of Human Resources or external hiring authority and is not necessarily the name (e.g., nickname) by which they may be commonly known within the organization. The value of the serial Number attribute used in naming State of Maine Government employees and contractors is not the State employee number assigned to the associate at the time of hiring.
DNs and their component RDNs are to be interpreted as defined in sections 3.1.1 and 3.1.2 of this CPS. Additional alternative name forms, if present, are to be interpreted in accordance with rules identified by the issuing name authority.
Names are unambiguously defined for each object in the naming hierarchy. The serial Number attribute (i.e., the Globally Unique Identifier (GUID) sequence number as part of a unique identifier) is used to ensure that no two individuals are assigned the same DN, and therefore the same electronic identity. Values of the serial Number attribute are never reused.
The State of Maine Government CA is ultimately responsible for resolution of any name claim disputes within State of Maine Government. Since both the common Name and serial Number attributes are used to create the RDNs for employees, such disputes are expected to be rare.
The State of Maine Government CA/RA authenticates names of employees and other entities within the State of Maine Government organization. Although the State of Maine Government CA will establish cross-certification with other CA domains, the naming and trademark issues associated with those names within those domains is outside the scope of this CA domain and this CPS.
In all cases where the Subscriber generates keys, the Subscriber shall be required to prove, to the certificate manager, possession of the private key which corresponds to the public key in the certificate request. For signature keys, this may be done by signing the request.
In the case where key is generated directly on the Subscriber's token, or in a key generator that benignly transfers the key to the Subscriber's token, then the Subscriber is in possession of the private key at the time of generation or transfer. If the Subscriber is not in possession of the token when the key is generated, then the token shall be delivered to the Subscriber via an accountable method (see Section 6.1.2).
For all assurance levels, when keyed hardware tokens are delivered to Subscribers, the delivery shall be accomplished in a way that ensures that the correct tokens and activation data are provided to the correct Subscribers. The certificate manager must maintain a record of validation for receipt of the token by the Subscriber. When any mechanism that includes a shared secret (e.g., a password or pin) is used, the mechanism shall ensure that the applicant and the certificate manager are the only recipients of this shared secret.
The State of Maine Government CA issues cross-certificates to the CAs of business partner organizations. As there are usually existing business agreements between State of Maine Government and the organization to be cross-certified, additional authentication of the identity of the organization is not generally required. If the State of Maine Government CPM determines that there is a need for further authentication, this is handled either by searches of recognized databases of registered corporations, or by presentation of the organization's articles of incorporation to the State of Maine Government EISD. In all cases, the authentication documentation is filed and archived by the State of Maine Government EISD.
The responsibility for authentication of all subscribers' identities resides with the RA. The RA may issue Basic Assurance Certificates, for any user accounts within the State of Maine Active Directory (LDAP) that have been or are authorized by the Trusted Agents such as HR or Business Unit Managers through established processes. The RA must receive a digitally signed email message or signed letter or memorandum from State Human Resources or external hiring authority for individuals who are assigned a Medium or High Assurance Certificates. Additionally, for contractors and vendors, a validity period must be specified.
In the case of State employees, if they have already presented themselves in person and been verified as part of the existing hiring processes; no further documentation is required.
In the case of business partners, if there are pre-established business relationships and the subscriber is personally known to the RA; limited record identity verification may be needed to document their status.
In the case of contractors and vendors, the RA must authenticate them subject to the validation requirements of the specific certificate policy required by the issued certificate.
State of Maine Government employees and business partners are updated automatically by using auto-enrollment. Prior to expiration of the current key pairs, Group Policy invokes auto-enrollment and the user's keys are updated transparently in the case of State of Maine Government Basic Assurance certificates and by requiring the user to sign their renewal request with their previous certificate’s private key in the case of a State of Maine Government High Assurance certificate. In these cases, authentication of the individual's identity as defined in section 3.1.9 of this CPS need not be repeated.
For State of Maine Government Medium Assurance certificates, the certificate requestor must apply for the new certificate by following the same certificate enrollment process used for the initial certificate request.
For users whose certificates have been revoked, rekey will generally not be permitted until the identification and authentication requirements for initial registration described in section 3.1.9 of this CPS are repeated. RAs may allow exceptions in the following situations:
n An organizational change within State of Maine Government results in changes to the DNs of several employees.
n A PKI user is temporarily unable to present him/herself in person (e.g., on extended travel) and the revocation was not due to a key compromise.
n A certificate was revoked by CA administrative action for reasons not related to adverse subscriber actions or key compromise.
Requests to revoke a certificate require a certificate manager credentials to service the revocation requests. Requests by the subscriber to revoke his/her own certificate require one of the following identification and authentication mechanisms as part of initiating a request:
n Subscriber presents him/herself in person to a RA agent along with their State of Maine Government photo badge;
n Digitally signed email sent from the subscriber to a certificate manager.
Requests to revoke a subscriber’s certificate may be made by the responsible Business Unit Manager by sending a digitally signed email or signed letter or memorandum from the Business Manager to the RA agent or certificate manager.
It is the intent of this Policy to identify the minimum requirements and procedures that are necessary to support trust in the PKI, and to minimize imposition of specific implementation requirements on certificate managers, Registration Authorities, Subscribers, and relying parties.
The applicant and the Registration Authority must perform the following steps when an applicant applies for a certificate:
n Establish and record the identity of Subscriber;
n Obtain a public/private key pair for each certificate required;
n Establish that the public key forms a functioning key pair with the private key held by the Subscriber;
n Provide a point of contact for verification of any roles or authorizations requested.
These steps may be performed in any order that is convenient for the certificate manager and Subscribers, and that does not defeat security; but all must be completed prior to certificate issuance.
Public keys shall be delivered to the certificate issuer in a way that binds the applicant’s verified identification to the public key being certified. This binding shall be accomplished using means that are as secure as the security offered by the keys being certified
In those cases where public/private key pairs are generated by the Smart card enrollment agent on behalf of the subscriber, the certificate manager 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, and that the token is not activated prior to receipt by the proper Subscriber.
Upon receiving the request of a State of Maine Government Medium Assurance or State of Maine Government High Assurance certificate, the Registration Authority will:
n verify the identity of the requestor;
n verify the authority of the requestor and the integrity of the information in the certificate request;
For State of Maine Government Basic Assurance certificates, the issuance of the certificate will depend entirely on the discretionary access control list (DACL) assigned to the requested certificate template. If the requestor has the correct permissions in the DACL, the certificate is issued.
4.2.1 Delivery of Subscriber's private key to Subscriber
In most cases, a private key will be generated and remain within the cryptographic boundary of a cryptographic module. If the owner of the module generates the key locally, then there is no need to deliver the subscriber's private key. If the key is generated on a smart card elsewhere, then the smart card must be delivered to the Subscriber. Accountability for the location and state of the smart card must be maintained until the Subscriber is in possession of it. The Subscriber shall acknowledge receipt of the smart card.
Private keys associated with State of Maine Government Basic Assurance and State of Maine Government Medium Assurance certificates may be generated and stored in software cryptographic modules. When the Subscriber generates these keys locally, there is no need to deliver them. Only those authorized by the State of Maine Government key recovery policy may access private keys associated with encryption certificates.
The PKI and the relying parties must work together to ensure the authenticated and integral delivery of Trusted Certificates. Acceptable methods for Trusted Certificate delivery include but are not limited to:
n Deployment of certificates through Active Directory to all Windows 2000 and higher clients in the forest;
n Secure distribution of Trusted Certificates through secure out-of-band mechanisms;
n Download of Issuing CA certificates from Authority Information Access (AIA) information in the issued certificates.
Before a CA allows a Subscriber to make effective use of its private key, a member of the OIT Certificate Services technical team (e.g. CA Administrator, Certificate Manager, and Registration Authority) shall
n Explain to the Subscriber its responsibilities as defined in Section 2.2.3;
n Inform the Subscriber of the issuance of a pending certificate when requesting a State of Maine Government Medium Assurance certificate;
n Require the Subscriber to indicate acceptance of its obligations and its certificate, with either a digital or handwritten signature; and
n Document the Subscriber's acceptance of its responsibilities and its certificate.
The ordering of this process, and the mechanisms used, will depend on factors such as where the key is generated and how certificates are posted. In the case of non-human components (router, firewalls, etc.), the manager of the device shall perform the functions of the Subscriber.
Certificates issued to users will be revoked before the expiration of the certificate validity period in the following circumstances:
n Any time that the associated user or computer account is expired or deleted. If a user or computer account is expired or deleted, the State of Maine Government account modification process must be modified to include revocation of any associated certificates. If the user account is disabled for a period of time in excess of 30 days, all issued certificates must be revoked and reissued when the user account is enabled. Use the revocation reason code of Change of Affiliation when revoking the certificate.
n An employee voluntarily resigns. If an employee terminates their employment at State of Maine Government, the user account must be disabled and all certificates issued to the user will be revoked within 30 days unless re-employed. Use the revocation reason code of Change of Affiliation when revoking the certificate.
n An employee is terminated. If an employee is terminated for any reason, the user account must be disabled and the certificates issued to the user will be immediately revoked. Use the revocation reason code of Change of Affiliation when revoking the certificate.
n Change of PKI-related administrative role. If a user’s responsibilities are changes so that they no longer hold a PKI-related administrative role, such as an enrollment agent, the PKI administrative certificate must be immediately revoked. Use the revocation reason code of Cease of Operation when revoking the certificate.
n An employee retires. If an employee retires from the State of Maine Government or any associated government entities that receive certificates from the State of Maine Government PKI, the user account must be disabled and the certificates issued to the employee will be terminated within 30 days of the time of retirement unless re-employed. Use the revocation reason code of Change of Affiliation when revoking the certificate.
n An employee is suspended. If an employee is suspended, the user account must be disabled and all certificates issued to the user must be revoked if the employee is not reinstated within 30 days. If an employee returns after an extended suspension, new certificates must be issued to the user. Use the revocation reason code of Change of Affiliation when revoking the certificate.
n An employee is on an extended leave of absence. If an employee is on an extended leave of absence, the user account must be disabled and all certificates issued to the user must be revoked if the employee does not return to work within 90 days. If an employee returns after an extended leave of absence in excess of 90 days, new certificates must be issued to the user. Use the revocation reason code of Change of Affiliation when revoking the certificate.
n An employee dies. If dies an employee passes away, the user account must be disabled and all certificates issued to the employee must be revoked within 30 days. Use the revocation reason code of Change of Affiliation when revoking the certificate.
n Reorganization of a government unit. If a unit of State of Maine Government is reorganized into a new entity that changes its constitutional reporting relationship (Executive, Judicial, Legislative branches of government or Constitutional Officers or independent Boards & Commissions, the certificates issued by the State of Maine Government PKI must be revoked. Use the revocation reason code of Change of Affiliation when revoking the certificate.
n A computer is stolen. If a computer is stolen, the computer account must be disabled and all certificates issued to the computer and to the users of the computer must be immediately revoked. Use the revocation reason code of Key Compromise when revoking the certificate.
n A Certification Authority is compromised. If a Certification Authority (CA) computer is compromised, all certificates issued by that CA, and the CAs subordinate to that CA in the CA hierarchy are considered compromised. The CA certificate must be revoked with a revocation reason of CA compromise.
n A smart card or other two factor device is lost or misplaced. If a smart card is lost, the holder of the smart card must report the smart card as missing to the IT Customer Support Center. When notice is received, the smart card must be revoked with a revocation reason of key compromise.
n A computer is replaced. If a computer is replaced or reloaded in such a manner that the computer name changes or if the identity of issued certificate is impacted, the computer account must be disabled and all certificates issued to the computer account must be revoked within 30 days with a revocation reason of Superseded certificate. However, if the computer is being rebuilt with the same name or the user profile becomes corrupt, there is no need to revoke the certificate. The only exception is a CA computer. The previous certificate and key pair must be restored to the replacement CA. Use the revocation reason code of Superseded when revoking the certificate.
n A certificate template is deleted or updated requiring redeployment of certificates. If a certificate template is deleted or updated, all previous certificates based on the previous version must be revoked, allowing replacement by the modified certificate template. Use the revocation reason code of Superseded when revoking the certificate.
n Contract is no longer valid. If an individual contractor is no longer serving under a valid State of Maine contract, any related certificates must be revoked within 30 days. Use the revocation reason code of Change of Affiliation when revoking the certificate.
Within the PKI, a Certificate Manager may summarily revoke certificates within its domain. A written notice and brief explanation for the revocation shall subsequently be provided to the Subscriber.
Any format that is used to request a revocation shall identify the certificate to be revoked, explain the reason for revocation, and allow the request to be authenticated (e.g., digitally or manually signed). A Certificate Manager action is required for revocation (a Subscriber may not, via an automated process, revoke its own certificate). Authentication of certificate revocation requests is important to prevent malicious revocation of certificates by unauthorized parties.
Upon receipt of a revocation request from the Subscriber or another authorized party, the certificate manager shall authenticate the revocation request. The certificate manager may, at its discretion, take reasonable measures to verify the need for revocation. If the revocation request appears to be valid, the certificate manager shall revoke the certificate by placing its serial number and other identifying information on a CRL.
For PKI implementations using hardware tokens, Subscribers leaving organizations that sponsored their participation in the PKI shall surrender to their certificate manager (through any accountable mechanism) all cryptographic hardware tokens that were issued under the sponsoring organization prior to leaving the organization.
There may limited grace periods, as defined above, for revocation under this policy; CAs will revoke certificates as quickly as practical upon receipt of a proper revocation request as detailed in section 4.4.1.
CRLs are periodically issued and posted to a repository, even if there are no changes or updates to be made, to ensure timeliness of information. CRLs may be issued more frequently than required; if there are circumstances under which a CA will post early updates, these shall be spelled out in its CPS. CAs shall ensure that superseded CRLs are removed from the repository upon posting of the latest CRL.
The following publication intervals are used for CRL publication:
n Offline CA will publish base CRL information every 26 weeks. No delta CRLs will be published for offline CAs.
n Online CAs will publish base CRLs at least every three days and delta CRLs will be published at least daily to allow earlier detection of revoked certificates by client computers and applications that support delta CRLs.
Use of revoked certificates could have damaging or catastrophic consequences in certain applications. State of Maine Government will configure all applications, where possible, to enforce strong CRL checking. In this configuration, if an application is unable to obtain revocation information, the application must reject the certificate until such time as the authenticity of the certificate can be determined.
This section describes the security auditing requirements for the State of Maine Government PKI.
For all CAs in the CA hierarchy, the following information is logged in the Windows Security Event log:
n Back up and restore the CA database
n Change CA configurations
n Change CA security settings
n Issue and manage certificate requests
n Revoke certificates and publish CRLs
n Store and retrieve archived keys
n Start and stop Certificate Services
In addition, logging is enabled at all HSM devices so that all HSM transactions are recorded in the system log of the HSM.
For offline CAs, security audit data review is only required for cause. For online CAs, at least 12 (monthly) reviews are required per year, with at least 33 percent of the security audit data generated since the last review to be examined.
The CA Administrators shall implement procedures to ensure that the security audit data is transferred prior to overwriting or overflow of automated security audit log files.
The information generated on the CA equipment shall be kept on the CA equipment until the information is moved to an appropriate archive facility. Deletion of the security audit data from the certificate manager equipment shall be performed only by auditors. Security audit data shall be retained as archive records in accordance with Section 4.6.2.
For online CAs, the security audit data shall not be open for reading or modification by any human, or by any automated process other than those that perform security audit processing. The entity performing security audit data 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 security audit data retention period (note that deletion requires modification access). Security audit data shall be moved to a safe, secure storage location separate from the certificate manager equipment.
The security audit data backup shall be protected in accordance with the requirements of Section 4.5.4.
The security audit process shall run independently and shall not in any way be under the control of the certificate manager. Security audit processes shall be invoked at system startup, and cease only at system shutdown. Should it become apparent that an automated security audit system has failed, the CA shall cease all operation except for revocation processing until the security audit capability can be restored. Under these circumstances, the CA administrator shall employ mechanisms to preclude unauthorized certificate manager functions. These mechanisms shall be described in the State of Maine Government CPS.
There is no requirement to notify a subject that an event was audited. Real-time alerts are neither required nor prohibited by this policy.
The Certificate Managers, CA Administrators, and other Certificate Services technical team personnel shall be watchful for attempts to violate the integrity of the PKI certificate services system, including the equipment, physical location, and personnel. The security audit data shall be reviewed by the security auditor for events such as repeated failed actions, requests for privileged information, attempted access of system files, and unauthenticated responses. The OIT Security Analyst shall check for continuity of the security audit data.
Certificate Manager archive records shall be detailed enough to establish the validity of a signature and of the proper operation of the PKI.
4.6.2 Retention period for archive
Archive records shall be kept for a period of
n at least ten years for offline CAs; and
n at least five years for online CAs;
without any loss of data. Applications necessary to read these archives must be maintained for at least the applicable retention period above.
No unauthorized CA equipment operator shall be able to modify or delete the archive, but archived records may be moved to another medium. 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. No transfer of medium shall invalidate certificate manager applied signatures. The certificate manager shall maintain a list of people authorized to modify or delete the archive, and make this list available during CPS compliance audits.
No stipulation - this section intentionally left blank
Archive data may be collected in any expedient manner.
Procedures detailing how to create, package and send the archive information shall be published in a CA procedures handbook or CPS. Only authorized CA equipment operators will be allowed to access the archive.
A CA uses a signing (private) key for creating certificates; however, relying parties employ the CA certificate for the life of the Subscriber certificate beyond that signing. Therefore, CAs must not issue Subscriber certificates that extend beyond the expiration dates of their own certificates and public keys, To minimize risk to the PKI through compromise of a CAs key, the private signing key will be changed more frequently, and only the new key will be used for certificate signing purposes from that time. The older, but still valid, certificate will be available to verify old signatures until all of the Subscriber certificates signed under it have also expired. If the old private key is used to sign CRLs that contain certificates signed with that key, then the old key must be retained and protected.
In case of a CA key compromise, a superior CA shall revoke that CA’s certificate, and the revocation information shall be published immediately in the most expedient manner. Subsequently, the CA installation shall be reestablished as above. If the CA is a Root-CA, the trusted self-signed certificate must be removed from each Relying Party application, and a new one distributed via Active Directory and other secure out-of-band mechanisms.
All CAs are required to maintain a Disaster Recovery Plan. This plan is to be submitted to the EISD for approval at the same time as the CPS. In the case of a disaster in which the CA equipment is damaged and inoperative, the CA operations shall be reestablished as quickly as possible, giving priority to the ability to revoke Subscriber's certificates. If the CA cannot reestablish revocation capabilities within one week, then the CA must report its keys as compromised, and reestablish the CA keys and certificates, all cross-certificates, and finally all Subscriber certificates. The IT department may grant extensions to CAs on a case-by-case basis. In the case of a disaster whereby a CA installation is physically damaged and all copies of the CA signature key are destroyed as a result, the CA shall request that its certificates be revoked. The CA installation shall then be completely rebuilt, by reestablishing the CA equipment, generating new private and public keys, being recertified, and re-issuing all cross certificates. Finally, all Subscriber certificates shall be re-issued.
In the event that the lease of the computer hosting a CA is expiring, the CA computer hardware must be replaced in a timely manner. During the lease hold transition, the previous CA hardware must continue to operate to allow ongoing certificate issuance, CRL issuance, and PKI processes. If the lease hold replacement results in the inability to reestablish revocation capabilities within one week, then the CA must report its keys as compromised, and reestablish the CA keys and certificates, all cross-certificates, and finally all Subscriber certificates
The lease hold replacement must restore the same CA key pairs, the CA database and log files so that the change is transparent to all relying parties.
CA termination will be handled in accordance with Section 4.8 above. If the termination is for convenience, contract expiration, re-organization, or other non-security related reason, and provisions have been made to continue compromise recovery (including destruction or continued protection of signing key), compliance and security audit, archive, and data recovery services, then neither the terminated CAs certificate, nor certificates signed by that CA, need to be revoked. If provisions for maintaining these services cannot be made, then the CA termination will be handled as a CA compromise in accordance with Section 4.8.1 above.
The Offline Root CA, Policy CA and Issuing CA as well as the Hardware Security Module (HSM) that protects the CAs private keys are housed in a physically secure room. Entry into the room requires an authorized access control badge. All entry is recorded to prevent unauthorized entry. The CAs and HSM are located in a specially secured rack in the locked Server Room. In addition, all HSM related security devices will be stored in a locked strongbox in the secured rack with the CAs. OIT Security staff will hold and maintain the keys for the server rack and strongbox.
A security check to the facility housing offline CA equipment shall occur at least once every week. The check should ensure that:
n the equipment is in a state appropriate to the current mode of operation (e.g., that cryptomodules and removable hard disks are in place when “open”, and secured when “closed”),
n any security containers are properly secured,
n physical security systems (e.g., door locks, vent covers) are functioning properly, and
n the area is secured against unauthorized access.
A role or person shall be made explicitly responsible for making such checks. When a role is responsible, a log identifying the individual performing such a check shall be maintained. A record shall be kept that describes the type of checks performed, the time, and the person who performed them.
For online CAs, there shall be a security check once per shift to assure the Issuing CA is operational and the console has not been left unlocked or logged on.
If the facility housing the CA equipment will be unattended for periods greater than 24 hours, it shall be protected by an intrusion detection system. Additionally, a check shall be made at least once every 24 hours to ensure that all doors to the facility are locked and there have been no attempts at forceful entry.
The management of the Certification Authority will be handled by OIT CA Administrators. Two staff members will have the administrative password for an offline CA. The password for the offline CAs and administrator account may also be sealed in a tamper-evident envelope and locked in a strongbox (see 5.1 for description). In addition, operation of the CAs will require the use of smart cards for all PKI administrative actions. The Root, Policy and Issuing CA smart cards are stored in a safe. Access to the safe is restricted to smart card holders.
n The OIT EISD is responsible for the operation of the Registration Authority (RA):
· maintain PKI services (consisting of Administration Service, Key Management Service, and Directory Service) plus the Active Directory entries;
· designate Recovery Agents who can recover subscribers private keys;
· designate the CA Administrators;
· designate Certificate managers;
n CA Administrators have the authority to:
· implement the security policy for the CA;
· Stop and start Certificate Services at the CA
· define the holders of other PKI management roles;
· authorize sensitive operations, such as adding and deleting PKI management role holders;
· manage cross-certification agreements and issue, update and revoke cross-certificates.
n Certificate Managers have the authority to:
· revoke user certificates;
· issue pending user certificates for State of Maine Government Medium Assurance or State of Maine Government High Assurance certificates;
· Extract archived private keys from the CA database.
n Auditors have the authority to:
· define PKI auditing events;
· view all entries in the Windows Security event log.
n Backup Operators have the authority to:
· backup Certificate Services;
· restore Certificate Services.
n Key Recovery Agents have the authority to:
· recover encrypted private keys provided by certificate managers from the CA database;
· must not be combined with the certificate manager role.
n Certificate template managers have the authority to:
· define which users or groups are allowed to enroll a specific certificate;
· manage key recovery for users; revoke user certificates; change user DNs.
All PKI operations need the authorization of at least one CA Administrator or one Certificate Manager. However, the following operations need additional authorizations:
n Publishing a CRL at an offline CA
n Issuing certificates to subordinate CAs from an offline CA
n Renewing CA certificates
n cross-certifying with other CAs.
Individuals filling any of the trusted roles at State of Maine Government must be members of the Office of Information Technology with a minimum of one year experience.
The State of Maine Government PKI will enforce Common Criteria role separation. No user may hold two or more of the following roles:
n CA Administrator
n Certificate Manager
n Backup Operator
n Auditor (e.g. state auditor, internal auditor or security auditor)
In addition, the State of Maine Government PKI will separate the roles of Certificate Manager and Key Recovery Agent to ensure that a minimum of two people are involved in all key recovery operations.
For individuals assigned PKI management roles, there is to be no conflict between their responsibilities within the operation and management of this PKI and other duties assigned to them as part of other daily responsibilities within State of Maine Government.
PKI administrative roles may be assigned on a CA-by-CA basis. For CAs, at least three and no more than 8 individuals shall be assigned CA Administrator privileges at anyone time. The background and clearance requirements for these roles are the same as those for the positions within the OIT occupied by these individuals. All are full-time State of Maine Government employees. Those with CA Administrator privileges must have a minimum of 3 years experience working in information technology and have demonstrated expertise as server systems administrators.
All must have completed CA Administrator training and been provided with the PKI infrastructure documentation.
At least three and no more than 8 individuals shall be assigned the Certificate Manager role at anyone time. The background and clearance requirements for these roles are the same as those for the positions within the OIT occupied by these individuals. All are full-time State of Maine Government employees. Those with Certificate Manager privileges must have a minimum of 1 year experience working in information technology and have demonstrated expertise as client or server systems administrators.
Those with Registration Authority roles must have a minimum of 1 year experience working in information technology and have demonstrated expertise computer system security.
All have completed must have completed Certificate Manager or Registration Authority training and been provided with the PKI infrastructure user documentation.
All PKI users must have access to the PKI User Guide.
The CA signing key pair is created during the installation of the CA and is protected by a Hardware Security Module (HSM). The CA key generation process complies with FIPS 140-2 Level 3
For all PKI user certificates, the MS PKI software generates the digital signature key pair and the encryption key pair. For an encryption certificate, the private key is securely transferred to the CA database by using the CA’s encryption certificate.
For State of Maine Government High Assurance certificates, the key pair is generated when a smart card enrollment agent makes the certificates request on behalf of the user. The smart card certificate is delivered to the user only after a registration authority validates the identity of the user based on the requirements for State of Maine Government High Assurance certificates. For State of Maine Government Basic Assurance and State of Maine Government Medium Assurance certificates, there are no delivery requirements for the private key, as the private key is generated at the requesting computer.
For cross-certificates, as the CA signing key pair is generated by the issuing CA and stored in Active Directory, no delivery of the private key to the subject CA is required.
The CA verification public key is delivered in a CA certificate to users using Active Directory publication and publication at Authority Information Access (AIA) URLs.
The following key sizes are used in the State of Maine Government PKI:
n PKI user signing key pairs are 1024 RSA.
n PKI user encryption key pairs are 1024 RSA.
n Root CA key pair is 2048 RSA.
n Subordinate CA signing key pairs are 2048 RSA.
n Issuing CA signing key pairs are 2048 RSA.
PKI users use Autoenrollment and Web enrollment to acquire user certificates. The digital signature or encryption key pair is generated by the Microsoft PKI software.
Certificates issued by State of Maine Government CA contain the Key Usage certificate extension restricting the purpose to which the certificate can be applied. Certificates are further restricted by both the Enhanced Key Usage (EKU) and Application Policies extensions to define what applications a certificate may be used for.
The cryptographic module used a State of Maine Government CA is designed to generate keys is designed to comply with FIPS 140-2 Level III. For user certificates, the cryptographic modules used to generate keys must be compliant with FIPS 140-2 Level 2
Actions which require verification by more than one administrative person include:
These actions must be authorized by a quorum of 3 of the 8 operator card set (OCS) holders.
n Issuing new subordinate CA certificates
n Renewing CA certificates
n Publishing CRLs at offline CAs
n Backing up CA private key material
These actions must be authorized by a quorum of 3 of the 10 operator card set (OCS) holders governing changes to the CAs.
n New Policy CA
n Change to existing Policy CA
n New Certificate Service
n Change to existing Certificate Services
n New Issuing CA
n Change to existing Issuing CA
In addition, three of 13 administrator card set (ACS) holders are required to authorize the following actions:
n Generating a new security world
n Adding a new HSM to the security world
n Replacing a failed HSM in the security world
n Recovering a lost operator card set PIN
n Replacing the existing administrator card set with a new set
CA private keys are backed up using the HSM’s backup methods. PKI user encryption private keys are backed up in the PKI database. The PKI user private signing key is never backed up at the database, in order to provide support for non-repudiation services. Private keys stored in the CA database are encrypted and its integrity is protected by PKI master keys. Only a certificate manager can extract the encrypted private key from the CA database. Once extracted, only a designated Key Recovery Agent can decrypt the private key and distribute the private key to the user.
The State of Maine Government signing key is protected by the HSM.
The encryption key pair history for all PKI users, including a complete history of all decryption private keys is stored encrypted in the PKI database. The CA signing key pair is also stored in the PKI database.
Online CA databases are backed up at a minimum on a daily basis. Offline CA databases are backed up each time that the CA is accessed for CRL publication or CA certificate renewal.
All key material used by the HSM stored on the local file system must be protected using AES 256 bit encryption.
CA signing private keys are generated in software, within the cryptographic module, and not entered by other entities into that module. In all cases, private keys are stored encrypted in the cryptographic module and are decrypted only at the time at which they are actually being used.
Subscriber signing private keys are generated in software at the client computer. The private keys are stored encrypted in the user’s profile and are protected by the Microsoft Data Protection API (DPAPI).
Private keys are activated at the time of subject login to the relevant PKI component occurs.
The private keys remain active for the period of login. The login period is ended either by the subject logging out from the PKI application or automatically as determined by a preset timer. Each PKI user as a general default option using the PKI/Client software sets the timer.
Cryptographic modules, which have been activated, must not be left unattended or otherwise open to unauthorized access. After use, they must be deactivated, e.g. via a manual logout procedure, or by a passive timeout. Hardware cryptomodules must be deactivated, removed, and stored when not in use.
All sensitive keys in memory are overwritten with zeros when no longer used. Permanent destruction of private keys is achieved with secure delete operations.
Private keys should be destroyed when they are no longer needed, or when the certificates to which they correspond expire or are revoked. For software cryptomodules, this can be overwriting the data. For hardware tokens, this will likely be executing a “zeroize” command. Physical destruction of hardware should not be required.
The CA signing key pair, user encryption public key certificates and verification public key certificates are backed up in the Certificate services database. The complete encryption key pair history and verification public key history for all PKI users, including history of status changes such as revocation date and reason, are stored in Active Directory in the userCertificate attribute of each user.
The PKI database is archived according to the procedures described in section 4.6 of this CPS.
The following lifetimes are defined for the CA hierarchy:
n Root CA: CA signing key lifetime is set to twenty years.
n Policy CA: CA signing key lifetime is set to fifteen years
n Issuing CAs: CA signing key lifetime is set to ten years
n Certificates issued to computers, users, and networks devices are defined on a certificate by certificate basis with a maximum lifetime set to five years.
All access to PKI components is managed by user accounts and passwords. Passwords are required by all entities logging on to PKI components and are associated with accounts stored in Active Directory or in the local security accounts management (SAM) database.
PKI requires a stringent set of rules to each password to ensure it is secure. The rules on password selection are:
n It must have at least eight characters;
n It must have at least one upper-case letter or digit;
n It must have at least one non-alpha or non-numeric key;
n It must have at least one lower-case letter;
n It must not have been used in the last 24 months.
n It must not be the same as the entity's profile name; .
The CA workstation is physically secured as described in section 5.1 of this CPS. The operating system enforces identification and authentication of all users.
Access to the PKI CA Administrator and Certificate Manager database and audit trails is restricted as described in sections 4.6.3 and 4.5.4 of this CPS.
Quality assurance processes were employed during the system development of Certificate Services to make applications PKI-ready. A complete, separate test environment was configured to provide rigorous testing.
Security management processes are industry standard.
Administration of Certificate Services requires console access for all offline CAs. Offline CAs are removed from the State network to prevent unauthorized access. For online CAs, remote administrative access is available through remote desktop and Microsoft Management Console (MMC). No other forms of remote access is permitted and unnecessary services are disabled at the CA.
This policy governs X.509 Version 3 certificates.
Rules for the inclusion, assignment of value, and processing of extensions are defined in certificate templates. Any valid X.509 version 3 certificate extensions may be included in the issued certificates.
In general, the DN will match the DN of the related Active Directory object. Some applications may require one or more alternative name formats. In this case, an alternate name form may be included in the subjectAltName extension. If there is no DN, then the subject field of the base certificate shall be an empty sequence, and that extension shall be marked critical.
Cross CA certificates issued to partner organizations shall impose name constraints and path length constraints as defined in the PKI agreement with the partner organization
7.1.5 Certificate policy object identifier
For State of Maine Government Medium Assurance and State of Maine Government High Assurance certificates, a Certificate Policy OID will be included to represent the certificate policy applied during the issuance process. For State of Maine Government Low Assurance certificates, the inclusion of a Certificate Policy OID is optional, with the assumption that if an OID does not exist, that a State of Maine Government Low Assurance issuance process was enforced at certificate issuance.
The certificate policy OIDS implemented in this CPS are described in Section 1.2.
CRLs issued under this Policy shall assert a version number as described in the X.509 standard.
The OIT EISD shall review this policy at least once every year. The EISD shall maintain and publish a Certificate Policy Plan that describes anticipated changes to this CPS that have been authorized by the Certification Policy Management (CPM) group. Errors, updates, or suggested changes to this document shall be communicated to the contact in Section 1.4. Such communication must include a description of the change, a change justification, and contact information for the person requesting the change.
All policy changes under consideration by the EISD shall be disseminated to interested parties (see Section 8.2) for a period of at least one month.
The EISD after acceptance by the CPM shall accept, accept with modifications, or reject the proposed change after completion of the review period.
The OIT EISD shall publish information (including this policy) on a web site. The EISD will maintain a list of CAs asserting this policy (this responsibility may be delegated to a Root- or Intermediate-CA in practice). Proposed changes to the policy and policy updates shall be sent to those CAs. The Certificate Manager shall notify its Subscribers of any changes to the certificate policy via a mechanism described in its CPS.
The EISD shall make the determination that a CPS complies with this policy for a given level of assurance. The certificate manager must have and meet all requirements of an approved CPS prior to commencing operations. In some cases the nature of the system function, the type of communications, or the operating environment may require the additional approval of an authorized agency.
The Certification Policy Management (CPM) group is authorized to make the determination that other Certificate Policies offer appropriately equivalent levels of assurance to the State of Maine Government Certification Policies. The PKI may respond to such decisions by issuing cross-certificates to other PKIs asserting other policies
Normally, the EISD shall decide that variation in Certificate Manager practice is acceptable under a current policy, or the certificate manager shall request a permanent change to the policy. Policy waivers may be granted by the EISD to meet urgent, unforeseen operational requirements.
When a waiver is granted, the EISD shall post the waiver on a web site accessible by relying parties, and shall either initiate a permanent change to the policy, or shall place a specific time limit, not to exceed one year, on the waiver.
Signatures:
In Witness Hereof, the party hereto has executed this agreement on the date set forth below.
For the State of Maine, Office of Information Technology:
_____________________________________________ Date: ___________________
Richard B. Thompson
Chief Information Officer
Attest By:
Memorandum of Understanding
Between
The State of Maine Government
Legislative Branch
Judicial Branch
Constitutional Offices
(Attorney General, Auditor, Secretary of State, Treasurer)
And
Executive Branch Office of Information Technology
This agreement is entered into by and between:
The State of Maine Government, Legislative Branch Judicial Branch, Constitutional Offices (Attorney General, Auditor, Secretary of State, Treasurer) and Executive Branch Office of Information Technology, herein referred to as “OIT”.
Article I – Background and Objectives
Background:
The Office of Information Technology (OIT) is tasked with management and operation of all computer systems for the State of Maine Executive Branch and with the management and operation of other systems as may be mutually agreed to with other branches of government.
OIT is working in cooperation with agencies within the State of Maine to facilitate the pooling of Information Technology resources to provide common data processing capabilities for all aspects of state government.
OIT continues developing the physical infrastructure (network, security controls) to facilitate effective interoperable and secure data communication operations for all agencies utilizing the State Wide Area Network.
Objectives:
Article II – Governance Structure and Procedures
Governance Structure:
o 2 - Executive Card Holders – appointed by and serving at the pleasure of the CIO
o 2 - Court Card Holders – appointed by and serving at the pleasure of the Chief Justice
o 2 - Legislative Card Holders – appointed by and serving at the pleasure of Legislative Council
o 4 - Constitutional Card Holders
§ 1 appointed by and serving at the pleasure of the Secretary of State
§ 1 appointed by and serving at the pleasure of the Attorney General
§ 1 appointed by and serving at the pleasure of the State Auditor
§ 1 appointed by and serving at the pleasure of the State Treasurer
Governance Procedures:
.
Article III – Term of Agreement
The initial term of this agreement shall begin on the effective date, continue through the following January 1, and then continue for an additional ten (10) full years. This agreement shall automatically renew on January 1 from year to year thereafter, unless any party gives Written Notice of its intent to withdraw from the agreement to all other parties.
Article IV – Payment
OIT will assess a fee as appropriate for each issued certificate to cover operating costs of the CAs and Certificate Services. The rate may be adjusted periodically to reflect actual operating expenses.
Article V – Prior Approval of Modification
This agreement may be modified only by a written instrument executed by all parties.
Article VI – Withdrawal
Any party may withdraw from this agreement with 90 days notice by providing all others “WRITTEN NOTICE” of its intent to withdraw.
Article VIII – Key Officials Contact Information
For the Office of Information Technology:
Enterprise Information Security Director
36 Anthony Avenue
138 State House Station
Augusta ME, 04333
Tel (207) 624-8892
Cell (207) 592-
DEFINITIONS
Certificate
A digital document that is commonly used for authentication and to secure information on open networks. A certificate securely binds a public key to the entity that holds the corresponding private key. Certificates are digitally signed by the issuing certification authority (CA), and they can be issued for a user, a computer, or a service.
A digital representation of a user’s or computer’s identity that includes a public key and information about who the certificate was issued to. Certificates are issued by a certification authority (CA), which guarantees the user’s or computer’s identity.
Certification Authority (CA)
An entity responsible for establishing and vouching for the authenticity of public keys belonging to subjects (usually users or computers) or other certification authorities. Activities of a certification authority can include binding public keys to distinguished names through signed certificates, managing certificate serial numbers, and certificate revocation.
A computer that is recognized as an authority trusted by one or more users or processes to issue and manage X.509 public key certificates, a revocation list of CAs that are no longer valid, and a revocation list of certificates that have been revoked.
Certification Policy
A document describing the measures taken to validate a certificate’s subject prior to certificate issuance.
Certificate Practices Statement (CPS)
A document defining the measures taken to secure Certification Authority (CA) operations and the management of CA-issued certificates.
Key
In encryption and digital signatures, a string of bits used for encrypting and decrypting information to be transmitted. Encryption commonly relies on two different types of keys, a public key known to more than one person (say, both the sender and the receiver) and a private key known only to one person (typically, the sender).
Hardware Security Module (HSM)
A Federal Information Processing System (FIPS) 140-2 level 3 security device that implements role separation in the protection of a Certification Authority’s private keys.
Primary Card Holder
A State government employee appointed by their branch policy maker, that performs a the technical function of authorizing changes to the HSM Security World using an Administrative Card Set (ACS) smart card and authorizing changes to the Root CA and Policy CA using an Operations Card Set (OCS) smart card.
Private Key
The component of a key pair that is kept secret by the owner of the key pair.
Public Key
The component of a key pair that is shared by the owner of the key pair.
The non-secret half of a cryptographic key pair that is used with a public key algorithm. Public keys are typically used when encrypting a session key, verifying a digital signature, or encrypting data that can be decrypted with the corresponding private key.
Public Key Infrastructure (PKI)
The component of a structure that issues certificates, uses certificates, and manages the certificate life cycle.
The laws, policies, standards, and software that regulate or manipulate certificates and public and private keys. In practice, it is a system of digital certificates, certification authorities, and other registration authorities that verify and authenticate the validity of each party involved in an electronic transaction.
COUNTERPARTS: At least two copies of this agreement shall be signed by the parties and each copy shall be deemed an original.
Signatures:
In Witness Hereof, the parties hereto have executed this agreement on the dates(s) set forth below.
For the Chief Justice, State of Maine Judiciary
___________________________________ Date: ___________________
Title: _______________________________
Attest By:
For the Legislative Council, State of Maine Legislature
___________________________________ Date: ___________________
Title: _______________________________
Attest By:
For the Attorney General, State of Maine
___________________________________ Date: ___________________
Title: _______________________________
Attest By:
For the Auditor, State of Maine
___________________________________ Date: ___________________
Title: _______________________________
Attest By:
For the Secretary of State, State of Maine
___________________________________ Date: ___________________
Title: _______________________________
Attest By:
For the Treasurer, State of Maine
___________________________________ Date: ___________________
Title: _______________________________
Attest By:
For the State of Maine, Office of Information Technology:
_____________________________________________ Date: ___________________
Richard B. Thompson
Chief Information Officer
Attest By: