4.  Contents of a Set of Provisions

   This section expands upon the contents of the simple framework of
   provisions, as introduced in Section 3.7.  The topics identified in
   this section are, consequently, candidate topics for inclusion in a
   detailed CP or CPS.

   While many topics are identified, it is not necessary for a CP or a
   CPS to include a concrete statement for every such topic.  Rather, a
   particular CP or CPS may state "no stipulation" for a component,
   subcomponent, or element on which the particular CP or CPS imposes no
   requirements or makes no disclosure.  In this sense, the list of
   topics can be considered a checklist of topics for consideration by
   the CP or CPS writer.

   It is recommended that each and every component and subcomponent be
   included in a CP or CPS, even if there is "no stipulation"; this will
   indicate to the reader that a conscious decision was made to include
   or exclude a provision concerning that topic.  This drafting style
   protects against inadvertent omission of a topic, while facilitating
   comparison of different certificate policies or CPSs, e.g., when
   making policy mapping decisions.

   In a CP, it is possible to leave certain components, subcomponents,
   and/or elements unspecified, and to stipulate that the required
   information will be indicated in a policy qualifier, or the document
   to which a policy qualifier points.  Such CPs can be considered
   parameterized definitions.  The set of provisions should reference or
   define the required policy qualifier types and should specify any
   applicable default values.

4.1.  Introductions

   This component identifies and introduces the set of provisions, and
   indicates the types of entities and applications for which the
   document (either the CP or the CPS being written) is targeted.

4.1.1.  Overview

   This subcomponent provides a general introduction to the document
   being written.  This subcomponent can also be used to provide a
   synopsis of the PKI to which the CP or CPS applies.  For example, it
   may set out different levels of assurance provided by certificates
   within the PKI.  Depending on the complexity and scope of the
   particular PKI, a diagrammatic representation of the PKI might be
   useful here.

4.1.2.  Document Name and Identification

   This subcomponent provides any applicable names or other identifiers,
   including ASN.1 object identifiers, for the document.  An example of
   such a document name would be the US Federal Government Policy for
   Secure E-mail.

4.1.3.  PKI Participants

   This subcomponent describes the identity or types of entities that
   fill the roles of participants within a PKI, namely:

   *  Certification authorities, i.e., the entities that issue
      certificates.  A CA is the issuing CA with respect to the
      certificates it issues and is the subject CA with respect to the
      CA certificate issued to it.  CAs may be organized in a hierarchy
      in which an organization's CA issues certificates to CAs operated
      by subordinate organizations, such as a branch, division, or
      department within a larger organization.

   *  Registration authorities, i.e., the entities that establish
      enrollment procedures for end-user certificate applicants, perform
      identification and authentication of certificate applicants,
      initiate or pass along revocation requests for certificates, and
      approve applications for renewal or re-keying certificates on
      behalf of a CA.  Subordinate organizations within a larger
      organization can act as RAs for the CA serving the entire
      organization, but RAs may also be external to the CA.

   *  Subscribers.  Examples of subscribers who receive certificates
      from a CA include employees of an organization with its own CA,
      banking or brokerage customers, organizations hosting e-commerce
      sites, organizations participating in a business-to-business
      exchange, and members of the public receiving certificates from a
      CA issuing certificates to the public at large.

   *  Relying parties.  Examples of relying parties include employees of
      an organization having its own CA who receive digitally signed e-
      mails from other employees, persons buying goods and services from
      e-commerce sites, organizations participating in a business-to-
      business exchange who receive bids or orders from other
      participating organizations, and individuals and organizations
      doing business with subscribers who have received their
      certificates from a CA issuing certificates to the public.
      Relying parties may or may not also be subscribers within a given
      PKI.

   *  Other participants, such as certificate manufacturing authorities,
      providers of repository services, and other entities providing
      PKI-related services.

4.1.4.  Certificate Usage

   This subcomponent contains:

   *  A list or the types of applications for which the issued
      certificates are suitable, such as electronic mail, retail
      transactions, contracts, and a travel order, and/or

   *  A list or the types of applications for which use of the issued
      certificates is prohibited.

   In the case of a CP or CPS describing different levels of assurance,
   this subcomponent can describe applications or types of applications
   that are appropriate or inappropriate for the different levels of
   assurance.

