[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 rfc2527                                           
PKIX Working Group                S. Chokhani (CygnaCom Solutions, Inc.)
Internet Draft                                  W. Ford (VeriSign, Inc.)

Expires in six months from                                July 3, 1997


                   Internet Public Key Infrastructure
   Part IV: Certificate Policy and Certification Practices Framework

                  <draft-ietf-pkix-ipki-part4-01.txt>

Status of this Memo

   This  document  is  an  Internet-Draft.   Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF),  its  areas,
   and  its  working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of  6  months
   and  may  be  updated,  replaced,  or  may  become  obsolete by other
   documents at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as work in progress.

   To  learn  the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained  in  the  Internet-Drafts  Shadow
   Directories    on   ftp.is.co.za(Africa),   nic.nordu.net   (Europe),
   munnari.oz.au (Pacific Rim),  ds.internic.net  (US  East  Coast),  or
   ftp.isi.edu (US West Coast).

Abstract

   This   document  presents  a  framework  to  assist  the  writers  of
   certificate  policies  or  certification  practice   statements   for
   certification   authorities   and  public  key  infrastructures.   In
   particular, the framework provides a  comprehensive  list  of  topics
   that potentially (at the writer's discretion) need to be covered in a
   certificate policy definition or a certification practice  statement.
   It is intended that this document, when fully developed, be published
   as an Informational RFC.

   1. INTRODUCTION

   1.1  BACKGROUND

      A  public-key  certificate  (hereinafter  "certificate")  binds  a
      public-key  value  to  a  set  of  information that identifies the
      entity (such as person, organization, account, or site) associated
      with use of the corresponding private key (this entity is known as



Chokhani/Ford                                                   [Page 1]


Internet Draft                PKIX Part IV                      Jul 1997


      the "subject" of the certificate).  A certificate  is  used  by  a
      "certificate  user" or "relying party" that needs to use, and rely
      upon  the  accuracy  of,  the  public  key  distributed  via  that
      certificate  (a  certificate  user  is typically an entity that is
      verifying a digital signature from the certificate's subject or an
      entity  sending  encrypted  data  to  the subject).  The degree to
      which a certificate user can  trust  the  binding  embodied  in  a
      certificate  depends on several factors. These factors include the
      practices  followed  by  the  certification  authority   (CA)   in
      authenticating the subject; the CA's operating policy, procedures,
      and security controls; the subject's obligations (for example,  in
      protecting the private key); and the stated undertakings and legal
      obligations of the CA (for example, warranties and limitations  on
      liability).

      A  Version  3 X.509 certificate may contain a field declaring that
      one  or  more  specific  certificate  policies  applies  to   that
      certificate  [ISO1].   According to X.509, a certificate policy is
      "a named set of  rules  that  indicates  the  applicability  of  a
      certificate  to a particular community and/or class of application
      with common security requirements." A certificate  policy  may  be
      used  by  a  certificate  user  to  help  in  deciding  whether  a
      certificate, and the binding therein, is sufficiently  trustworthy
      for  a  particular application.  The certificate policy concept is
      an  outgrowth  of  the  policy  statement  concept  developed  for
      Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1].

      A more detailed description of the practices followed by a  CA  in
      issuing  and otherwise managing certificates may be contained in a
      certification practice statement (CPS) published by or  referenced
      by  the  CA.   According  to  the American Bar Association Digital
      Signature Guidelines (hereinafter "ABA Guidelines"), "a CPS  is  a
      statement of the practices which a certification authority employs
      in issuing certificates." [ABA1]

   1.2  PURPOSE

      The purpose of this document is to establish a clear  relationship
      between  certificate policies and CPSs, and to present a framework
      to assist the writers of certificate policies or CPSs  with  their
      tasks.   In particular, the framework identifies the elements that
      may need to be considered in formulating a certificate policy or a
      CPS.  The purpose is not to define particular certificate policies
      or CPSs, per se.







Chokhani/Ford                                                   [Page 2]


Internet Draft                PKIX Part IV                      Jul 1997


   1.3  SCOPE

      The scope of  this  document  is  limited  to  discussion  of  the
      contents  of a certificate policy (as defined in X.509) or CPS (as
      defined in the ABA  Guidelines).   In  particular,  this  document
      describes  the  types of information that should be considered for
      inclusion in a certificate policy definition or a CPS.   While the
      framework  as presented generally assumes use of the X.509 version
      3 certificate format, it is not  intended  that  the  material  be
      restricted  to  use  of  that  certificate  format.  Rather, it is
      intended that this framework be  adaptable  to  other  certificate
      formats that may come into use.

      The  scope does not extend to defining security policies generally
      (such as organization security policy, system security policy,  or
      data   labeling  policy)  beyond  the  policy  elements  that  are
      considered of particular  relevance  to  certificate  policies  or
      CPSs.

      This  document  does  not  define a specific certificate policy or
      CPS.

      It is assumed  that  the  reader  is  familiar  with  the  general
      concepts  of  digital  signatures,  certificates,  and  public-key
      infrastructure, as used in X.509 and the ABA Guidelines.

2.  DEFINITIONS

   This document makes use of the following defined terms:

      Activation data - Data values, other than keys, that are  required
      to  operate  cryptographic  modules  and that need to be protected
      (e.g., a PIN, a passphrase, or a manually-held key share).

      CA-certificate - A certificate for one CA's public key  issued  by
      another CA.

      Certificate  policy  -  A  named  set  of rules that indicates the
      applicability of a certificate to a  particular  community  and/or
      class  of  application  with  common  security  requirements.  For
      example,  a   particular   certificate   policy   might   indicate
      applicability  of  a  type of certificate to the authentication of
      electronic data interchange transactions for the trading of  goods
      within a given price range.

      Certification  path  -  An ordered sequence of certificates which,
      together with the public key of the initial object  in  the  path,
      can be processed to obtain that of the final object in the path.



Chokhani/Ford                                                   [Page 3]


Internet Draft                PKIX Part IV                      Jul 1997


      Certification  Practice  Statement  (CPS)  -  A  statement  of the
      practices which  a  certification  authority  employs  in  issuing
      certificates.

      Issuing certification authority (issuing CA) - In the context of a
      particular certificate, the issuing CA is the CA that  issued  the
      certificate (see also Subject certification authority).

      Policy qualifier - Policy-dependent information that accompanies a
      certificate policy identifier in an X.509 certificate.

      Practices and policy specification - A  list  of  practice  and/or
      policy statements, spanning a range of standard topics, for use in
      expressing a certificate policy definition or  CPS  employing  the
      approach described in this framework.

      Registration  authority  (RA)  - An entity that is responsible for
      identification and authentication  of  certificate  subjects,  but
      that does not sign or issue certificates (i.e., an RA is delegated
      certain tasks on behalf of a CA).

      Relying party -  A recipient of a certificate who acts in reliance
      on  that certificate and/or digital signatures verified using that
      certificate.  In this document, the terms "certificate  user"  and
      "relying party" are used interchangeably.

      Subject certification authority (subject CA) - In the context of a
      particular CA-certificate, the subject CA is the CA  whose  public
      key   is   certified   in   the   certificate  (see  also  Issuing
      certification authority).

3.  CONCEPTS

   This section explains the concepts of certificate policy and CPS, and
   describes  their  relationship.   Other  related  concepts  are  also
   described.  Some of the material covered in this section and in  some
   other  sections  is  specific  to  certificate policies extensions as
   defined X.509 version 3.  Except for those sections,  this  framework
   is  intended  to  be  adaptable to other certificate formats that may
   come into use.

   3.1  CERTIFICATE POLICY

      When  a  certification  authority  issues  a  certificate,  it  is
      providing  a  statement  to  a  certificate  user (i.e., a relying
      party) that a particular public  key  is  bound  to  a  particular
      entity  (the  certificate  subject).  However, the extent to which
      the certificate user should rely on that statement by the CA needs



Chokhani/Ford                                                   [Page 4]


