idnits 2.17.1 draft-ietf-pkix-apki-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview of the PKI Architecture' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 26 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [Applications], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 164 has weird spacing: '... policy arise...' == Line 197 has weird spacing: '...eration facil...' == Line 230 has weird spacing: '...user to suspe...' == Line 231 has weird spacing: '...ctivate his p...' == Line 446 has weird spacing: '...onality witho...' == (8 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1996) is 10017 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Applications' on line 687 looks like a reference -- Missing reference section? '1' on line 1751 looks like a reference -- Missing reference section? '2' on line 1758 looks like a reference -- Missing reference section? '3' on line 1763 looks like a reference -- Missing reference section? '4' on line 1769 looks like a reference -- Missing reference section? '5' on line 1774 looks like a reference -- Missing reference section? '6' on line 1780 looks like a reference -- Missing reference section? '7' on line 1785 looks like a reference -- Missing reference section? '8' on line 1790 looks like a reference -- Missing reference section? '9' on line 1796 looks like a reference -- Missing reference section? '10' on line 1798 looks like a reference -- Missing reference section? '11' on line 1802 looks like a reference -- Missing reference section? '12' on line 1805 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft B. Blakley (IBM) 3 IETF PKIX WG and the APKI Working Group 4 draft-ietf-pkix-apki-00.txt November 1996 6 Architecture for Public-Key Infrastructure 8 STATUS OF THIS MEMO 10 This document is an Internet Draft. Internet Drafts are 11 working documents of the Internet Engineering Task Force 12 (IETF), its Areas, and its Working Groups. Note that 13 other groups may also distribute working documents as 14 Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum 17 of six months. Internet Drafts may be updated, replaced, 18 or obsoleted by other documents at any time. It is not 19 appropriate to use Internet Drafts as reference material 20 or to cite them other than as a "working draft" or "work 21 in progress." 23 To learn the current status of any Internet-Draft, please 24 check the 1id-abstracts.txt listing contained in the 25 Internet-Drafts Shadow Directories on ds.internic.net, 26 nic.nordu.net, ftp.isi.edu, or munnari.oz.au. 28 Comments and suggestions on this document are encouraged. 29 Of particular interest are interfaces and protocols which 30 may have been omitted and specifications which are 31 believed to be suitable bases for standardization of APKI 32 interfaces and protocols. Comments on this document 33 should be sent to the APKI WG discussion list: 35 pki-tg@opengroup.org 37 ABSTRACT 39 This document describes Requirements and an Architecture 40 for Public-Key Infrastructure components, identifies 41 which elements of the architecture should (in the opinion 42 of the authors) be standardized, and identifies candidate 43 interface and protocol specifications which might serve 44 as base documents for the standardization effort. 46 ACKNOWLEDGMENTS 48 Members of the APKI working group contributing 49 substantially to this document include: 51 Anne Anderson (HP), Charles Blauner (JP Morgan), Belinda 52 Fairthorne (ICL), Warwick Ford, Robert Jueneman (Novell), 53 Ellen McDermott (Open Market), Howard Melman (OSF), Denis 54 Pinkas (Groupe Bull), Walt Tuvell (OSF), and John Wray 55 (Digital Equipment Corporation). 57 Many other working group members contributed important 58 insights during conversations of the material in this 59 document. 61 CONTENTS 63 1. Requirements ....................................... 4 64 1.1 Baseline Requirements ............................. 4 65 1.2 The Importance of Architecture .................... 10 66 1.3 Document Overview ................................. 14 68 2. Overview of the PKI Architecture ................... 15 70 3. Public-Key Infrastructure Components ............... 16 71 3.1 Crypto Primitive Components ....................... 17 72 3.2 Crypto Service Components ......................... 19 73 3.3 Long-Term Key Services Components ................. 22 74 3.4 Protocol Security Services Components ............. 29 75 3.5 Secure Protocol Components ........................ 33 76 3.6 System Security Enabling Components ............... 35 77 3.7 Security Policy Services Components ............... 36 78 3.8 Supporting Services Components .................... 37 80 4. Hardware Security Devices in the Architecture ...... 37 82 5. Relationship to Other Standards and Architectures .. 39 83 5.1 ISO 7498-2 ........................................ 39 84 5.2 IETF IPKI Drafts .................................. 39 85 5.3 X/Open XDSF ....................................... 39 86 5.4 ECMA TR-46 ........................................ 39 87 5.5 RSA PKCS Standards ................................ 39 89 6. Example Applications of the Architecture ........... 40 90 6.1 OSF DCE 1.1 ....................................... 40 91 6.2 SESAME ............................................ 40 92 6.3 Nortel Entrust .................................... 40 93 6.4 OMG CORBA ......................................... 40 94 6.5 Lotus Notes ....................................... 40 95 6.6 Novell Netware .................................... 40 97 7. Glossary ........................................... 40 99 8. Security Considerations ............................ 40 101 9. References ......................................... 40 103 1. Requirements 105 The following requirements have been collected by the 106 Open Group (OSF - X/Open) Security Program Group Public 107 Key Infrastructure (PKI) Task Group (TG), with the 108 participation of the following organizations: 110 Barclays Bank, Shell International, Sweden Post, UK 111 Ministry of Defense, BCTEL, US DISA, The Open Group, 112 Telecom Finland Ltd., Pacific Gas & Electric, Electronic 113 Data Systems, Jet Propulsion Laboratory, Boeing, 114 Information & Support Group, Harris Corporation, ICL, 115 Lockheed Martin, Guide International, J P Morgan, IBM, 116 Bellcore, Nortel, HP, NIST, SUN, Siemens Nixdorf, 117 Dynasoft, SCO, Bull, NCR, US NSA, Digital Equipment 118 Corporation, Amdahl, OpenVision, Citicorp, Fujitsu-ICL, 119 Mitre. 121 The Open Group PKI TG continues to refine and extend 122 these requirements; comments should be sent by electronic 123 mail to OGsecurity@opengroup.org. 125 1.1 Baseline Requirements for a Global PKI and PK Services 127 An interoperable global PKI is required to provide 128 privacy and digital signature services in support of 129 international commerce, balancing the legitimate needs of 130 commerce, governments and privacy of citizens. The global 131 PKI must support multiple governance policy models within 132 a single global PKI framework, and must enable the 133 enforcement of all existing governance policy mandates. 135 1.1.1 Required Services 137 A. Establishment of domains of trust and governance 138 B. Confidentiality (sealing) 139 C. Integrity and authentication (signing) 140 D. Non-repudiation 141 E. End-to-end monitoring, reporting and auditing of PKI 142 services 144 1.1.2 Required Functionality and Characteristics 145 A. Key life-cycle management 147 The actual life cycle of a key depends on whether it 148 is used for confidentiality or signature purposes. 149 Key life-cycle facilities to be supported are: 151 1. Key recovery facilities 153 The PKI shall provide for key recovery. Key 154 recovery facilities shall provide the following 155 functionality: 157 i. Use of key recovery facilities implies 158 acceptance of a mandatory policy for 159 the protection and recovery of keys. 160 The policy defines how the keys are to 161 be protected and under what conditions 162 and to whom a key will be made 163 available. The mandatory aspect of 164 policy arises as the operations of a 165 key recovery facility may be regulated 166 by legislation or procedures required 167 under commercial contracts for 168 liability management. 169 ii. Only key recovery enabled systems shall 170 be usable within a PKI. 171 iii. A key recovery facility shall be 172 unconditionally trusted and be liable 173 to uphold the stated policy with 174 redress for loss arising from failures 175 to uphold policy through contractual 176 liability and penalties. 177 iv. A key recovery center shall be able to 178 verify the legitimacy of a key 179 submitted to it for storage. 180 v. A user of a key recovery repository 181 shall be able to verify that it is an 182 authorized repository. 183 vi. The PKI shall provide for coordination 184 between the management of public and 185 private keys in PKI and in data 186 recovery centers. Note that public and 187 private key parts do not have the same 188 life cycle and key parts may be 189 archived. 191 vii. The PKI shall support aging, 192 revocation, and repudiation of keys. 193 viii. The PKI shall support discretionary key 194 fragmentation between key recovery 195 facilities. 197 2. Key Generation facility 199 The method of key generation shall be 200 discretionary, subject to commercial decision 201 and business requirement. Selection of key 202 quality, uniqueness, secrecy and recoverability 203 of keys must be left to the discretion of the 204 organization generating the keys (and any 205 governance authorities to which it is subject). 207 3. Key Distribution, Revocation, Suspension, 208 Repudiation and Archive 210 The PKI must support the following 211 functionality: 213 i. Facilities for the distribution of keys 214 to appropriate storage devices and 215 directories. 216 ii. Ability of a certification authority to 217 revoke certificates for individual keys 218 under the terms of the applicable 219 policy. 220 iii. Ability of a certification authority to 221 suspend and reactivate certificates for 222 individual keys under the terms of the 223 applicable policy. 224 iv. Ability of a certification authority to 225 force delivery of revocation, 226 suspension, and reactivation notices. 227 v. Facilities to enable a user to 228 repudiate his public key under the 229 terms of the applicable policy. 230 vi. Facilities to enable a user to suspend 231 and reactivate his public key under 232 the terms of the applicable policy. 233 vii. Facilities to enable the user and 234 subscriber to retrieve revocation, 235 suspension, and reactivation notices. 237 viii. Facilities to enable the user and 238 subscriber to determine the status 239 (e.g., revoked or suspended) of a 240 specific certificate. 241 ix. Facilities to enable the archive and 242 subsequent retrieval of certificates in 243 support of the retrieval and 244 verification of long term information 245 in accordance with governance policy. 247 4. Warranted retrieval 249 The PKI must enable the following warranted 250 retrieval scenarios: 252 i. Law enforcement retrieval (subject to 253 policy conditions) 254 ii. Corporate agency retrieval (subject to 255 policy and authorizations) 256 iii. Individual retrieval (subject to policy 257 and authorizations) 259 The following functionality is required in 260 support of warranted retrieval: 262 i. An electronic vehicle for the delivery 263 of a notarized electronic warrant, to 264 support the automation of key retrieval 265 under due process (this must be able to 266 take advantage of existing legal 267 agreements) 268 ii. A permanent, non-repudiable and 269 independently verifiable record of key 270 retrieval operations must be 271 maintained. 273 Note that warranted retrieval policy includes 274 policy regarding disclosure or non-disclosure of 275 key retrieval to owner of the retrieved key. 277 B. Distributed Certificate Management Structure 279 The PKI must provide distributed Certificate 280 Management functionality, driven by the requirements 281 of the transaction or business domain. The following 282 Certificate Management function must be provided by 283 the PKI: 285 1. Policing and policy enforcement (governance 286 model), including the following: 288 i. Policy creation and maintenance. The 289 policies include those covering key 290 generation, key recovery, key 291 distribution, revocation, suspension, 292 repudiation, archive and warranted 293 retrieval . 294 ii. Ability to register a key and the 295 binding between the key and a name. 296 iii. Ability to query which keys are bound 297 to a name 298 iv. Policies (for services built on PKI 299 access control) must not be required to 300 be based on individual identity. 301 v. Certification of the binding between a 302 public key and a directory name shall 303 be mandatory 304 vi. Certification of the binding between 305 additional attributes and a directory 306 name shall be discretionary 307 vii. Auditing and support for the monitoring 308 of policy compliance is required 310 2. Concurrent support of multiple policies 311 3. exchange of certificates. 312 4. Support for continuance of service in the event 313 of transfer of certificate services from one 314 certification authority to another. 315 5. Certificate authority policy mapping services to 316 establish cross certification between CAs. 317 6. Support for arbitration to determine 318 acceptability of certificates in the event of 319 multiple conflicting certification paths. 320 7. Support for separation of the certification 321 authority and repository functions in accordance 322 with the governance policy. changes to 323 certificate repositories must be transactional 324 (e.g., two-phase commits). 326 C. Security of the PKI 327 The PKI itself must be secure. In particular, the PKI 328 must: 330 1. Protect the confidentiality, integrity and 331 availability of the PKI services, for example 332 key generation, key distribution, and key 333 storage. 334 2. Provide strong non-repudiation services for 335 actions of certificate services. 336 3. Prevent PKI services themselves from repudiating 337 their own actions. 338 4. Prevent users and subscribers from repudiating 339 their own actions. 341 D. Time service 343 A universal, networked time service must be available 344 for time stamping. 346 E. Interoperability 348 PKI elements provided by different vendors must 349 interoperate. In support of interoperability, PKI 350 elements must: 352 1. support international standards for certificates 353 and associated data 354 2. support international standards for certificate 355 services 356 3. support internationalization of all certificates 357 and associated data 358 4. support internationalization of all certificate 359 services 361 1.1.3 Known Issues 363 For interoperability there is a dependency upon the 364 definition of standard application program interfaces to 365 and protocols between the component services of the 366 Public Key Infrastructure. 368 Work is required to define and agree profiles of option 369 fields in certificates. 371 1.1.4 Recommendations 373 Adopt X.509 version 3 as a basis for certificates in the 374 development of the PKI. 376 Adopt and adapt existing standards and protocols wherever 377 possible, invent new standards or protocols only as a 378 last resort. 380 1.2 The Importance of Architecture 382 The APKI working group feels that a robust, flexible, 383 standard, open Public-Key Infrastructure Architecture is 384 critical to the success of secure systems based on 385 Public-Key technology. This section explains why. 387 1.2.1 What is Architecture? 389 The architecture of a software system is the set of 390 interfaces through which its functions are accessed, and 391 the set of protocols through which it communicates with 392 other systems. 394 The remainder of this section discusses the importance of 395 standardizing the interfaces and protocols which comprise 396 the Public-Key Infrastructure software Architecture. 398 1.2.2 Interfaces 400 The following figure illustrates a system on which three 401 security products have been installed. 403 In the figure: 405 - Product 1 includes a protocol and all the security 406 functionality needed to protect data flowing over that 407 protocol. Only the secure protocol's interface is 408 exposed; the underlying security functionality is not 409 available to other applications. 410 - Product 2 also includes a protocol and its requisite 411 security functionality, but it exposes the data 412 protection functionality through a public interface so 413 that other applications can use it. It does not 414 permit direct access to cryptographic functionality. 415 - Product 3 is a hardware cryptographic adapter; it 416 Product 1 Product 2 417 +-------------------+ +-------------------+ 418 |+-----------------+| |+-----------------+| 419 || Secure || || Secure || 420 || Protocol || || Protocol || 421 |+-----------------+| |+-----------------+| 422 |+-----------------+| |+-----------------+| 423 || Security || || Security || 424 || State Mgmt & || || State Mgmt & || 425 || Data Protection || || Data Protection || 426 |+-----------------+| |+-----------------+| 427 |+-----------------+| |+-----------------+| 428 || Crypto || || Crypto || 429 || Software || || Software || 430 |+-----------------+| |+-----------------+| 431 +-------------------+ +-------------------+ 433 +-----------------+ 434 Product 3 | Crypto Hardware | 435 +-----------------+ 437 comes with a software driver permitting access by 438 applications to its cryptographic functionality. 440 This configuration has several bad characteristics: 442 - Because neither product 1 nor product 2 accesses 443 cryptographic functionality through a standard 444 interface, neither can use the cryptographic adapter. 445 Furthermore, because both product 1 and product 2 446 embed cryptographic functionality without exposing an 447 interface through which it can be accessed, neither 448 can use the other's cryptographic software. The end 449 result is that three different cryptographic 450 subsystems (two software and one hardware) must be 451 installed on the system, even if all three products 452 use the same cryptographic algorithms! 453 - Because product 1 and product 2 embed cryptographic 454 functionality rather than accessing a separate 455 cryptographic subsystem through a published interface, 456 they will not be deployable (without code changes) in 457 countries whose regulatory environment restricts or 458 forbids use of the cryptographic functions they embed. 460 This example illustrates some of the benefits of standard 461 interfaces; these include: 463 - Replaceability of services (e.g. cryptography) without 464 change to exploiting applications 465 - Elimination of duplicate service implementations in 466 configurations in which multiple applications require 467 the same kind of service 468 - Reduced programmer training costs (programmers need 469 learn only one standard interface for a service rather 470 than learning the proprietary interfaces of multiple 471 products providing the same service) 472 - Reduced application porting complexity (code 473 exploiting services through standard interfaces need 474 not be changed, or requires only minimal changes, when 475 porting from one platform supporting the standard 476 interface to another such platform) 478 1.2.3 Protocols 480 The following figure illustrates two certificate- 481 management products. 483 In the figure: 485 - Product 1 communicates key requests to the 486 Certification Authority (CA) via electronic mail, and 487 receives keys and certificates from the CA via email. 488 - Product 2 communicates key requests to the CA using a 489 proprietary protocol and retrieves keys from a 490 directory service using the LDAP protocol. 492 A configuration including both products would have 493 several bad characteristics: 495 - Neither product's CA could accept key requests from 496 the other product's clients. 497 - Applications using product 1 clients and wishing to 498 advertise their certificates in the directory service 499 would require installation of a separate directory- 500 access product. 501 - Applications using product 1 clients and wishing to 502 retrieve partners' certificates from the directory 503 service would require installation of a separate 504 directory-access product. 506 Product 1 507 +--------------------------------+ +-----------+ 508 | +-------+ +-+ | | +-+ +----+| 509 | Application --|Key |---|e|--|------|-|e|-| || 510 | ^ |Request| |m| | | |m| | || 511 | | +-------+ |a| | | |a| | CA || 512 |+----------+ |i| | | |i| | || 513 ||User Key |---------------|l|--|------|-|l|-| || 514 ||Management| +-+ | | +-+ +----+| 515 |+----------+ | | | 516 +--------------------------------+ +-----------+ 518 Product 2 519 +-------------------------+ +-----------+ 520 | +-------+ | | +----+| 521 | Application --|Key |-|-------------|-----| || 522 | ^ |Request| | | +-+ | || 523 | | +-------+ | | |L| | CA || 524 |+----------+ +------+ | +---------+ | |D| | || 525 ||User Key |---| LDAP |--|-|Directory|-|-|A|-| || 526 ||Management| | | | +---------+ | |P| +----+| 527 |+----------+ +------+ | | +-+ | 528 +-------------------------+ +-----------+ 530 This example illustrates the benefit of standard 531 protocols: 533 - Applications supporting standard protocols can 534 interoperate, even if produced by different providers. 536 1.2.4 Profiles 538 Many of the services in the Public-Key Infrastructure 539 Architecture can be implemented using a variety of 540 different mechanisms and protocols (e.g. data privacy 541 protection can be implemented using a variety of 542 different cryptographic algorithms). This variety of 543 mechanisms and protocols has arisen in part because 544 different environments impose different security 545 requirements. 547 Multiplicity of mechanisms means that different 548 providers' implementations of the PKI Architecture will 549 not necessarily interoperate - even though they support 550 the standard interfaces and a selection of the standard 551 protocols. 553 A profile defines the set of mechanisms and protocols 554 which should be used in a particular environment. The 555 mechanisms and protocols comprising a profile are usually 556 chosen on the basis of their strength against the attacks 557 which are common in the environment supported by the 558 profile. Profiling has the following advantages: 560 - Systems conforming to an environment's profile will 561 interoperate. 562 - Systems conforming to an environment's profile will be 563 well-protected against that environment's risks. 564 - Profiling helps to assure that mechanisms in use work 565 together appropriately and securely. 567 1.2.5 Negotiation 569 Some profiles will allow multiple mechanisms and 570 protocols in order to support different qualities of 571 protection, or to accommodate a fragmented security 572 product market. In these environments, it is desirable 573 to provide a negotiation meta-protocol which allows 574 communicating partners to determine: 576 - which mechanisms and protocols they both (or all) 577 share 578 - which mechanism and protocol, among the shared set, 579 best supports the desired quality of protection. 581 It is important to note that negotiation does not always 582 require an on-line dialog between the negotiating 583 entities. 585 1.3 Document Overview 587 Section 2 presents the high-level structure of the PKI 588 Architecture by grouping the architecture's components 589 into broad functional categories. 591 Section 3: 593 - enumerates the components in each of the 594 Architecture's functional categories 595 - describes the functionality of each component and 596 lists existing specifications which could serve as 597 candidate standards for each component's interfaces 598 and protocols (To be considered a "candidate" for 599 purposes of the public-key infrastructure 600 architecture, an interface or protocol must: (1) be 601 described by a publicly-available specification, and 602 (2) support a significant fraction of the 603 functionality of the PKI component for which it is 604 proposed as a candidate. It is assumed that the 605 candidate interface and protocol specifications 606 identified in this document will serve as base 607 documents for open standardization processes, which 608 will produce finalized PKI component interface and 609 protocol specifications.) 610 - identifies where negotiation facilities are required 611 to deal with the probable existence of a multiplicity 612 of security mechanisms 613 - enumerates important public-key-related protocols and 614 discusses the need for environment-specific profiles 616 Section 4 discusses the use of hardware security devices 617 in the architecture. 619 Appendices to the document provide: 621 - examples illustrating application of the architecture 622 to existing secure systems, 623 - the relationship of this document to existing security 624 architecture standards 625 - a glossary of terms related to security and public-key 626 cryptography 627 - an annotated list of references 629 2. Overview of the PKI Architecture 631 The PKI architecture components are grouped into the 632 following broad functional categories: 634 A. System Security Enabling Services provide the 635 functionality which allows a user's or other 636 principal's identity to be established and associated 637 with his actions in the system. 638 B. Crypto Primitives and Services provide the 639 cryptographic functions on which public-key security 640 is based (including secret-key primitives such as 641 DES). 642 C. Long-term Key Services permit users and other 643 principals to manage their own long-term keys and 644 certificates and to retrieve and check the validity of 645 other principals' certificates 646 D. Protocol Security Services provide security 647 functionality (data origin authentication, data 648 integrity protection, data privacy protection, 649 nonrepudiation) suitable for use by implementors of 650 security-aware applications such as secure protocols. 651 E. Secure Protocols provide secure inter-application 652 communications for security-unaware and "mildly" 653 security-aware applications. 654 F. Security Policy Services provide the policy-related 655 information which must be carried in secure protocols 656 to enable access control, and provide access-control 657 checking facilities to security-aware applications 658 which must enforce policy. 659 G. Supporting Services provide functionality which is 660 required for secure operation, but is not directly 661 involved in security policy enforcement. 663 The following figure illustrates the PKI architecture. 665 Section 3 describes each of these categories in more 666 detail (listing the components in each category), and 667 identifies interfaces and protocols which may be 668 candidate bases for standardization of each component. 669 Appendix B uses the figure above to illustrate how a 670 number of existing security technologies fit into the 671 architecture. 673 Note that while the architecture described in this 674 document could be implemented on insecure operating 675 system platforms, implementors of the architecture must 676 insure that keys, security context data, and policy data 677 are appropriately protected in such environments. 679 3. Public-Key Infrastructure Components 681 Each of this section's subsections describes one of the 682 Architecture's categories in detail, enumerating its 683 components and describing component functions, 685 +-------------------------------------------------------+ 686 | | 687 | [Applications] | 688 | | 689 +-------------------------------------------------------+ 690 | | | | 691 | | Secure Protocols | Security | 692 | | | Policy | 693 | System +-------------------------------+ Services | 694 | Security | | | 695 | Enabling | Protocol Security Services +------------+ 696 | Services | | | 697 | +-------------------------------+ | 698 | | | | 699 | | Long-Term Key Services | | 700 | | | | 701 +----------+-------------------------------+ Supporting | 702 | | Services | 703 | Cryptographic Services | | 704 | | | 705 +...............................+ | 706 | | | 707 | Cryptographic Primitives | | 708 | | | 709 +-------------------------------+------------+ 711 interfaces, and protocols. 713 3.1 Crypto Primitive Components 715 The figure below illustrates the Crypto Primitive 716 Components: 718 Note that the architecture's cryptographic primitives may 719 be provided by hardware (e.g. smartcards or cryptographic 720 modules) or by software. 722 3.1.1 Function 724 These components provide access to low-level 725 cryptographic primitives such as key generation, hash 726 function application to a data buffer, encryption of a 727 data buffer using secret-key or public-key algorithms, 728 decryption of a data buffer using secret-key or public- 729 key algorithms, etc.... 731 +------------+ +--------------+ +--------------+ +------------+ 732 | Random | | Key | | Secret | | | 733 | Number | | Generation | | Sharing | | Hashing | 734 | Generation | | | | | | | 735 +------------+ +--------------+ +--------------+ +------------+ 737 +------------+ +--------------+ +--------------+ 738 | Keyed | | Symmetric | | Asymmetric | 739 | Hashing | | (secret-key) | | (public-key) | 740 | | | Crypto | | Crypto | 741 | | | Primitives | | Primitives | 742 +------------+ +--------------+ +--------------+ 744 3.1.2 Protocols 746 Cryptographic primitives are typically called locally; it 747 is not anticipated that any cryptographic primitive 748 protocols will be defined. 750 3.1.3 Interfaces 752 Candidate interfaces for access to cryptographic 753 primitives include: 755 - The RSA BSafe library interface 756 - The X/Open GCS-API 757 - The Microsoft CryptoAPI 1.0 759 Other interfaces which may support some or all of the 760 cryptographic primitive function include 762 - Fortezza 763 - IBM CCA 765 Standardization of these interfaces would be of interest 766 to developers of cryptographic service modules and to 767 providers of cryptographic primitive modules. 768 Standardization of an interface for access to 769 cryptographic primitives would facilitate "pluggable" 770 implementations of cryptographic services. The consensus 771 of the APKI working group, however, is that cryptographic 772 functionality will ordinarily be used through the 773 cryptographic service interfaces rather than through the 774 cryptographic primitive interfaces. Therefore, 775 standardization of cryptographic primitive interfaces is 776 not viewed as essential. 778 3.1.4 Profiles 780 Most cryptographic modules provide support for multiple 781 primitives. Many primitives are subject to legal 782 restrictions on deployment (including both intellectual 783 property encumbrances and national and international 784 regulatory constraints on export, import, and 785 deployment). 787 Cryptographic primitive profiles will have to be 788 developed for PKI environments of interest (including, 789 for example, the Internet, OMG CORBA, OSF DCE, Financial, 790 etc.). 792 3.1.5 Negotiation 794 Cryptographic primitives are ordinarily used only by the 795 implementors of cryptographic services. Negotiation 796 should be used to establish which cryptographic 797 service(s) are to be used, rather than to establish what 798 primitives should be used. Ordinarily this negotiation 799 will be done at a higher level than that of the 800 cryptographic primitives and services themselves. No 801 protocol for negotiating cryptographic primitives should 802 be required. 804 3.2 Crypto Service Components 806 The figure below illustrates the Cryptographic Service 807 Components: 809 +-----------+ +------------+ +------------+ +------------+ 810 | Crypto | | Key | | Key | | Key | 811 | Context | | Import & | | Derivation | | Agreement | 812 | Management| | Export | | | | | 813 +-----------+ +------------+ +------------+ +------------+ 815 +-----------+ +------------+ +------------+ +------------+ 816 | Key | | Data | | Data | | Data | 817 | Usage | | Integrity | | Privacy | | Signature | 818 | Control | | | | | | | 819 +-----------+ +------------+ +------------+ +------------+ 821 3.2.1 Function 823 These components provide access to cryptographic services 824 such as data integrity and privacy protection ("data" 825 here might be a file, a message, an i/o stream, etc...), 826 key import and export, digital signature, keyed hash, 827 etc.... 829 Cryptographic Context Management provides the facilities 830 through which applications initialize the cryptographic 831 subsystem, activate keys for encryption and decryption, 832 and clean up the state of the cryptographic subsystem 833 after use. 835 Key usage controls permit control over a variety of 836 aspects of key use, including how many times a key may be 837 used; for what purposes it may be used (e.g. for 838 signature only, for privacy only, for both signature and 839 privacy, etc...), and so on. 841 Key derivation services permit generation of 842 cryptographic-quality keys from non-key values such as 843 passwords. 845 Crypto services are built on crypto primitives. A crypto 846 service may support multiple implementations, each of 847 which uses a different crypto primitive. 849 Descriptions of a few DES-based services will illustrate 850 the difference between primitives and services; note that 851 these are only examples: 853 - DEA is a crypto primitive which uses a 56-bit key and 854 an initialization vector to transform a 64-bit 855 plaintext into a 64-bit ciphertext. 856 - Data privacy is a crypto service. DES-CBC is an 857 implementation of the cryptographic data privacy 858 service which uses a 56-bit key, an initialization 859 vector, and the DEA primitive to transform a 860 plaintext of arbitrary length into a ciphertext of the 861 same length subject to some rules defined by a "mode 862 of operation". The rules describe how to "pad" 863 plaintexts to a multiple of 64 bits and whether and 864 how to induce dependencies among 64-bit blocks of the 865 ciperhtext by feeding ciperhtext material from 866 previous rounds of the encryption process into the 867 current round. 868 - Data integrity is a crypto service. DES-CBC-MAC is an 869 implementation of the data integrity service which 870 uses the DEA primitive to generate a message 871 authentication code given a 56-bit key, an 872 initialization vector, and a plaintext of arbitrary 873 length. 875 3.2.2 Protocols 877 Cryptographic services are typically called locally; it 878 is not anticipated that any cryptographic service 879 protocols will be standardized. 881 3.2.3 Interfaces 883 Candidate interfaces for cryptographic services include: 885 - X/Open GCS-API 886 - Microsoft CryptoAPI 1.0 887 - SESAME CSF API 889 Other interfaces which may support some or all of the 890 cryptographic primitive function include 892 - Cryptoki 893 - RSA BSAFE 895 Standardization of these interfaces would be of interest 896 to developers of long-term-key service and protocol 897 security service modules and to providers of 898 cryptographic service modules. The APKI working group 899 feels that it is important to standardize a single 900 interface for cryptographic services. 902 3.2.4 Profiles 904 Most cryptographic modules provide support for multiple 905 services. Many crypto services are subject to legal 906 restrictions on deployment (including both intellectual 907 property encumbrances and national and international 908 regulatory constraints on export, import, and 909 deployment). 911 Cryptographic service profiles will have to be developed 912 for PKI environments of interest (including, for example, 913 the Internet, OMG CORBA, OSF DCE, Financial, etc.). 914 These profiles will have to be developed with 915 international deployment issues in mind. Each profile 916 should be expressed in terms of the parameters used to 917 select cryptographic services (and implementations of 918 cryptographic services -- often called "mechanisms") 919 through the cryptographic service interface (see the next 920 section for more information on service and mechanism 921 selection). 923 Profiles will need to specify, in addition to mechanism 924 information, the data formats which each service can 925 accept and return. 927 3.2.5 Negotiation 929 Negotiation of cryptographic services to be used by 930 secure protocols and other security-aware applications 931 is generally done at level higher than that of the 932 cryptographic services themselves. The cryptographic 933 service interface therefore must allow selection among 934 available cryptographic services, and among available 935 implementations of a single service, but it need not 936 support negotiation. 938 3.3 Long-Term Key Services Components 940 The following figure illustrates the Long-Term Key 941 Services Components; each component is described in more 942 detail below. 944 +-----------+ +------------+ +------------+ +------------+ 945 | Key | | Key | | Key | | Virtual | 946 | Lifecycle | | Escrow | | Recovery | | Smartcard | 947 | Management| | | | | | Service | 948 +-----------+ +------------+ +------------+ +------------+ 950 +-----------+ +------------+ 951 |Certificate| | Public-Key | 952 | Management| | Delivery & | 953 | | |Verification| 954 +-----------+ +------------+ 956 3.3.1 Function 958 Key Lifecycle Management 960 This component provides including key revocation, key 961 repudiation, key expiration, and related services. 963 Key Escrow and Key Recovery 965 These components permit secure storage of keys for later 966 recovery under policy control. 968 Virtual Smartcard Service 970 The Virtual Smartcard Service Component permits users and 971 other principals to store long-term personal security 972 information (including private keys, certificates, and 973 other information) in protected storage, to activate 974 personal keys for use via an authentication procedure, 975 and to use those keys for encryption, decryption, and 976 signature activities. 978 The following figure illustrates the structure of this 979 component. 981 +------------------------+ 982 | | 983 | Virtual Smartcard Svc. | 984 | | 985 +----------+--+----------+ 986 | Hardware | | Software | 987 | Security | | Personal | 988 | Token | | Security | 989 | | | Model | 990 +----------+ +----------+ 992 Certificate Management 994 The Certificate Management component allows users, 995 administrators and other principals to request 996 certification of public keys and revocation of previously 997 certified keys. It may optionally generate key pairs and 998 provide key-pair recovery services. There are four 999 Certificate Management sub-components: 1001 The Local Registration Authority provides interfaces for 1002 requesting generation of key-pairs and corresponding 1003 certificates, requesting certification of existing public 1004 keys, and requesting revocation of existing certificates. 1006 The Certification Authority Agent (CA Agent) provides 1007 interfaces for certifying existing public keys, 1008 generating and returning key pairs and corresponding 1009 certificates, revoking existing certificates. The CA 1010 Agent implements these interfaces via calls to a 1011 Certification Authority (CA). 1013 The Certification Authority certifies public keys 1014 (returning the generated certificate) and generates 1015 certificate revocation lists. In some configurations it 1016 will be "off-line". 1018 The Publication Authority provides interfaces through 1019 which CAs and CA Agents can place certificates and CRLs 1020 into public repositories or transmit them directly to 1021 requestors. 1023 Public-Key Delivery and Verification 1025 This component allows a program to retrieve any 1026 principal's certificate, verify its validity, and extract 1027 the principal's certified public key from the 1028 certificate. 1030 The following figure illustrates the structure and 1031 interrelationships of the Certificate Management and 1032 Public-Key Delivery and Verification components and 1033 sub-components. 1035 3.3.2 Protocols 1037 Virtual Smartcard Service 1039 When the Virtual Smartcard Service component is used for 1040 retrieval of user private keys, two models exist. One 1041 model (exemplified by PGP and Lotus Notes) manages 1042 private keys primarily on the client principal's machine 1043 (either in a software personal security module, or in a 1044 security token or other device external to the 1045 principal's workstation). In this model, no protocols 1047 +-----------+---------------++=====+==============++ 1048 | | Public || | Local || 1049 | | Key || | Registration || double border 1050 | Virtual | Delivery || | Authority || / encloses 1051 | Smartcard | and || +--------------++ / Certificate 1052 | Service | Verification || CA || / Management 1053 | | || Agent || < Component 1054 | | ++---------+----------++ 1055 | | || | || 1056 | +-------++======++ | || 1057 | || | || 1058 | || Publication | CA || 1059 | || Authority | || 1060 +-------------------++=================+==========++ 1062 are required for User/Principle Personal Security Info 1063 Management, since all operations are client-local. 1065 The second model (exemplified by Novell NetWare) manages 1066 private keys at a central server and distributes them to 1067 client principals using a secure protocol. In this 1068 model, the client/server protocol for retrieval of 1069 private keys needs to be supported by the software 1070 personal security module subcomponent of the Virtual 1071 Smartcard Service component, as illustrated in the figure 1072 below (the dotted arrow in the figure represents the 1073 protocol): 1075 +-----------------------+ 1076 |User/Principal | 1077 |Personal Security Info | 1078 |Management Interface | 1079 +--------------+--------+ +----------+ 1080 |Software| |Remote | 1081 |Personal| |Private | 1082 |Security|---->|Key | 1083 |Module | |Repository| 1084 +--------+ +----------+ 1086 The APKI working group does not view standardization of 1087 this protocol to be essential. 1089 Certificate Management 1091 Protocols must be defined to permit creation, revocation, 1092 and update of certificates. The diagram below 1093 illustrates Certificate Management protocols which might 1094 be standardized; each arrow in the diagram represents a 1095 protocol. 1097 Certificate Management 1098 +-----------------------------------------+ 1099 +--------------+ | +------------+ +-----------+ | 1100 | Application | | | Local | |Certificate| | 1101 |(or Smartcard)|---->|Registration|----------->| Authority | | 1102 | | | | Authority | | Agent | | 1103 +--------------+ | +------------+ +-----------+ | 1104 | | / ^ | 1105 | +-------------+ / | | 1106 | | v | | 1107 +------------+ | +-----------+ | | 1108 | Public-Key | | |Publication| | | 1109 | Delivery & |<..................| Authority | | | 1110 |Verification| | | | | | 1111 | |-----+ | +-----------+ | | 1112 +------------+ | +---/-------+ | | 1113 | v v | v | 1114 +------------+ +---------------+ | +-----------+ | 1115 | Virtual | | Repository & | | |Certificate| | 1116 | Smartcard | | Subscription | | | Authority | | 1117 | Services | | Services | | | | | 1118 +------------+ +---------------+ | +-----------+ | 1119 +---------------+ 1121 Note that implementations may choose to assign the 1122 responsibility for generation of private keys (through 1123 use of the key generation facilities of the PKI 1124 architecture) to the CA, the LRA, or the User Workstation 1125 or Smartcard; additional protocols will be required to 1126 transmit the private key to the User Workstation or 1127 Smartcard if it is not generated there in the first 1128 place. 1130 The APKI working group feels that the following 1131 protocols should be standardized at a minimum: 1133 - User Workstation or Smartcard to Certificate 1134 Management component 1135 - Local Registration Authority to CA Agent 1137 A candidate protocol specification including these 1138 protocols as well as a protocol for the Publication 1139 Authority to Public-Key Delivery protocol exists as IETF 1140 draft RFC ietf-pkix-ipki-part3-01.txt 1142 Public-Key Delivery and Verification 1144 Protocols must be defined to transport certificates from 1145 the repositories in which they reside to the requester's 1146 machine. In the diagram, these protocols are represented 1147 by the arrows from the Publication Authority to the 1148 Public-Key Delivery and Verification component. The APKI 1149 working group feels that these protocols should be 1150 standardized. At least LDAP, email, and HTTP versions of 1151 these protocols should be defined. 1153 A candidate protocol specification is in preparation and 1154 will be published as IETF draft RFC ietf-pkix-ipki- 1155 part2-01.txt 1157 3.3.3 Interfaces 1159 Virtual Smartcard Service 1161 Candidate interfaces for this component include: 1163 - PSM (HP Submission to OSF) 1164 - SESAME CSF API 1166 Other interfaces which may support some or all of the 1167 Virtual Smartcard Service functionality include: 1169 - Microsoft Wallet 1171 The APKI working group feels that the Virtual Smartcard 1172 Service interface should be standardized. 1174 Additionally, the APKI working group feels that the 1175 interface through which software communicates with 1176 Hardware Security Tokens should be standardized. A 1177 candidate interface for this functionality is: 1179 - RSA PKCS-11 1181 Public-Key Delivery and Verification 1182 Candidate interfaces for this component include: 1184 - CMS-API (Nortel) 1185 - SESAME PKM-API 1186 - NSA CM-API 1187 - Nortel CMS-API 1189 Other interfaces which may support some or all of the 1190 Public-Key Delivery and Verification function include 1192 - Microsoft CryptoAPI version 2.0 1193 - Intel CDSA 1195 The APKI working group feels that the Public-Key Delivery 1196 and Verification interface should be standardized. 1198 Certificate Management 1200 Candidate interfaces for this component include: 1202 - Nortel CMS-API 1203 - SESAME PKM API 1204 - OSF RFC 80 API 1206 Other interfaces which may support some or all of the 1207 Certificate Management function include 1209 - Microsoft CryptoAPI version 2.0 1210 - Intel CDSA 1212 The APKI working group feels that the following 1213 interfaces should be standardized at a minimum: 1215 - CA Agent 1216 - Local Registration Authority 1218 Specification of the Publication Authority interface 1219 would also be useful to providers of repositories and 1220 communications protocols who wish to make their products 1221 available as certificate and CRL transmission media; a 1222 standard Publication Authority interface would allow 1223 them to provide Publication Authority services without 1224 requiring changes to CA Agent code. 1226 3.3.4 Profiles 1228 It is anticipated that multiple CAs will exist in 1229 typical PKI environments; individual servers may require 1230 the use of certificates with specific properties (signing 1231 CA, supported extensions, name format, etc...) Profiles 1232 for certificate format, contents, extensions, and policy 1233 will be needed for PKI environments of interest, 1234 including the Internet, Financial Industry, Credit Card 1235 Industry (for use with SET), Government, and Healthcare 1236 Industry environments. 1238 A draft profile (for the Internet PKI environment) for 1239 certificate format, contents, and extensions exists as 1240 IETF draft RFC ietf-pkix-ipki-part1-01.txt. A draft 1241 policy profile for the Internet PKI environment is in 1242 preparation and will be published as IETF draft RFC 1243 ietf-pkix-ipki-part4-01.txt. 1245 3.3.5 Negotiation 1247 It is not anticipated that any of the Long-Term Key 1248 Services components will require negotiation protocols. 1249 The Certificate Management interfaces will need to 1250 provide a mechanism through which callers can identify 1251 which CA should issue certificates and CRLs requested 1252 through its interface, in case more than one CA is 1253 available. 1255 The Virtual Smartcard Service interface will need to 1256 support selection of user/principal certificates for 1257 environments in which users have more than one 1258 certificate. 1260 3.4 Protocol Security Services Components 1262 Protocol security services are divided into two 1263 fundamental classes: 1265 - Session-Oriented: security services which require 1266 exploiting entities to maintain security state 1267 information associated with protocol exchanges. 1268 - Store & Forward: security services which encapsulate 1269 all required security state information inside the 1270 protected message tokens they generate; these services 1271 do not require exploiting entities to maintain 1272 security state information. Nonrepudiation services 1273 are necessarily store-and-forward services, because 1274 they must allow for "protection" of the 1275 nonrepudiability of a transaction after it has been 1276 completed and its state information destroyed. 1277 Nonrepudiation services are depicted separately from 1278 other store-and-forward protocol security services 1279 because, unlike store-and-forward data privacy and 1280 integrity services, use of Nonrepudiation services 1281 usually requires explicit user action. 1283 The following figure illustrates the Protocol Security 1284 Services Components. 1286 +--------+ +----------+ +---------------+ 1287 |Session-| | Store & | |Non-Repudiation| 1288 |Oriented| | Forward | |Services | 1289 |Services| | Services | +---------------+ 1290 +--------+ +----------+ 1292 3.4.1 Function 1294 These components provide security services appropriate 1295 for use by designers of protocol stacks. Specifically, 1296 these components: 1298 - Provide security mechanism and quality-of-protection 1299 negotiation protocols for use by communication 1300 partners needing to agree on a common security regime 1301 - Manage security state information (if any) needed by 1302 protocol partners wishing to set up and maintain 1303 secure associations 1304 - Encapsulate data origin authentication, data 1305 protection, and credential and privilege transport 1306 transparently within a single service (Crypto 1307 Services, by contrast, typically provide only data 1308 protection) 1309 - Apply security mechanisms based on administered policy 1310 information 1312 3.4.2 Protocols 1314 Session-Oriented Protocol Security Services 1315 A wide variety of protocol security services can be used 1316 to provide security for session-oriented protocols; 1317 examples which are described in existing or proposed 1318 Internet standards include the SPKM (which is Public-Key 1319 based), Kerberos (which is Secret-Key based), and SESAME 1320 (which has Public-Key, Secret-Key, and hybrid variants). 1321 Some of these services define their own protocols for 1322 run-time access to on-line security servers of a variety 1323 of types. All of them define formats for protected 1324 message tokens to be transported by their callers. 1326 Store & Forward Protocol Security Services 1328 Only a few protocol security services suitable for 1329 protection of store & forward protocol messages have been 1330 defined. The IDUP and SESAME services are proposed for 1331 Internet standardization. Both of these services define 1332 formats for protected message tokens to be transported by 1333 their callers. 1335 Notary and Non-Repudiation Services. 1337 These services must define formats for Non-Repudiation 1338 evidence tokens to be transmitted along with notarized 1339 data, and protocols implementing non-repudiable delivery 1340 and non-repudiable receipt. 1342 The APKI working group feels that multiple protocol 1343 security services will continue to be required to meet 1344 the needs of diverse environments. No single standard 1345 for Session-Oriented, Store-and-Forward, or 1346 Nonrepudiation Protocol Security Services is proposed, 1347 therefore. The Protocol Security Services component 1348 interfaces will need to provide negotiation (for 1349 environments in which more than one service is 1350 available), and Protocol Security Service profiles will 1351 have to be established for PKI environments of interest. 1353 3.4.3 Interfaces 1355 The APKI working group feels that all of the Protocol 1356 Security Services interfaces should be standardized. 1358 The structure of the Protocol Security Services is 1359 illustrated by the following figure. 1361 +----------+ +-----------+ +----------------+ +---------------+ 1362 |Privilege,| |Mechanism | |Session-Oriented| |Store & Forward| 1363 |Delegation| |Negotiation| | Protection | | Protection, | 1364 |Management| | | | | |Non-Repudiation| 1365 +----------+ +-----------+ +----------------+ +---------------+ 1366 | | | | | 1367 | +------------------+ | | 1368 | |Context Management| | | 1369 | +------------------+ | | 1370 | | | 1371 | +--------------------------------+ 1372 | | Token Processing | 1373 | +--------------------------------+ 1374 | | | | | 1375 +----------------------------+ +-----------+ +----------+ | 1376 | PAC Generation, Use, | |Key | |Dialog Key| | 1377 | Protection, Verification, | |Acquisition| |Generation| | 1378 | Delegation | |Negotiation| | | | 1379 +----------------------------+ +-----------+ +----------+ | 1380 | | | 1381 +-------------------------+ 1382 | Mechanism Provider | 1383 | Interface | 1384 +-------------------------+ 1385 | | | 1386 +----+ +----+ +------+ 1387 |Kerb| |SPKM| |Sesame| 1388 +----+ +----+ +------+ 1390 Session-Oriented Protocol Security Services 1392 The preferred interface for these services is GSS-API 1393 (IETF RFC 1508). 1395 Store & Forward Protocol Security Services 1397 The preferred interface for these services is IDUP-GSS- 1398 API (IETF CAT draft ietf-cat-idup-gss-api-04.txt). 1400 Non-Repudiation Services 1402 The preferred interface for these services is IDUP-GSS- 1403 API (IETF CAT draft ietf-cat-idup-gss-api-04.txt). 1405 In addition to these interfaces, the APKI working group 1406 feels that interfaces for Protection Mechanism 1407 Negotiation and Privilege and Delegation Management 1408 should be standardized. The preferred interfaces for 1409 these services are draft-ietf-cat-gss-nego and draft- 1410 ietf-cat-xgss, respectively. 1412 Other interfaces which may support some or all of the 1413 Protocol Security Services functionality include: 1415 - Microsoft SSPI 1416 - OMG CORBA Security 1417 - TIPEM 1418 - SHTTP 1420 3.4.4 Profiles 1422 GSS-API and IDUP-GSS-API are capable of supporting 1423 multiple security mechanisms; each API also allows 1424 selection of a wide range of qualities of data protection 1425 (e.g. strength of supported privacy protection, 1426 delegation mode, etc...) for each supported security 1427 mechanism. 1429 Profiles will have to be developed to describe the set of 1430 preferred mechanisms and data protection quality 1431 parameters for PKI environments of interest. The APKI 1432 working group is not aware of a draft profile in this 1433 area. 1435 3.4.5 Negotiation 1437 Because they will be deployed in environments which 1438 require and provide multiple data protection mechanisms, 1439 the Protocol Security Services interfaces will need to 1440 support negotiation (of both protection mechanisms to be 1441 used and Quality of Protection to be applied). 1443 A negotiation mechanism for GSS-API has been proposed and 1444 is described in IETF draft ietf-cat-gss-nego-02.txt. 1446 3.5 Secure Protocol Components 1448 There are many kinds of secure protocols. Three 1449 important categories of secure protocols are: 1451 - Connection-oriented peer-to-peer: These protocols 1452 allow exactly two partners, each of which must be on- 1453 line, to communicate securely. 1454 - Connectionless peer-to-peer: These protocols allow 1455 exactly two partners, one or both of which may be 1456 off-line for some portion of the time interval during 1457 which messages are transmitted, to communicate 1458 securely. 1459 - Connectionless multicast: These protocols allow one 1460 entity to communicate simultaneously and securely with 1461 several partners. Any or all entities may be off-line 1462 for some portion of the time interval during which 1463 messages are transmitted. 1465 The following figure illustrates the Secure Protocol 1466 Components. 1468 +-------------------+ +-------------------+ +-----------------+ 1469 |Connection-Oriented| | Connectionless | | Multicast | 1470 | Peer-to-Peer | | Peer-to-Peer | | | 1471 +-------------------+ +-------------------+ +-----------------+ 1473 3.5.1 Function 1475 Secure protocols provide protected data transfer between 1476 communicating partners without requiring any calls to 1477 security services. Applications using secure protocols 1478 may have to specify a desired quality of protection 1479 before initiating a secure protocol exchange. 1481 3.5.2 Protocols 1483 Examples of secure protocols include: 1485 - Connection-oriented peer-to-peer: Secure RPC, SSL, 1486 SHTTP, OMG SECIOP 1487 - Connectionless peer-to-peer: IPSec, secure e-mail 1488 - Connectionless multicast: Secure e-mail 1490 3.5.3 Interfaces 1492 Each secure protocol typically has its own interface. 1494 3.5.4 Profiles 1496 It is not yet clear whether profiles will be established 1497 for which Web transaction security protocols (e.g. SHTTP, 1498 HTTP-over-GSSAPI, etc...) should be used in which 1499 contexts. 1501 3.5.5 Negotiation 1503 The APKI working group feels that negotiation of secure 1504 protocols is outside the scope of the Public-Key (or even 1505 Security) Infrastructure effort. 1507 3.6 System Security Enabling Components 1509 The following figure illustrates the System Security 1510 Enabling Components. 1512 +---------+ +--------------+ +------------+ 1513 | | | Credential | | Security | 1514 | Logon | | Acquisition | | Context | 1515 | | | | | Management | 1516 +---------+ +--------------+ +------------+ 1518 3.6.1 Function 1520 System functions (for example, Operating System 1521 functions) are needed to support user logon, user 1522 credential acquisition, and association of security state 1523 information with user processes and threads. For 1524 example, once a user has acquired credentials by 1525 authenticating himself to a smartcard, that user's 1526 processes should be able to use the smartcard interface 1527 to sign data using a private key stored on the smartcard. 1528 This will only be possible (and secure) if the system has 1529 maintained security state information associating the 1530 user's processes with the handle returned when the user 1531 authenticated himself to the smartcard. 1533 It is not anticipated that the Internet Public-Key 1534 infrastructure will define any interfaces, protocols, 1535 profiles, or negotiation mechanisms in the area of System 1536 Security Enabling Services. 1538 3.7 Security Policy Services Components 1540 The following figure illustrates the Security Policy 1541 Service Components. 1543 +----------+ +----------+ 1544 | Privilege| | Access | 1545 |Services &| | Control | 1546 |Delegation| | | 1547 +----------+ +----------+ 1548 |User Info | 1549 |Management| 1550 |(Registry)| 1551 +----------+ 1553 3.7.1 Function 1555 Security Policy Services manage information about users' 1556 (and other principals') privileges and resource access 1557 control policies, and make access control decisions based 1558 on that information. 1560 3.7.2 Protocols 1562 Formats for privilege attribute tokens to be transported 1563 within secure protocols will need to be standardized. 1564 The most prominent existing privilege attribute format 1565 definitions today are those defined by ANSI X9, OSF DCE, 1566 SESAME, and the OMG CORBASEC standard. Privileges could 1567 be carried in X.509v3 certificate extensions, or in 1568 separate privilege attribute tokens. 1570 3.7.3 Interfaces 1572 It is not anticipated that the Internet Public-Key 1573 Infrastructure will define interfaces to privilege 1574 attribute services or access control services. 1576 3.7.4 Profiles 1578 Interoperation of systems in differing security 1579 management domains will require standardization of 1580 privilege attribute types and of the semantics of values 1581 of those types. No proposed standard profile for 1582 privilege attributes exists today. 1584 3.7.5 Negotiation 1586 <> 1588 3.8 Supporting Services Components 1590 The following figure lists the Supporting Services 1591 Components. 1593 +----------+ +---------+ +------------+ 1594 | Security | | Time | | Directory &| 1595 | Auditing | | Service | |Subscription| 1596 | Service | | | | Services | 1597 +----------+ +---------+ +------------+ 1599 3.8.1 Function 1601 These components provide functions required by the 1602 security services or required for secure operation of a 1603 networked system; however they do not enforce security 1604 policies. 1606 3.8.2 Protocols 1608 <> 1610 3.8.3 Interfaces 1612 <> 1614 3.8.4 Profiles 1616 <> 1618 3.8.5 Negotiation 1620 <> 1622 4. Hardware Security Devices in the Architecture 1624 The architecture is intended to support at least two 1625 kinds of hardware security devices: 1627 - Security Tokens 1628 This class of devices includes smartcards, memory 1629 cards, time-synchronized tokens, and challenge- 1630 response tokens. These devices may provide crypto 1631 primitives and services, Virtual Smartcard services, 1632 and authentication functions. 1634 Smartcards are assumed by the architecture to provide 1635 Virtual Smartcard Services. They will also frequently 1636 also provide at least the "Key Activation" and 1637 "Signing" components of Crypto Services; they may also 1638 provide other Crypto Services. 1640 Memory cards provide only storage; Virtual Smartcard 1641 services involving state maintenance (e.g. key 1642 activation) or cryptography will have to be provided 1643 by the memory card's software drivers. The figure 1644 below illustrates how smartcards and memory cards can 1645 be used to support the Virtual Smartcard services: 1647 +------------------------------------+ 1648 | Virtual Smartcard Interface | 1649 +------------------------------------+ 1650 | | | 1651 | +---------------+ +-----------+ 1652 | |Memory Card | | | 1653 | |Personal Crypto| | | 1654 | |Module | | Software | 1655 | +---------------+ | Personal | 1656 | | | | Security | 1657 +-----------------+ | | Module | 1658 | Security Card | | | | 1659 | Access Interface| | | | 1660 +-----------------+ | | | 1661 | | | | | 1662 +-------+ +------+ | | | 1663 | Smart | |Memory| | +-----------+ 1664 | Card | | Card | | | 1665 +- - - -+ +------+ +----------------+ 1666 | Crypto| | Cryptographic | 1667 | Funcs | | Services | 1668 +-------+ +----------------+ 1670 Time-synchronized and challenge-response tokens 1671 provide only authentication functionality, and will 1672 typically be integrated into the architecture through 1673 modifications to the System Security Enabling Services 1674 (particularly the "Logon" and "Obtain Credentials" 1675 components of those services). 1677 - Cryptographic Modules 1679 This class of devices includes chipsets, bus-connected 1680 cryptographic adaptors, and remote cryptographic 1681 servers providing crypto primitives and services, but 1682 not providing user authentication functions. 1684 Cryptographic modules are assumed by the architecture 1685 to provide the full range of Crypto Services (and they 1686 may provide direct access to some Crypto Primitives 1687 for the convenience of designers of new Crypto 1688 Services). 1690 5. Relationship to Other Standards and Architectures 1692 5.1 ISO 7498-2 1694 <> 1696 5.2 IETF IPKI Drafts 1698 This document anticipates adoption (mutatis mutandis) of 1699 the four IPKI drafts as Internet RFCs, and seeks to 1700 define the larger architectural context into which those 1701 drafts fit. 1703 5.3 X/Open XDSF 1705 <> 1707 5.4 ECMA TR-46 1709 <> 1711 5.5 RSA PKCS Standards 1713 This architecture assumes support for the following PCKS 1714 standards: Cryptographic message syntax; signature 1715 formats (PCKS-7) Smartcard function access (PKCS-11) 1717 6. Example Applications of the Architecture 1719 <> 1721 6.1 OSF DCE 1.1 1723 6.2 SESAME 1725 6.3 Nortel Entrust 1727 6.4 OMG CORBA 1729 6.5 Lotus Notes 1731 6.6 Novell Netware 1733 7. Glossary 1734 <> Notes: 1736 1. We use "confidentiality" and "privacy" 1737 interchangeably. 1738 2. "Secret-key cryptography" is used to mean cryptography 1739 using a symmetric-key algorithm; "public-key" 1740 cryptography has the usual meaning; "private key" is 1741 used only to describe the private (secret) half of a 1742 key-pair generated for use with a public-key 1743 cryptographic system. 1745 8. Security Considerations 1747 Security issues are discussed throughout this document. 1749 9. References 1751 [1] draft-ietf-pkix-ipki-part1-00.txt. 1753 This document describes profiles for use of X.509 1754 certificates and certificate revocation lists (CRLs) and 1755 their respective extension fields in the Internet 1756 environment 1758 [2] draft-ietf-pkix-ipki-part3-00.txt. 1760 This document describes protocols for certificate 1761 management in the Internet environment 1763 [3] Internet RFC 1508. 1765 This document describes the GSS-API interface, which 1766 provides integrity and privacy services for session- 1767 oriented messages 1769 [4] draft-ietf-wts-gssapi-00.txt. 1771 This document describes how to use GSS-API to protect Web 1772 transactions (HTTP protocol exchanges, in particular) 1774 [5] draft-ietf-cat-idup-gss-04.txt. 1776 This document describes the IDUP-GSS-API interface, which 1777 provides integrity and privacy services for store-and- 1778 forward messages, and non-repudiation services. 1780 [6] draft-ietf-cat-spkmgss-06.txt. 1782 This document describes how to use the SPKM protocol 1783 under a GSS-API interface 1785 [7] draft-ietf-cat-sesamemech-00.txt. 1787 This document describes the use of the SESAME protocols 1788 under a GSS-API interface. 1790 [8] draft-ietf-cat-snego-01.txt. 1792 This document describes a proposed mechanism negotiation 1793 preamble protocol for use by protocol partners wishing to 1794 use GSS-API to establish a secure association. 1796 [9] X/Open Distributed Security Framework. 1798 [10] ISO 7498-2 "Information processing systems - Open 1799 Systems Interconnection - Basic Reference Model - Part 2: 1800 Security Architecture". 1802 [11] ECMA TR/46 "Security in Open Systems: A Security 1803 Framework". 1805 [12] The SSL Protocol v3. 1807 Describes version 3 of the SSL protocol; available from 1808 Netscape Web site 1810 AUTHOR'S ADDRESS 1811 Bob Blakley 1812 IBM 1813 Mail Stop 9132 1814 11400 Burnet Road 1815 Austin, TX 78758 USA 1817 Phone: +1 512 838 8133 1818 FAX : +1 512 838 0156 1820 email: blakley@vnet.ibm.com