4.1.5.  Policy Administration

   This subcomponent includes the name and mailing address of the
   organization that is responsible for the drafting, registering,
   maintaining, and updating of this CP or CPS.  It also includes the
   name, electronic mail address, telephone number, and fax number of a
   contact person.  As an alternative to naming an actual person, the
   document may name a title or role, an e-mail alias, and other
   generalized contact information.  In some cases, the organization may
   state that its contact person, alone or in combination with others,
   is available to answer questions about the document.

   Moreover, when a formal or informal policy authority is responsible
   for determining whether a CA should be allowed to operate within or
   interoperate with a PKI, it may wish to approve the CPS of the CA as
   being suitable for the policy authority's CP.  If so, this
   subcomponent can include the name or title, electronic mail address
   (or alias), telephone number, fax number, and other generalized
   information of the entity in charge of making such a determination.
   Finally, in this case, this subcomponent also includes the procedures
   by which this determination is made.

4.1.6.  Definitions and Acronyms

   This subcomponent contains a list of definitions for defined terms
   used within the document, as well as a list of acronyms in the
   document and their meanings.

4.2.  Publication and Repository Responsibilities

   This component contains any applicable provisions regarding:

   *  An identification of the entity or entities that operate
      repositories within the PKI, such as a CA, certificate
      manufacturing authority, or independent repository service
      provider;

   *  The responsibility of a PKI participant to publish information
      regarding its practices, certificates, and the current status of
      such certificates, which may include the responsibilities of
      making the CP or CPS publicly available using various mechanisms
      and of identifying components, subcomponents, and elements of such
      documents that exist but are not made publicly available, for
      instance, security controls, clearance procedures, or trade secret
      information due to their sensitivity;

   *  When information must be published and the frequency of
      publication; and

   *  Access control on published information objects including CPs,
      CPS, certificates, certificate status, and CRLs.

4.3.  Identification and Authentication

   This component describes the procedures used to authenticate the
   identity and/or other attributes of an end-user certificate applicant
   to a CA or RA prior to certificate issuance.  In addition, the
   component sets forth the procedures for authenticating the identity
   and the criteria for accepting applicants of entities seeking to
   become CAs, RAs, or other entities operating in or interoperating
   with a PKI.  It also describes how parties requesting re-key or
   revocation are authenticated.  This component also addresses naming
   practices, including the recognition of trademark rights in certain
   names.

4.3.1.  Naming

   This subcomponent includes the following elements regarding naming
   and identification of the subscribers:

   *  Types of names assigned to the subject, such as X.500
      distinguished names; RFC-822 names; and X.400 names;

   *  Whether names have to be meaningful or not;(3)

   *  Whether or not subscribers can be anonymous or pseudonymous, and
      if they can, what names are assigned to or can be used by
      anonymous subscribers;

   *  Rules for interpreting various name forms, such as the X.500
      standard and RFC-822;

   *  Whether names have to be unique; and

   *  Recognition, authentication, and the role of trademarks.