Internet Draft                PKIX Part IV                      Jul 1997


      to  be  assessed  by the certificate user.  Different certificates
      are issued following different practices and procedures,  and  may
      be suitable for different applications and/or purposes.

      The X.509 standard defines a certificate policy as "a named set of
      rules that indicates the  applicability  of  a  certificate  to  a
      particular  community  and/or  class  of  application  with common
      security requirements"[ISO1].  An X.509 Version 3 certificate  may
      contain  an indication of certificate policy, which may be used by
      a certificate user to decide whether or not to trust a certificate
      for a particular purpose.

      A  certificate  policy,  which  needs to be recognized by both the
      issuer and user of a certificate, is represented in a  certificate
      by  a  unique,  registered  Object  Identifier.  The  registration
      process follows  the  procedures  specified  in  ISO/IEC  and  ITU
      standards.   The  party  that registers the Object Identifier also
      publishes a textual specification of the certificate  policy,  for
      examination  by  certificate  users.   Any  one  certificate  will
      typically declare a single certificate  policy  or,  possibly,  be
      issued consistent with a small number of different policies.

      Certificate  policies also constitute a basis for accreditation of
      CAs.  Each CA  is  accredited  against  one  or  more  certificate
      policies  which  it  is  recognized  as implementing.  When one CA
      issues a CA-certificate for another CA, the issuing CA must assess
      the set of certificate policies for which it trusts the subject CA
      (such assessment may be based upon accreditation  with respect  to
      the   certificate   policies   involved).   The  assessed  set  of
      certificate policies is then indicated by the issuing  CA  in  the
      CA-certificate.   The   X.509  certification path processing logic
      employs these certificate policy indications in  its  well-defined
      trust model.

   3.2  CERTIFICATE POLICY EXAMPLES

      For  example purposes, suppose that IATA undertakes to define some
      certificate policies for use throughout the airline industry, in a
      public-key  infrastructure  operated  by  IATA in combination with
      public-key infrastructures operated by individual  airlines.   Two
      certificate  policies  are  defined  -  the  IATA  General-Purpose
      policy, and the IATA Commercial-Grade policy.

      The IATA General-Purpose policy is intended for  use  by  industry
      personnel   for   protecting  routine  information  (e.g.,  casual
      electronic mail) and for  authenticating  connections  from  World
      Wide  Web  browsers  to  servers for general information retrieval
      purposes. The key pairs may  be  generated,  stored,  and  managed



Chokhani/Ford                                                   [Page 5]


Internet Draft                PKIX Part IV                      Jul 1997


      using   low-cost,   software-based  systems,  such  as  commercial
      browsers.  Under this policy, a certificate may  be  automatically
      issued to anybody listed as an employee in the corporate directory
      of IATA or any member airline who  submits  a  signed  certificate
      request   form   to   a   network  administrator  in  his  or  her
      organization.

      The IATA Commercial-Grade policy  is  used  to  protect  financial
      transactions  or  binding  contractual exchanges between airlines.
      Under this policy, IATA  requires  that  certified  key  pairs  be
      generated  and  stored  in approved cryptographic hardware tokens.
      Certificates and tokens are provided  to  airline  employees  with
      disbursement  authority. These authorized individuals are required
      to present themselves to the corporate  security  office,  show  a
      valid identification badge, and sign an undertaking to protect the
      token and use it only for authorized purposes, before a token  and
      a certificate are issued.

   3.3 X.509 CERTIFICATE FIELDS

      The following extension fields in an X.509 certificate are used to
      support certificate policies:

         * Certificate Policies extension;
         * Policy Mappings extension; and
         * Policy Constraints extension.

      3.3.1 Certificate Policies Extension

         The Certificate Policies extension has two variants - one  with
         the field flagged non- critical and  one with the field flagged
         critical.  The purpose of the field is  different  in  the  two
         cases.

         A  non-critical  Certificate  Policies  field lists certificate
         policies  that  the  certification   authority   declares   are
         applicable.   However, use of the certificate is not restricted
         to the purposes indicated by the  applicable  policies.   Using
         the  example  of the IATA General- Purpose and Commercial-Grade
         policies defined in Section 3.2,  the  certificates  issued  to
         regular  airline  employees  will contain the object identifier
         for certificate policy for  the  General-Purpose  policy.   The
         certificates   issued   to   the  employees  with  disbursement
         authority will contain the  object  identifiers  for  both  the
         General-Purpose  policy  and  the Commercial-Grade policy.  The
         Certificate Policies field may also optionally convey qualifier
         values  for  each  identified  policy;  use  of  qualifiers  is
         discussed in Section 3.4.



Chokhani/Ford                                                   [Page 6]


Internet Draft                PKIX Part IV                      Jul 1997


         The non-critical Certificate Policies field is designed  to  be
         used  by  applications  as  follows.   Each application is pre-
         configured to know what policy it requires.  Using the  example
         in  Section  3.2,  electronic mail applications and Web servers
         will be  configured  to  require  the  General-Purpose  policy.
         However, an airline's financial applications will be configured
         to require the Commercial-Grade policy for validating financial
         transactions over a certain dollar value.

         When processing a certification path, a certificate policy that
         is acceptable to  the  certificate-using  application  must  be
         present  in  every  certificate  in  the  path,  i.e.,  in  CA-
         certificates as well as end entity certificates.

         If the Certificate  Policies  field  is  flagged  critical,  it
         serves  the  same  purpose  as  described above but also has an
         additional role.  It indicates that the use of the  certificate
         is  restricted  to  one  of  the identified policies, i.e., the
         certification authority is declaring that the certificate  must
         only  be  used  in accordance with the provisions of one of the
         listed certificate policies. This field is intended to  protect
         the  certification authority against damage claims by a relying
         party who has used the certificate for an inappropriate purpose
         or  in an inappropriate manner, as stipulated in the applicable
         certificate policy definition.

         For  example,  the  Internal  Revenue   Service   might   issue
         certificates  to  taxpayers  for  the purpose of protecting tax
         filings.  The Internal  Revenue  Service  understands  and  can
         accommodate   the   risks   of   accidentally   issuing  a  bad
         certificate,  e.g.,  to  a   wrongly-   authenticated   person.
         However,  suppose someone used an Internal Revenue Service tax-
         filing certificate as the basis for  encrypting  multi-million-
         dollar-value  proprietary  secrets which subsequently fell into
         the wrong hands because of an error  in  issuing  the  Internal
         Revenue  Service certificate.  The Internal Revenue Service may
         want to protect itself  against  claims  for  damages  in  such
         circumstances.    The   critical-flagged  Certificate  Policies
         extension is intended to mitigate the risk to  the  certificate
         issuer in such situations.











Chokhani/Ford                                                   [Page 7]


Internet Draft                PKIX Part IV                      Jul 1997


      3.3.2  Policy Mappings Extension

         The   Policy  Mappings  extension  may  only  be  used  in  CA-
         certificates. This field allows a  certification  authority  to
         indicate  that  certain  policies  in  its  own  domain  can be
         considered equivalent to certain other policies in the  subject
         certification authority's domain.

         For   example,  suppose  the  ACE  Corporation  establishes  an
         agreement  with  the  ABC  Corporation  to  cross-certify  each
         others' public-key infrastructures for the purposes of mutually
         protecting electronic data interchange (EDI). Further,  suppose
         that  both  companies  have  pre-existing financial transaction
         protection policies called ace-e- commerce and  abc-e-commerce,
         respectively.    One  can  see  that  simply  generating  cross
         certificates between the  two  domains  will  not  provide  the
         necessary  interoperability, as the two companies' applications
         are configured with and  employee  certificates  are  populated
         with  their  respective  certificate  policies.   One  possible
         solution is to reconfigure all of the financial applications to
         require  either policy and to reissue all the certificates with
         both policies.   Another  solution,  which  may  be  easier  to
         administer,  uses  the  Policy Mapping field.  If this field is
         included  in  a  cross-certificate  for  the  ABC   Corporation
         certification   authority   issued   by   the  ACE  Corporation
         certification authority, it can provide a  statement  that  the
         ABC's  financial  transaction  protection  policy (i.e., abc-e-
         commerce) can be considered  equivalent  to  that  of  the  ACE
         Corporation (i.e., ace-e- commerce).

      3.3.3  Policy Constraints Extension

         The   Policy   Constraints   extension  supports  two  optional
         features.   The  first  is  the  ability  for  a  certification
         authority   to   require   that   explicit  certificate  policy
         indications be present in  all  subsequent  certificates  in  a
         certification   path.    Certificates   at   the   start  of  a
         certification path may be considered by a certificate  user  to
         be  part  of  a trusted domain, i.e., certification authorities
         are trusted for  all  purposes  so  no  particular  certificate
         policy  is  needed  in the Certificate Policies extension. Such
         certificates  need  not   contain   explicit   indications   of
         certificate policy.  However, when a certification authority in
         the  trusted  domain  certifies  outside  the  domain,  it  can
         activate  the  requirement  for  explicit certificate policy in
         subsequent certificates in the certification path.

         The other optional feature in the Policy Constraints  field  is



