post the certificate to an X.500 or LDAP repository.
* Notification of certificate issuance by the CA to other entities.
As an example, the CA may send the certificate to the RA.
4.4.5. Key Pair and Certificate Usage
This subcomponent is used to describe the responsibilities relating
to the use of keys and certificates, including:
* Subscriber responsibilities relating to use of the subscriber’s
private key and certificate. For example, the subscriber may be
required to use a private key and certificate only for appropriate
applications as set forth in the CP and in consistency with
applicable certificate content (e.g., key usage field). Use of a
private key and certificate are subject to the terms of the
subscriber agreement, the use of a private key is permitted only
after the subscriber has accepted the corresponding certificate,
or the subscriber must discontinue use of the private key
following the expiration or revocation of the certificate.
* Relying party responsibilities relating to the use of a
subscriber’s public key and certificate. For instance, a relying
party may be obligated to rely on certificates only for
appropriate applications as set forth in the CP and in consistency
with applicable certificate content (e.g., key usage field),
successfully perform public key operations as a condition of
relying on a certificate, assume responsibility to check the
status of a certificate using one of the required or permitted
mechanisms set forth in the CP/CPS (see Section 4.4.9 below), and
assent to the terms of the applicable relying party agreement as a
condition of relying on the certificate.
4.4.6. Certificate Renewal
This subcomponent is used to describe the following elements related
to certificate renewal. Certificate renewal means the issuance of a
new certificate to the subscriber without changing the subscriber or
other participant’s public key or any other information in the
certificate:
* Circumstances under which certificate renewal takes place, such as
where the certificate life has expired, but the policy permits the
same key pair to be reused;
* Who may request certificate renewal, for instance, the subscriber,
RA, or the CA may automatically renew an end-user subscriber
certificate;
* A CA or RA’s procedures to process renewal requests to issue the
new certificate, for example, the use of a token, such as a
password, to re-authenticate the subscriber, or procedures that
are the same as the initial certificate issuance;
* Notification of the new certificate to the subscriber;
* Conduct constituting acceptance of the certificate;
* Publication of the certificate by the CA; and
* Notification of certificate issuance by the CA to other entities.
4.4.7. Certificate Re-key
This subcomponent is used to describe the following elements related
to a subscriber or other participant generating a new key pair and
applying for the issuance of a new certificate that certifies the new
public key:
* Circumstances under which certificate re-key can or must take
place, such as after a certificate is revoked for reasons of key
compromise or after a certificate has expired and the usage period
of the key pair has also expired;
* Who may request certificate re-key, for example, the subscriber;
* A CA or RA’s procedures to process re-keying requests to issue the
new certificate, such as procedures that are the same as the
initial certificate issuance;
* Notification of the new certificate to the subscriber;
* Conduct constituting acceptance of the certificate;
* Publication of the certificate by the CA; and
* Notification of certificate issuance by the CA to other entities.
4.4.8. Certificate Modification
This subcomponent is used to describe the following elements related
to the issuance of a new certificate (6) due to changes in the
information in the certificate other than the subscriber public key:
* Circumstances under which certificate modification can take place,
such as name change, role change, reorganization resulting in a
change in the DN;
* Who may request certificate modification, for instance,
subscribers, human resources personnel, or the RA;
* A CA or RA’s procedures to process modification requests to issue
the new certificate, such as procedures that are the same as the
initial certificate issuance;
* Notification of the new certificate to the subscriber;
* Conduct constituting acceptance of the certificate;
* Publication of the certificate by the CA; and
* Notification of certificate issuance by the CA to other entities.
4.4.9. Certificate Revocation and Suspension
This subcomponent addresses the following:
* Circumstances under which a certificate may be suspended and
circumstances under which it must be revoked, for instance, in
cases of subscriber employment termination, loss of cryptographic
token, or suspected compromise of the private key;
* Who can request the revocation of the participant’s certificate,
for example, the subscriber, RA, or CA in the case of an end-user
subscriber certificate.
* Procedures used for certificate revocation request, such as a
digitally signed message from the RA, a digitally signed message
from the subscriber, or a phone call from the RA;
* The grace period available to the subscriber, within which the
subscriber must make a revocation request;
* The time within which CA must process the revocation request;
* The mechanisms, if any, that a relying party may use or must use
in order to check the status of certificates on which they wish to
rely;
* If a CRL mechanism is used, the issuance frequency;
* If a CRL mechanism is used, maximum latency between the generation
of CRLs and posting of the CRLs to the repository (in other words,
the maximum amount of processing- and communication-related delays
in posting CRLs to the repository after the CRLs are generated);
* On-line revocation/status checking availability, for instance,
OCSP and a web site to which status inquiries can be submitted;
* Requirements on relying parties to perform on-line
revocation/status checks;
* Other forms of revocation advertisements available;
* Any variations of the above stipulations for which suspension or
revocation is the result of private key compromise (as opposed to
other reasons for suspension or revocation).
* Circumstances under which a certificate may be suspended;
* Who can request the suspension of a certificate, for example, the
subscriber, human resources personnel, a supervisor of the
subscriber, or the RA in the case of an end-user subscriber
certificate;
* Procedures to request certificate suspension, such as a digitally
signed message from the subscriber or RA, or a phone call from the
RA; and
* How long the suspension may last.
4.4.10. Certificate Status Services
This subcomponent addresses the certificate status checking services
available to the relying parties, including:
* The operational characteristics of certificate status checking
services;
* The availability of such services, and any applicable policies on
unavailability; and
* Any optional features of such services.
4.4.11. End of Subscription
This subcomponent addresses procedures used by the subscriber to end
subscription to the CA services, including:
* The revocation of certificates at the end of subscription (which
may differ, depending on whether the end of subscription was due
to the expiration of the certificate or termination of the
service).
4.4.12. Key Escrow and Recovery
This subcomponent contains the following elements to identify the
policies and practices relating to the escrowing, and/or recovery of
private keys where private key escrow services are available (through
the CA or other trusted third parties):
* Identification of the document containing private key escrow and
recovery policies and practices or a listing of such policies and
practices; and
* Identification of the document containing session key
encapsulation and recovery policies and practices or a listing of
such policies and practices.
4.5. Management, Operational, and Physical Controls
This component describes non-technical security controls (that is,
physical, procedural, and personnel controls) used by the issuing CA
to securely perform the functions of key generation, subject
authentication, certificate issuance, certificate revocation,
auditing, and archiving.
This component can also be used to define non-technical security
controls on repositories, subject CAs, RAs, subscribers, and other
participants. The non-technical security controls for the subject
CAs, RAs, subscribers, and other participants could be the same,
similar, or very different.
These non-technical security controls are critical to trusting the
certificates since lack of security may compromise CA operations
resulting for example, in the creation of certificates or CRLs with
erroneous information or compromising the CA private key.
Within each subcomponent, separate consideration will, in general,
need to be given to each entity type, that is, the issuing CA,
repository, subject CAs, RAs, subscribers, and other participants.
4.5.1. Physical Security Controls
In this subcomponent, the physical controls on the facility housing
the entity systems are described. Topics addressed may include:
* Site location and construction, such as the construction
requirements for high-security zones and the use of locked rooms,
cages, safes, and cabinets;
* Physical access, i.e., mechanisms to control access from one area
of the facility to another or access into high-security zones,
such as locating CA operations in a secure computer room monitored
by guards or security alarms and requiring movement from zone to
zone to be accomplished using a token, biometric readers, and/or
access control lists;
* Power and air conditioning;
* Water exposures;
* Fire prevention and protection;
* Media storage, for example, requiring the storage of backup media
in a separate location that is physically secure and protected
from fire and water damage;
* Waste disposal; and
* Off-site backup.
4.5.2. Procedural Controls
In this subcomponent, requirements for recognizing trusted roles are
described, together with the responsibilities for each role.
Examples of trusted roles include system administrators, security
officers, and system auditors.
For each task identified, the number of individuals required to
perform the task (n out m rule) should be stated for each role.
Identification and authentication requirements for each role may also
be defined.
This component also includes the separation of duties in terms of the
roles that cannot be performed by the same individuals.
4.5.3. Personnel Security Controls
This subcomponent addresses the following:
* Qualifications, experience, and clearances that personnel must
have as a condition of filling trusted roles or other important
roles. Examples include credentials, job experiences, and
official government clearances that candidates for these positions
must have before being hired;
* Background checks and clearance procedures that are required in
connection with the hiring of personnel filling trusted roles or
perhaps other important roles; such roles may require a check of
their criminal records, references, and additional clearances that
a participant undertakes after a decision has been made to hire a
particular person;
* Training requirements and training procedures for each role
following the hiring of personnel;
* Any retraining period and retraining procedures for each role
after completion of initial training;
* Frequency and sequence for job rotation among various roles;
* Sanctions against personnel for unauthorized actions, unauthorized
use of authority, and unauthorized use of entity systems for the
purpose of imposing accountability on a participant’s personnel;
* Controls on personnel that are independent contractors rather than
employees of the entity; examples include:
- Bonding requirements on contract personnel;
- Contractual requirements including indemnification for damages
due to the actions of the contractor personnel;
- Auditing and monitoring of contractor personnel; and
- Other controls on contracting personnel.
* Documentation to be supplied to personnel during initial training,
retraining, or otherwise.
4.5.4. Audit Logging Procedures
This subcomponent is used to describe event logging and audit
systems, implemented for the purpose of maintaining a secure
environment. Elements include the following:
* Types of events recorded, such as certificate lifecycle
operations, attempts to access the system, and requests made to
the system;
* Frequency with which audit logs are processed or archived, for
example, weekly, following an alarm or anomalous event, or when
ever the audit log is n% full;
* Period for which audit logs are kept;
* Protection of audit logs:
- Who can view audit logs, for example only the audit
administrator;
- Protection against modification of audit logs, for instance a
requirement that no one may modify or delete the audit records
or that only an audit administrator may delete an audit file as
part of rotating the audit file; and
- Protection against deletion of audit logs.
* Audit log back up procedures;
* Whether the audit log accumulation system is internal or external
to the entity;
* Whether the subject who caused an audit event to occur is notified
of the audit action; and
* Vulnerability assessments, for example, where audit data is run
through a tool that identifies potential attempts to breach the
security of the system.
4.5.5. Records Archival
This subcomponent is used to describe general records archival (or
records retention) policies, including the following:
* Types of records that are archived, for example, all audit data,
certificate application information, and documentation supporting
certificate applications;
* Retention period for an archive;
* Protection of an archive:
- Who can view the archive, for example, a requirement that only
the audit administrator may view the archive;
- Protection against modification of the archive, such as
securely storing the data on a write once medium;
- Protection against deletion of the archive;
- Protection against the deterioration of the media on which the
archive is stored, such as a requirement for data to be
migrated periodically to fresh media; and
- Protection against obsolescence of hardware, operating systems,
and other software, by, for example, retaining as part of the
archive the hardware, operating systems, and/or other software
in order to permit access to and use of archived records over
time.
* Archive backup procedures;
* Requirements for time-stamping of records;
* Whether the archive collection system is internal or external; and
* Procedures to obtain and verify archive information, such as a
requirement that two separate copies of the archive data be kept
under the control of two persons, and that the two copies be
compared in order to ensure that the archive information is
accurate.
4.5.6. Key Changeover
This subcomponent describes the procedures to provide a new public
key to a CA’s users following a re-key by the CA. These procedures
may be the same as the procedure for providing the current key.
Also, the new key may be certified in a certificate signed using the
old key.
4.5.7. Compromise and Disaster Recovery
This subcomponent describes requirements relating to notification and
recovery procedures in the event of compromise or disaster. Each of
the following may need to be addressed separately:
* Identification or listing of the applicable incident and
compromise reporting and handling procedures.
* The recovery procedures used if computing resources, software,
and/or data are corrupted or suspected to be corrupted. These
procedures describe how a secure environment is re-established,
which certificates are revoked, whether the entity key is revoked,
how the new entity public key is provided to the users, and how
the subjects are re-certified.
* The recovery procedures used if the entity key is compromised.
These procedures describe how a secure environment is re-
established, how the new entity public key is provided to the
users, and how the subjects are re-certified.
* The entity’s capabilities to ensure business continuity following
a natural or other disaster. Such capabilities may include the
availability of a remote hot-site at which operations may be
recovered. They may also include procedures for securing its
facility during the period of time following a natural or other
disaster and before a secure environment is re-established, either
at the original site or at a remote site. For example, procedures
to protect against theft of sensitive materials from an
earthquake-damaged site.
4.5.8. CA or RA Termination
This subcomponent describes requirements relating to procedures for
termination and termination notification of a CA or RA, including the
identity of the custodian of CA and RA archival records.
4.6. Technical Security Controls
This component is used to define the security measures taken by the
issuing CA to protect its cryptographic keys and activation data
(e.g., PINs, passwords, or manually-held key shares). This component
may also be used to impose constraints on repositories, subject CAs,
subscribers, and other participants to protect their private keys,
activation data for their private keys, and critical security
parameters. Secure key management is critical to ensure that all
secret and private keys and activation data are protected and used
only by authorized personnel.
This component also describes other technical security controls used
by the issuing CA to perform securely the functions of key
generation, user authentication, certificate registration,
certificate revocation, auditing, and archiving. Technical controls
include life-cycle security controls (including software development
environment security, trusted software development methodology) and
operational security controls.
This component can also be used to define other technical security
controls on repositories, subject CAs, RAs, subscribers, and other
participants.
4.6.1. Key Pair Generation and Installation
Key pair generation and installation need to be considered for the
issuing CA, repositories, subject CAs, RAs, and subscribers. For
each of these types of entities, the following questions potentially
need to be answered:
1. Who generates the entity public, private key pair? Possibilities
include the subscriber, RA, or CA. Also, how is the key
generation performed? Is the key generation performed by hardware
or software?
2. How is the private key provided securely to the entity?
Possibilities include a situation where the entity has generated
it and therefore already has it, handing the entity the private
key physically, mailing a token containing the private key
securely, or delivering it in an SSL session.
3. How is the entity’s public key provided securely to the
certification authority? Some possibilities are in an online SSL
session or in a message signed by the RA.
4. In the case of issuing CAs, how is the CA’s public key provided
securely to potential relying parties? Possibilities include
handing the public key to the relying party securely in person,
physically mailing a copy securely to the relying party, or
delivering it in a SSL session.
5. What are the key sizes? Examples include a 1,024 bit RSA modulus
and a 1,024 bit DSA large prime.
6. Who generates the public key parameters, and is the quality of the
parameters checked during key generation?
7. For what purposes may the key be used, or for what purposes should
usage of the key be restricted? For X.509 certificates, these
purposes should map to the key usage flags in X.509 Version 3
certificates.
4.6.2. Private Key Protection and Cryptographic Module Engineering
Controls
Requirements for private key protection and cryptographic modules
need to be considered for the issuing CA, repositories, subject CAs,
RAs, and subscribers. For each of these types of entities, the
following questions potentially need to be answered:
1. What standards, if any, are required for the cryptographic module
used to generate the keys? A cryptographic module can be
composed of hardware, software, firmware, or any combination of
them. For example, are the keys certified by the infrastructure
required to be generated using modules compliant with the US FIPS
140-1? If so, what is the required FIPS 140-1 level of the
module? Are there any other engineering or other controls
relating to a cryptographic module, such as the identification of
the cryptographic module boundary, input/output, roles and
services, finite state machine, physical security, software
security, operating system security, algorithm compliance,
electromagnetic compatibility, and self tests.
2. Is the private key under n out of m multi-person control?(7) If
yes, provide n and m (two person control is a special case of n
out of m, where n = m = 2)?
3. Is the private key escrowed?(8) If so, who is the escrow agent,
what form is the key escrowed in (examples include plaintext,
encrypted, split key), and what are the security controls on the
escrow system?
4. Is the private key backed up? If so, who is the backup agent,
what form is the key backed up in (examples include plaintext,
encrypted, split key), and what are the security controls on the
backup system?
5. Is the private key archived? If so, who is the archival agent,
what form is the key archived in (examples include plaintext,
encrypted, split key), and what are the security controls on the
archival system?
6. Under what circumstances, if any, can a private key be
transferred into or from a cryptographic module? Who is
permitted to perform such a transfer operation? In what form is
the private key during the transfer (i.e., plaintext, encrypted,
or split key)?
7. How is the private key stored in the module (i.e., plaintext,
encrypted, or split key)?
8. Who can activate (use) the private key? What actions must be
performed to activate the private key (e.g., login, power on,