4.3.2.  Initial Identity Validation

   This subcomponent contains the following elements for the
   identification and authentication procedures for the initial
   registration for each subject type (CA, RA, subscriber, or other
   participant):

   *  If and how the subject must prove possession of the companion
      private key for the public key being registered, for example, a
      digital signature in the certificate request message;(4)

   *  Identification and authentication requirements for organizational
      identity of subscriber or participant (CA; RA; subscriber (in the
      case of certificates issued to organizations or devices controlled
      by an organization), or other participant), for example,
      consulting the database of a service that identifies organizations
      or inspecting an organization's articles of incorporation;

   *  Identification and authentication requirements for an individual
      subscriber or a person acting on behalf of an organizational
      subscriber or participant (CA, RA, in the case of certificates
      issued to organizations or devices controlled by an organization,
      the subscriber, or other participant),(5) including:

      *  Type of documentation and/or number of identification
         credentials required;

      *  How a CA or RA authenticates the identity of the organization
         or individual based on the documentation or credentials
         provided;

      *  If the individual must personally present to the authenticating
         CA or RA;

      *  How an individual as an organizational person is authenticated,
         such as by reference to duly signed authorization documents or
         a corporate identification badge.

   *  List of subscriber information that is not verified (called "non-
      verified subscriber information") during the initial registration;

   *  Validation of authority involves a determination of whether a
      person has specific rights, entitlements, or permissions,
      including the permission to act on behalf of an organization to
      obtain a certificate; and

   *  In the case of applications by a CA wishing to operate within, or
      interoperate with, a PKI, this subcomponent contains the criteria
      by which a PKI, CA, or policy authority determines whether or not
      the CA is suitable for such operations or interoperation.  Such
      interoperation may include cross-certification, unilateral
      certification, or other forms of interoperation.

4.3.3.  Identification and Authentication for Re-key Requests

   This subcomponent addresses the following elements for the
   identification and authentication procedures for re-key for each
   subject type (CA, RA, subscriber, and other participants):

   *  Identification and authentication requirements for routine re-key,
      such as a re-key request that contains the new key and is signed
      using the current valid key; and

   *  Identification and authentication requirements for re-key after
      certificate revocation.  One example is the use of the same
      process as the initial identity validation.

4.3.4.  Identification and Authentication for Revocation Requests

   This subcomponent describes the identification and authentication
   procedures for a revocation request by each subject type (CA, RA,
   subscriber, and other participant).  Examples include a revocation
   request digitally signed with the private key whose companion public
   key needs to be revoked, and a digitally signed request by the RA.

4.4.  Certificate Life-Cycle Operational Requirements

   This component is used to specify requirements imposed upon issuing
   CA, subject CAs, RAs, subscribers, or other participants with respect
   to the life-cycle of a certificate.

   Within each subcomponent, separate consideration may need to be given
   to subject CAs, RAs, subscribers, and other participants.

4.4.1.  Certificate Application

   This subcomponent is used to address the following requirements
   regarding subject certificate application:

   *  Who can submit a certificate application, such as a certificate
      subject or the RA; and

   *  Enrollment process used by subjects to submit certificate
      applications and responsibilities in connection with this process.
      An example of this process is where the subject generates the key
      pair and sends a certificate request to the RA.  The RA validates
      and signs the request and sends it to the CA.  A CA or RA may have
      the responsibility of establishing an enrollment process in order
      to receive certificate applications.  Likewise, certificate
      applicants may have the responsibility of providing accurate
      information on their certificate applications.

4.4.2.  Certificate Application Processing

   This subcomponent is used to describe the procedure for processing
   certificate applications.  For example, the issuing CA and RA may
   perform identification and authentication procedures to validate the
   certificate application.  Following such steps, the CA or RA will
   either approve or reject the certificate application, perhaps upon
   the application of certain criteria.  Finally, this subcomponent sets
   a time limit during which a CA and/or RA must act on and process a
   certificate application.

4.4.3.  Certificate Issuance

   This subcomponent is used to describe the following certificate
   issuance related elements:

   *  Actions performed by the CA during the issuance of the
      certificate, for example a procedure whereby the CA validates the
      RA signature and RA authority and generates a certificate; and

   *  Notification mechanisms, if any, used by the CA to notify the
      subscriber of the issuance of the certificate; an example is a
      procedure under which the CA e-mails the certificate to the
      subscriber or the RA or e-mails information permitting the
      subscriber to download the certificate from a web site.

4.4.4.  Certificate Acceptance

   This subcomponent addresses the following:

   *  The conduct of an applicant that will be deemed to constitute
      acceptance of the certificate.  Such conduct may include
      affirmative steps to indicate acceptance, actions implying
      acceptance, or a failure to object to the certificate or its
      content.  For instance, acceptance may be deemed to occur if the
      CA does not receive any notice from the subscriber within a
      certain time period; a subscriber may send a signed message
      accepting the certificate; or a subscriber may send a signed
      message rejecting the certificate where the message includes the
      reason for rejection and identifies the fields in the certificate
      that are incorrect or incomplete.

   *  Publication of the certificate by the CA.  For example, the CA may
      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,
       supply PIN, insert token/key, automatic, etc.)?  Once the key is
       activated, is the key active for an indefinite period, active for
       one time, or active for a defined time period?

   9.  Who can deactivate the private key and how?  Examples of methods
       of deactivating private keys include logging out, turning the
       power off, removing the token/key, automatic deactivation, and
       time expiration.

   10. Who can destroy the private key and how?  Examples of methods of
       destroying private keys include token surrender, token
       destruction, and overwriting the key.

   11. Provide the capabilities of the cryptographic module in the
       following areas: 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.  Capability may be expressed through reference to
       compliance with a standard such as U.S. FIPS 140-1, associated
       level, and rating.