Chokhani/Ford                                                   [Page 8]


Internet Draft                PKIX Part IV                      Jul 1997


         the  ability  for  a  certification authority to disable policy
         mapping  by   subsequent   certification   authorities   in   a
         certification  path.   It  may  be  prudent  to  disable policy
         mapping when certifying outside the domain.  This can assist in
         controlling  risks  due  to  transitive trust, e.g., a domain A
         trusts domain B, domain B trusts domain C, but  domain  A  does
         not want to be forced to trust domain C.

   3.4  POLICY QUALIFIERS

      The  Certificate  Policies  extension  field  has  a provision for
      conveying,  along  with  each   certificate   policy   identifier,
      additional policy-dependent information in a qualifier field.  The
      X.509 standard does not mandate the purpose for which  this  field
      is  to  be  used, nor does it prescribe the syntax for this field.
      Policy qualifier types can be registered by any organization.

      The following policy qualifier types are defined in  PKIX  Part  I
      [PKI1]:

         (a)   The  CPS  Pointer  qualifier  contains  a  pointer  to  a
         Certification Practice Statement (CPS)  published  by  the  CA.
         The  pointer  is  in  the form of a uniform resource identifier
         (URI).

         (b) The User Notice qualifier contains a text string that is to
         be  displayed  to a certificate user (including subscribers and
         relying parties) prior to the use of the certificate.  The text
         string may be an IA5String or a BMPString - a subset of the ISO
         100646-1 multiple octet coded character set.  A CA may invoke a
         procedure  that  requires  that the certficate user acknowledge
         that the applicable terms and conditions have been disclosed or
         accepted.

      Policy  qualifiers  can  be  used  to  support  the  definition of
      generic,  or  parameterized,   certificate   policy   definitions.
      Provided  the  base  certificate  policy  definition  so provides,
      policy qualifier types  can  be  defined  to  convey,  on  a  per-
      certificate basis, additional specific policy details that fill in
      the generic definition.
   3.5  CERTIFICATION PRACTICE STATEMENT

      The term certification practice statement (CPS) is defined by  the
      ABA   Guidelines  as:  "A  statement  of  the  practices  which  a
      certification authority employs in issuing  certificates."  [ABA1]
      In  the  1995  draft  of  the ABA guidelines, the ABA expands this
      definition with the following comments:




Chokhani/Ford                                                   [Page 9]


Internet Draft                PKIX Part IV                      Jul 1997


         A certification practice statement  may  take  the  form  of  a
         declaration  by  the  certification authority of the details of
         its trustworthy system and the  practices  it  employs  in  its
         operations  and  in support of issuance of a certificate, or it
         may be a statute or regulation applicable to the  certification
         authority  and  covering similar subject matter. It may also be
         part of the contract between the  certification  authority  and
         the  subscriber. A certification practice statement may also be
         comprised of multiple documents, a combination of  public  law,
         private contract, and/or declaration.

         Certain  forms  for legally implementing certification practice
         statements lend themselves  to  particular  relationships.  For
         example,  when  the  legal relationship between a certification
         authority  and  subscriber  is  consensual,  a  contract  would
         ordinarily  be  the  means  of giving effect to a certification
         practice statement. The certification authority's duties  to  a
         relying   person  are  generally  based  on  the  certification
         authority's representations, which may include a  certification
         practice statement.

         Whether  a  certification  practice  statement  is binding on a
         relying person  depends  on  whether  the  relying  person  has
         knowledge  or notice of the certification practice statement. A
         relying person has knowledge or at least notice of the contents
         of  the  certificate  used  by  the  relying person to verify a
         digital signature, including documents  incorporated  into  the
         certificate   by   reference.  It  is  therefore  advisable  to
         incorporate  a  certification   practice   statement   into   a
         certificate by reference.

         As  much as possible, a certification practice statement should
         indicate any of the widely recognized standards  to  which  the
         certification   authority's  practices  conform.  Reference  to
         widely  recognized  standards  may   indicate   concisely   the
         suitability  of  the  certification  authority's  practices for
         another  person's  purposes,   as   well   as   the   potential
         technological  compatibility  of the certificates issued by the
         certification authority with repositories and other systems.

   3.6   RELATIONSHIP  BETWEEN  CERTIFICATE  POLICY  AND   CERTIFICATION
   PRACTICE STATEMENT

      The  concepts  of  certificate  policy and CPS come from different
      sources and were developed for different reasons.  However,  their
      interrelationship is important.

      A  certification  practice  statement is a detailed statement by a



Chokhani/Ford                                                  [Page 10]


Internet Draft                PKIX Part IV                      Jul 1997


      certification authority as  to  its  practices,  that  potentially
      needs   to   be   understood  and  consulted  by  subscribers  and
      certificate users (relying parties).  Although the level of detail
      may  vary  among  CPSs,  they will generally be more detailed than
      certificate  policy  definitions.  Indeed,  CPSs  may   be   quite
      comprehensive,  robust  documents  providing  a description of the
      precise service offerings, detailed procedures of  the  life-cycle
      management  of  certificates,  and  more - a level of detail which
      weds the CPS to a particular  (proprietary)  implementation  of  a
      service offering.

      Although  such detail may be indispensable to adequately disclose,
      and to make a full assessment of trustworthiness in the absence of
      accreditation  or other recognized quality metrics, a detailed CPS
      does not form a suitable basis for  interoperability  between  CAs
      operated by different organizations.  Rather, certificate policies
      best serve as the vehicle on which to base common interoperability
      standards  and  common  assurance criteria on an industry-wide (or
      possibly more global) basis.  A CA with a single CPS  may  support
      multiple  certificate  policies  (used  for  different application
      purposes and/or by different certificate user communities).  Also,
      multiple  different CAs, with non-identical certification practice
      statements, may support the same certificate policy.

      For example, the Federal Government might define a government-wide
      certificate  policy  for  handling  confidential  human  resources
      information.  The certificate policy definition will  be  a  broad
      statement  of  the  general  characteristics  of  that certificate
      policy, and an indication of the types of applications  for  which
      it  is  suitable  for use.  Different departments or agencies that
      operate certification  authorities  with  different  certification
      practice statements might support this certificate policy.  At the
      same  time,  such  certification  authorities  may  support  other
      certificate policies.

      The  main  difference  between  certificate  policy  and  CPS  can
      therefore be summarized as follows:

         (a)   Most  organizations  that  operate   public   or   inter-
         organizational  certification  authorities  will document their
         own practices in CPSs or similar statements.  The CPS is one of
         the  organization's  means of protecting itself and positioning
         its business relationships with subscribers and other entities.

         (b)   There  is  strong  incentive,  on  the  other hand, for a
         certificate policy to apply more broadly than to just a  single
         organization.   If  a  particular  certificate policy is widely
         recognized and imitated, it has great potential as the basis of



Chokhani/Ford                                                  [Page 11]


Internet Draft                PKIX Part IV                      Jul 1997


         automated  certificate  acceptance  in  many systems, including
         unmanned systems and systems that  are  manned  by  people  not
         independently  empowered  to  determine  the  acceptability  of
         different presented certificates.

      In addition to populating the certificate policies field with  the
      certificate  policy  identifier,  a  certification  authority  may
      include,  in  certificates  it  issues,   a   reference   to   its
      certification  practice  statement.   A  standard  way to do this,
      using a certificate policy qualifier, is described in Section 3.4.

   3.7  PRACTICES AND POLICY SPECIFICATION

      A  practices and policy specification is a list of practice and/or
      policy statements, spanning a range of standard topics, for use in
      expressing  a  certificate  policy definition or CPS employing the
      approach described in this framework.

      A certificate policy can be expressed as a  single  practices  and
      policy specification.

      A   CPS  can  be  expressed  as  a  single  practices  and  policy
      specification with each component addressing the  requirements  of
      one  or  more  certificate  policies,  or,  alternatively,  as  an
      organized collection of practices and policy specifications.   For
      example,  a  CPS  could  be  expressed  as  a  combination  of the
      following:

         (a)  a list of certificate policies supported by the CPS;

         (b)  for each certificate policy in (a), a practices and policy
         specification   which  contains  statements  that  refine  that
         certificate policy by filling in details not stipulated in that
         policy  or  expressly left to the discretion of the CPS by that
         certificate policy; such statements serve to   state  how  this
         particular  CPS  implements  the requirements of the particular
         certificate policy;

         (c)   a  practices  and  policy  specification  that   contains
         statements  regarding  the  certification  practices on the CA,
         regardless of certificate policy.

      The statements provided in (b) and (c) may augment or  refine  the
      stipulations  of the applicable certificate policy definition, but
      must not conflict with any of the stipulations of such certificate
      policy definition.

      This  framework  outlines  the  contents of a practices and policy



