PKIX Working Group                S. Chokhani (CygnaCom Solutions, Inc.)
Internet Draft                                  W. Ford (VeriSign, Inc.)

Expires in six months from                          September 30, 1997


                   Internet Public Key Infrastructure
        Certificate Policy and Certification Practices Framework

                  <draft-ietf-pkix-ipki-part4-02.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



Chokhani/Ford                                                   [Page 1]


Internet Draft                    PKIX                    September 1997


      with use of the corresponding private key (this entity is known as
      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                    September 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                    September 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.

      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).   [Note:   The  term Local
      Registration Authority  (LRA)  is  used  elsewhere  for  the  same
      concept.]

      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.

      Set of  provisions  -  A  collection  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.

      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



Chokhani/Ford                                                   [Page 4]


Internet Draft                    PKIX                    September 1997


      entity  (the  certificate  subject).  However, the extent to which
      the certificate user should rely on that statement by the CA needs
      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



Chokhani/Ford                                                   [Page 5]


Internet Draft                    PKIX                    September 1997


      Wide  Web  browsers  to  servers for general information retrieval
      purposes. The key pairs may  be  generated,  stored,  and  managed
      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



Chokhani/Ford                                                   [Page 6]


Internet Draft                    PKIX                    September 1997


         values  for  each  identified  policy;  use  of  qualifiers  is
         discussed in Section 3.4.

         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                    September 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                    September 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                    September 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                    September 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                    September 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  SET OF PROVISIONS

      A  set  of  provisions  is  a collection 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  set  of
      provisions.

      A  CPS  can  be  expressed as a single set of provisions with each
      component addressing the requirements of one or  more  certificate
      policies, or, alternatively, as an organized collection of sets of
      provisions.   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 set of provisions
         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 set of provisions 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 set  of  provisions,  in
      terms of eight primary components, as follows:



Chokhani/Ford                                                  [Page 12]


Internet Draft                    PKIX                    September 1997


         * 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.  CONTENTS OF A SET OF PROVISIONS

   This section expands upon the contents of a  set  of  provisions,  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
   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



Chokhani/Ford                                                  [Page 13]


Internet Draft                    PKIX                    September 1997


   parameterized definitions.  The set of provisions 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  set  of  provisions,
      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 set of
         provisions.

      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
            all other uses for the certificates.)




Chokhani/Ford                                                  [Page 14]


Internet Draft                    PKIX                    September 1997


            * 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:

         * Obligations;

         * Liability;

         * 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                    September 1997


      4.2.1  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;
               and
               *   Acknowledgment   of  applicable  liability  caps  and
               warranties.

            * Repository obligations

               *  Timely  publication  of  certificates  and  revocation
               information












Chokhani/Ford                                                  [Page 16]


Internet Draft                    PKIX                    September 1997


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








Chokhani/Ford                                                  [Page 17]


Internet Draft                    PKIX                    September 1997


      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.

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



Chokhani/Ford                                                  [Page 18]


Internet Draft                    PKIX                    September 1997


            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;

            *  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



Chokhani/Ford                                                  [Page 19]


Internet Draft                    PKIX                    September 1997


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

            * 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)








Chokhani/Ford                                                  [Page 20]


Internet Draft                    PKIX                    September 1997


      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:

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








Chokhani/Ford                                                  [Page 21]


Internet Draft                    PKIX                    September 1997


      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.

      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




Chokhani/Ford                                                  [Page 22]


Internet Draft                    PKIX                    September 1997


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

      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



Chokhani/Ford                                                  [Page 23]


Internet Draft                    PKIX                    September 1997


               - Protection against deletion of archive.

            * Archive backup procedures;

            * Requirements for time-stamping of records;

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

            * Procedures to obtain and verify archive information.

      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.










Chokhani/Ford                                                  [Page 24]


Internet Draft                    PKIX                    September 1997


      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.

      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.












Chokhani/Ford                                                  [Page 25]


Internet Draft                    PKIX                    September 1997


      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.

      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;



Chokhani/Ford                                                  [Page 26]


Internet Draft                    PKIX                    September 1997


            *  Frequency  and  sequence  for  job rotation among various
            roles;

            * Sanctions  against  personnel  for  unauthorized  actions,
            unauthorized  use  of  authority,  and  unauthorized  use of
            entity systems; (25)

            * Controls on contracting personnel, including:

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

            * Documentation to be supplied to personnel.

   4.6  TECHNICAL SECURITY CONTROLS

      This  component  is  used to define the security measures taken by
      the issuing CA to protect its cryptographic  keys  and  activation
      data  (e.g.,  PINs, passwords, or manually-held key shares).  This
      component may also be used to impose constraints on  repositories,
      subject  CAs  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;



Chokhani/Ford                                                  [Page 27]


Internet Draft                    PKIX                    September 1997


         * Computer Security Controls;

         * Life-Cycle Security Controls;

         * Network Security Controls; and

         * Cryptographic Module Engineering Controls.




      4.6.1  Key Pair Generation and Installation

         Key  pair generation and installation need to be considered for
         the issuing CA, repositories, subject CAs, RAs, and subject end
         entities.   For  each of these types of entities, the following
         questions potentially need to be answered:

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

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

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

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










Chokhani/Ford                                                  [Page 28]