4.6.3.  Other Aspects of Key Pair Management

   Other aspects of key management need to be considered for the issuing
   CA, repositories, subject CAs, RAs, subscribers, and other
   participants.  For each of these types of entities, the following
   questions potentially need to be answered:

   1.  Is the public key archived?  If so, who is the archival agent and
       what are the security controls on the archival system?  Also,
       what software and hardware need to be preserved as part of the
       archive to permit use of the public key over time?  Note: this
       subcomponent is not limited to requiring or describing the use of
       digital signatures with archival data, but rather can address
       integrity controls other than digital signatures when an archive
       requires tamper protection.  Digital signatures do not provide
       tamper protection or protect the integrity of data; they merely
       verify data integrity.  Moreover, the archival period may be
       greater than the cryptanalysis period for the public key needed
       to verify any digital signature applied to archival data.

   2.  What is the operational period of the certificates issued to the
       subscriber.  What are the usage periods, or active lifetimes, for
       the subscriber's key pair?

4.6.4.  Activation Data

   Activation data refers to data values other than whole private keys
   that are required to operate private keys or cryptographic modules
   containing private keys, such as a PIN, passphrase, or portions of a
   private key used in a key-splitting scheme.  Protection of activation
   data prevents unauthorized use of the private key, and potentially
   needs to be considered for the issuing CA, subject CAs, RAs, and
   subscribers.  Such consideration potentially needs to address the
   entire life-cycle of the activation data from generation through
   archival and destruction.  For each of the entity types (issuing CA,
   repository, subject CA, RA, subscriber, and other participants), all
   of the questions listed in 4.6.1 through 4.6.3 potentially need to be
   answered with respect to activation data rather than with respect to
   keys.

4.6.5.  Computer Security Controls

   This subcomponent is used to describe computer security controls such
   as: use of the trusted computing base concept, discretionary access
   control, labels, mandatory access controls, object re-use, audit,
   identification and authentication, trusted path, security testing,
   and penetration testing.  Product assurance may also be addressed.

   A computer security rating for computer systems may be required.  The
   rating could be based, for example, on the Trusted System Evaluation
   Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria,
   European Information Technology Security Evaluation Criteria (ITSEC),
   or the Common Criteria for Information Technology Security
   Evaluation, ISO/IEC 15408:1999.  This subcomponent can also address
   requirements for product evaluation analysis, testing, profiling,
   product certification, and/or product accreditation related activity
   undertaken.

4.6.6.  Life Cycle Security Controls

   This subcomponent addresses system development controls and security
   management controls.

   System development controls include development environment security,
   development personnel security, configuration management security
   during product maintenance, software engineering practices, software
   development methodology, modularity, layering, use of failsafe design
   and implementation techniques (e.g., defensive programming) and
   development facility security.

   Security management controls include execution of tools and
   procedures to ensure that the operational systems and networks adhere
   to configured security.  These tools and procedures include checking
   the integrity of the security software, firmware, and hardware to
   ensure their correct operation.

   This subcomponent can also address life-cycle security ratings based,
   for example, on the Trusted Software Development Methodology (TSDM)
   level IV and V, independent life-cycle security controls audit, and
   the Software Engineering Institute's Capability Maturity Model (SEI-
   CMM).

4.6.7.  Network Security Controls

   This subcomponent addresses network security related controls,
   including firewalls.