Chokhani/Ford                                                  [Page 12]


Internet Draft                PKIX Part IV                      Jul 1997


      specification, in terms of eight primary components, as follows:


         * Introduction;

         * General Provisions;

         * Identification and Authentication;

         * Operational Requirements;

         * Physical, Procedural, and Personnel Security Controls;

         * Technical Security Controls;

         * Certificate and CRL Profile; and

         * Specification Administration.


      Components can  be  further  divided  into  subcomponents,  and  a
      subcomponent may comprise multiple elements.  Section 4 provides a
      more detailed description of the contents of the above components,
      and their subcomponents.

4.  PRACTICES AND POLICY SPECIFICATION TOPICS

   This  section  expands  upon  the  contents of a practices and policy
   specification, as introduced in Section 3.7.  The  topics  identified
   in  this section are, consequently, candidate topics for inclusion in
   a certificate policy definition  or CPS.

   While  many  topics  are  identified,  it  is  not  necessary  for  a
   certificate policy or a CPS to include a concrete statement for every
   such topic.   Rather, a particular  certificate  policy  or  CPS  may
   state  "no  stipulation" for a component, subcomponent, or element on
   which  the  particular  certificate  policy   or   CPS   imposes   no
   requirements.   In this sense, the list of topics can be considered a
   checklist of topics for consideration by the  certificate  policy  or
   CPS  writer.   It  is  recommended  that each and every component and
   subcomponent be included in a certificate  policy  or  CPS,  even  if
   there  is  "no  stipulation"; this will indicate to the reader that a
   conscious decision was made to include or exclude that  topic.   This
   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  certificate policy definition, it is possible to leave certain



Chokhani/Ford                                                  [Page 13]


Internet Draft                PKIX Part IV                      Jul 1997


   components,  subcomponents,  and/or  elements  unspecified,  and   to
   stipulate that the required information will be indicated in a policy
   qualifier.  Such certificate policy  definitions  can  be  considered
   parameterized  definitions.   The  practices and policy specification
   should reference or define the required policy  qualifier  types  and
   should specify any applicable default values.

   4.1 INTRODUCTION

      This  component identifies and introduces the practices and policy
      specification,  and  indicates   the   types   of   entities   and
      applications for which the specification is targeted.

      This component has the following subcomponents:
         * Overview;

         * Identification;

         * Community and Applicability; and

         * Contact Details.

      4.1.1  Overview

         This  subcomponent  provides  a  general  introduction  to  the
         specification.

      4.1.2  Identification

         This  subcomponent  provides  any  applicable  names  or  other
         identifiers,   including  ASN.1  object  identifiers,  for  the
         specification.

      4.1.3  Community and Applicability

         This subcomponent describes the types of  entities  that  issue
         certificates  or  that are certified as subject CAs (2, 3), the
         types of entities that perform RA functions (4), and the  types
         of  entities  that  are  certified  as  subject end entities or
         subscribers. (5, 6)

         This subcomponent also contains:

            * A list of applications for which the  issued  certificates
            are suitable.

            *  A  list  of  applications  for  which  use  of the issued
            certificates is restricted.  (This list implicitly prohibits



Chokhani/Ford                                                  [Page 14]


Internet Draft                PKIX Part IV                      Jul 1997


            all other uses for the certificates.)

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

      4.1.4  Contact Details

         This subcomponent includes the name and mailing address of  the
         authority   that   is   responsible   for   the   registration,
         maintenance, and interpretation of this certificate  policy  or
         CPS.   It  also  includes  the  name,  electronic mail address,
         telephone number, and fax number of a contact person.

   4.2  GENERAL PROVISIONS

      This component specifies any applicable presumptions on a range of
      legal and general practices topics.

      This component contains the following subcomponents:

         * Liability;

         * Obligations;

         * Financial Responsibility;

         * Interpretation and Enforcement;

         * Fees;

         * Publication and Repositories;

         * Compliance Audit;

         * Confidentiality; and

         * Intellectual Property Rights.

      Each subcomponent may need to separately state provisions applying
      to the entity types: CA, repository, RA, subscriber,  and  relying
      party.   (Specific  provisions  regarding  subscribers and relying
      parties are only  applicable  in  the  Liability  and  Obligations
      subcomponents.)








Chokhani/Ford                                                  [Page 15]


Internet Draft                PKIX Part IV                      Jul 1997


      4.2.1  Liability

         This   subcomponent   contains,   for  each  entity  type,  any
         applicable provisions  regarding  apportionment  of  liability,
         such as:

            * Warranties and limitations on warranties;

            *   Kinds  of  damages  covered  (e.g.,  indirect,  special,
            consequential,  incidental,  punitive,  liquidated  damages,
            negligence and fraud) and disclaimers;

            *   Loss   limitations   (caps)   per   certificate  or  per
            transaction; and

            *  Other  exclusions  (e.g.,  Acts  of  God,   other   party
            responsibilities).

      4.2.2  Obligations

         This   subcomponent   contains,   for  each  entity  type,  any
         applicable provisions regarding  the  entity's  obligations  to
         other entities.  Such provisions may include:

            * CA and/or RA obligations:
               *  Notification  of  issuance  of  a  certificate  to the
               subscriber who is the subject of  the  certificate  being
               issued;
               *  Notification  of  issuance  of a certificate to others
               than the subject of the certificate;
               *  Notification  of  revocation  or   suspension   of   a
               certificate  to the subscriber whose certificate is being
               revoked or suspended; and
               *  Notification  of  revocation  or   suspension   of   a
               certificate  to others than the subject whose certificate
               is being revoked or suspended.
            * Subscriber obligations:

               * Accuracy of representations in certificate application;
               * Protection of the entity's private key;
               * Restrictions on private key and certificate use; and
               * Notification upon private key compromise.

            * Relying party obligations:

               * Purposes for which certificate is used;
               * Digital signature verification responsibilities;
               *  Revocation  and  suspension checking responsibilities;



Chokhani/Ford                                                  [Page 16]


Internet Draft                PKIX Part IV                      Jul 1997


               and
               *  Acknowledgment  of  applicable  liability   caps   and
               warranties.
            * Repository obligations
               *  Timely  publication  of  certificates  and  revocation
               information

      4.2.3  Financial Responsibility

         This subcomponent contains, for CAs, repository, and  RAs,  any
         applicable  provisions  regarding  financial  responsibilities,
         such as:

            * Indemnification of CA and/or RA by relying parties;

            * Fiduciary relationships  (or  lack  thereof)  between  the
            various entities; and

            * Administrative processes (e.g., accounting, audit).

      4.2.4  Interpretation and Enforcement

         This  subcomponent contains any applicable provisions regarding
         interpretation and enforcement of  the  certificate  policy  or
         CPS, addressing such topics as:

            * Governing law;

            *  Severability of provisions, survival, merger, and notice;
            and

            * Dispute resolution procedures.

      4.2.5  Fees

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

            * Certificate issuance or renewal fees;

            * Certificate access fee;

            * Revocation or status information access fee;

            * Fees for other services such as policy information; and

            * Refund policy.




Chokhani/Ford                                                  [Page 17]


