付録 1. 今後の動向の調査方法 (英文) Appendix A. How to judge the future trend of API This material is based on a method that I have been using to organize different topics for the I-4 (International Information Integrity institute). I have modified the criteria used to judge the maturity level so that they are more specific to the APIS this report is studying. This organization is based on the idea that technology and ideas progress through several different stages. I have narrowed it to the following five stages: Stage Definitions Idea Future or new concept with no physical representation or practical implementation Interest comes from potential relevance Proof of Concept Small-scale implementation or laboratory experiment whose results show potential for viable applications Interest based on early positive results Growth Period of rapid marketplace acceptance Interest based on inevitability, and need to manage growth Maturity Ubiquitous acceptance and usage Interest comes from management and maintenance Decline Topic area and usage decline in importance toward obsolescence Interest in decommission or migration to replacement These can be shown on a graph as below: 196 Most ideas start with an initial acceptance, then some skepticism that is followed by a lot of marketing and selling. After that there is a decrease in importance as a process of working out the bugs takes place. Then, for things that will really get accepted there is a slow increase during the proof of concept and growth stage. After that importance levels off and then begins to decline. For I-4 we treat subjects differently, depending on their stage. For example we might to an exploratory paper for something early in the life cycle; but look at replacement strategies for a technology in the maintenance phase. Below are the criteria that I mentioned that we use to judge the phase. 197 付録 2. セキュリティ関連 API の標準化動向 (英文) Appendix B. Standardization Trends This section discusses the standardization process of the different APIs studied. Fro each API there will be a description of where it originated and its progress towards becoming a standard. These APIs are in various stages with some not yet completed standards while others have been standards for quite a while and are undergoing revisions. A2.1 APKI – (Architecture for a Public Key Infrastructure) The APKI standard was created by the members of the Open Group. The APKI (Architecture for a Public Key Infrastructure) is a high level architecture that specifies both APIs and protocols. Although not an API itself, it organizes these APIs and protocols into logical layers. The goal of the APKI was to bring order into the PKI world in the early days of PKI. Each layer in the APKI describes specific services. Where appropriate standards existed they were adopted into the APKI. The missing protocols or APIs in the structure were filled by creating new APIs or protocols. The standardization process consisted of coming to agreement on what should be in each layer and what standards should be referenced or created to occupy the layers. Where standards did not specify enough information to guarantee interoperability, the APKI included profiles or specific subsets of the standards. The APKI APIs and protocols were required to support the establishment of domains of trust and governance, confidentiality, integrity, authentication and non-repudiation. Monitoring and auditing of PKI services would need to be supported. The APKI layers are shown below: Applications System Security Secure Protocols Security Policy Enabling Services Services (authorization) Protocol Security Services (Identification, authentication) Supporting Services Long Term Key Services (audit, directory, time) Cryptographic Services Cryptographic Primitives 198 Work began on the APKI in 1994. Many of the necessary APIs and protocols were either in draft or missing. The APKI was finished and released in March of 1999. Its Open Group document number is G801 and its ISBN is 1-85912-221-3. An HTML version is available at: http://www.opengroup.org/pubs/catalog/g801.htm . The released standard fills in the APKI layers as shown below: Applications System Secure Protocols SecuritSecurityy PolicPolicyy Security IETF IPSec, IKE Services Enabling Interfaces: Each secure protocol typically has its ((authorizationauthorizationauthorization)) Services own interface Protocols: Defines in (identity, privilege attribute Protocol Security Services authen.) standards by ANSI Protocols: Multiple protocols will continue to be X9, OSF DCE, needed SESAME and OMG APIs: Session oriented – IETF GSS-API, Store CORBASEC and forward and Non-Repudiation– IETF IDUP-GSS-API Profiles: Need to be developed Supporting ServServicesices Negotiation: IETF GSS-API described in RFC Protocols 2478 IETF SNTP (time) Long Term Key Services APIs: Open Group Protocols: IETF PKIX family XDAS (distributed APIs: CSSM/CDSA Audit) Profiles: IETF PKIX (RFC 2459, 2527) LDAP API (directory) Profiles: Open Group Cryptographic Services and IETF LDAP APIs: CDSA/CSSM APIs profiles Profiles: Need to be developed for specific PKI environments (CORBA, DCE, Financial, etc.) Cryptographic Primitives APIs: CSSM and other crypto algorithms (RSA, DH, DES, AES, etc.) Profiles: Still Needed Not all of the desired functionality has been implemented. In particular the System Security Enabling Services section is empty. This is partly because there are so many different methods of doing this that there is no clear choice for a standard. These services are usually embedded in the operating system or sometimes in applications. Current standards work on the APKI has stopped with the formal publication of the standard in March of 1999. The Open Group has no immediate plans to create a revision to the APKI, although some individual members of the Open Group have enlarged it for their own purposes. An outgrowth of the APKI led to the current Open Group work on security patterns. 199 Title Architecture for Public-Key Infrastructure Publication ISBN 1-85912-221-3, Open Group Document G801 Information Date Published March 1999 Revision History No Revisions Controlling The Open Group, www.opengroup.org Organization Authors Anne Anderson, Hewlett-Packard Company Charles Blauner, JP Morgan & Co. Inc. Belinda Fairthorne, Fujitsu-ICL Warwick Ford Robert Jueneman, Novell, Inc. Ellen McDermott, Open Market Howard Melman, formerly OSF Denis Pinkas, Groupe Bull Walt Tuvell, formerly OSF John Wray, Compaq Computer Corporation Ordering http://www.opengroup.org/pubs/catalog/g801.htm Information A2.2 PKCS#11 (Public-Key Cryptography Standard) PKCS#11 is one of a sequence of standards created and controlled by RSA Security. Although not a standards body, RSA Security has invited participation from outside in the creation and modification of their family of PKCS (Public-Key Cryptography Standards) standards. PKCS#11, also called Cryptoki (short for Cryptographic Token Interface), defines an architecture and specifies the interfaces used for storing cryptographic keys or certificates in hardware devices or tokens such as smart cards. In addition to smart cards, PKCS#11 was designed to work with other types of hardware such as disks and PCMCIA cards. PKCS#11 was designed to be both application and operating system independent. It provides a low level programming interface that hides these hardware differences from the application developer. Applications that use this API do not need to know what kind of hardware device they are talking to. PKCS#11 was announced by RSA Security on 12 Jan 1994 in conjunction with an announcement by National Semiconductor about their iPower series of smart cards. Version 1.0 of the completed standard was released a little over a year later on the 28th of April, 1995. It and all subsequent versions are available on RSA Security’s web site at: http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html . Version 1 of PKCS#11 was quite successful and was the first standard of its type. Its usage showed where improvements were needed. These improvements led to a major revision about two years later. Whereas version 1 was 132 pages, version 2 was over twice as long. Two drafts of version 2 were released in 1997, version 2 draft 1 on 15 April 1997 and draft 2 on 1 July 1997. Neither of these drafts 200 was released as a finished standard and they are not officially supported. Finally, a finished PKCS#11 version 2.01 was released on 22 December 1997. Version 2.01 added additional functionality, support for the C++ programming language and support for many algorithms that were new or not included in version 1. Version 2.10 was released in December of 1999. The current version of PKCS#11 is 2.11 that were completed in late 2001. Version 2.11 supports additional algorithms. The table below shows a comparison of the algorithms and functions supported in versions 1, 2.01 and 2.11. PKCS #11v1 PKCS #11v2.01 PKCS #11v2.11 Public/Private RSA, DSA, DH RSA, DSA, ECDSA, RSA, DSA, ECDSA, Key Algorithms DH, KEA DH, X9.42, KEA Secret Key RC2, RC4, DES, RC2, RC4, RC5, DES, RC2, RC4, RC5, AES, Algorithms DES2, DES3 DES2, DES3, CAST, DES, DES2, DES3, CAST3, CAST128, CAST, CAST3, IDEA, CDMF, CAST128, IDEA, SKIPJACK, BATON, CDMF, SKIPJACK, JUNIPER BATON, JUNIPER Hash Functions MD2, MD5, SHA-1 MD2, MD5, SHA-1, MD2, MD5, SHA-1, FASTHASH FASTHASH Note the addition in version 2.01 of KEA and SKIPJACK that were part of the U.S. government’s collection of key escrow algorithms. Important additions in version 2.11 are support for ANSI X9.42 and the AES or Advanced Encryption Standard. Version 2.11 is now 373 pages and includes additional functionality as well as support for a larger number of standard algorithms. In August of 2001 the first amendment to version 2.11 was proposed. This amendment proposes support for additional devices called Personal Trust Devices (PTD). It defines a PTD as a device that is carried, controlled and used by a single user most of the time and is capable of advanced security.