4.6.8.  Time-stamping

   This subcomponent addresses requirements or practices relating to the
   use of timestamps on various data.  It may also discuss whether or
   not the time-stamping application must use a trusted time source.

4.7.  Certificate and CRL Profiles

   This component is used to specify the certificate format and, if CRLs
   and/or OCSP are used, the CRL and/or OCSP format.  This includes
   information on profiles, versions, and extensions used.

4.7.1.  Certificate Profile

   This subcomponent addresses such topics as the following (potentially
   by reference to a separate profile definition, such as the one
   defined in IETF PKIX RFC 3280):

   *  Version number(s) supported;

   *  Certificate extensions populated and their criticality;

   *  Cryptographic algorithm object identifiers;

   *  Name forms used for the CA, RA, and subscriber names;

   *  Name constraints used and the name forms used in the name
      constraints;

   *  Applicable CP OID(s);

   *  Usage of the policy constraints extension;

   *  Policy qualifiers syntax and semantics; and

   *  Processing semantics for the critical CP extension.

4.7.2.  CRL Profile

   This subcomponent addresses such topics as the following (potentially
   by reference to a separate profile definition, such as the one
   defined in IETF PKIX RFC 3280):

   *  Version numbers supported for CRLs; and

   *  CRL and CRL entry extensions populated and their criticality.

4.7.3.  OCSP Profile

   This subcomponent addresses such topics as the following (potentially
   by reference to a separate profile definition, such as the IETF RFC
   2560 profile):

   *  Version of OCSP that is being used as the basis for establishing
      an OCSP system; and

   *  OCSP extensions populated and their criticality.

4.8.  Compliance Audit and Other Assessment

   This component addresses the following:

   *  The list of topics covered by the assessment and/or the assessment
      methodology used to perform the assessment; examples include
      WebTrust for CAs (9) and SAS 70 (10).

   *  Frequency of compliance audit or other assessment for each entity
      that must be assessed pursuant to a CP or CPS, or the
      circumstances that will trigger an assessment; possibilities
      include an annual audit, pre-operational assessment as a condition
      of allowing an entity to be operational, or investigation
      following a possible or actual compromise of security.

   *  The identity and/or qualifications of the personnel performing the
      audit or other assessment.

   *  The relationship between the assessor and the entity being
      assessed, including the degree of independence of the assessor.

   *  Actions taken as a result of deficiencies found during the
      assessment; examples include a temporary suspension of operations
      until deficiencies are corrected, revocation of certificates
      issued to the assessed entity, changes in personnel, triggering
      special investigations or more frequent subsequent compliance
      assessments, and claims for damages against the assessed entity.

   *  Who is entitled to see results of an assessment (e.g., assessed
      entity, other participants, the general public), who provides them
      (e.g., the assessor or the assessed entity), and how they are
      communicated.

4.9.  Other Business and Legal Matters

   This component covers general business and legal matters.  Sections
   9.1 and 9.2 of the framework discuss the business issues of fees to
   be charged for various services and the financial responsibility of
   participants to maintain resources for ongoing operations and for
   paying judgments or settlements in response to claims asserted
   against them.  The remaining sections are generally concerned with
   legal topics.

   Starting with Section 9.3 of the framework, the ordering of topics is
   the same as or similar to the ordering of topics in a typical
   software licensing agreement or other technology agreement.
   Consequently, this framework may not only be used for CPs and CPSs,
   but also associated PKI-related agreements, especially subscriber
   agreements, and relying party agreements.  This ordering is intended
   help lawyers review CPs, CPSs, and other documents adhering to this
   framework.

   With respect to many of the legal subcomponents within this
   component, a CP or CPS drafter may choose to include in the document
   terms and conditions that apply directly to subscribers or relying
   parties.  For instance, a CP or CPS may set forth limitations of
   liability that apply to subscribers and relying parties.  The
   inclusion of terms and conditions is likely to be appropriate where
   the CP or CPS is itself a contract or part of a contract.

   In other cases, however, the CP or CPS is not a contract or part of a
   contract; instead, it is configured so that its terms and conditions
   are applied to the parties by separate documents, which may include
   associated agreements, such as subscriber or relying party
   agreements.  In that event, a CP drafter may write a CP so as to
   require that certain legal terms and conditions appear (or not
   appear) in such associated agreements.  For example, a CP might
   include a subcomponent stating that a certain limitation of liability
   term must appear in a CA's subscriber and relying party agreements.
   Another example is a CP that contains a subcomponent prohibiting the
   use of a subscriber or relying party agreement containing a
   limitation upon CA liability inconsistent with the provisions of the
   CP.  A CPS drafter may use legal subcomponents to disclose that
   certain terms and conditions appear in associated subscriber, relying
   party, or other agreements in use by the CA.  A CPS might explain,
   for instance, that the CA writing it uses an associated subscriber or
   relying party agreement that applies a particular provision for
   limiting liability.