Internet Draft                    PKIX                    September 1997


      4.6.2  Private Key Protection

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

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

            2. Is  the  private  key  under  n  out  of  m  multi-person
            control?(18)  If yes, provide n and m (two person control is
            a special case of n out of m, where n = m = 2)?

            3. Is the private key escrowed?  (19)  If  so,  who  is  the
            escrow  agent,  what  form  is the key escrowed in (examples
            include plaintext, encrypted, split key), and what  are  the
            security controls on the escrow system?

            4.  Is  the private key backed up?  If so, who is the backup
            agent, what form is the key backed up in  (examples  include
            plaintext,  encrypted, split key), and what are the security
            controls on the backup system?

            5. Is the private key archived?  If so, who is the  archival
            agent,  what  form  is the key archived in (examples include
            plaintext, encrypted, split key), and what are the  security
            controls on the archival system?

            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.




Chokhani/Ford                                                  [Page 29]


Internet Draft                    PKIX                    September 1997


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

      4.6.3  Other Aspects of Key Pair Management

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

            1. Is the public key archived?  If so, who is  the  archival
            agent  and  what  are  the security controls on the archival
            system?   The  archival  system  should  provide   integrity
            controls  other  than digital signatures since: the archival
            period may be greater than the cryptanalysis period for  the
            key and the archive requires tamper protection, which is not
            provided by digital signatures.

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

      4.6.4  Activation Data

         Activation  data refers to data values other than keys that are
         required to operate cryptographic modules and that need  to  be
         protected.  (20)   Protection  of  activation  data potentially
         needs to be considered for the issuing CA,  subject  CAs,  RAs,
         and  end  entities.   Such  consideration  potentially needs to
         address the entire  life-cycle  of  the  activation  data  from
         generation  through  archival and destruction.  For each of the
         entity types (issuing CA, repository, subject CA, RA,  and  end
         entity)  all  of  the  questions  listed in 4.6.1 through 4.6.3
         potentially need to be answered with respect to activation data
         rather than with respect to keys.

      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



Chokhani/Ford                                                  [Page 30]


Internet Draft                    PKIX                    September 1997


         Products  Evaluation  Criteria, European Information Technology
         Security Evaluation Criteria (ITSEC), or the  Common  Criteria.
         This  subcomponent  can  also  address requirements for product
         evaluation analysis, testing, profiling, product certification,
         and/or product accreditation related activity undertaken.

      4.6.6  Life Cycle Security Controls

         This  subcomponent  addresses  system  development controls and
         security management controls.

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

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


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

      4.6.7  Network Security Controls

         This subcomponent addresses network security related  controls,
         including firewalls.

      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)





Chokhani/Ford                                                  [Page 31]


Internet Draft                    PKIX                    September 1997


   4.7  CERTIFICATE AND CRL PROFILES

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

      This component has two subcomponents:

         * Certificate Profile; and

         * CRL Profile.


      4.7.1  Certificate Profile

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

            * Version number(s) supported;

            * Certificate extensions populated and their criticality;

            * Cryptographic algorithm object 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.












Chokhani/Ford                                                  [Page 32]


Internet Draft                    PKIX                    September 1997


      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 certificate
      policy definition or CPS will be maintained.

      It contains the following subcomponents:

         * Specification Change Procedures;

         * Publication and Notification Procedures; and

         * CPS Approval Procedures.




      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



Chokhani/Ford                                                  [Page 33]


Internet Draft                    PKIX                    September 1997


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

      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. OUTLINE OF A SET OF PROVISIONS

   This  section  contains  a  possible outline for a set of provisions,
   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.



Chokhani/Ford                                                  [Page 34]


Internet Draft                    PKIX                    September 1997


      (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
      1.4.2  Contact person
      1.4.3  Person determining CPS suitability for the policy

   2.  GENERAL PROVISIONS

   2.1  Obligations

      2.1.1  CA obligations
      2.1.2  RA obligations
      2.1.3  Subscriber obligations
      2.1.4  Relying party obligations 2.1.5  Repository obligations

   2.2  Liability

      2.2.1  CA liability
      2.2.2  RA liability

   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




Chokhani/Ford                                                  [Page 35]


Internet Draft                    PKIX                    September 1997


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



Chokhani/Ford                                                  [Page 36]


Internet Draft                    PKIX                    September 1997


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



Chokhani/Ford                                                  [Page 37]


Internet Draft                    PKIX                    September 1997


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




Chokhani/Ford                                                  [Page 38]


Internet Draft                    PKIX                    September 1997


   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

   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




Chokhani/Ford                                                  [Page 39]


Internet Draft                    PKIX                    September 1997


   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

6.  SECURITY CONSIDERATIONS

   This entire memo deals with security.

7.  ACKNOWLEDGMENTS

   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. Special  thanks  are
   due  to  Dave  Fillingham,  Jim Brandt, and Edmond Van Hees for their
   inspiration, support, and  valuable inputs.

   The following individuals also deserve credit 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;



Chokhani/Ford                                                  [Page 40]


Internet Draft                    PKIX                    September 1997


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

   [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,  X.509 Certificate and CRL Profile," RFC [tbd], 1997.

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



Chokhani/Ford                                                  [Page 41]


Internet Draft                    PKIX                    September 1997


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




Chokhani/Ford                                                  [Page 42]


Internet Draft                    PKIX                    September 1997


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



Chokhani/Ford                                                  [Page 43]


Internet Draft                    PKIX                    September 1997


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



Chokhani/Ford                                                  [Page 44]


Internet Draft                    PKIX                    September 1997


   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.

   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

   36




Chokhani/Ford                                                  [Page 45]


Internet Draft                    PKIX                    September 1997





















































Chokhani/Ford                                                  [Page 46]