[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 5217

Network Working Group                                        M. Shimaoka
Request for Comments: DRAFT                              SECOM Trust.net
<draft-shimaoka-multidomain-pki-00.txt>                        June 2003


                      Memorandum for multi-domain
            Public Key Infrastructure (PKI) Interoperability


Status of this Memo

   This memo is a guideline for the multi-domain PKI interoperability.
   This is a best current practice, not a specification. Distribution of
   this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This memo is used to share the awareness necessary to deployment of
   multi-domain PKI. Scope of this memo is to establish trust
   relationship and interoperability between plural PKI domains.  Both
   single-domain PKI and multi-domain PKI are established by the trust
   relationships between Certification Authorities (CAs).  Typical and
   primitive PKI models are specified as single-domain PKI.  Multi-
   domain PKI established by plural single-domain PKI is categorized as
   multi-trust point model and single-trust point model. Multi-trust
   point model is based on trust list model, and single-trust point
   model is based on cross-certification.

Table of Contents

   1  Introduction      . . . . . . . . . . . . . . . . . . . . . . . .  2
   2  Requirements and Assumptions    . . . . . . . . . . . . . . . . .  3
   2.1  Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.2  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3  Trust Relationship  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.1  Trust List  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.1.1  User Trust List . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1.2  Authority Trust List  . . . . . . . . . . . . . . . . . . . .  5
   3.2  Cross-Certification . . . . . . . . . . . . . . . . . . . . . .  6
   3.2.1  Unilateral Cross-Certification  . . . . . . . . . . . . . . .  7
   3.2.2  Mutual Cross-Certification  . . . . . . . . . . . . . . . . .  8
   3.3  Subordination (Hierarchy) . . . . . . . . . . . . . . . . . . .  8
   4  Single-domain PKI . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.1  Single PKI model  . . . . . . . . . . . . . . . . . . . . . . .  9



SHIMAOKA                                                        [Page 1]

INTERNET DRAFT                                                 June 2003


   4.2  Hierarchy PKI model . . . . . . . . . . . . . . . . . . . . . . 10
   4.3  Mesh PKI model  . . . . . . . . . . . . . . . . . . . . . . . . 10
   5  multi-domain PKI  . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.1  Multi Trust point model (based on Trust List) . . . . . . . . . 11
   5.1.1  Based on User Trust List    . . . . . . . . . . . . . . . . . 11
   5.1.2  Based on Authority Trust List . . . . . . . . . . . . . . . . 12
   5.2  Single Trust Point model (based on Cross-Certification) . . . . 12
   5.2.1  Peer-to-Peer model (based on Cross-Certification) . . . . . . 12
   5.2.2  Super Domain model (based on unilateral Cross-Certification). 13
   5.2.3  Hub model (a.k.a Bridge CA) . . . . . . . . . . . . . . . . . 13
   6  Security Considerations . . . . . . . .  .  . . . . . . . . . . . 13
   6.1  Certificate and CRL Profile . . . . . . . . . . . . . . . . . . 13
   6.2  Repository      . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.3  Path Validation . . . . . . . . . . . . . . . . . . . . . . . . 14
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . 14
   9  Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 15
   10  Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15

1  Introduction

   PKI is able to achieve various architecture, through the means that
   CAs establish trust relationship with each other.  When a certain CA
   establishes a trust relationship with another CA, the CA MUST compare
   the policy of each CAs carefully because various CAs have various
   policy. So, establishment method for every trust relationship MAY
   differ by the result of comparison.  To establish appropriate trust
   relationship, fully understanding about a relationship between such
   establishment method and comparison is required.  In addition, all
   trust relationships established are able to categorize  two patterns,
   single-domain PKI and multi-domain PKI.  The technology needed for
   such an interconnection is insufficient with only the specification
   of conventional protocol and data format and need to define the thing
   such as PKI domain and PKI architecture.  This document clarifies
   these definitions for multi-domain PKI interoperability.

   Section 2 describes the terminology necessary to consider multi-
   domain PKI. Section 3 categorizes the trust relationships between CAs
   as Trust List, Cross-Certification, and Subordination. Section 4
   defines major models necessary to establish single-domain PKI.
   Section 5 profiles multi-domain PKI as multi trust point model and
   single trust point model. Multi-trust point model is based on trust
   list model. Single-trust point model is based on cross-certification
   model , and is categorized as peer model, super domain model and hub
   model. Finally, section 6 describes considerations focused on
   Certificate and Certificate Revocation List (CRL) profiles,
   Repository, and path validation.




SHIMAOKA                                                        [Page 2]

INTERNET DRAFT                                                 June 2003


2  Requirements and Assumptions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

2.1  Abbreviations

   PKI:  Public Key Infrastructure

   CA:   Certification Authority

   EE:   End Entity

   CRL:  Certificate Revocation List

   ARL:  Authority Revocation List

2.2  Terminology

   Subscriber

     Holder of the certificate which is verified.

   Relying Party

     Entity who verifies the certificate.

   Top CA

     Only CA that is as a root of hierarchy PKI model.  Top CA MUST
     issue a self-signed certificate.  Top CA SHOULD be used for
     Hierarchy PKI model.

   PKI domain

     A set of PKIs, which gathers upon a certain trust relationship, and
     MUST share a certain policy, at least one.
        Essentially, PKI domain is only a view from relying party
        outside of subscriber domain.

   Domain Policy

     A set of certificate policies what are shared in a PKI domain.

   Trust Point

     Starting point of a certification path to SUBSCRIBER certificate.



SHIMAOKA                                                        [Page 3]

INTERNET DRAFT                                                 June 2003


     Trust Point MUST be a self-signed certificate, except for Mesh PKI
     model.

   Principal CA

     A CA that trusts other PKI domain or is trusted from other PKI
     domain.  Principal CA SHOULD issue a self-signed certificate.

   Trust Anchor

     Trust anchor is a principal CA in RELYING PARTY domain, and is also
     one of trust points.  Trust Anchor SHOULD be a self-signed
     certificate, except for Mesh PKI model.

     If it is necessary to claim clearly that CA is a trust anchor of an
     issued certificate, CA MAY indicate URI of its published CA
     certificate to caIssuer in AuthorityInformationAccess extension.

   Trust Relationship

     In this document, this means a trust relation ship between CAs.
     This relationship is required for tracking from a trust point to a
     subscriber.

   Validation parameters

     This is a term for only this document. Five parameters that are
     part of seven inputs for path validation defined in section 6.1.1
     of RFC3280.
        (c) user-initial-policy-set
        (d) trust anchor information,
        (e) initial-policy-mapping-inhibit
        (f) initial-explicit-policy
        (g) initial-any-policy-inhibit
     As these parameters MAY NOT be depended on a built certification
     path and validation time, these parameters are bound to a trust
     point and are able to consider without two parameters '(a) a
     prospective certification path of length n' and '(b) the current
     date/time'.

3  Trust Relationship

   This section describes major trust relationships for plural PKI
   interconnection.  All PKIs that are going to participate in multi-
   domain PKI SHOULD use these trust relationships for multi-domain PKI
   interoperability.

3.1  Trust List



SHIMAOKA                                                        [Page 4]

INTERNET DRAFT                                                 June 2003


   Definition

     Trust list is a list of more than one CA certificate that means a
     trust point.  Trust list is used for specifying a trust point by
     relying party.

   Requirements

     CA in a trust list SHOULD NOT cross-certify each other.  All
     relying parties in this model MUST have a trust list.

   Considerations

     TBD

3.1.1  User Trust List

   Definition

     The model in which a trust list is managed by End Entitiy (EE).  EE
     is able to have its own user trust list individually.


   Advantage

     EE is able to manage its own user trust list.  EE is able to add
     any CA certificate to its own user trust list or delete it.  This
     is an easier and typical method for making a trust relationship to
     other PKI.

   Disadvantage

     Except for EE itself, anyone is not able to control the trust
     relationship.  If EE trusts unknown PKI domain irresponsibly, then
     its issuer CA cannot apply their security policy to the EE.

   Considerations

     To consider how to update the user trust list, when CA certificate
     in the user trust list is updated.

3.1.2  Authority Trust List

   Definition







SHIMAOKA                                                        [Page 5]

INTERNET DRAFT                                                 June 2003


     The model in which a trust list is issued by the trust anchor of
     relying party.  All EEs who share the same trust anchor SHOULD
     share a single authority trust list provided by its trust anchor.

   Advantage

     EE cannot control its trust relationship from its trust anchor to
     other.  Authority SHOULD control trust relationship.

   Disadvantage

     Management method for authority trust list is not established.

   Considerations

     To consider about a format of the authority trust list that is able
     to be processed by various applications.  To consider about a
     management method for the authority trust list.

3.2  Cross-Certification

   Definition

     Cross-Certification is an issuing certificate to another CA.

   Requirement

     CA issued cross-certificate SHOULD have a self-signed certificate.

   Advantage

     Cross-Certification is stricter trust relationship than the trust
     list model, because the trust relationship is indicated by a
     certificate and (authority) revocation list and is recorded to an
     audit log.  Because all subject CAs have a self-signed certificate,
     a cross-certificate revocation does not always link to the subject
     CA compromise.

   Disadvantage

     CA MUST support cross-certification.

   Considerations

     for path construction

        Subject CA SHOULD issue a cross-certification request which
        contains subjectKeyIdentifier in extensionRequest, and its value



SHIMAOKA                                                        [Page 6]

INTERNET DRAFT                                                 June 2003


        MUST be identical with subjectKeyIdentifier in self-signed
        certificate.  Issuer CA SHOULD issue a cross-certificate which
        contains subjectKeyIdentifier set to the same value in the
        corresponding cross-certification request.

     for PKI issuing Revocation List

        Issuer CA MAY issue Authority Revocation List (ARL), or SHOULD
        issue fullCRL at least.  However, ARL including
        issuingDistributionPoint extension MAY NOT be processed by some
        applications.

     for CA Key Rollover

        TBD

3.2.1  Unilateral cross-certification

   Definition

     The model in which a CA issues a cross-certificate to another CA
     unilaterally.

   Advantage

     This certification is able to use like subordination, and is able
     to establish more flexible trust relationship.  Even if cross-
     certificate is revoked, subject CA MAY be able to continue its
     operation.

   Disadvantage

     for PKI using directory system

        CA SHOULD generate a crossCertificatePair, even though
        unilaterally.


   Considerations

     Subordination is peculiar unilateral cross-certification.  If a
     cross-certification request is got by any CA, unilateral cross-
     certification is established easily without agreement from
     requested CA.

     for PKI using directory system

        Issuer CA MUST store a cross-certificate, which he issued, to



SHIMAOKA                                                        [Page 7]

INTERNET DRAFT                                                 June 2003


        issuedByThisCA element of crossCertificatePair attribute in its
        own directory entry, except subordinate CA certificate.  Subject
        CA SHOULD store an issued cross-certificate to issuedToThisCA
        element of crossCertificatePair attribute in its own directory
        entry, except subordinate CA certificate.

3.2.2  Mutual cross-certification

   Definition

     The model in which a CA issues a cross-certificate to another CA
     mutually.


   Advantage

     TBD

   Disadvantage

     for PKI using directory system

        Both CAs MUST generate a crossCertificatePair that is composed
        of a cross-certificate it issued and the corresponding issued
        cross-certificate.  When either CA updates a cross-certificate,
        each CA MUST re-generate their crossCertificatePair
        synchronously.

   Considerations

     Both CAs MUST agree about more information to issue a cross-certificate (e.g., validity, keyUsage, and some constraints) and MUST exchange it.

     for PKI using directory system

        Each CAs MUST generate a crossCertificatePair that is composed
        by cross-certificate it issues and issued cross-certificate.
        for issuing cross-certificate

3.3  Subordination (Hierarchy)

   Subordination is a peculiar unilateral cross-certification.


   Definition

     Subordination is certificate issuing to CA that has no self-signed
     certificate.  Subordinate CA MUST have only one superior CA.




SHIMAOKA                                                        [Page 8]

INTERNET DRAFT                                                 June 2003


        In unilateral cross-certification, subject CA MAY have some
        issuer CAs.


   Advantage

     Subordinate CA MAY NOT require any accreditation, rather the
     accreditation is required only for superior CA or top CA.
     Subordinate CA is able to inherit some policies and constraints
     from its superior CA.  Because Subordinate CA has clear trust
     relationship with its superior CA, the subordinate CA is able to be
     trusted easily by all EEs who trust the superior CA.

   Disadvantage

     Subordinate CA MUST NOT cross-certify any CAs , MAY just allow
     subordination.  When a subordinate CA certificate is revoked by a
     superior CA, also all certificates issued by the subordinate CA
     MUST NOT be trusted.

   Considerations

     Subordination MUST be used in Single-domain PKI, not multi-domain
     PKI.

     for PKI using directory system

        Superior CA MUST NOT store a subordinate CA certificate to
        issuedByThisCA element of crossCertificatePair attribute in its
        own (superior CA) entry, because path construction will work
        inefficiently.  Subordinate CA MAY store its own subordinate CA
        certificate to issuedToThisCA element of crossCertificatePair
        attribute in its own (subordinate CA) entry.  Subordinate CA
        MUST store its own subordinate CA certificate to cACertificate
        attribute in its own entry.

4  Single-domain PKI

   This section describes appropriate PKI architectures for single PKI
   domain.  All PKIs that are going to participate in multi-domain PKI
   SHOULD adopt any models of the following for multi-domain PKI
   interoperability.

4.1  Single PKI model

   This is simplest PKI model. All PKI models are composed of set of
   this.




SHIMAOKA                                                        [Page 9]

INTERNET DRAFT                                                 June 2003


   Definition

     Single PKI is composed of an only top CA and its EEs.  All EEs
     SHOULD trust only the top CA.  All subscribers MUST be issued their
     certificate by the only top CA.

   Principal CA

     Principal CA MUST be the top CA.

   Trust anchor

     Trust anchor MUST be the top CA.

4.2  Hierarchy PKI model

   This is a typical architecture of PKI.


   Definition

     Hierarchy PKI is composed of an only top CA, some subordinate CAs
     and EEs.  Only a Top CA MUST issue a self-signed certificate.  All
     subordinate CAs MUST have only one superior CA.

   Principal CA

     Principal CA MUST be the top CA.

   Trust anchor

     Trust anchor MUST be the top CA.  All EEs SHOULD trust only a top
     CA.

4.3  Mesh PKI model

   Definition

     Mesh PKI is composed of plural CAs and their EEs.  All CAs MUST
     cross-certify more than one CA unilaterally, and MUST be cross-
     certified by more than one CA unilaterally.

   Principal CA

     Principal CA SHOULD be unique in the domain.


   Trust anchor



SHIMAOKA                                                       [Page 10]

INTERNET DRAFT                                                 June 2003


     Trust anchor SHOULD be a CA which issued a certificate to relying
     party.


   Considerations

     All EEs MUST trust only a CA that issued their own certificate.
     Which SHOULD be a principal CA for foreign PKI domain?

5  multi-domain PKI

   Multi-domain PKI is composed of plural PKI domain that MUST have
   different domain policy which is able to map each other.  Each PKI
   domain establishes a trust relationship with more than one PKI
   domain.

   This section describes topology models for multi-domain PKI.  All
   PKIs that compose multi-domain PKI SHOULD adopt any models of the
   following  for multi-domain PKI interoperability.

   Considerations

     Required all information for path validation MUST be able to be
     obtained through Internet.
        - Intermediate certificate
        - Revocation information
     For this, CA MAY operate a repository, and SHOULD include
     authorityInfoAccess or cRLDistributionPoints extensions in the
     certificates it issues.

5.1  Multi Trust point model (based on Trust List)

   The model in which a relying party trusts plural domains by a trust
   list.  Relying-party is able to use trust list for specifying the
   trust point in other domains.  Trust list is a list of more than one
   CA certificate as a principal CA certificate in another domain.


   Considerations

     The CA in a trust list SHOULD not cross-certify each other.  The
     validation parameters SHOULD be given to each trust point
     individually.

5.1.1  Based on User Trust List

   Considerations




SHIMAOKA                                                       [Page 11]

INTERNET DRAFT                                                 June 2003


     This is an easier and typically method for making a trust
     relationship to other PKI domain.  Relying-Party is able to
     establish trust relationship with other domain irresponsibly to his
     trust anchor.  When CA updated the certificates, what relying party
     recognizes it is difficult.  Relying-party MAY need to obtain some
     inputs, e.g.,user-initial-policy-set, initial-policy-mapping-
     inhibit, initial-explicit-policy and initial-any-policy-inhibit,
     for path validation from somewhere.

5.1.2  Based on Authority Trust List

   Authority MAY distribute the validation parameters by including in
   the trust list.

   Considerations

     Relying-party MAY need to obtain some inputs, e.g.,user-initial-
     policy-set, initial-policy-mapping-inhibit, initial-explicit-policy
     and initial-any-policy-inhibit, for path validation from somewhere.

5.2  Single Trust Point model (based on Cross-Certification)

   The model in which all domains related by Cross-Certification.  In
   this model, a trust point is just a trust anchor. Therefore,
   certification path always start from trust anchor of relying party.



   Considerations

     Each domain SHOULD use policy mapping for indicating different
     domain. In addition, cross-certificate SHOULD set zero to
     requireExplicitPolicy in the policyConstraints extension, and MAY
     set any value to inhibitPolicyMappings in the policyConstraints
     extension. If the domain does not use policy mapping, it MAY seem
     same domain.

     All certification path MUST be started from the only trust anchor,
     then validation parameters MAY be an only set.

     Cross-Certificate SHOULD use authorityKeyIdentifier extension and
     subjectKeyIdentifier extension for path construction.

5.2.1  Peer-to-Peer model (based on Cross-Certification)

   The model in which two peer domains trust each other by Cross-
   Certification.  This trust relationship SHOULD be established by
   mutual Cross-Certification, or MAY be established by unilateral



SHIMAOKA                                                       [Page 12]

INTERNET DRAFT                                                 June 2003


   Cross-certification.

   In Cross-Certification model, because trust-anchor is an only one,
   the validation parameters SHOULD be authority-constrained things.

5.2.2  Super Domain model (based on unilateral Cross-Certification)

   The model in which plural domains have a common superior CA that
   issues cross-certificates to each domain unilaterally.  Each domain
   MUST have a certain common certificate policy at least.

   This model looks like a subordination model, except for that the
   intermediate CA has a self-signed certificate.  Therefore, often this
   model is used as hierarchy model in multi-domain PKI.

5.2.3  Hub model (a.k.a Bridge CA)

   The model in which every domains trust each other through a Bridge CA
   by Cross-Certification.  This is useful to reduce the complexity of
   cross-certification.

   Considerations

     Bridge CA SHOULD be operated by neutral trusted third party.
     Bridge CA SHOULD do policy mapping appropriately with both domains.
     Both domains that cross-certified to Bridge CA SHOULD NOT use
     nameConstraints extension because they cannot limit name-spaces via
     Bridge CA.  Bridge CA MUST have an independent certificate policy,
     and MUST use it for policy mapping for both domains.

6  Security Considerations

6.1  Certificate and CRL Profile

   To define the Certificate and CRL profile for multi-domain PKI
   interoperability is not scope of this memo.  CA in multi-domain PKI
   SHOULD consider about the following  for the Certificate and CRL
   profile.

     * Authority Key Identifier extension and Subject Key Identidier
     extension SHOULD be used for aiding a path construction.

     * Certificate Policies extension SHOULD be used for identifying
     each policy domain.

     * Policy Mapping extension MAY be used for policy mapping in single
     trust point model.




SHIMAOKA                                                       [Page 13]

INTERNET DRAFT                                                 June 2003


     * Name Constraints extension MAY NOT be used for multi-domain PKI
     because name space of multi-domain PKI is not managed by anyone.

     * Policy Constraints extension MAY be used for path validation of
     foreign PKI domain.

6.2  Repository

   Relying party must obtain all required information for path
   construction and validation.  If necessary, CA issues a certificate
   including Authority Information Access extension or CRL Distribution
   Points extension for aiding in that a relying party does the path
   construction.

6.3  Path Validation

   Validation parameters used for path validation SHOULD be intersection
   between authority-constrained parameters and user-constrained
   parameters.  Non certificate holders MUST determine carefully their
   validation parameters including the trust anchor.

7  References

7.1  Normative References

      [PKIX]      Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
                  X.509 Public Key Infrastructure Certificate and CRL
                  Profile", RFC 3280, April 2002.

      [INTEROP]   Lloyd, S., PKI Forum, "PKI Interoperability Framework",
                  March 2001.

      [CA-CA]     Lloyd, S., PKI Forum,  "CA-CA Interoperability", March
                  2001.

      [ISO-X509]  ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
                  Technology - Open Systems Interconnection: The Directory:
                  Authentication Framework," 2001 edition.

7.2  Informative References

   TBD

8  Acknowledgements

   This document is based on some valuable documents and many
   experiences with PKI interoperability experiments.  The authors
   gratefully acknowledge the contributions of members of various multi-



SHIMAOKA                                                       [Page 14]

INTERNET DRAFT                                                 June 2003


   domain PKI interoperability experiments, in particular: Kenji Nakada,
   Kiyoshi Watanabe, Sang Hwan Park, Ryu Inada, Hiroyuki Yoshida and
   Yasushi Matsumoto.

   The author are also grateful to members of the Internet Engineering
   Task Force (IETF) Public Key Infrastructure working group (PKIX), and
   the Technical Working Group in Interoperability Working Group, which
   is consisted of Japan PKI Forum, Korea PKI Forum, Singapore PKI Forum
   and Chinese Taipei PKI Forum (JKST-IWG) for ideas and useful
   discussions which helped us in this effort.  This work is aided by
   Information-technology Promotion Agency Information-technology
   Security Center (IPA/ISEC) and Japan Network Security Association
   (JNSA).

9  Author's Address

   Masaki SHIMAOKA
   SECOM Trust.net Co., Ltd.
   SECOM SC Center, 8-10-16, Shimorenjaku
   Mitaka, Tokyo JAPAN

   Email: shimaoka@secom.ne.jp



10  Full Copyright Statement

   "Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING



SHIMAOKA                                                       [Page 15]

INTERNET DRAFT                                                 June 2003


   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.















































SHIMAOKA                                                       [Page 16]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/