4.9.1.  Fees

   This subcomponent contains any applicable provisions regarding fees
   charged by CAs, repositories, or RAs, such as:

   *  Certificate issuance or renewal fees;

   *  Certificate access fees;

   *  Revocation or status information access fees;

   *  Fees for other services such as providing access to the relevant
      CP or CPS; and

   *  Refund policy.

4.9.2.  Financial Responsibility

   This subcomponent contains requirements or disclosures relating to
   the resources available to CAs, RAs, and other participants providing
   certification services to support performance of their operational
   PKI responsibilities, and to remain solvent and pay damages in the
   event they are liable to pay a judgment or settlement in connection
   with a claim arising out of such operations.  Such provisions
   include:

   *  A statement that the participant maintains a certain amount of
      insurance coverage for its liabilities to other participants;

   *  A statement that a participant has access to other resources to
      support operations and pay damages for potential liability, which
      may be couched in terms of a minimum level of assets necessary to
      operate and cover contingencies that might occur within a PKI,
      where examples include assets on the balance sheet of an
      organization, a surety bond, a letter of credit, and a right under
      an agreement to an indemnity under certain circumstances; and

   *  A statement that a participant has a program that offers first-
      party insurance or warranty protection to other participants in
      connection with their use of the PKI.

4.9.3.  Confidentiality of Business Information

   This subcomponent contains provisions relating to the treatment of
   confidential business information that participants may communicate
   to each other, such as business plans, sales information, trade
   secrets, and information received from a third party under a
   nondisclosure agreement.  Specifically, this subcomponent addresses:

   *  The scope of what is considered confidential information,

   *  The types of information that are considered to be outside the
      scope of confidential information, and

   *  The responsibilities of participants that receive confidential
      information to secure it from compromise, and refrain from using
      it or disclosing it to third parties.

4.9.4.  Privacy of Personal Information

   This subcomponent relates to the protection that participants,
   particularly CAs, RAs, and repositories, may be required to afford to
   personally identifiable private information of certificate
   applicants, subscribers, and other participants.  Specifically, this
   subcomponent addresses the following, to the extent pertinent under
   applicable law:

   *  The designation and disclosure of the applicable privacy plan that
      applies to a participant's activities, if required by applicable
      law or policy;

   *  Information that is or is not considered private within the PKI;

   *  Any responsibility of participants that receive private
      information to secure it, and refrain from using it and from
      disclosing it to third parties;

   *  Any requirements as to notices to, or consent from individuals
      regarding use or disclosure of private information; and

   *  Any circumstances under which a participant is entitled or
      required to disclose private information pursuant to judicial,
      administrative process in a private or governmental proceeding, or
      in any legal proceeding.

4.9.5.  Intellectual Property Rights

   This subcomponent addresses the intellectual property rights, such as
   copyright, patent, trademarks, or trade secrets, that certain
   participants may have or claim in a CP, CPS, certificates, names, and
   keys, or are the subject of a license to or from participants.