Internet Draft                PKIX Part IV                      Jul 1997


      4.2.6  Publication and Repositories

         This subcomponent contains any applicable provisions regarding:

            * A CA's obligations to publish  information  regarding  its
            practices,  its certificates, and the current status of such
            certificates;

            * Frequency of publication;

            * Access control on published information objects  including
            certificate    policy    definitions,   CPS,   certificates,
            certificate status, and CRLs; and

            *  Requirements  pertaining  to  the  use  of   repositories
            operated by CAs or by other independent parties.

      4.2.7  Compliance Audit

         This subcomponent addresses the following:

            * Frequency of compliance audit for each entity;

            * Identity of the auditor;

            * Auditor's relationship to the entity being audited; (30)

            * List of topics covered under the compliance audit; (31)

            *  Actions  taken  as  a result of a deficiency found during
            compliance audit; (32)

            * Compliance audit results: who they are shared with  (e.g.,
            subject  CA,  RA,  and/or  end  entities), who provides them
            (e.g., entity  being  audited  or  auditor),  how  they  are
            communicated.

      4.2.8  Confidentiality Policy

         This subcomponent addresses the following:

            *  Types of information that must be kept confidential by CA
            or RA;

            * Types of information that are not considered confidential;

            *  Who  is entitled to be informed of reasons for revocation
            and suspension of certificates;



Chokhani/Ford                                                  [Page 18]


Internet Draft                PKIX Part IV                      Jul 1997


            * Policy  on  release  of  information  to  law  enforcement
            officials;

            *  Information  that  can  be  revealed  as  part  of  civil
            discovery;

            * Conditions upon which CA or RA may disclose  upon  owner's
            request; and

            *   Any   other   circumstances   under  which  confidential
            information may be disclosed.

      4.2.9  Intellectual Property Rights

         This subcomponent addresses ownership rights  of  certificates,
         practice/policy specifications, names, and keys.

   4.3  IDENTIFICATION AND AUTHENTICATION

      This  component  describes  the  procedures used to authenticate a
      certificate applicant to a CA or RA prior to certificate issuance.
      It  also  describes how parties requesting rekey or revocation are
      authenticated.  This component also  addresses  naming  practices,
      including  name ownership recognition and name dispute resolution.

      This component has the following subcomponents:

         * Initial Registration;

         * Routine Rekey;

         * Rekey After Revocation; and

         * Revocation Request.

      4.3.1  Initial Registration

         This subcomponent includes  the  following  elements  regarding
         identification  and  authentication  procedures  during  entity
         registration or certificate issuance:

            * Types of names assigned to the subject (7);

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

            * Rules for interpreting various name forms;

            * Whether names have to be unique;



Chokhani/Ford                                                  [Page 19]


Internet Draft                PKIX Part IV                      Jul 1997


            * How name claim disputes are resolved;

            * Recognition, authentication, and role of trademarks;

            * If and how  the  subject  must  prove  possession  of  the
            companion  private  key  for the public key being registered
            (9);

            * Authentication requirements for organizational identity of
            subject (CA, RA, or end entity) (10);

            *  Authentication requirements for a person acting on behalf
            of a subject (CA, RA, or end entity) (11), including:

               * Number of pieces of identification required;
               * How a CA or RA validates the pieces  of  identification
               provided;
               *  If  the  individual  must  present  personally  to the
               authenticating CA or RA;
               * How  an  individual  as  an  organizational  person  is
               authenticated (12).

      4.3.2  Routine Rekey

         This    subcomponent    describes    the   identification   and
         authentication procedures for routine rekey  for  each  subject
         type (CA, RA, and end entity). (13)

      4.3.3  Rekey After Revocation -- No Key Compromise

         This    subcomponent    describes    the   identification   and
         authentication procedures for rekey for each subject type  (CA,
         RA,  and  end  entity)  after  the subject certificate has been
         revoked. (14)

      4.3.4  Revocation Request

         This   subcomponent   describes    the    identification    and
         authentication  procedures  for  a  revocation  request by each
         subject type (CA, RA, and end entity). (16)

   4.4  OPERATIONAL REQUIREMENTS

      This component  is  used  to  specify  requirements  imposed  upon
      issuing  CA,  subject  CAs,  RAs,  or end entities with respect to
      various operational activities.

      This component consists of the following subcomponents:



Chokhani/Ford                                                  [Page 20]


Internet Draft                PKIX Part IV                      Jul 1997


         * Certificate Application;

         * Certificate Issuance;

         * Certificate Acceptance;

         * Certificate Suspension and Revocation;

         * Security Audit Procedures;

         * Records Archival;

         * Key Changeover;

         * Compromise and Disaster Recovery; and

         * CA Termination.

      Within each subcomponent, separate consideration may  need  to  be
      given  to  issuing  CA,  repository,  subject  CAs,  RAs,  and end
      entities.

      4.4.1  Certificate Application

         This subcomponent  is  used  to  state  requirements  regarding
         subject enrollment and request for certificate issuance.

      4.4.2  Certificate Issuance

         This  subcomponent  is  used  to  state  requirements regarding
         issuance of a certificate and notification to the applicant  of
         such issuance.

      4.4.3  Certificate Acceptance

         This  subcomponent  is  used  to  state  requirements regarding
         acceptance  of  an  issued  certificate  and   for   consequent
         publication of certificates.













Chokhani/Ford                                                  [Page 21]


Internet Draft                PKIX Part IV                      Jul 1997


      4.4.4  Certificate Suspension and Revocation

         This subcomponent addresses the following:

            * Circumstances under which a certificate may be revoked;

            * Who can request the revocation of the entity certificate;

            * Procedures used for certificate revocation request;

            * Revocation request grace period available to the subject;

            * Circumstances under which a certificate may be suspended;

            * Who can request the suspension of a certificate;

            * Procedures to request certificate suspension;

            * How long the suspension may last;

            * If a CRL mechanism is used, the issuance frequency;

            * Requirements on relying parties to check CRLs;

            * On-line revocation/status checking availability;

            *   Requirements  on  relying  parties  to  perform  on-line
            revocation/status checks;

            * Other forms of revocation advertisements available; and

            * Requirements on relying parties to check  other  forms  of
            revocation advertisements.

            *   Any  variations  on  the  above  stipulations  when  the
            suspension or  revocation  is  the  result  of  private  key
            compromise  (as  opposed  to other reasons for suspension or
            revocation).













Chokhani/Ford                                                  [Page 22]


Internet Draft                PKIX Part IV                      Jul 1997


      4.4.5  Security Audit 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; (28)

            * Frequency with which audit logs are processed or audited;

            * Period for which audit logs are kept;

            * Protection of audit logs:

               - Who can view audit logs;
               - Protection against modification of audit log; and
               - Protection against deletion of audit log.

            * 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.
      4.4.6  Records Archival

         This subcomponent is used to describe general records  archival
         (or records retention) policies, including the following:

            * Types of events recorded; (29)

            * Retention period for archive;

            * Protection of archive:

               - Who can view the archive;
               - Protection against modification of archive; and
               - Protection against deletion of archive.

            * Archive backup procedures;

            * Requirements for time-stamping of records;

            *  Whether  the  archive  collection  system  is internal or
            external; and



Chokhani/Ford                                                  [Page 23]


Internet Draft                PKIX Part IV                      Jul 1997


            * Procedures to obtain and verify archive information.

      4.4.7  Key Changeover

         This subcomponent describes the procedures  to  provide  a  new
         public key to a CA's users.

      4.4.8  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 circumstances may need to
         be addressed separately:

            * 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   reestablished,   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 recertified.

            * The recovery procedures used if the entity public  key  is
            revoked.  These procedures describe how a secure environment
            is reestablished, how the new entity public key is  provided
            to the users, and how the subjects are recertified.

            *  The  recovery  procedures  used  if  the  entity  key  is
            compromised.   These  procedures  describe  how   a   secure
            environment  is reestablished, how the new entity public key
            is  provided  to  the  users,  and  how  the  subjects   are
            recertified.

      4.4.9  CA Termination

         This subcomponent describes requirements relating to procedures
         for termination and for termination notification of a CA or RA,
         including  the  identity of the custodian of CA and RA archival
         records.

   4.5  PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS

      This component describes non-technical security controls (that is,
      physical,  procedural, and personnel controls) used by the issuing
      CA to perform securely the functions of  key  generation,  subject
      authentication,   certificate  issuance,  certificate  revocation,
      audit, and archival.




Chokhani/Ford                                                  [Page 24]


