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

Versions: 00

          Internet-Draft                              B. Blakley (IBM)
          IETF PKIX WG                      and the APKI Working Group
          draft-ietf-pkix-apki-00.txt                    November 1996
          
                   Architecture for Public-Key Infrastructure
          
          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 six months. Internet Drafts may be updated, replaced,
             or obsoleted by other documents at any time. It is not
             appropriate to use Internet Drafts as reference material
             or to cite them other than as a "working draft" or "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 ds.internic.net,
             nic.nordu.net, ftp.isi.edu, or munnari.oz.au.
          
             Comments and suggestions on this document are encouraged.
             Of particular interest are interfaces and protocols which
             may have been omitted and specifications which are
             believed to be suitable bases for standardization of APKI
             interfaces and protocols.  Comments on this document
             should be sent to the APKI WG discussion list:
          
                    pki-tg@opengroup.org
          
          ABSTRACT
          
             This document describes Requirements and an Architecture
             for Public-Key Infrastructure components, identifies
             which elements of the architecture should (in the opinion
             of the authors) be standardized, and identifies candidate
             interface and protocol specifications which might serve
             as base documents for the standardization effort.
          
          
          
          
          
          Blakley          Document Expires: May 1997         [Page 1]


          Internet-Draft              APKI               November 1996
          
          
          
          ACKNOWLEDGMENTS
          
             Members of the APKI working group contributing
             substantially to this document include:
          
             Anne Anderson (HP), Charles Blauner (JP Morgan), Belinda
             Fairthorne (ICL), Warwick Ford, Robert Jueneman (Novell),
             Ellen McDermott (Open Market), Howard Melman (OSF), Denis
             Pinkas (Groupe Bull), Walt Tuvell (OSF), and John Wray
             (Digital Equipment Corporation).
          
             Many other working group members contributed important
             insights during conversations of the material in this
             document.
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Blakley          Document Expires: May 1997         [Page 2]


          Internet-Draft              APKI               November 1996
          
          
          
          CONTENTS
          
             1.  Requirements .......................................  4
             1.1  Baseline Requirements .............................  4
             1.2  The Importance of Architecture .................... 10
             1.3  Document Overview ................................. 14
          
             2.  Overview of the PKI Architecture ................... 15
          
             3.  Public-Key Infrastructure Components ............... 16
             3.1  Crypto Primitive Components ....................... 17
             3.2  Crypto Service Components ......................... 19
             3.3  Long-Term Key Services Components ................. 22
             3.4  Protocol Security Services Components ............. 29
             3.5  Secure Protocol Components ........................ 33
             3.6  System Security Enabling Components ............... 35
             3.7  Security Policy Services Components ............... 36
             3.8  Supporting Services Components .................... 37
          
             4.  Hardware Security Devices in the Architecture ...... 37
          
             5.  Relationship to Other Standards and Architectures .. 39
             5.1  ISO 7498-2 ........................................ 39
             5.2  IETF IPKI Drafts .................................. 39
             5.3  X/Open XDSF ....................................... 39
             5.4  ECMA TR-46 ........................................ 39
             5.5  RSA PKCS Standards ................................ 39
          
             6.  Example Applications of the Architecture ........... 40
             6.1  OSF DCE 1.1 ....................................... 40
             6.2  SESAME ............................................ 40
             6.3  Nortel Entrust .................................... 40
             6.4  OMG CORBA ......................................... 40
             6.5  Lotus Notes ....................................... 40
             6.6  Novell Netware .................................... 40
          
             7.  Glossary ........................................... 40
          
             8.  Security Considerations ............................ 40
          
             9.  References ......................................... 40
          
          
          
          
          
          
          
          Blakley          Document Expires: May 1997         [Page 3]


          Internet-Draft              APKI               November 1996
          
          
          
          1.  Requirements
          
             The following requirements have been collected by the
             Open Group (OSF - X/Open) Security Program Group Public
             Key Infrastructure (PKI) Task Group (TG), with the
             participation of the following organizations:
          
             Barclays Bank, Shell International, Sweden Post, UK
             Ministry of Defense, BCTEL, US DISA, The Open Group,
             Telecom Finland Ltd., Pacific Gas & Electric, Electronic
             Data Systems, Jet Propulsion Laboratory, Boeing,
             Information & Support Group, Harris Corporation, ICL,
             Lockheed Martin, Guide International, J P Morgan, IBM,
             Bellcore, Nortel, HP, NIST, SUN, Siemens Nixdorf,
             Dynasoft, SCO, Bull, NCR, US NSA, Digital Equipment
             Corporation, Amdahl, OpenVision, Citicorp, Fujitsu-ICL,
             Mitre.
          
             The Open Group PKI TG continues to refine and extend
             these requirements; comments should be sent by electronic
             mail to OGsecurity@opengroup.org.
          
          1.1  Baseline Requirements for a Global PKI and PK Services
          
             An interoperable global PKI is required to provide
             privacy and digital signature services in support of
             international commerce, balancing the legitimate needs of
             commerce, governments and privacy of citizens. The global
             PKI must support multiple governance policy models within
             a single global PKI framework, and must enable the
             enforcement of all existing governance policy mandates.
          
          1.1.1  Required Services
          
          
            A.  Establishment of domains of trust and governance
            B.  Confidentiality (sealing)
            C.  Integrity and authentication (signing)
            D.  Non-repudiation
            E.  End-to-end monitoring, reporting and auditing of PKI
                services
          
          1.1.2  Required Functionality and Characteristics
          
          
          
          
          
          Blakley          Document Expires: May 1997         [Page 4]


          Internet-Draft              APKI               November 1996
          
          
          
            A.  Key life-cycle management
          
                The actual life cycle of a key depends on whether it
                is used for confidentiality or signature purposes.
                Key life-cycle facilities to be supported are:
          
                  1.  Key recovery facilities
          
                      The PKI shall provide for key recovery.  Key
                      recovery facilities shall provide the following
                      functionality:
          
                           i.  Use of key recovery facilities implies
                               acceptance of a mandatory policy for
                               the protection and recovery of keys.
                               The policy defines how the keys are to
                               be protected and under what conditions
                               and to whom a key will be made
                               available.  The mandatory aspect of
                               policy  arises as the operations of a
                               key recovery facility may be regulated
                               by legislation or procedures required
                               under commercial contracts for
                               liability management.
                          ii.  Only key recovery enabled systems shall
                               be usable within a PKI.
                         iii.  A key recovery facility shall be
                               unconditionally trusted and be liable
                               to uphold the stated policy with
                               redress for loss arising from failures
                               to uphold policy through contractual
                               liability and penalties.
                          iv.  A key recovery center shall be able to
                               verify the legitimacy of a key
                               submitted to it for storage.
                           v.  A user of a key recovery repository
                               shall be able to verify that it is an
                               authorized repository.
                          vi.  The PKI shall provide for coordination
                               between the management of public and
                               private keys in PKI and in data
                               recovery centers.  Note that public and
                               private key parts do not have the same
                               life cycle and key parts may be
                               archived.
          
          
          
          Blakley          Document Expires: May 1997         [Page 5]


          Internet-Draft              APKI               November 1996
          
          
          
                         vii.  The PKI shall support aging,
                               revocation, and repudiation of keys.
                        viii.  The PKI shall support discretionary key
                               fragmentation between key recovery
                               facilities.
          
                  2.  Key Generation  facility
          
                      The method of key generation shall be
                      discretionary, subject to commercial decision
                      and business requirement.   Selection of key
                      quality, uniqueness, secrecy and recoverability
                      of keys must be left to the discretion of the
                      organization generating the keys (and any
                      governance authorities to which it is subject).
          
                  3.  Key Distribution, Revocation, Suspension,
                      Repudiation and Archive
          
                      The PKI must support the following
                      functionality:
          
                           i.  Facilities for the distribution of keys
                               to appropriate storage devices and
                               directories.
                          ii.  Ability of a certification authority to
                               revoke certificates for individual keys
                               under the terms of the applicable
                               policy.
                         iii.  Ability of a certification authority to
                               suspend and reactivate certificates for
                               individual keys under the terms of the
                               applicable policy.
                          iv.  Ability of a certification authority to
                               force delivery of revocation,
                               suspension, and reactivation notices.
                           v.  Facilities to enable a user to
                               repudiate his public key under the
                               terms of the applicable policy.
                          vi.  Facilities to enable a user to  suspend
                               and reactivate  his public key under
                               the terms of the applicable policy.
                         vii.  Facilities to enable the user and
                               subscriber to retrieve revocation,
                               suspension, and reactivation notices.
          
          
          
          Blakley          Document Expires: May 1997         [Page 6]


          Internet-Draft              APKI               November 1996
          
          
          
                        viii.  Facilities to enable the user and
                               subscriber to determine the status
                               (e.g., revoked or suspended) of a
                               specific certificate.
                          ix.  Facilities to enable the archive and
                               subsequent retrieval of certificates in
                               support of the retrieval and
                               verification of long term information
                               in accordance with governance policy.
          
                  4.  Warranted retrieval
          
                      The PKI must enable the following warranted
                      retrieval scenarios:
          
                           i.  Law enforcement retrieval (subject to
                               policy conditions)
                          ii.  Corporate agency retrieval (subject to
                               policy and authorizations)
                         iii.  Individual retrieval (subject to policy
                               and authorizations)
          
                      The following functionality is required in
                      support of warranted retrieval:
          
                           i.  An electronic vehicle for the delivery
                               of a notarized electronic warrant, to
                               support the automation of key retrieval
                               under due process (this must be able to
                               take advantage of existing legal
                               agreements)
                          ii.  A permanent, non-repudiable and
                               independently verifiable record of key
                               retrieval operations must be
                               maintained.
          
                      Note that warranted retrieval policy includes
                      policy regarding disclosure or non-disclosure of
                      key retrieval to owner of the retrieved key.
          
            B.  Distributed Certificate Management Structure
          
                The PKI must provide distributed Certificate
                Management functionality, driven by the requirements
                of the transaction or business domain. The following
          
          
          
          Blakley          Document Expires: May 1997         [Page 7]


          Internet-Draft              APKI               November 1996
          
          
          
                Certificate Management function must be provided by
                the PKI:
          
                  1.  Policing and policy enforcement (governance
                      model), including the following:
          
                           i.  Policy creation and maintenance. The
                               policies include those covering key
                               generation, key recovery, key
                               distribution, revocation, suspension,
                               repudiation, archive and warranted
                               retrieval .
                          ii.  Ability to register a key and the
                               binding between the key and a name.
                         iii.  Ability to query which keys are bound
                               to a name
                          iv.  Policies (for services built on PKI
                               access control) must not be required to
                               be based on individual identity.
                           v.  Certification of the binding between a
                               public key and a directory name shall
                               be mandatory
                          vi.  Certification of the binding between
                               additional attributes and a directory
                               name shall be discretionary
                         vii.  Auditing and support for the monitoring
                               of policy compliance is required
          
                  2.  Concurrent support of multiple policies
                  3.  exchange of certificates.
                  4.  Support for continuance of service in the event
                      of transfer of certificate services from one
                      certification authority to another.
                  5.  Certificate authority policy mapping services to
                      establish cross certification between CAs.
                  6.  Support for arbitration to determine
                      acceptability of certificates in the event of
                      multiple conflicting certification paths.
                  7.  Support for separation of the certification
                      authority and repository functions in accordance
                      with the governance policy. changes to
                      certificate repositories must be transactional
                      (e.g., two-phase commits).
          
            C.  Security of the PKI
          
          
          
          Blakley          Document Expires: May 1997         [Page 8]


          Internet-Draft              APKI               November 1996
          
          
          
                The PKI itself must be secure.  In particular, the PKI
                must:
          
                  1.  Protect the confidentiality, integrity and
                      availability of the PKI services, for example
                      key generation, key distribution, and key
                      storage.
                  2.  Provide strong non-repudiation services for
                      actions of certificate services.
                  3.  Prevent PKI services themselves from repudiating
                      their own actions.
                  4.  Prevent users and subscribers from repudiating
                      their own actions.
          
            D.  Time service
          
                A universal, networked time service must be available
                for time stamping.
          
            E.  Interoperability
          
                PKI elements provided by different vendors must
                interoperate.  In support of interoperability, PKI
                elements must:
          
                  1.  support international standards for certificates
                      and associated data
                  2.  support international standards for certificate
                      services
                  3.  support internationalization of all certificates
                      and associated data
                  4.  support internationalization of all certificate
                      services
          
          1.1.3  Known Issues
          
             For interoperability there is a dependency upon the
             definition of standard application program interfaces to
             and protocols between the component services of the
             Public Key Infrastructure.
          
             Work is required to define and agree profiles of option
             fields in certificates.
          
          
          
          
          
          Blakley          Document Expires: May 1997         [Page 9]


          Internet-Draft              APKI               November 1996
          
          
          
          1.1.4  Recommendations
          
             Adopt X.509 version 3 as a basis for certificates in the
             development of the PKI.
          
             Adopt and adapt existing standards and protocols wherever
             possible, invent new standards or protocols only as a
             last resort.
          
          1.2  The Importance of Architecture
          
             The APKI working group feels that a robust, flexible,
             standard, open Public-Key Infrastructure Architecture is
             critical to the success of secure systems based on
             Public-Key technology.  This section explains why.
          
          1.2.1  What is Architecture?
          
             The architecture of a software system is the set of
             interfaces through which its functions are accessed, and
             the set of protocols through which it communicates with
             other systems.
          
             The remainder of this section discusses the importance of
             standardizing the interfaces and protocols which comprise
             the Public-Key Infrastructure software Architecture.
          
          1.2.2  Interfaces
          
             The following figure illustrates a system on which three
             security products have been installed.
          
             In the figure:
          
              - Product 1 includes a protocol and all the security
                functionality needed to protect data flowing over that
                protocol.  Only the secure protocol's interface is
                exposed; the underlying security functionality is not
                available to other applications.
              - Product 2 also includes a protocol and its requisite
                security functionality, but it exposes the data
                protection functionality through a public interface so
                that other applications can use it.  It does not
                permit direct access to cryptographic functionality.
              - Product 3 is a hardware cryptographic adapter; it
          
          
          
          Blakley          Document Expires: May 1997        [Page 10]


          Internet-Draft              APKI               November 1996
          
          
          
                    Product 1                   Product 2
                +-------------------+      +-------------------+
                |+-----------------+|      |+-----------------+|
                || Secure          ||      || Secure          ||
                || Protocol        ||      || Protocol        ||
                |+-----------------+|      |+-----------------+|
                |+-----------------+|      |+-----------------+|
                || Security        ||      || Security        ||
                || State Mgmt &    ||      || State Mgmt &    ||
                || Data Protection ||      || Data Protection ||
                |+-----------------+|      |+-----------------+|
                |+-----------------+|      |+-----------------+|
                || Crypto          ||      || Crypto          ||
                || Software        ||      || Software        ||
                |+-----------------+|      |+-----------------+|
                +-------------------+      +-------------------+
          
                             +-----------------+
                   Product 3 | Crypto Hardware |
                             +-----------------+
          
                comes with a software driver permitting access by
                applications to its cryptographic functionality.
          
             This configuration has several bad characteristics:
          
              - Because neither product 1 nor product 2 accesses
                cryptographic functionality through a standard
                interface, neither can use the cryptographic adapter.
                Furthermore, because both product 1 and product 2
                embed cryptographic functionality  without exposing an
                interface through which it can be accessed, neither
                can use the other's cryptographic software.  The end
                result is that three different cryptographic
                subsystems (two software and one hardware) must be
                installed on the system, even if all three products
                use the same cryptographic algorithms!
              - Because product 1 and product 2 embed cryptographic
                functionality rather than accessing a separate
                cryptographic subsystem through a published interface,
                they will not be deployable (without code changes) in
                countries whose regulatory environment restricts or
                forbids use of the cryptographic functions they embed.
          
             This example illustrates some of the benefits of standard
          
          
          
          Blakley          Document Expires: May 1997        [Page 11]


          Internet-Draft              APKI               November 1996
          
          
          
             interfaces; these include:
          
              - Replaceability of services (e.g. cryptography) without
                change to exploiting applications
              - Elimination of duplicate service implementations in
                configurations in which multiple applications require
                the same kind of service
              - Reduced programmer training costs (programmers need
                learn only one standard interface for a service rather
                than learning the proprietary interfaces of multiple
                products providing the same service)
              - Reduced application porting complexity (code
                exploiting services through standard interfaces need
                not be changed, or requires only minimal changes, when
                porting from one platform supporting the standard
                interface to another such platform)
          
          1.2.3  Protocols
          
             The following figure illustrates two certificate-
             management products.
          
             In the figure:
          
              - Product 1 communicates key requests to the
                Certification Authority (CA) via electronic mail, and
                receives keys and certificates from the CA via email.
              - Product 2 communicates key requests to the CA using a
                proprietary protocol and retrieves keys from a
                directory service using the LDAP protocol.
          
             A configuration including both products would have
             several bad characteristics:
          
              - Neither product's CA could accept key requests from
                the other product's clients.
              - Applications using product 1 clients and wishing to
                advertise their certificates in the directory service
                would require installation of a separate directory-
                access product.
              - Applications using product 1 clients and wishing to
                retrieve partners' certificates from the directory
                service would require installation of a separate
                directory-access product.
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 12]


          Internet-Draft              APKI               November 1996
          
          
          
               Product 1
             +--------------------------------+      +-----------+
             |               +-------+   +-+  |      | +-+ +----+|
             | Application --|Key    |---|e|--|------|-|e|-|    ||
             |     ^         |Request|   |m|  |      | |m| |    ||
             |     |         +-------+   |a|  |      | |a| | CA ||
             |+----------+               |i|  |      | |i| |    ||
             ||User Key  |---------------|l|--|------|-|l|-|    ||
             ||Management|               +-+  |      | +-+ +----+|
             |+----------+                    |      |           |
             +--------------------------------+      +-----------+
          
               Product 2
             +-------------------------+             +-----------+
             |               +-------+ |             |     +----+|
             | Application --|Key    |-|-------------|-----|    ||
             |     ^         |Request| |             | +-+ |    ||
             |     |         +-------+ |             | |L| | CA ||
             |+----------+   +------+  | +---------+ | |D| |    ||
             ||User Key  |---| LDAP |--|-|Directory|-|-|A|-|    ||
             ||Management|   |      |  | +---------+ | |P| +----+|
             |+----------+   +------+  |             | +-+       |
             +-------------------------+             +-----------+
          
             This example illustrates the benefit of standard
             protocols:
          
              - Applications supporting standard protocols can
                interoperate, even if produced by different providers.
          
          1.2.4  Profiles
          
             Many of the services in the Public-Key Infrastructure
             Architecture can be implemented using a variety of
             different mechanisms and protocols (e.g. data privacy
             protection can be implemented using a variety of
             different cryptographic algorithms).  This variety of
             mechanisms and protocols has arisen in part because
             different environments impose different security
             requirements.
          
             Multiplicity of mechanisms means that different
             providers' implementations of the PKI Architecture will
             not necessarily interoperate - even though they support
             the standard interfaces and a selection of the standard
          
          
          
          Blakley          Document Expires: May 1997        [Page 13]


          Internet-Draft              APKI               November 1996
          
          
          
             protocols.
          
             A profile defines the set of mechanisms and protocols
             which should be used in a particular environment.  The
             mechanisms and protocols comprising a profile are usually
             chosen on the basis of their strength against the attacks
             which are common in the environment supported by the
             profile.  Profiling has the following  advantages:
          
              - Systems conforming to an environment's profile will
                interoperate.
              - Systems conforming to an environment's profile will be
                well-protected against that environment's risks.
              - Profiling helps to assure that mechanisms in use work
                together appropriately and securely.
          
          1.2.5  Negotiation
          
             Some profiles will allow multiple mechanisms and
             protocols in order to support different qualities of
             protection, or to accommodate a fragmented security
             product market.  In these environments, it is desirable
             to provide a negotiation meta-protocol which allows
             communicating partners to determine:
          
              - which mechanisms and protocols they both (or all)
                share
              - which mechanism and protocol, among the shared set,
                best supports the desired quality of protection.
          
             It is important to note that negotiation does not always
             require an on-line dialog between the negotiating
             entities.
          
          1.3  Document Overview
          
             Section 2 presents the high-level structure of the PKI
             Architecture by grouping the architecture's components
             into broad functional categories.
          
             Section 3:
          
              - enumerates the components in each of the
                Architecture's functional categories
              - describes the functionality of each component and
          
          
          
          Blakley          Document Expires: May 1997        [Page 14]


          Internet-Draft              APKI               November 1996
          
          
          
                lists existing specifications which could serve as
                candidate standards for each component's interfaces
                and protocols (To be considered a "candidate" for
                purposes of the public-key infrastructure
                architecture, an interface or protocol must: (1) be
                described by a publicly-available specification, and
                (2) support a significant fraction of the
                functionality of the PKI component for which it is
                proposed as a candidate.  It is assumed that the
                candidate interface and protocol specifications
                identified in this document will serve as base
                documents for open standardization processes, which
                will produce finalized PKI component interface and
                protocol specifications.)
              - identifies where negotiation facilities are required
                to deal with the probable existence of a multiplicity
                of security mechanisms
              - enumerates important public-key-related protocols and
                discusses the need for environment-specific profiles
          
             Section 4 discusses the use of hardware security devices
             in the architecture.
          
             Appendices to the document provide:
          
              - examples illustrating application of the architecture
                to existing secure systems,
              - the relationship of this document to existing security
                architecture standards
              - a glossary of terms related to security and public-key
                cryptography
              - an annotated list of references
          
          
          2.  Overview of the PKI Architecture
          
             The  PKI architecture components are grouped into the
             following broad functional categories:
          
            A.  System Security  Enabling Services provide the
                functionality which allows a user's or other
                principal's identity to be established and associated
                with his actions in the system.
            B.  Crypto Primitives and Services provide the
                cryptographic functions on which public-key security
          
          
          
          Blakley          Document Expires: May 1997        [Page 15]


          Internet-Draft              APKI               November 1996
          
          
          
                is based (including secret-key primitives such as
                DES).
            C.  Long-term Key Services permit users and other
                principals to manage their own long-term keys and
                certificates and to retrieve and check the validity of
                other principals'  certificates
            D.  Protocol Security Services provide security
                functionality (data origin authentication, data
                integrity protection, data privacy protection,
                nonrepudiation) suitable for use by implementors of
                security-aware applications such as secure protocols.
            E.  Secure Protocols provide secure inter-application
                communications for security-unaware and "mildly"
                security-aware applications.
            F.  Security Policy Services provide the policy-related
                information which must be carried in secure protocols
                to enable access control, and provide access-control
                checking facilities to security-aware applications
                which must enforce policy.
            G.  Supporting Services provide functionality which is
                required for secure operation, but is not directly
                involved in security policy enforcement.
          
             The following figure illustrates the PKI architecture.
          
             Section 3 describes each of these categories in more
             detail (listing the components in each category), and
             identifies interfaces and protocols which may be
             candidate bases for standardization of each component.
             Appendix B uses  the figure above to illustrate how a
             number of existing security technologies fit into the
             architecture.
          
             Note that while the architecture described in this
             document could be implemented on insecure operating
             system platforms, implementors of the architecture must
             insure that keys, security context data, and policy data
             are appropriately protected in such environments.
          
          
          3.  Public-Key Infrastructure Components
          
             Each of this section's subsections describes one of the
             Architecture's categories in detail, enumerating its
             components and describing component functions,
          
          
          
          Blakley          Document Expires: May 1997        [Page 16]


          Internet-Draft              APKI               November 1996
          
          
          
           +-------------------------------------------------------+
           |                                                       |
           |                  [Applications]                       |
           |                                                       |
           +-------------------------------------------------------+
           |          |                               |            |
           |          |       Secure Protocols        |  Security  |
           |          |                               |   Policy   |
           |  System  +-------------------------------+  Services  |
           | Security |                               |            |
           | Enabling |  Protocol Security Services   +------------+
           | Services |                               |            |
           |          +-------------------------------+            |
           |          |                               |            |
           |          |    Long-Term Key Services     |            |
           |          |                               |            |
           +----------+-------------------------------+ Supporting |
                      |                               |  Services  |
                      |    Cryptographic Services     |            |
                      |                               |            |
                      +...............................+            |
                      |                               |            |
                      |   Cryptographic Primitives    |            |
                      |                               |            |
                      +-------------------------------+------------+
          
             interfaces, and protocols.
          
          3.1  Crypto Primitive Components
          
             The figure below illustrates the Crypto Primitive
             Components:
          
             Note that the architecture's cryptographic primitives may
             be provided by hardware (e.g. smartcards or cryptographic
             modules) or by software.
          
          3.1.1  Function
          
             These components provide access to low-level
             cryptographic primitives such as key generation, hash
             function application to a data buffer, encryption of a
             data buffer using secret-key or public-key algorithms,
             decryption of a data buffer using secret-key or public-
             key algorithms, etc....
          
          
          
          Blakley          Document Expires: May 1997        [Page 17]


          Internet-Draft              APKI               November 1996
          
          
          
          +------------+ +--------------+ +--------------+ +------------+
          |   Random   | |      Key     | |   Secret     | |            |
          |   Number   | |  Generation  | |   Sharing    | |  Hashing   |
          | Generation | |              | |              | |            |
          +------------+ +--------------+ +--------------+ +------------+
          
          +------------+ +--------------+ +--------------+
          |   Keyed    | |  Symmetric   | |  Asymmetric  |
          |  Hashing   | | (secret-key) | | (public-key) |
          |            | |    Crypto    | |    Crypto    |
          |            | |  Primitives  | |  Primitives  |
          +------------+ +--------------+ +--------------+
          
          3.1.2  Protocols
          
             Cryptographic primitives are typically called locally; it
             is not anticipated that any cryptographic primitive
             protocols will be defined.
          
          3.1.3  Interfaces
          
             Candidate interfaces for access to cryptographic
             primitives include:
          
              - The RSA BSafe library interface
              - The X/Open GCS-API
              - The Microsoft CryptoAPI 1.0
          
             Other interfaces which may support some or all of the
             cryptographic primitive function include
          
              - Fortezza
              - IBM CCA
          
             Standardization of these interfaces would be of interest
             to developers of cryptographic service modules and to
             providers of cryptographic primitive modules.
             Standardization of an interface for access to
             cryptographic primitives would facilitate "pluggable"
             implementations of cryptographic services.  The consensus
             of the APKI working group, however, is that cryptographic
             functionality will ordinarily be used through the
             cryptographic service interfaces rather than through the
             cryptographic primitive interfaces.  Therefore,
             standardization of cryptographic primitive interfaces is
          
          
          
          Blakley          Document Expires: May 1997        [Page 18]


          Internet-Draft              APKI               November 1996
          
          
          
             not viewed as essential.
          
          3.1.4  Profiles
          
             Most cryptographic modules provide support for multiple
             primitives.  Many primitives are subject to legal
             restrictions on deployment (including both intellectual
             property encumbrances and national and international
             regulatory constraints on export, import, and
             deployment).
          
             Cryptographic primitive profiles will have to be
             developed for PKI environments of interest (including,
             for example, the Internet, OMG CORBA, OSF DCE, Financial,
             etc.).
          
          3.1.5  Negotiation
          
             Cryptographic primitives are ordinarily used only by the
             implementors of cryptographic services.  Negotiation
             should be used to establish which cryptographic
             service(s) are to be used, rather than to establish what
             primitives should be used.  Ordinarily this negotiation
             will be done at a higher level than that of the
             cryptographic primitives and services themselves.  No
             protocol for negotiating cryptographic primitives should
             be required.
          
          3.2  Crypto Service Components
          
             The figure below illustrates the Cryptographic Service
             Components:
          
           +-----------+ +------------+ +------------+ +------------+
           |  Crypto   | |    Key     | |     Key    | |    Key     |
           |  Context  | |  Import &  | | Derivation | | Agreement  |
           | Management| |   Export   | |            | |            |
           +-----------+ +------------+ +------------+ +------------+
          
           +-----------+ +------------+ +------------+ +------------+
           |    Key    | |    Data    | |    Data    | |    Data    |
           |   Usage   | |  Integrity | |   Privacy  | |  Signature |
           |  Control  | |            | |            | |            |
           +-----------+ +------------+ +------------+ +------------+
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 19]


          Internet-Draft              APKI               November 1996
          
          
          
          3.2.1  Function
          
             These components provide access to cryptographic services
             such as data integrity and privacy protection ("data"
             here might be a file, a message, an i/o stream, etc...),
             key import and export, digital signature, keyed hash,
             etc....
          
             Cryptographic Context Management provides the facilities
             through which applications initialize the cryptographic
             subsystem, activate keys for encryption and decryption,
             and clean up the state of the cryptographic subsystem
             after use.
          
             Key usage controls permit control over a variety of
             aspects of key use, including how many times a key may be
             used; for what purposes it may be used (e.g. for
             signature only, for privacy only, for both signature and
             privacy, etc...), and so on.
          
             Key derivation services permit generation of
             cryptographic-quality keys from non-key values such as
             passwords.
          
             Crypto services are built on crypto primitives.  A crypto
             service may support multiple implementations, each of
             which uses a different crypto primitive.
          
             Descriptions of a few DES-based services will illustrate
             the difference between primitives and services; note that
             these are only examples:
          
              - DEA is a crypto primitive which uses a 56-bit key and
                an initialization vector to transform a 64-bit
                plaintext into a 64-bit ciphertext.
              - Data privacy is a crypto service.  DES-CBC is an
                implementation of the cryptographic data privacy
                service which uses a 56-bit key, an initialization
                vector, and the DEA primitive  to transform a
                plaintext of arbitrary length into a ciphertext of the
                same length subject to some rules defined by a "mode
                of operation".  The rules describe how to "pad"
                plaintexts to a multiple of 64 bits and whether and
                how to induce dependencies among 64-bit blocks of the
                ciperhtext by feeding ciperhtext material from
          
          
          
          Blakley          Document Expires: May 1997        [Page 20]


          Internet-Draft              APKI               November 1996
          
          
          
                previous rounds of the encryption process into the
                current round.
              - Data integrity is a crypto service. DES-CBC-MAC is an
                implementation of the data integrity service which
                uses the DEA primitive to generate a message
                authentication code given a 56-bit key, an
                initialization vector,  and  a plaintext of arbitrary
                length.
          
          3.2.2  Protocols
          
             Cryptographic services are typically called locally; it
             is not anticipated that any cryptographic service
             protocols will be standardized.
          
          3.2.3  Interfaces
          
             Candidate interfaces for cryptographic services include:
          
              - X/Open GCS-API
              - Microsoft CryptoAPI 1.0
              - SESAME CSF API
          
             Other interfaces which may support some or all of the
             cryptographic primitive function include
          
              - Cryptoki
              - RSA BSAFE
          
             Standardization of these interfaces would be of interest
             to developers of long-term-key service and protocol
             security service modules and to providers of
             cryptographic service modules.  The  APKI working group
             feels that it is important to standardize a single
             interface for cryptographic services.
          
          3.2.4  Profiles
          
             Most cryptographic modules provide support for multiple
             services.  Many crypto services are subject to legal
             restrictions on deployment (including both intellectual
             property encumbrances and national and international
             regulatory constraints on export, import, and
             deployment).
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 21]


          Internet-Draft              APKI               November 1996
          
          
          
             Cryptographic service profiles will have to be developed
             for PKI environments of interest (including, for example,
             the Internet, OMG CORBA, OSF DCE, Financial, etc.).
             These profiles will have to be developed with
             international deployment issues in mind.  Each profile
             should be expressed in terms of the parameters used to
             select cryptographic services (and implementations of
             cryptographic services -- often called "mechanisms")
             through the cryptographic service interface (see the next
             section for more information on service and mechanism
             selection).
          
             Profiles will need to specify, in addition to mechanism
             information,  the data formats which each service can
             accept and return.
          
          3.2.5  Negotiation
          
             Negotiation of cryptographic services to be used by
             secure protocols and other security-aware applications
             is generally done at level higher than that of the
             cryptographic services themselves.  The cryptographic
             service interface therefore must allow selection among
             available cryptographic services, and among available
             implementations of a single service, but it need not
             support negotiation.
          
          3.3  Long-Term Key Services Components
          
             The following figure illustrates the Long-Term Key
             Services Components; each component is described in more
             detail below.
          
           +-----------+ +------------+ +------------+ +------------+
           |    Key    | |    Key     | |    Key     | |   Virtual  |
           | Lifecycle | |   Escrow   | |  Recovery  | |  Smartcard |
           | Management| |            | |            | |  Service   |
           +-----------+ +------------+ +------------+ +------------+
          
           +-----------+ +------------+
           |Certificate| | Public-Key |
           | Management| | Delivery & |
           |           | |Verification|
           +-----------+ +------------+
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 22]


          Internet-Draft              APKI               November 1996
          
          
          
          3.3.1  Function
          
          Key Lifecycle Management
          
             This component provides including key revocation, key
             repudiation, key expiration, and related services.
          
          Key Escrow and Key Recovery
          
             These components permit secure storage of keys for later
             recovery under policy control.
          
          Virtual Smartcard Service
          
             The Virtual Smartcard Service Component permits users and
             other principals to store long-term personal security
             information (including private keys, certificates, and
             other information) in protected storage, to activate
             personal keys for use via an authentication procedure,
             and to use those keys for encryption, decryption, and
             signature activities.
          
             The following figure illustrates the structure of this
             component.
          
                           +------------------------+
                           |                        |
                           | Virtual Smartcard Svc. |
                           |                        |
                           +----------+--+----------+
                           | Hardware |  | Software |
                           | Security |  | Personal |
                           |  Token   |  | Security |
                           |          |  |  Model   |
                           +----------+  +----------+
          
          
          Certificate Management
          
             The Certificate Management component allows users,
             administrators and other principals to request
             certification of public keys and revocation of previously
             certified keys.  It may optionally generate key pairs and
             provide key-pair recovery services.  There are four
             Certificate Management sub-components:
          
          
          
          Blakley          Document Expires: May 1997        [Page 23]


          Internet-Draft              APKI               November 1996
          
          
          
             The Local Registration Authority provides interfaces for
             requesting generation of key-pairs and corresponding
             certificates, requesting certification of existing public
             keys, and requesting revocation of existing certificates.
          
             The Certification Authority Agent (CA Agent) provides
             interfaces for certifying existing public keys,
             generating and returning key pairs and corresponding
             certificates,  revoking existing certificates.  The CA
             Agent implements these interfaces via calls to a
             Certification Authority (CA).
          
             The Certification Authority certifies public keys
             (returning the generated certificate) and generates
             certificate revocation lists.  In some configurations it
             will be "off-line".
          
             The Publication Authority provides interfaces through
             which CAs and CA Agents can place certificates and CRLs
             into public repositories or transmit them directly to
             requestors.
          
          Public-Key Delivery and Verification
          
             This component allows a program to retrieve any
             principal's certificate, verify its validity, and extract
             the principal's certified public key from the
             certificate.
          
             The following figure illustrates the structure and
             interrelationships of the Certificate Management and
             Public-Key Delivery and Verification components and
             sub-components.
          
          3.3.2  Protocols
          
          Virtual Smartcard Service
          
             When the Virtual Smartcard Service component is used for
             retrieval of user private keys, two models exist.  One
             model (exemplified by PGP and Lotus Notes) manages
             private keys primarily on the client principal's machine
             (either in a software personal security module, or in a
             security token or other device external to the
             principal's workstation).  In this model, no protocols
          
          
          
          Blakley          Document Expires: May 1997        [Page 24]


          Internet-Draft              APKI               November 1996
          
          
          
          +-----------+---------------++=====+==============++
          |           |  Public       ||     |     Local    ||
          |           |  Key          ||     | Registration ||      double border
          | Virtual   |  Delivery     ||     |   Authority  ||    / encloses
          | Smartcard |  and          ||     +--------------++   /  Certificate
          | Service   |  Verification ||         CA         ||  /   Management
          |           |               ||        Agent       || <    Component
          |           |               ++---------+----------++
          |           |               ||         |          ||
          |           +-------++======++         |          ||
          |                   ||                 |          ||
          |                   ||   Publication   |    CA    ||
          |                   ||    Authority    |          ||
          +-------------------++=================+==========++
          
             are required for User/Principle Personal Security Info
             Management, since all operations are client-local.
          
             The second model (exemplified by Novell NetWare) manages
             private keys at a central server and distributes them to
             client principals using a secure protocol.  In this
             model, the client/server protocol for retrieval of
             private keys needs to be supported by the software
             personal security module subcomponent of the Virtual
             Smartcard Service component, as illustrated in the figure
             below (the dotted arrow in the figure represents the
             protocol):
          
                   +-----------------------+
                   |User/Principal         |
                   |Personal Security Info |
                   |Management Interface   |
                   +--------------+--------+     +----------+
                                  |Software|     |Remote    |
                                  |Personal|     |Private   |
                                  |Security|---->|Key       |
                                  |Module  |     |Repository|
                                  +--------+     +----------+
          
             The APKI working group does not view standardization of
             this protocol to be essential.
          
          Certificate Management
          
             Protocols must be defined to permit creation, revocation,
          
          
          
          Blakley          Document Expires: May 1997        [Page 25]


          Internet-Draft              APKI               November 1996
          
          
          
             and update of certificates.  The diagram below
             illustrates Certificate Management protocols which might
             be standardized; each arrow in the diagram represents a
             protocol.
          
                                       Certificate Management
                             +-----------------------------------------+
          +--------------+   | +------------+            +-----------+ |
          | Application  |   | |   Local    |            |Certificate| |
          |(or Smartcard)|---->|Registration|----------->| Authority | |
          |              |   | | Authority  |            |   Agent   | |
          +--------------+   | +------------+            +-----------+ |
                  |          |                            /      ^     |
                  |          +-------------+             /       |     |
                  |                        |            v        |     |
            +------------+                 | +-----------+       |     |
            | Public-Key |                 | |Publication|       |     |
            | Delivery & |<..................| Authority |       |     |
            |Verification|                 | |           |       |     |
            |            |-----+           | +-----------+       |     |
            +------------+     |           +---/-------+         |     |
                  |            v              v        |         v     |
            +------------+   +---------------+         | +-----------+ |
            |  Virtual   |   | Repository &  |         | |Certificate| |
            | Smartcard  |   | Subscription  |         | | Authority | |
            |  Services  |   |   Services    |         | |           | |
            +------------+   +---------------+         | +-----------+ |
                                                       +---------------+
          
             Note that implementations may choose to assign the
             responsibility for generation of private keys (through
             use of the key generation facilities of the PKI
             architecture) to the CA, the LRA, or the User Workstation
             or Smartcard; additional protocols will be required to
             transmit the private key to the User Workstation or
             Smartcard if it is not generated there in the first
             place.
          
             The APKI working  group feels that the following
             protocols should be standardized at a minimum:
          
              - User Workstation or Smartcard to Certificate
                Management component
              - Local Registration Authority to CA Agent
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 26]


          Internet-Draft              APKI               November 1996
          
          
          
             A candidate protocol specification including these
             protocols as well as a protocol for the Publication
             Authority to Public-Key Delivery protocol exists as IETF
             draft RFC ietf-pkix-ipki-part3-01.txt
          
             Public-Key Delivery and Verification
          
             Protocols must be defined to transport certificates from
             the repositories in which they reside to the requester's
             machine.  In the diagram, these protocols are represented
             by the arrows from the Publication Authority to the
             Public-Key Delivery and Verification component.  The APKI
             working group feels that these protocols should be
             standardized.  At least LDAP, email, and HTTP versions of
             these protocols should be defined.
          
             A candidate protocol specification is in preparation and
             will be published as IETF draft RFC ietf-pkix-ipki-
             part2-01.txt
          
          3.3.3  Interfaces
          
          Virtual Smartcard Service
          
             Candidate interfaces for this component include:
          
              - PSM (HP Submission to OSF)
              - SESAME CSF API
          
             Other interfaces which may support some or all of the
             Virtual Smartcard Service  functionality include:
          
              - Microsoft Wallet
          
             The APKI working group feels that the Virtual Smartcard
             Service  interface should be standardized.
          
             Additionally, the APKI working group feels that the
             interface through which software communicates with
             Hardware Security Tokens should be standardized.  A
             candidate interface for this functionality is:
          
              - RSA PKCS-11
          
          Public-Key Delivery and Verification
          
          
          
          Blakley          Document Expires: May 1997        [Page 27]


          Internet-Draft              APKI               November 1996
          
          
          
             Candidate interfaces for this component include:
          
              - CMS-API (Nortel)
              - SESAME PKM-API
              - NSA CM-API
              - Nortel CMS-API
          
             Other interfaces which may support some or all of the
             Public-Key Delivery and Verification function include
          
              - Microsoft CryptoAPI version 2.0
              - Intel CDSA
          
             The APKI working group feels that the Public-Key Delivery
             and Verification interface should be standardized.
          
          Certificate Management
          
             Candidate interfaces for this component include:
          
              - Nortel CMS-API
              - SESAME PKM API
              - OSF RFC 80 API
          
             Other interfaces which may support some or all of the
             Certificate Management function include
          
              - Microsoft CryptoAPI version 2.0
              - Intel CDSA
          
             The APKI working group feels that the following
             interfaces should be standardized at a minimum:
          
              - CA Agent
              - Local Registration Authority
          
             Specification of the Publication Authority interface
             would also be useful to providers of repositories and
             communications protocols who wish to make their products
             available as certificate and CRL transmission media; a
             standard Publication Authority interface would allow
             them to provide Publication Authority services without
             requiring changes to CA Agent code.
          
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 28]


          Internet-Draft              APKI               November 1996
          
          
          
          3.3.4  Profiles
          
             It is anticipated that multiple  CAs will exist in
             typical PKI environments; individual  servers may require
             the use of certificates with specific properties (signing
             CA, supported extensions, name format, etc...) Profiles
             for certificate format, contents, extensions, and policy
             will be needed for  PKI environments of interest,
             including the Internet, Financial Industry, Credit Card
             Industry (for use with SET), Government, and Healthcare
             Industry environments.
          
             A draft profile (for the Internet PKI environment) for
             certificate format, contents, and extensions exists as
             IETF draft RFC ietf-pkix-ipki-part1-01.txt.   A draft
             policy profile for the Internet PKI environment is in
             preparation and will be published as IETF draft RFC
             ietf-pkix-ipki-part4-01.txt.
          
          3.3.5  Negotiation
          
             It is not anticipated that any of the Long-Term Key
             Services components will require negotiation protocols.
             The Certificate Management interfaces will need to
             provide a mechanism through which callers can identify
             which CA should issue certificates and CRLs requested
             through its interface, in case more than one CA is
             available.
          
             The Virtual Smartcard Service interface will need to
             support selection of user/principal certificates for
             environments in which users have more than one
             certificate.
          
          3.4  Protocol Security Services Components
          
             Protocol security services are divided into two
             fundamental classes:
          
              - Session-Oriented: security services which require
                exploiting entities to maintain security state
                information associated with protocol exchanges.
              - Store & Forward: security services which encapsulate
                all required security state information inside the
                protected message tokens they generate; these services
          
          
          
          Blakley          Document Expires: May 1997        [Page 29]


          Internet-Draft              APKI               November 1996
          
          
          
                do not require exploiting entities to maintain
                security state information.  Nonrepudiation services
                are necessarily store-and-forward services, because
                they must allow for "protection" of the
                nonrepudiability of a transaction after it has been
                completed and its state information destroyed.
                Nonrepudiation services are depicted separately from
                other store-and-forward protocol security services
                because, unlike store-and-forward data privacy and
                integrity services, use of Nonrepudiation services
                usually requires explicit user action.
          
             The following figure illustrates the Protocol Security
             Services Components.
          
                +--------+    +----------+    +---------------+
                |Session-|    | Store &  |    |Non-Repudiation|
                |Oriented|    | Forward  |    |Services       |
                |Services|    | Services |    +---------------+
                +--------+    +----------+
          
          3.4.1  Function
          
             These components provide security services appropriate
             for use by designers of protocol stacks.  Specifically,
             these components:
          
              - Provide security mechanism and quality-of-protection
                negotiation protocols for use by communication
                partners needing to agree on a common security regime
              - Manage security state information (if any) needed by
                protocol partners wishing to set up and maintain
                secure associations
              - Encapsulate data origin authentication, data
                protection, and credential and privilege transport
                transparently within a single service (Crypto
                Services, by contrast, typically provide only data
                protection)
              - Apply security mechanisms based on administered policy
                information
          
          3.4.2  Protocols
          
          Session-Oriented Protocol Security Services
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 30]


          Internet-Draft              APKI               November 1996
          
          
          
             A wide variety of protocol security services can be used
             to provide security for session-oriented protocols;
             examples which are described in existing or proposed
             Internet standards include the SPKM (which is Public-Key
             based), Kerberos (which is Secret-Key based), and SESAME
             (which has Public-Key, Secret-Key, and hybrid variants).
             Some of these services define their own protocols for
             run-time access to on-line security servers of a variety
             of types.  All of them define formats for protected
             message tokens to be transported by their callers.
          
          Store & Forward Protocol Security Services
          
             Only a few protocol security services suitable for
             protection of store & forward protocol messages have been
             defined.  The IDUP and SESAME services are proposed for
             Internet standardization.  Both of these services define
             formats for protected message tokens to be transported by
             their callers.
          
          Notary and Non-Repudiation Services.
          
             These services must define formats for Non-Repudiation
             evidence tokens to be transmitted along with notarized
             data, and protocols implementing non-repudiable delivery
             and non-repudiable receipt.
          
             The APKI working group feels that multiple protocol
             security services will continue to be required to meet
             the needs of diverse environments.  No single standard
             for Session-Oriented, Store-and-Forward, or
             Nonrepudiation Protocol Security Services is proposed,
             therefore.  The Protocol Security Services component
             interfaces will need to provide negotiation (for
             environments in which more than one service is
             available), and Protocol Security Service profiles will
             have to be established for PKI environments of interest.
          
          3.4.3  Interfaces
          
             The APKI working group feels that all of the Protocol
             Security Services interfaces should be standardized.
          
             The structure of the Protocol Security Services is
             illustrated by the following figure.
          
          
          
          Blakley          Document Expires: May 1997        [Page 31]


          Internet-Draft              APKI               November 1996
          
          
          
          +----------+ +-----------+ +----------------+ +---------------+
          |Privilege,| |Mechanism  | |Session-Oriented| |Store & Forward|
          |Delegation| |Negotiation| |   Protection   | |   Protection, |
          |Management| |           | |                | |Non-Repudiation|
          +----------+ +-----------+ +----------------+ +---------------+
                 |              |         |        |           |
                 |           +------------------+  |           |
                 |           |Context Management|  |           |
                 |           +------------------+  |           |
                 |                                 |           |
                 |                     +--------------------------------+
                 |                     |       Token Processing         |
                 |                     +--------------------------------+
                 |                      |          |           |       |
             +----------------------------+ +-----------+ +----------+ |
             |    PAC Generation, Use,    | |Key        | |Dialog Key| |
             |  Protection, Verification, | |Acquisition| |Generation| |
             |        Delegation          | |Negotiation| |          | |
             +----------------------------+ +-----------+ +----------+ |
                                                   |           |       |
                                              +-------------------------+
                                              |    Mechanism Provider   |
                                              |         Interface       |
                                              +-------------------------+
                                                  |      |       |
                                               +----+ +----+ +------+
                                               |Kerb| |SPKM| |Sesame|
                                               +----+ +----+ +------+
          
          Session-Oriented Protocol Security Services
          
             The preferred interface for these services is GSS-API
             (IETF RFC 1508).
          
          Store & Forward Protocol Security Services
          
             The preferred interface for these services is IDUP-GSS-
             API (IETF CAT draft ietf-cat-idup-gss-api-04.txt).
          
          Non-Repudiation Services
          
             The preferred interface for these services is IDUP-GSS-
             API (IETF CAT draft ietf-cat-idup-gss-api-04.txt).
          
             In addition to these interfaces, the APKI working group
          
          
          
          Blakley          Document Expires: May 1997        [Page 32]


          Internet-Draft              APKI               November 1996
          
          
          
             feels that interfaces for Protection Mechanism
             Negotiation and Privilege and Delegation Management
             should be standardized.  The preferred interfaces for
             these services are draft-ietf-cat-gss-nego and draft-
             ietf-cat-xgss, respectively.
          
             Other interfaces which may support some or all of the
             Protocol Security Services functionality include:
          
              - Microsoft SSPI
              - OMG CORBA Security
              - TIPEM
              - SHTTP
          
          3.4.4  Profiles
          
             GSS-API and IDUP-GSS-API are capable of supporting
             multiple security mechanisms; each API also allows
             selection of a wide range of qualities of data protection
             (e.g. strength of supported privacy protection,
             delegation mode, etc...) for each supported security
             mechanism.
          
             Profiles will have to be developed to describe the set of
             preferred mechanisms and data protection quality
             parameters for PKI environments of interest.  The APKI
             working group is not aware of a draft profile in this
             area.
          
          3.4.5  Negotiation
          
             Because they will be deployed in environments which
             require and provide multiple data protection mechanisms,
             the Protocol Security Services interfaces will need to
             support negotiation (of both protection mechanisms to be
             used and Quality of Protection to be applied).
          
             A negotiation mechanism for GSS-API has been proposed and
             is described in IETF draft ietf-cat-gss-nego-02.txt.
          
          3.5  Secure Protocol Components
          
             There are many kinds of secure protocols.  Three
             important categories of secure protocols are:
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 33]


          Internet-Draft              APKI               November 1996
          
          
          
              - Connection-oriented peer-to-peer: These protocols
                allow exactly two partners, each of which must be on-
                line, to communicate securely.
              - Connectionless peer-to-peer: These protocols allow
                exactly two partners, one or both of which may be
                off-line for some portion of the time interval during
                which messages are transmitted, to communicate
                securely.
              - Connectionless multicast: These protocols allow one
                entity to communicate simultaneously and securely with
                several partners.  Any or all entities may be off-line
                for some portion of the time interval during which
                messages are transmitted.
          
             The following figure illustrates the Secure Protocol
             Components.
          
          +-------------------+ +-------------------+ +-----------------+
          |Connection-Oriented| |  Connectionless   | |    Multicast    |
          |   Peer-to-Peer    | |   Peer-to-Peer    | |                 |
          +-------------------+ +-------------------+ +-----------------+
          
          3.5.1  Function
          
             Secure protocols provide protected data transfer between
             communicating partners without requiring any calls to
             security services.  Applications using secure protocols
             may have to specify a desired quality of protection
             before initiating a secure protocol exchange.
          
          3.5.2  Protocols
          
             Examples of secure protocols include:
          
              - Connection-oriented peer-to-peer: Secure RPC, SSL,
                SHTTP, OMG SECIOP
              - Connectionless peer-to-peer: IPSec, secure e-mail
              - Connectionless multicast: Secure e-mail
          
          3.5.3  Interfaces
          
             Each secure protocol typically has its own interface.
          
          
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 34]


          Internet-Draft              APKI               November 1996
          
          
          
          3.5.4  Profiles
          
             It is not yet clear whether profiles will be established
             for which Web transaction security protocols (e.g. SHTTP,
             HTTP-over-GSSAPI, etc...) should be used in which
             contexts.
          
          3.5.5  Negotiation
          
             The APKI working group feels that negotiation of secure
             protocols is outside the scope of the Public-Key (or even
             Security) Infrastructure effort.
          
          3.6  System Security Enabling Components
          
             The following figure illustrates the System Security
             Enabling Components.
          
                  +---------+ +--------------+ +------------+
                  |         | |  Credential  | |  Security  |
                  |  Logon  | | Acquisition  | |   Context  |
                  |         | |              | | Management |
                  +---------+ +--------------+ +------------+
          
          3.6.1  Function
          
             System functions  (for example, Operating System
             functions) are needed to support user logon, user
             credential acquisition, and association of security state
             information with user processes and threads.  For
             example, once a user has acquired credentials by
             authenticating himself to a smartcard, that user's
             processes should be able to use the smartcard interface
             to sign data using a private key stored on the smartcard.
             This will only be possible (and secure) if the system has
             maintained security state information associating the
             user's processes with the handle returned when the user
             authenticated himself to the smartcard.
          
             It is not anticipated that the Internet Public-Key
             infrastructure will define any interfaces, protocols,
             profiles, or negotiation mechanisms in the area of System
             Security Enabling Services.
          
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 35]


          Internet-Draft              APKI               November 1996
          
          
          
          3.7  Security Policy Services Components
          
             The following figure illustrates the Security Policy
             Service Components.
          
                           +----------+ +----------+
                           | Privilege| |  Access  |
                           |Services &| |  Control |
                           |Delegation| |          |
                           +----------+ +----------+
                           |User Info |
                           |Management|
                           |(Registry)|
                           +----------+
          
          3.7.1  Function
          
             Security Policy Services manage information about users'
             (and other principals') privileges and resource access
             control policies, and make access control decisions based
             on that information.
          
          3.7.2  Protocols
          
             Formats for privilege attribute tokens to be transported
             within secure protocols will need to be standardized.
             The most prominent existing privilege attribute format
             definitions today are those defined by ANSI X9, OSF DCE,
             SESAME, and the OMG CORBASEC standard.  Privileges could
             be carried in X.509v3 certificate extensions, or in
             separate privilege attribute tokens.
          
          3.7.3  Interfaces
          
             It is not anticipated that the Internet Public-Key
             Infrastructure will define interfaces to privilege
             attribute services or access control services.
          
          3.7.4  Profiles
          
             Interoperation of systems in differing security
             management domains will require standardization of
             privilege attribute types and of the semantics of values
             of those types.  No proposed standard profile for
             privilege attributes exists today.
          
          
          
          Blakley          Document Expires: May 1997        [Page 36]


          Internet-Draft              APKI               November 1996
          
          
          
          3.7.5  Negotiation
          
             <<TBD>>
          
          3.8  Supporting Services Components
          
             The following figure lists the Supporting Services
             Components.
          
                    +----------+ +---------+ +------------+
                    | Security | |  Time   | | Directory &|
                    | Auditing | | Service | |Subscription|
                    | Service  | |         | |  Services  |
                    +----------+ +---------+ +------------+
          
          3.8.1  Function
          
             These components provide functions required by the
             security services or required for secure operation of a
             networked system; however they do not enforce security
             policies.
          
          3.8.2  Protocols
          
             <<TBD>>
          
          3.8.3  Interfaces
          
             <<TBD>>
          
          3.8.4  Profiles
          
             <<TBD>>
          
          3.8.5  Negotiation
          
             <<Not germane to this document?>>
          
          
          4.  Hardware Security Devices in the Architecture
          
             The architecture is intended to support at least two
             kinds of hardware security devices:
          
              - Security Tokens
          
          
          
          Blakley          Document Expires: May 1997        [Page 37]


          Internet-Draft              APKI               November 1996
          
          
          
                This class of devices includes smartcards, memory
                cards, time-synchronized tokens, and challenge-
                response tokens.  These devices may provide crypto
                primitives and services, Virtual Smartcard services,
                and authentication functions.
          
                Smartcards are assumed by the architecture to provide
                Virtual Smartcard Services. They will also frequently
                also provide at least the "Key Activation" and
                "Signing" components of Crypto Services; they may also
                provide other Crypto Services.
          
                Memory cards provide only storage; Virtual Smartcard
                services involving state maintenance (e.g. key
                activation) or cryptography will have to be provided
                by the memory card's software drivers.  The figure
                below illustrates how smartcards and memory cards can
                be used to support the Virtual Smartcard services:
          
                     +------------------------------------+
                     |     Virtual Smartcard Interface    |
                     +------------------------------------+
                       |           |                 |
                       |   +---------------+  +-----------+
                       |   |Memory Card    |  |           |
                       |   |Personal Crypto|  |           |
                       |   |Module         |  | Software  |
                       |   +---------------+  | Personal  |
                       |         |        |   | Security  |
                     +-----------------+  |   |  Module   |
                     | Security Card   |  |   |           |
                     | Access Interface|  |   |           |
                     +-----------------+  |   |           |
                         |         |      |   |           |
                     +-------+  +------+  |   |           |
                     | Smart |  |Memory|  |   +-----------+
                     | Card  |  | Card |  |          |
                     +- - - -+  +------+ +----------------+
                     | Crypto|           | Cryptographic  |
                     | Funcs |           |   Services     |
                     +-------+           +----------------+
          
          
                Time-synchronized and challenge-response tokens
                provide only authentication functionality, and will
          
          
          
          Blakley          Document Expires: May 1997        [Page 38]


          Internet-Draft              APKI               November 1996
          
          
          
                typically be integrated into the architecture through
                modifications to the System Security Enabling Services
                (particularly the "Logon" and "Obtain Credentials"
                components of those services).
          
              - Cryptographic Modules
          
                This class of devices includes chipsets, bus-connected
                cryptographic adaptors, and remote cryptographic
                servers providing crypto primitives and services, but
                not providing user authentication functions.
          
                Cryptographic modules are assumed by the architecture
                to provide the full range of Crypto Services (and they
                may provide direct access to some Crypto Primitives
                for the convenience of designers of new Crypto
                Services).
          
          
          5.  Relationship to Other Standards and Architectures
          
          
          5.1  ISO 7498-2
          
             <<TBD>>
          
          5.2  IETF IPKI Drafts
          
             This document anticipates adoption (mutatis mutandis) of
             the four IPKI drafts as Internet RFCs, and seeks to
             define the larger architectural context into which those
             drafts fit.
          
          5.3  X/Open XDSF
          
             <<TBD>>
          
          5.4  ECMA TR-46
          
             <<TBD>>
          
          5.5  RSA PKCS Standards
          
             This architecture assumes support for the following PCKS
             standards:  Cryptographic message syntax; signature
          
          
          
          Blakley          Document Expires: May 1997        [Page 39]


          Internet-Draft              APKI               November 1996
          
          
          
             formats (PCKS-7) Smartcard function access (PKCS-11)
          
          
          6.  Example Applications of the Architecture
          
             <<This section TBD by various people>>
          
          6.1  OSF DCE 1.1
          
          6.2  SESAME
          
          6.3  Nortel Entrust
          
          6.4  OMG CORBA
          
          6.5  Lotus Notes
          
          6.6  Novell Netware
          
          
          7.  Glossary
             <<TBD>> Notes:
          
            1.  We use "confidentiality" and "privacy"
                interchangeably.
            2.  "Secret-key cryptography" is used to mean cryptography
                using a symmetric-key algorithm; "public-key"
                cryptography has the usual meaning; "private key" is
                used only to describe the private (secret) half of a
                key-pair generated for use with a public-key
                cryptographic system.
          
          
          8.  Security Considerations
          
             Security issues are discussed throughout this document.
          
          
          9.  References
          
             [1] draft-ietf-pkix-ipki-part1-00.txt.
          
             This document describes profiles for use of X.509
             certificates and certificate revocation lists (CRLs) and
             their respective extension fields in the Internet
          
          
          
          Blakley          Document Expires: May 1997        [Page 40]


          Internet-Draft              APKI               November 1996
          
          
          
             environment
          
             [2] draft-ietf-pkix-ipki-part3-00.txt.
          
             This document describes protocols for certificate
             management in the Internet environment
          
             [3] Internet RFC 1508.
          
             This document describes the GSS-API interface, which
             provides integrity and privacy services for session-
             oriented messages
          
             [4] draft-ietf-wts-gssapi-00.txt.
          
             This document describes how to use GSS-API to protect Web
             transactions (HTTP protocol exchanges, in particular)
          
             [5] draft-ietf-cat-idup-gss-04.txt.
          
             This document describes the IDUP-GSS-API interface, which
             provides integrity and privacy services for store-and-
             forward messages, and non-repudiation services.
          
             [6] draft-ietf-cat-spkmgss-06.txt.
          
             This document describes how to use the SPKM protocol
             under a GSS-API interface
          
             [7] draft-ietf-cat-sesamemech-00.txt.
          
             This document describes the use of the SESAME protocols
             under a GSS-API interface.
          
             [8] draft-ietf-cat-snego-01.txt.
          
             This document describes a proposed mechanism negotiation
             preamble protocol for use by protocol partners wishing to
             use GSS-API to establish a secure association.
          
             [9] X/Open Distributed Security Framework.
          
             [10] ISO 7498-2 "Information processing systems - Open
             Systems Interconnection - Basic Reference Model - Part 2:
             Security Architecture".
          
          
          
          Blakley          Document Expires: May 1997        [Page 41]


          Internet-Draft              APKI               November 1996
          
          
          
             [11] ECMA TR/46 "Security in Open Systems: A Security
             Framework".
          
             [12] The SSL Protocol v3.
          
             Describes version 3 of the SSL protocol; available from
             Netscape Web site
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 42]


          Internet-Draft              APKI               November 1996
          
          
          
          AUTHOR'S ADDRESS
             Bob Blakley
             IBM
             Mail Stop 9132
             11400 Burnet Road
             Austin, TX  78758 USA
          
             Phone: +1 512 838 8133
             FAX  : +1 512 838 0156
          
             email: blakley@vnet.ibm.com
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Blakley          Document Expires: May 1997        [Page 43]
          

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/