4.9.6.  Representations and Warranties

   This subcomponent can include representations and warranties of
   various entities that are being made pursuant to the CP or CPS.  For
   example, a CPS that serves as a contract might contain a CA's
   warranty that information contained in the certificate is accurate.
   Alternatively, a CPS might contain a less extensive warranty to the
   effect that the information in the certificate is true to the best of
   the CA's knowledge after performing certain identity authentication
   procedures with due diligence.  This subcomponent can also include
   requirements that representations and warranties appear in certain
   agreements, such as subscriber or relying party agreements.  For
   instance, a CP may contain a requirement that all CAs utilize a
   subscriber agreement, and that a subscriber agreement must contain a

   warranty by the CA that information in the certificate is accurate.
   Participants that may make representations and warranties include
   CAs, RAs, subscribers, relying parties, and other participants.

4.9.7.  Disclaimers of Warranties

   This subcomponent can include disclaimers of express warranties that
   may otherwise be deemed to exist in an agreement, and disclaimers of
   implied warranties that may otherwise be imposed by applicable law,
   such as warranties of merchantability or fitness for a particular
   purpose.  The CP or CPS may directly impose such disclaimers, or the
   CP or CPS may contain a requirement that disclaimers appear in
   associated agreements, such as subscriber or relying party
   agreements.

4.9.8.  Limitations of Liability

   This subcomponent can include limitations of liability in a CP or CPS
   or limitations that appear or must appear in an agreement associated
   with the CP or CPS, such as a subscriber or relying party agreement.
   These limitations may fall into one of two categories:  limitations
   on the elements of damages recoverable and limitations on the amount
   of damages recoverable, also known as liability caps.  Often,
   contracts contain clauses preventing the recovery of elements of
   damages such as incidental and consequential damages, and sometimes
   punitive damages.  Frequently, contracts contain clauses that limit
   the possible recovery of one party or the other to an amount certain
   or to an amount corresponding to a benchmark, such as the amount a
   vendor was paid under the contract.

4.9.9.  Indemnities

   This subcomponent includes provisions by which one party makes a
   second party whole for losses or damage incurred by the second party,
   typically arising out of the first party's conduct.  They may appear
   in a CP, CPS, or agreement.  For example, a CP may require that
   subscriber agreements contain a term under which a subscriber is
   responsible for indemnifying a CA for losses the CA sustains arising
   out of a subscriber's fraudulent misrepresentations on the
   certificate application under which the CA issued the subscriber an
   inaccurate certificate.   Similarly, a CPS may say that a CA uses a
   relying party agreement, under which relying parties are responsible
   for indemnifying a CA for losses the CA sustains arising out of use
   of a certificate without properly checking revocation information or
   use of a certificate for purposes beyond what the CA permits.

4.9.10.  Term and Termination

   This subcomponent can include the time period in which a CP or a CPS
   remains in force and the circumstances under which the document,
   portions of the document, or its applicability to a particular
   participant can be terminated.  In addition or alternatively, the CP
   or CPS may include requirements that certain term and termination
   clauses appear in agreements, such as subscriber or relying party
   agreements.  In particular, such terms can include:

   *  The term of a document or agreement, that is, when the document
      becomes effective and when it expires if it is not terminated
      earlier.

   *  Termination provisions stating circumstances under which the
      document, certain portions of it, or its application to a
      particular participant ceases to remain in effect.

   *  Any consequences of termination of the document.  For example,
      certain provisions of an agreement may survive its termination and
      remain in force.  Examples include acknowledgements of
      intellectual property rights and confidentiality provisions.
      Also, termination may trigger a responsibility of parties to
      return confidential information to the party that disclosed it.

4.9.11.  Individual notices and communications with participants

   This subcomponent discusses the way in which one participant can or
   must communicate with another participant on a one-to-one basis in
   order for such communications to be legally effective.  For example,
   an RA may wish to inform the CA that it wishes to terminate its
   agreement with the CA.  This subcomponent is different from
   publication and repository functions, because unlike individual
   communications described in this subcomponent, publication and
   posting to a repository are for the purpose of communicating to a
   wide audience of recipients, such as all relying parties.  This
   subcomponent may establish mechanisms for communication and indicate
   the contact information to be used to route such communications, such
   as digitally signed e-mail notices to a specified address, followed
   by a signed e-mail acknowledgement of receipt.