Internet Draft                PKIX Part IV                      Jul 1997


      This component can also be used to define  non-technical  security
      controls  on  repository, subject CAs, RAs, and end entities.  The
      non technical security controls for the subject CAs, RAs, and  end
      entities 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 the compromise  of  the  CA  private
      key.

      This component consists of three subcomponents:

         * Physical Security Controls;

         * Procedural Controls; and

         * Personnel Security Controls.

      Within each subcomponent, separate consideration will, in general,
      need to be given  to  each  entity  type,  that  is,  issuing  CA,
      repository, subject CAs, RAs, and end entities.

      4.5.1  Physical Security Controls

         In  this  subcomponent,  the  physical controls on the facility
         housing the entity systems are described.(21)  Topics addressed
         may include:

            * Site location and construction;

            * Physical access;

            * Power and air conditioning;

            * Water exposures;

            * Fire prevention and protection;

            * Media storage;

            * Waste disposal; and

            * Off-site backup.







Chokhani/Ford                                                  [Page 25]


Internet Draft                PKIX Part IV                      Jul 1997


      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



Chokhani/Ford                                                  [Page 26]


Internet Draft                PKIX Part IV                      Jul 1997


      data (e.g., PINs, passwords, or manually-held key  shares).   This
      component  may also be used to impose constraints on repositories,
      subject CAs 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



Chokhani/Ford                                                  [Page 27]


Internet Draft                PKIX Part IV                      Jul 1997


            certificate issuer?

            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



Chokhani/Ford                                                  [Page 28]


Internet Draft                PKIX Part IV                      Jul 1997


            plaintext,  encrypted, split key), and what are the security
            controls on the archival system?

            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?











Chokhani/Ford                                                  [Page 29]


Internet Draft                PKIX Part IV                      Jul 1997


      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.

      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



Chokhani/Ford                                                  [Page 30]


Internet Draft                PKIX Part IV                      Jul 1997


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




Chokhani/Ford                                                  [Page 31]


Internet Draft                PKIX Part IV                      Jul 1997


            * Cryptographic algorithm object identifiers;

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

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

            * Applicable certificate policy Object Identifier(s);

            * Usage of the policy constraints extension;

            * Policy qualifiers syntax and semantics; and

            * Processing semantics for the critical  certificate  policy
            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 PKIX Part I profile):

            * Version numbers supported for CRLs; and

            *   CRL   and  CRL  entry  extensions  populated  and  their
            criticality.

   4.8  SPECIFICATION ADMINISTRATION

      This component is used to specify how  this  particular  practices
      and policy specification will be maintained.

      It contains the following subcomponents:

         * Specification Change Procedures;

         * Publication and Notification Procedures; and

         * CPS Approval Procedures.












Chokhani/Ford                                                  [Page 32]


Internet Draft                PKIX Part IV                      Jul 1997


      4.8.1  Specification Change Procedures

         It   will  occasionally  be  necessary  to  change  certificate
         policies and Certification Practice Statements.  Some of  these
         changes  will  not  materially  reduce  the  assurance  that  a
         certificate policy or its implementation provides, and will  be
         judged   by  the  policy  administrator  as  not  changing  the
         acceptability of certificates  asserting  the  policy  for  the
         purposes  for  which  they  have  been  used.   Such changes to
         certificate policies and Certification Practice Statements need
         not   require   a  change  in  the  certificate  policy  Object
         Identifier or the  CPS  pointer  (URL).   Other  changes  to  a
         specification will change the acceptability of certificates for
         specific purposes, and these changes will  require  changes  to
         the  certificate policy Object Identifier or CPS pointer (URL).

         This subcomponent contains the following information:

            * A list of specification components, subcomponents,  and/or
            elements  thereof  that  can be changed without notification
            and  without  changes  to  the  certificate  policy   Object
            Identifier or CPS pointer (URL).

            *  A list of specification components, subcomponents, and/or
            elements thereof that may change  following  a  notification
            period   without  changing  the  certificate  policy  Object
            Identifier or CPS pointer (URL).  The procedures to be  used
            to notify interested parties (relying parties, certification
            authorities, etc.) of the certificate policy or CPS  changes
            are  described.   The description of notification procedures
            includes the notification mechanism, notification period for
            comments,  mechanism  to receive, review and incorporate the
            comments, mechanism for final changes to the policy, and the
            period before final changes become effective.

            *  A list of specification components, subcomponents, and/or
            elements, changes to which require a change  in  certificate
            policy Object Identifier or CPS pointer (URL)..













Chokhani/Ford                                                  [Page 33]


Internet Draft                PKIX Part IV                      Jul 1997


      4.8.2  Publication and Notification Procedures

         This subcomponent contains the following elements:

            *  A list of components, subcomponents, and elements thereof
            that exist but that are not made publicly available; (33)

            *  Descriptions  of  mechanisms  used  to   distribute   the
            certificate  policy  definition  or  CPS,  including  access
            controls on such distribution.

      4.8.3  CPS Approval Procedures

         In a certificate policy definition, this subcomponent describes
         how  the  compliance  of  a  specific  CPS with the certificate
         policy can be determined.


5. PRACTICES AND POLICY SPECIFICATION OUTLINE

   This section contains a possible outline for a practices  and  policy
   specification, intended to serve as a checklist or (with some further
   development) a standard template for use by certificate policy or CPS
   writers.  Such a common outline will facilitate:

      (a)    Comparison   of  two  certificate  policies  during  cross-
      certification (for the purpose of equivalency mapping).

      (b) Comparison of a CPS with a certificate  policy  definition  to
      ensure that the CPS faithfully implements the policy.

      (c) Comparison of two CPSs.


   1.   INTRODUCTION

   1.1  Overview

   1.2  Identification

   1.3  Community and Applicability
      1.3.1  Certification authorities
      1.3.2  Registration authorities
      1.3.3  End entities
      1.3.4  Applicability

   1.4  Contact Details
      1.4.1  Specification administration organization



Chokhani/Ford                                                  [Page 34]


Internet Draft                PKIX Part IV                      Jul 1997


      1.4.2  Contact person
      1.4.3  Person determining CPS suitability for the policy

   2.  GENERAL PROVISIONS

   2.1  Liability

      2.1.1  CA liability
      2.1.2  RA liability

   2.2  Obligations

      2.2.1  CA obligations
      2.2.2  RA obligations
      2.2.3  Subscriber obligations
      2.2.4  Relying party obligations 2.2.5  Repository obligations

   2.3  Financial responsibility

      2.3.1  Indemnification by relying parties
      2.3.2  Fiduciary relationships
      2.3.3  Administrative processes

   2.4  Interpretation and Enforcement

      2.4.1  Governing law
      2.4.2  Severability, survival, merger, notice
      2.4.3  Dispute resolution procedures

   2.5  Fees

      2.5.1  Certificate issuance or renewal fees
      2.5.2  Certificate access fees
      2.5.3  Revocation or status information access fees
      2.5.4  Fees for other services such as policy information
      2.5.5  Refund policy

   2.6  Publication and Repository

      2.6.1  Publication of CA information
      2.6.2  Frequency of publication
      2.6.3  Access controls
      2.6.4  Repositories

   2.7  Compliance audit

      2.7.1  Frequency of entity compliance audit
      2.7.2  Identity/qualifications of auditor



Chokhani/Ford                                                  [Page 35]


Internet Draft                PKIX Part IV                      Jul 1997


      2.7.3  Auditor's relationship to audited party
      2.7.4  Topics covered by audit
      2.7.5  Actions taken as a result of deficiency
      2.7.6  Communication of results

   2.8  Confidentiality

      2.8.1  Types of information to be kept confidential
      2.8.2  Types of information not considered confidential
      2.8.3  Disclosure of certificate revocation/suspension information
      2.8.4  Release to law enforcement officials
      2.8.5  Release as part of civil discovery
      2.8.6  Disclosure upon owner's request
      2.8.7  Other information release circumstances

   2.9  Intellectual Property Rights

   3.   IDENTIFICATION AND AUTHENTICATION (34)

   3.1  Initial Registration
      3.1.1  Types of names
      3.1.2  Need for names to be meaningful
      3.1.3  Rules for interpreting various name forms
      3.1.4  Uniqueness of names
      3.1.5  Name claim dispute resolution procedure
      3.1.6  Recognition, authentication and role of trademarks
      3.1.7  Method to prove possession of private key
      3.1.8  Authentication of organization identity
      3.1.9  Authentication of individual identity

   3.2  Routine Rekey

   3.3  Rekey after Revocation

   3.4  Revocation Request

