rfc2527.txt

RFC 的详细文档！

      * Power and air conditioning;

      * Water exposures;

      * Fire prevention and protection;

      * Media storage;

      * Waste disposal; and



Chokhani & Ford              Informational                     [Page 24]

RFC 2527                          PKIX                        March 1999


      * 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.(22)

   For each task identified for each role, it should also be stated how
   many individuals are required to perform the task (n out m rule).
   Identification and authentication requirements for each role may also
   be defined.

4.5.3 Personnel Security Controls

   This subcomponent addresses the following:

      * Background checks and clearance procedures required for the
        personnel filling the trusted roles; (23)

      * Background checks and clearance procedures requirements for
        other personnel, including janitorial staff; (24)

      * Training requirements and training procedures for each role;

      * Any retraining period and retraining procedures for each role;

      * 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; (25)

        * Controls on contracting personnel, including:

         - Bonding requirements on contract personnel;
         - Contractual requirements including indemnification  for
           damages due to the actions of the contractor personnel;
         - Audit and monitoring of contractor personnel; and
         - Other controls on contracting personnel.

      * Documentation to be supplied to personnel.

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



Chokhani & Ford              Informational                     [Page 25]

RFC 2527                          PKIX                        March 1999


   and end entities to protect their cryptographic 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, audit, and archival.  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, and end entities.

   This component has the following subcomponents:

      * Key Pair Generation and Installation;

      * Private Key Protection;

      * Other Aspects of Key Pair Management;

      * Activation Data;

      * Computer Security Controls;

      * Life-Cycle Security Controls;

      * Network Security Controls; and

      * Cryptographic Module Engineering Controls.

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 subject end entities.
   For each of these types of entities, the following questions
   potentially need to be answered:

      1. Who generates the entity public, private key pair?

      2. How is the private key provided securely to the entity?

      3. How is the entity's public key provided securely to the
         certificate issuer?




Chokhani & Ford              Informational                     [Page 26]

RFC 2527                          PKIX                        March 1999


      4. If the entity is a CA (issuing or subject) how is the entity's
         public key provided securely to the users?

      5. What are the key sizes?

      6. Who generates the public key parameters?

      7. Is the quality of the parameters checked during key generation?

      8. Is the key generation performed in hardware or software?

      9. 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 the Version
         3, X.509 certificates)?

4.6.2 Private Key Protection

   Requirements for private key protection need to be considered for the
   issuing CA, repositories, subject CAs, RAs, and subject end entities.
   For each of these types of entity, the following questions
   potentially need to be answered:

      1. What standards, if any, are required for the module used to
         generate the keys?  For example, are the keys certified by the
         infrastructure required to be generated using modules complaint
         with the US FIPS 140-1?  If so, what is the required FIPS 140-1
         level of the module?

      2. Is the private key under n out of m multi-person control?(18)
         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?  (19) 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?




Chokhani & Ford              Informational                     [Page 27]

RFC 2527                          PKIX                        March 1999


      6. Who enters the private key in the cryptographic module?  In
         what form (i.e., plaintext, encrypted, or split key)?  How is
         the private key stored in the module (i.e., plaintext,
         encrypted, or split key)?

      7. 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?

      8. Who can deactivate the private key and how? Example of how
         might include, logout, power off, remove token/key, automatic,
         or time expiration.

      9. Who can destroy the private key and how?  Examples of how might
         include token surrender, token destruction, or key overwrite.

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, and subject end entities.  For
   each of these types of entity, 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?  The
         archival system should provide integrity controls other than
         digital signatures since: the archival period may be greater
         than the cryptanalysis period for the key and the archive
         requires tamper protection, which is not provided by digital
         signatures.

      2. What are the usage periods, or active lifetimes, for the public
         and the private key respectively?

4.6.4 Activation Data

   Activation data refers to data values other than keys that are
   required to operate cryptographic modules and that need to be
   protected.  (20) Protection of activation data potentially needs to
   be considered for the issuing CA, subject CAs, RAs, and end entities.
   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, and end entity) 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.



Chokhani & Ford              Informational                     [Page 28]

RFC 2527                          PKIX                        March 1999


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 reuse, 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.  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.






Chokhani & Ford              Informational                     [Page 29]

RFC 2527                          PKIX                        March 1999


4.6.8 Cryptographic Module Engineering Controls (26)

   This subcomponent addresses the following aspects of a cryptographic
   module: 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.
   Requirements may be expressed through reference to a standard such as
   U.S. FIPS 140-1. (27)

4.7 CERTIFICATE AND CRL PROFILES

   This component is used to specify the certificate format and, if CRLs
   are used, the CRL format.  Assuming use of the X.509 certificate and
   CRL formats, this includes information on profiles, versions, and
   extensions used.

   This component has two subcomponents:

      * Certificate Profile; and

      * CRL Profile.

4.7.1 Certificate Profile

   This subcomponent addresses such topics as the following (potentially
   by reference to a separate profile definition, such as the PKIX Part
   I profile):

      * Version number(s) supported;

      * Certificate extensions populated and their criticality;

      * Cryptographic algorithm object identi