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]