4.  OPERATIONAL REQUIREMENTS (34)

   4.1  Certificate Application

   4.2  Certificate Issuance

   4.3  Certificate Acceptance

   4.4  Certificate Suspension and Revocation
      4.4.1  Circumstances for revocation
      4.4.2  Who can request revocation
      4.4.3  Procedure for revocation request



Chokhani/Ford                                                  [Page 36]


Internet Draft                PKIX Part IV                      Jul 1997


      4.4.4  Revocation request grace period
      4.4.5  Circumstances for suspension
      4.4.6  Who can request suspension
      4.4.7  Procedure for suspension request
      4.4.8  Limits on suspension period
      4.4.9  CRL issuance frequency (if applicable)
      4.4.10  CRL checking requirements
      4.4.11  On-line revocation/status checking availability
      4.4.12  On-line revocation checking requirements
      4.4.13  Other forms of revocation advertisements available
      4.4.14   Checking  requirements  for  other  forms  of  revocation
      advertisements
      4.4.15  Special requirements re key compromise

   4.5  Security Audit Procedures
      4.5.1  Types of event recorded
      4.5.2  Frequency of processing log
      4.5.3  Retention period for audit log
      4.5.4  Protection of audit log
      4.5.5  Audit log backup procedures
      4.5.6  Audit collection system (internal vs external)
      4.5.7  Notification to event-causing subject
      4.5.8  Vulnerability assessments

   4.6  Records Archival

      4.6.1  Types of event recorded
      4.6.2  Retention period for archive
      4.6.3  Protection of archive
      4.6.4  Archive backup procedures
      4.6.5  Archive collection system (internal or external)
      4.6.6  Procedures to obtain and verify archive information

   4.7  Key changeover

   4.8  Compromise and Disaster Recovery

   4.9  CA Termination


   5.  PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS (34)

   5.1  Physical Controls
      5.1.1  Site location and construction
      5.1.2  Physical access
      5.1.3  Power and air conditioning
      5.1.4  Water exposures
      5.1.5  Fire prevention and protection



Chokhani/Ford                                                  [Page 37]


Internet Draft                PKIX Part IV                      Jul 1997


      5.1.6  Media storage
      5.1.7  Waste disposal
      5.1.8  Off-site backup

   5.2  Procedural Controls
      5.2.1  Trusted roles
      5.2.2  Number of persons required per task
      5.2.3  Identification and authentication for each role

   5.3  Personnel Controls
      5.3.1    Background,  qualifications,  experience,  and  clearance
      requirements
      5.3.2  Background check procedures
      5.3.3  Training requirements
      5.3.4  Retraining frequency and requirements
      5.3.5  Job rotation frequency and sequence
      5.3.6  Sanctions for unauthorized actions
      5.3.7  Contracting personnel requirements
      5.3.8  Documentation supplied to personnel

   6.  TECHNICAL SECURITY CONTROLS (34)

   6.1  Key Pair Generation and Installation
      6.1.1  Key pair generation
      6.1.2  Private key delivery to entity
      6.1.3  Public key delivery to certificate issuer
      6.1.4  CA public key delivery to users
      6.1.5  Key sizes
      6.1.6  Public key parameters generation
      6.1.7  Parameter quality checking
      6.1.8  Hardware/software key generation
      6.1.9  Key usage purposes (as per X.509 v3 key usage field)

   6.2  Private Key Protection
      6.2.1  Standards for cryptographic module
      6.2.2  Private key (n out of m) multi-person control
      6.2.3  Private key escrow
      6.2.4  Private key backup
      6.2.5  Private key archival
      6.2.6  Private key entry into cryptographic module
      6.2.7  Method of activating private key
      6.2.8  Method of deactivating private key
      6.2.9  Method of destroying private key

   6.3  Other Aspects of Key Pair Management
      6.3.1  Public key archival
      6.3.2  Usage periods for the public and private keys




Chokhani/Ford                                                  [Page 38]


Internet Draft                PKIX Part IV                      Jul 1997


   6.4  Activation Data
      6.4.1  Activation data generation and installation
      6.4.2  Activation data protection
      6.4.3  Other aspects of activation data

   6.5  Computer Security Controls
      6.5.1  Specific computer security technical requirements
      6.5.2  Computer security rating

   6.6  Life Cycle Technical Controls
      6.6.1  System development controls
      6.6.2  Security management controls
      6.6.3  Life cycle security ratings

   6.7  Network Security Controls

   6.8  Cryptographic Module Engineering Controls

7.  CERTIFICATE AND CRL PROFILES

   7.1  Certificate Profile

      7.1.1  Version number(s)
      7.1.2  Certificate extensions
      7.1.3  Algorithm object identifiers
      7.1.4  Name forms
      7.1.5  Name constraints
      7.1.6  Certificate policy Object Identifier
      7.1.7  Usage of Policy Constraints extension
      7.1.8  Policy qualifiers syntax and semantics
      7.1.9 Processing semantics for  the  critical  certificate  policy
      extension

   7.2  CRL Profile

      7.2.1  Version number(s)
      7.2.2  CRL and CRL entry extensions

   8.  SPECIFICATION ADMINISTRATION

   8.1  Specification change procedures

   8.2  Publication and notification policies

   8.3  CPS approval procedures






Chokhani/Ford                                                  [Page 39]


Internet Draft                PKIX Part IV                      Jul 1997


6.  SECURITY CONSIDERATIONS

   This   entire   memo  deals  with  security,  related  to  public-key
   certificates.

7.  ACKNOWLEDGMENTS

   We wish to thank Dave Fillingham, Jim Brandt, and Edmond Van Hees for
   their  inspiration, support, and  valuable inputs. The development of
   this document was supported by  the  Government  of  Canada's  Policy
   Management  Authority  (PMA) Committee, the National Security Agency,
   the National Institute of Standards and Technology  (NIST),  and  the
   American Bar Association Information Security Committee Accreditation
   Technical Working Group.

   We also wish to thank the following individuals for their review  and
   input:

      Teresa Acevedo, A&N Associates;
      Michael Baum; VeriSign;
      Sharon Boeyen, Entrust;
      Bob Burger, McCarter & English;
      Bill Burr, NIST;
      Patrick Cain, BBN;
      Michael Harrop, Government of Canada Treasury Board;
      Rick Hornbeck, Digital Commerce Services;
      Francois Marinier, Domus Software;
      John Morris, CygnaCom Solutions;
      Tim Moses, Entrust;
      Noel Nazario, NIST;
      John Nicolletos, A&N Associates;
      Jean Petty, CygnaCom Solutions;
      Denis Pinkas, Bull;
      J.-F. Sauriol, Domus Software;
      Robert Shirey, BBN;
      Mark Silvern, VeriSign;
      David Simonetti, Booz, Allen and Hamilton; and
      Darryl Stal, Entrust.

   Johnny  Hsiung,  and  Chris Miller assisted in the preparation of the
   manuscript.

8.  REFERENCES

   [ABA1]  American Bar Association, Digital Signature Guidelines: Legal
   Infrastructure for Certification Authorities and Electronic Commerce,
   Draft 1995.




Chokhani/Ford                                                  [Page 40]


Internet Draft                PKIX Part IV                      Jul 1997


   [BAU1]  Michael. S. Baum, Federal Certification  Authority  Liability
   and Policy, NIST-GCR- 94-654, June 1994.

   [ISO1]    ISO/IEC  9594-8/ITU-T  Recommendation  X.509,  "Information
   Technology   -   Open   Systems   Interconnection:   The   Directory:
   Authentication Framework," 1997 edition. (Pending publication of 1997
   edition, use 1993  edition  with  the  following  amendment  applied:
   Final  Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate
   Extensions, June 1996.)

   [PEM1]  S. Kent, "Privacy Enhancement for Internet  Electronic  Mail,
   Part II: Certificate- Based Key Management," Internet RFC 1422, 1993.

   [PKI1] R. Housley, W. Ford, W. Polk, D. Solo,  "Internet  Public  Key
   Infrastructure,  Part  I:  X.509 Certificate and CRL Profile," draft-
   ietf-pkix-ipki-part1-03.txt, 1996.