4.9.12.  Amendments

   It will occasionally be necessary to amend a CP or CPS.  Some of
   these changes will not materially reduce the assurance that a CP or
   its implementation provides, and will be judged by the policy
   administrator to have an insignificant effect on the acceptability of
   certificates.  Such changes to a CP or CPS need not require a change

   in the CP OID or the CPS pointer (URL).  On the other hand, some
   changes to a specification will materially change the acceptability
   of certificates for specific purposes, and these changes may require
   corresponding changes to the CP OID or CPS pointer qualifier (URL).

   This subcomponent may also contain the following information:

   *  The procedures by which the CP or CPS and/or other documents must,
      may be, or are amended.  In the case of CP or CPS amendments,
      change procedures may include a notification mechanism to provide
      notice of proposed amendments to affected parties, such as
      subscribers and relying parties, a comment period, a mechanism by
      which comments are received, reviewed and incorporated into the
      document, and a mechanism by which amendments become final and
      effective.

   *  The circumstances under which amendments to the CP or CPS would
      require a change in CP OID or CPS pointer (URL).

4.9.13.  Dispute Resolution Procedures

   This subcomponent discusses procedures utilized to resolve disputes
   arising out of the CP, CPS, and/or agreements.  Examples of such
   procedures include requirements that disputes be resolved in a
   certain forum or by alternative dispute resolution mechanisms.

4.9.14.  Governing Law

   This subcomponent sets forth a statement that the law of a certain
   jurisdiction governs the interpretation and enforcement of the
   subject CP or CPS or agreements.

4.9.15.  Compliance with Applicable Law

   This subcomponent relates to stated requirements that participants
   comply with applicable law, for example, laws relating to
   cryptographic hardware and software that may be subject to the export
   control laws of a given jurisdiction.  The CP or CPS could purport to
   impose such requirements or may require that such provisions appear
   in other agreements.

4.9.16.  Miscellaneous Provisions

   This subcomponent contains miscellaneous provisions, sometimes called
   "boilerplate provisions," in contracts. The clauses covered in this
   subcomponent may appear in a CP, CPS, or agreements and include:

   *  An entire agreement clause, which typically identifies the
      document or documents comprising the entire agreement between the
      parties and states that such agreements supersede all prior and
      contemporaneous written or oral understandings relating to the
      same subject matter;

   *  An assignment clause, which may act to limit the ability of a
      party in an agreement, assigning its rights under the agreement to
      another party (such as the right to receive a stream of payments
      in the future) or limiting the ability of a party to delegate its
      obligations under the agreement;

   *  A severability clause, which sets forth the intentions of the
      parties in the event that a court or other tribunal determines
      that a clause within an agreement is, for some reason, invalid or
      unenforceable, and whose purpose is frequently to prevent the
      unenforceability of one clause from causing the whole agreement to
      be unenforceable; and

   *  An enforcement clause, which may state that a party prevailing in
      any dispute arising out of an agreement is entitled to attorneys'
      fees as part of its recovery, or may state that a party's waiver
      of one breach of contract does not constitute a continuing waiver
      or a future waiver of other breaches of contract.

   *  A force majeure clause, commonly used to excuse the performance of
      one or more parties to an agreement due to an event outside the
      reasonable control of the affected party or parties.  Typically,
      the duration of the excused performance is commensurate with the
      duration of the delay caused by the event.  The clause may also
      provide for the termination of the agreement under specified
      circumstances and conditions.  Events considered to constitute a
      "force majeure" may include so-called "Acts of God," wars,
      terrorism, strikes, natural disasters, failures of suppliers or
      vendors to perform, or failures of the Internet or other
      infrastructure.  Force majeure clauses should be drafted so as to
      be consistent with other portions of the framework and applicable
      service level agreements.  For instance, responsibilities and
      capabilities for business continuity and disaster recovery may
      place some events within the reasonable control of the parties,
      such as an obligation to maintain backup electrical power in the
      face of power outages.

4.9.17.  Other Provisions

   This subcomponent is a "catchall" location where additional
   responsibilities and terms can be imposed on PKI participants that do
   not neatly fit within one of the other components or subcomponents of
   the framework.  CP and CPS writers can place any provision within
   this subcomponent that is not covered by another subcomponent.