9.  AUTHORS' ADDRESSES

      Santosh Chokhani
      CygnaCom Solutions, Inc.
      Suite 100 West
      7927 Jones Branch Drive
      McLean, VA 22102

      Phone: (703) 848-0883
      Fax: (703) 848-0960
      EMail: chokhani@cygnacom.com


      Warwick Ford
      VeriSign, Inc.
      One Alewife Center
      Cambridge, MA 02140

      Phone: (617) 492-2816 x225
      Fax: (617) 661-0716
      EMail: wford@verisign.com



NOTES


   1 The ABA Digital Signature Guidelines can be purchased from the ABA.
   See http://www.abanet.com for ordering details.

   2  Examples  of  types  of  entity  for subject CAs are a subordinate



Chokhani/Ford                                                  [Page 41]


Internet Draft                PKIX Part IV                      Jul 1997


   organization (e.g., branch or division), a federal government agency,
   or a state or provincial government department.

   3   This  statement  can have significant implications.  For example,
   suppose a bank claims that it issues CA certificates to its  branches
   only.   Now,  the  user  of  a  CA certificate issued by the bank can
   assume that the subject CA in the certificate is a branch of the bank

   4  Examples  of  the  types  of  subject  RA  entities are branch and
   division of an organization.

   5 Examples of types of  subject  end  entities  are  bank  customers,
   telephone   company   subscribers,  and  employees  of  a  government
   department

   6 This statement can have  significant  implications.   For  example,
   suppose   Government   CA  claims  that  it  issues  certificates  to
   Government employees only.  Now, the user of a certificate issued  by
   the Government CA can assume that the subject of the certificate is a
   Government employee.

   7 Examples include X.500 distinguished name, Internet e-mail address,
   and URL.

   8  The  term  "meaningful"  means  that  the  name  form has commonly
   understood semantics to  determine  identity  of  the  person  and/or
   organization.   Directory names and RFC 822 names may be more or less
   meaningful.

   9 Examples of proof include the issuing CA  generating  the  key,  or
   requiring  the subject to send an electronically signed request or to
   sign a challenge.

   10 Examples of organization identity authentication are: articles  of
   incorporation,  duly  signed corporate resolutions, company seal, and
   notarized documents.

   11 Examples of individual  identity  authentication  are:  biometrics
   (thumb  print,  ten  finger  print,  face,  palm,  and  retina scan),
   driver's  license,  passport,  credit  card,   company   badge,   and
   government badge.

   12  Examples include duly signed authorization papers or corporate ID
   badge.

   13 The identification policy for routine rekey should be the same  as
   the  one  for  initial  registration  since  the  same  subject needs
   rekeying. The rekey authentication  may  be  accomplished  using  the



Chokhani/Ford                                                  [Page 42]


Internet Draft                PKIX Part IV                      Jul 1997


   techniques for initial I&A or using digitally signed requests.

   14 This identification and authentication policy could be the same as
   that for initial registration.

   15 This policy could be the same as the one for initial registration.

   16 The identification policy for Revocation request could be the same
   as that for initial registration since the same  subject  certificate
   needs  to  be  revoked.   The  authentication  policy  could accept a
   Revocation request digitally signed by subject.   The  authentication
   information  used during initial registration could be acceptable for
   Revocation request. Other less stringent authentication policy  could
   be defined.

   17 The identification policy for key compromise notification could be
   the same as the one for initial registration since the  same  subject
   certificate  needs  to  be  revoked.  The authentication policy could
   accept  a  Revocation  request  digitally  signed  by  subject.   The
   authentication  information used during initial registration could be
   acceptable for key  compromise  notification.  Other  less  stringent
   authentication policy could be defined.

   18  The  n  out of m rule allows a key to be split in m parts.  The m
   parts may be given to m different individuals.  Any n  parts  out  of
   the m parts may be used to fully reconstitute the key, but having any
   n-1 parts provides one with no information about the key.

   19 A key may be escrowed, backed  up  or  archived.   Each  of  these
   functions  have  different  purpose.   Thus, a key may go through any
   subset of these functions depending on the requirements.  The purpose
   of  escrow  is  to  allow  a  third party (such as an organization or
   government) to legally obtain the key without the cooperation of  the
   subject.   The  purpose  of  back  up  is  to  allow  the  subject to
   reconstitute the key in case of the  destruction  of  the  key.   The
   purpose  of  archive  is  to  provide for reuse of the key in future,
   e.g., use the private key to decrypt a document.

   20 An example of activation data is a PIN or passphrase.

   21 Examples of physical access controls  are:  monitored  facility  ,
   guarded  facility,  locked  facility, access controlled using tokens,
   access controlled using biometrics, and access controlled through  an
   access list.

   22  Examples  of  the  roles  include  system  administrator,  system
   security officer, and system  auditor.   The  duties  of  the  system
   administrator  are  to  configure,  generate,  boot,  and operate the



Chokhani/Ford                                                  [Page 43]


Internet Draft                PKIX Part IV                      Jul 1997


   system.  The duties of the system  security  officer  are  to  assign
   accounts and privileges.  The duties of the system auditor are to set
   up system audit profile, perform audit  file  management,  and  audit
   review.

   23  The  background  checks  may include clearance level (e.g., none,
   sensitive, confidential, secret, top secret, etc.) and the  clearance
   granting  authority  name.   In  lieu  of or in addition to a defined
   clearance, the background checks  may  include  types  of  background
   information (e.g., name, place of birth, date of birth, home address,
   previous residences, previous employment, and any  other  information
   that  may  help  determine  trustworthiness).  The description should
   also include which information was verified and how.

   24 For example, the certificate policy may impose personnel  security
   requirements  on  the  network system administrator responsible for a
   CA's network access.

   25 Each authorized person should be accountable for his/her  actions.

   26  A  cryptographic module is hardware, software, or firmware or any
   combination of them.

   27 The compliance description should be specific  and  detailed.  For
   example,  for  each  FIPS  140-1  requirement, describe the level and
   whether the level has been certified by an accredited laboratory.

   28 Example of audit events are:  request  to  create  a  certificate,
   request   to  revoke  a  certificate,  key  compromise  notification,
   creation of a certificate, revocation of a certificate, issuance of a
   certificate,  issuance  of  a  CRL,  issuance  of key compromise CRL,
   establishment  of  trusted  roles  on  the  CA,  actions  of   truste
   personnel, changes to CA keys, etc.

   29  Example  of  archive events are: request to create a certificate,
   request  to  revoke  a  certificate,  key  compromise   notification,
   creation of a certificate, revocation of a certificate, issuance of a
   certificate, issuance of a CRL, issuance of key compromise  CRL,  and
   changes to CA keys.

   30 A parent CA is an example of audit relationship.

   31  Example  of  compliance audit topics: sample check on the various
   I&A policies,   comprehensive  checks  on  key  management  policies,
   comprehensive  checks  on  system  security  controls,  comprehensive
   checks on operations policy, and comprehensive checks on  certificate
   profiles.




Chokhani/Ford                                                  [Page 44]


Internet Draft                PKIX Part IV                      Jul 1997


   32  The  examples  include,  temporary suspension of operations until
   deficiencies are corrected, revocation of entity certificate,  change
   in   personnel,   invocation   of  liability  policy,  more  frequent
   compliance audit, etc.

   33 An organization may choose not to make public some of its security
   controls,  clearance procedures, or some others elements due to their
   sensitivity.

   34 All or some of the  following  items  may  be  different  for  the
   various types of entities, i.e., CA, RA, and end entities.

LIST OF ACRONYMS

   ABA - American Bar Association
   CA - Certification Authority
   CPS - Certification Practice Statement
   CRL - Certificate Revocation List
   DAM - Draft Amendment
   FIPS - Federal Information Processing Standard
   I&A - Identification and Authentication
   IEC - International Electrotechnical Commission
   IETF - Internet Engineering Task Force
   IP - Internet Protocol
   ISO - International Organization for Standardization
   ITU - International Telecommunications Union
   NIST - National Institute of Standards and Technology
   OID - Object Identifier
   PIN - Personal Identification Number
   PKI - Public Key Infrastructure
   PKIX - Public Key Infrastructure (X.509) (IETF Working Group)
   RA - Registration Authority
   RFC - Request For Comment
   URL - Uniform Resource Locator
   US - United States
















Chokhani/Ford                                                  [Page 45]