11.0 References and Notes

M. Baum, "Federal Certification Authority Liability and Policy: Law and Policy of Certificate-Based Public Key and Digital Signatures", Published by: U. S. Dept. of Commerce, NIST, June, 1994.

From ftp://ftp.cert.org/pub/cert_faq:

"The CERT Coordination Center is the organization that grew from the computer emergency response team formed by the Defense Advanced Research Projects Agency (DARPA) in November 1988 in response to the needs exhibited during the Internet worm incident. The CERT charter is to work with the Internet community to facilitate its response to computer security events involving Internet hosts, to take proactive steps to raise the community’s awareness of computer security issues, and to conduct research targeted at improving the security of existing systems."

Douglas Comer, Internetworking with TCP/IP, Volumes 1, 2, and 3, Prentice Hall

These books are the "standard" textbooks on TCP/IP. See, for example http://www.prenhall.com/~rich/013/216986/21698-6.html

David Curry, UNIX System Security: A Guide for Users and System Administrators. Reading, MA: Addison-Wesley Publishing Co., Inc., 1992. (ISBN 0-201-56327-4)

Federal Electronic Commerce Acquisition Team, Streamlining Procurement Through Electronic Commerce, available from http://snad.ncsl.nist.gov/dartg/edi/arch.html. October 13, 1994, Federal Electronic Commerce Acquisition Team, Skyline 4, Suite 400 5113 Leesburg Pike Falls Church, Virginia 22041.Tel: (703) 681-0369, FAX: (703) 681-0362.

This report is a good introduction to the use of EDI within a complete electronic commerce architecture. It describes a strategy for converting all government procurement to use EDI.

"The recommended architecture and underlying rationale consists of the following fundamental components:

• A single means of supplier registration to do business electronically with the Federal government including a standardized trading partner agreement embodying the "rules of the road"
• A standard method of implementing the electronic data interchange (EDI) transaction formats used in the United States [currently those approved by the American National Standards Institute (ANSI) Accredited Standards Committee(ASC) X12]
• Existing agency-managed procurement systems modified to generate standard EDI ASC X12 transactions (i.e., agencies would modify their existing systems to feed data in "flat file format" to a commercial off-the-shelf software package called a translator that generates the ASC X12 transaction)
• A "virtual network" connecting agency standardized transactions to facilities where value-added networks (VANs) or other entities can access them
• A standard agreement between the government and the VANs that support the government and its trading partners
• A standards-based system that gives agency procurement staff access to government data bases supporting their operations
• The use of electronic funds transfer (EFT) as the principal method of payment and the development of a supportive EFT architecture."

W. Houser, J. Griffin and C. Hage, "EDI Meets the Internet: Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet." Internet RFC-1865. (Available at ftp://ds.internic.net/rfc/rfc1865.txt)

Electric Power Research Institute, Power Delivery Group, "Real-Time Information Networks (RINs) Implementation Information". A WWW page at A WWW page at http://www.epri.com/org/pdg/ssos/rin/rininfo.html

Electric Power Research Institute, Power Delivery Group, "EPRI RIN Working Group Summary Presentations of ‘How’ Transmission Service Information Networks (TSINs) will Operate". A WWW page at http://www.epri.com/org/pdg/ssos/rin/wrkgrp.html

Warwick Ford, Computer Communications Security: Principles, Standards, Protocols, and Techniques, Prentice Hall, Englewood Cliffs, New Jersey, 07632, 1995. ISBN 0-13-799453-2.

David Robertson, William Johnston, and Wing Nip, "Virtual Frog Dissection: Interactive 3D Graphics Via the WWW," Proceedings, The Second International WWW Conference ‘94: Mosaic and the Web, Chicago, IL (1994). (Available at http://www-itg.lbl.gov/vfrog/WWW.94.paper.html.)

From the paper:

"We have developed a set of techniques for providing interactive 3D graphics via the World Wide Web (WWW) as part of the ‘Whole Frog’ project. We had three goals: (1) to provide K-12 biology students with the ability to explore the anatomy of a frog with a virtual dissection tool; (2) to show the feasibility of interactive visualization over the Web; and (3) to show the possibility for the Web and its associated browsers to be an easily used and powerful front end for high-performance computing resources."

"We have developed techniques to utilize the Common Gateway Interface (CGI) capability of WWW servers to provide an interactive 3D visualization front end through Web clients. These techniques have been used to make a ‘Virtual Frog Dissection Kit’. A student using this kit has the ability to view various parts of a frog from many different angles, and with the different anatomical structures visible or invisible. For example, the student can press ‘form’ buttons that indicate that he or she wants to view the frog from above, with the exterior and skeleton removed. An advantage to this technique, as opposed to dissecting a real frog, is that undissection is as easy as dissection."

"The kit has a forms -based interface. Form submission results in a call to a CGI script, which in turn contacts a continuously running process on a more powerful machine to accomplish the graphics rendering of a large 3D data set representing the frog and its internal organs. The resulting image is converted to Graphics Interchange Format (GIF) encoding. When that process completes generation of the image, it passes the location of the image file and control back to the script which rewrites the image on the client. While this might sound awkward, the overall process is quite similar to how [conventional] rendering systems work, [where] the image [is] being written into a local frame buffer, or sent across the network as an X-window image."

Also see http://george.lbl.gov/frog .

Simson Garfinkel and Gene Spafford, Practical UNIX Security. Sebastopol, CA: O’Reilly & Associates, Inc., 1991. (ISBN 0-937175-72-2)

J. Linn, "Generic Security Service Application Program Interface, Version 2", an Internet Engineering Task Force draft from the Common Authentication Technology Working Group (http://www.ietf.cnri.reston.va.us/html.charters/cat-charter.html). The GSSAPI document is at ftp://ds.internic.net/internet-drafts/draft-ietf-cat-gssv2-03.txt .

From the Abstract:

"The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications:

• documents defining specific parameter bindings for particular language environments
• documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms

This Internet-Draft revises RFC-1508, making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this draft or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track."

Strictly speaking the GSS-API defines a service rather than a protocol. An example of a specific protocol implementing the GSS-API is to be found in "The Kerberos Version 5 GSS-API Mechanism", J. Linn, ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb5gss-02.txt .

Harvard University, "Information Security Handbook", gopher://gopher.harvard.edu:70/00/.vine/providers/oit/Computer_Security_Handbook/Information_Security_Handbook/

From the Background section:

"An Information Security Working Group has been organized to review issues of safekeeping and confidentiality of information resources, identify risks, raise consciousness in the community and, where appropriate, develop policy statements, advisories, and guidelines. The working group has representatives from almost all the schools and major central administration departments. The intention is to build consensus among these groups, promote common definitions, compile good practices and check lists in the form of an Information Security Handbook which will be published and updated as the need arises.

While the effort was initially intended to look at administrative computer systems and the electronic distribution of data to the desktop, it was felt that the security issues of paper files, library, and research data could not be excluded. Many of the security practices recommended in the handbook are already standard practice for paper documents; they need to be extended to electronic forms of information as well. Moreover, the integration of systems across mainframes, minicomputers, microcomputers and networks makes it impossible to separate many of the concerns by application type. Security issues must be considered across many environments and media, including paper, which are increasingly shared among a heterogeneous community of users. Many of the people involved in this working group and in the University at large have cross functional responsibility and must look at security issues across their entire organizations."

Charles L. Hedrick "Introduction to the Internet Protocols" (Available from http://www.aetc.af.mil/tutorials/ipintro.html or ftp://nic.merit.edu/introducing.the.internet/intro.to.ip)

This document is a brief introduction to the Internet networking protocols (TCP/IP). It includes a summary of the facilities available and brief descriptions of the major protocols in the family.

IRC stands for "Internet Relay Chat".

From http://www.main.com/dms/irc.html :

"It was originally written by Jarkko Oikarinen (jto@tolsun.oulu.fi) in 1988. Since starting in Finland, it has been used in over 60 countries around the world. It was designed as a replacement for the "talk" program but has become much more than that. IRC is a multi-user chat system, where people convene on "channels" (a virtual place, usually with a topic of conversation) to talk in groups, or privately. IRC is constantly evolving, so the way things to work one week may not be the way they work the next. Read the MOTD (message of the day) every time you use IRC to keep up on any new happenings or server updates. IRC gained international fame during the 1991 Persian Gulf War, where updates from around the world came across the wire, and most irc users who were on-line at the time gathered on a single channel to hear these reports. IRC had similar uses during the coup against Boris Yeltsin in September 1993, where IRC users from Moscow were giving live reports about the unstable situation there."

"IRC works when the user runs a "client" program (usually called ‘irc’) which connects to the irc network via another program called a "server". Servers exist to pass messages from user to user over the irc network."

"Java: A simple, object-oriented, distributed, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, and dynamic language" that provides for interactive applications in the context of the World Wide Web. http://java.sun.com/1.0alpha3/doc/overview/java/index.html More generally, see: http://java.sun.com/

"Realtime Information Networks for Open Access to Electric Power Transmission Facilities" an informational WWW Page at http://www-itg.lbl.gov/~johnston/EDM/FERC-NOPRA.html

Brendan P. Kehoe "Zen and the Art of the Internet: A Beginner’s Guide to the Internet" Available from gopher://nic.merit.edu:7043/0/introducing.the.internet/zen.txt or http://sundance.cso.uiuc.edu/Publications/Other/Zen/zen-1.0_toc.html .

This is a bit dated (no information on the WWW) but a classic introduction to the Internet.

Steve Kent, "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC-1422, http://ds.internic.net/rfc/rfc1422.txt .

RFC-1422 establishes the conceptual framework for certification authorities. The hierarchical authority chain defined in the RFC will probably be modified in the next version of the document, but most of the concepts are still valid. From the RFC:

"This document defines a supporting key management architecture and infrastructure, based on public-key certificate techniques, to provide keying information to message originators and recipients......

The key management architecture described in this document is compatible with the authentication framework described in CCITT 1988 X.509. This document goes beyond X.509 by establishing procedures and conventions for a key management infrastructure for use with Privacy Enhanced Mail (PEM) and with other protocols, from both the TCP/IP and OSI suites, in the future. There are several motivations for establishing these procedures and conventions (as opposed to relying only on the very general framework outlined in X.509):

• It is important that a certificate management infrastructure for use in the Internet community accommodate a range of clearly-articulated certification policies for both users and organizations in a well-architected fashion. Mechanisms must be provided to enable each user to be aware of the policies governing any certificate which the user may encounter. This requires the introduction and standardization of procedures and conventions that are outside the scope of X.509.
• The procedures for authenticating originators and recipient in the course of message submission and delivery should be simple, automated and uniform despite the existence of differing certificate management policies. For example, users should not have to engage in careful examination of a complex set of certification relationships in order to evaluate the credibility of a claimed identity.
• The authentication framework defined by X.509 is designed to operate in the X.500 directory server environment. However X.500 directory servers are not expected to be ubiquitous in the Internet in the near future, so some conventions are adopted to facilitate operation of the key management infrastructure in the near term.
• Public key cryptosystems are central to the authentication technology of X.509 and those which enjoy the most widespread use are patented in the U.S. Although this certification management scheme is compatible with the use of different digital signature algorithms, it is anticipated that the RSA cryptosystem will be used as the primary signature algorithm in establishing the Internet certification hierarchy. Special license arrangements have been made to facilitate the use of this algorithm in the U.S. portion of Internet environment."

Laura Lemay, "Teach Yourself Web Publishing in a Week," Published by Sams Publishing, 1995. ISBN 0-672-30667-0 (Tel: 1-800-428-5331, http://www.mcp.com/cgi-bin/do-bookstore.cgi)

"This book covers HTML 2.0, images, sound and video, servers, CGI, forms, and imagemaps. In addition, unlike most other books about HTML, this book will teach you about how to create well-designed, easy to navigate and maintainable Web presentations with information about design, organization, and effective linking."

Cricket Liu, Jerry Peek, Russ Jones, Bryan Buus & Adrian Nye, Managing Internet Information Services: World Wide Web, Gopher, FTP, and more, O’Reilly & Associates, 1995. (http://www.ora.com, Tel: 1-800-889-8969), ISBN: 1-56592-062-7.

"This comprehensive guide describes how to set up information services and make them available over the Internet. It discusses why a company would want to offer Internet services, provides complete coverage of all popular services, and tells how to select which ones to provide. Most of the book describes how to set up Gopher, World Wide Web, FTP, and WAIS servers and email services."

Lombard Institutional Brokerage, Inc. "Real-Time Trading and Research Information" http://www.lombard.com/

From the introduction:

"Welcome to the Lombard Institutional Brokerage Real-Time Trading and Research Information Center. Our philosophy is simple: ‘Through the use of cutting edge technology, we are dedicated to providing our customers in the Internet community with a wide variety of investment options, enhanced investment tools and an unparalleled commitment to customer service...’ "

For an example of a trading system interface, specifically see the Lombard demonstration at http://www.lombard.com/Demo/

Michael R. Macedonia and Donald P. Brutzman, Naval Postgraduate School, "MBone Provides Audio and Video Across the Internet," IEEE COMPUTER magazine, pp. 30-36, April 1994.

From ftp://taurus.cs.nps.navy.mil/pub/mbmg/mbone.html:

"Short for Multicast Backbone, MBone is a virtual network that has been in existence since early 1992. It was named by Steve Casner of the University of Southern California, Information Sciences Institute and originated from an effort to multicast audio and video from meetings of the Internet Engineering Task Force. Today, hundreds of researchers use MBone to develop protocols and applications for group communication. Multicast provides one-to-many and many-to-many network delivery services for applications such as video conferencing and audio where several hosts need to communicate simultaneously. The magic of MBone is that teleconferencing can be done in the hostile world of the Internet where variable packet delivery delays and limited bandwidth play havoc with applications that require some real-time guarantees. Limited experiments demonstrated the feasibility of audio over the ARPAnet as early as 1973. However, only a few years ago, transmitting video across the Internet was considered impossible. Development of effective multicast protocols disproved that widespread opinion. In this respect, MBone is like the proverbial talking dog: It’s not so much what the dog has to say that is amazing, it’s more that the dog can talk at all!"

"The key network concepts that make MBone possible are IP multicast and real-time stream delivery via adaptive receivers. For example, in addition to the multicast protocols, many MBone applications are using the draft Real-Time Protocol on top of the User Datagram Protocol and Internet Protocol. RTP, being developed by the Audio-Video Transport Working Group of the Internet Engineering Task Force, provides timing and sequencing services, permitting the application to adapt and smooth out network-induced latencies and errors."

Also see the "Mbone Homepage" http://www.best.com/~prince/techinfo/mbone.html and http://www.rpi.edu/Internet/Guides/decemj/itools/cmc-mass-mbone.html

S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security Services." Internet RFC-1848. (Available at ftp://ds.internic.net/rfc/rfc1848.txt)

"This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework to apply digital signature and encryption services to MIME objects. The services are offered through the use of end-to-end cryptography between an originator and a recipient at the application layer. Asymmetric (public key) cryptography is used in support of the digital signature service and encryption key management. Symmetric (secret key) cryptography is used in support of the encryption service. The procedures are intended to be compatible with a wide range of public key management approaches, including both ad hoc and certificate-based schemes. Mechanisms are provided to support many public key management approaches."

J. Markoff, "Security Flaw is Discovered in Software Used in Shopping", the New York Times Front Page, Sept. 19, 1995

L. Zuckerman, "AT&T Starts On-Line Service Aimed as Small Business", the New York Times Business Section, Sept. 20, 1995

"Site Security Handbook" (available from ftp://nis.nsf.net/internet/documents/rfc/rfc1244.txt or ftp://ds.internic.net/rfc/rfc1244.txt)

"This handbook is the product of the Site Security Policy Handbook Working Group (SSPHWG), a combined effort of the Security Area and User Services Area of the Internet Engineering Task Force (IETF)."

"This handbook is a guide to setting computer security policies and procedures for sites that have systems on the Internet. This guide lists issues and factors that a site must consider when setting their own policies. It makes some recommendations and gives discussions of relevant areas."

RFC-1244 is updated by [SSH].

http://www.rsa.com/rsalabs/faq/faq_home.html

From the introduction to the FAQ:

"This is an introduction to modern cryptography, including answers to commonly asked questions about public key algorithms such as RSA, ElGamal and Diffie-Hellman; secret key techniques such as DES, RC2 and RC4; and hash functions such as MD, MD2, MD5 and SHA. Certificates, key management, patents, Kerberos, discrete log, factoring, domestic and international standards are also among the topics discussed."

"New in this edition is expanded treatment of recent government involvement in encryption policy and standards, including discussions on the controversial Capstone, Clipper and DSS proposals, export controls, NIST, NSA, privacy and intellectual property concerns."

E. Rescorla, A. Schiffman, "The Secure HyperText Transfer Protocol" (available from ftp://ds.internic.net/internet-drafts/draft-ietf-wts-shttp-00.txt)

"This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. Secure HTTP (S-HTTP) is an extension of HTTP, providing independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin."

"COAST/Spaf’s Hotlist: Computer Security, Law & Privacy" http://www.cs.purdue.edu/homes/spaf/hotlists/csec.html

This is a WWW site with many pointers to security related information:

• Organizations & Agencies
  • FIRST Teams (Forum of Incident Response and Security Teams)
  • Professional Organizations
  • U.S. Government
  • Others
• Education in Computer Security
• Publications
  • Newsletters and Mailing Lists
  • FAQs and Glossaries
  • Books & Book Info
  • Other Publications
• Security Archives, Servers & Indices
  • Comprehensive Sites
  • Tools
  • "Underground" Sites
• Cryptography
  • PGP-related
  • Export Control & Politics
  • Other cryptography
• Computer Viruses
• Privacy Issues
• Computing Ethics
• Security in WWW
• Commercial Sites
  • Computer Vendors
  • Primarily Firewalls
  • Others
• Law
• Miscellaneous

B. Fraser, et al, "Site Security Handbook", an Internet-Draft (such drafts are replaced by RFCs or new drafts after about 6 months.) This draft is available from ftp://ds.internic.net/internet-drafts/draft-ietf-ssh-handbook-00.txt

From the IETF SSH home page (http://www.cert.dfn.de/eng/resource/ietf/ssh/):

"The Site Security Handbook Working Group is chartered to create two documents: (1) a revised handbook that will help system and network administrators develop their own site-specific policies and procedures to deal with computer security problems and their prevention and (2) a new handbook for users. The text of these documents will be developed from the existing RFC 1244, plus needed revisions and additions. "

Netscape Communications Corporation, "Netscape SSLRef" (http://home.netscape.com/info/sslref.html):

"SSL is Secure Sockets Layer, an open, publicly available and license-free security protocol specification suitable for use on the Internet and other TCP/IP networks in a broad range of contexts. It can be used with application-level protocols such as HTTP, FTP, Gopher, Telnet, NNTP, rdist, and many others (including protocols yet to be invented).

The SSL protocol enables advanced security in an application using a variety of mechanisms which include authentication, confidentiality and integrity.

The full protocol specification has been available to software developers and the Internet community since last October.

Netscape Communications Corporation, "Industry Leaders Support Secure Sockets Layer for Internet Security" (A "news release". (http://home.netscape.com/info/newsrelease17.html):

"MOUNTAIN VIEW, Calif. (March 20, 1995) -- Netscape Communications Corporation today announced that a number of industry-leading companies and organizations are supporting the Secure Sockets Layer (SSL) protocol for Internet security. Apple Computer, Inc., Bank of America, ConnectSoft, Delphi Internet Services Corporation, Digital Equipment Corporation, First Data Corporation, IBM, MarketNet, MasterCard International Inc., MCI Communications Corp., Microsoft Corporation, Novell, Inc., Open Market, Prodigy, Silicon Graphics, Inc., StarNine, Sun Microsystems, Inc., Visa International, and Wells Fargo are among companies backing SSL.

SSL is an open protocol for securing data communications across computer networks. The broad support for this protocol will promote interoperability between products from many organizations and will speed the growth of electronic commerce on the Internet and private TCP/IP networks. Today, more than 3 million people are already using SSL-enabled products, which have been available since December 1994. In October 1994, Netscape published the specification for SSL on the Internet. Recently, the company also published the source code to the reference implementation, called SSLRef, on the net. SSLRef is free for non-commercial use and is available for flat-fee licensing by companies who want to use it in commercial products."

Netscape Communications Corporation, "The SSL Protocol", http://home.netscape.com/info/SSL.html

William Stallings, Network and Internetwork Security, Prentice Hall, Englewood Cliffs, New Jersey, 1995. (ISBN: 07803-1107-8)

William Stallings, Protect Your Privacy - A Guide for PGP Users, Prentice Hall, Englewood Cliffs, New Jersey, 1995. (ISBN: 0-13-185596-4)

This book is Stallings’ description of Phil Zimmerman’s PGP system.

Informal discussions with the Electronic Commerce Services group of the U. S. Postal Service about their electronic commerce services plans, especially for certificates, indicates the following.

USPS is organizing their certificate services around a Certification Authority (CA) that they will run without reference to a higher authority (e.g. the IRPA). Like many others who are running CAs, USPS intends to set its policy in accordance with what they think that their commercial customer base will find most useful. USPS expects to see a number of "high level" CAs (like USPS) cooperate by signing each other’s certificates in order to allow for inter-operation. (Steven Kent, IETF PEM Working Group Chair. recently indicated that the IETF would soon set up a working group to review and revise the RFC-1422 CA model.)

USPS will issue two classes, and several subclasses of certificates:

• organizational or corporate certificates would essentially let organizations operate their own CA, referenced to USPS CA policy
• personal - five levels of certification:
  • biometric (encodes a body measurement in a certificate and on a "smart token"-like card)
  • certified (in-person presentation of "official", picture id)
  • basic (written or digital signature, mailed in)
  • proxy (power-of-attorney - based on signed documents of someone else)
  • generic (anonymous)

The certificates are X.509v3 and will (in the future) be able to reference attribute certificates (this provides a way of certifying information not defined in X.509 format).

Certificate access will initially be via X.400 and SMTP e-mail, with WWW access coming soon. USPS does not plan to allow unrestricted public access to the certificate database. In USPS operated X.500 servers the certificates would be in a private directory. Their model is that they will have "listed" and "unlisted" certificates. Listed certificates may be obtained by anyone, but only when requested by name (i.e. you have to know the distinguished name, you cannot "browse" the certificate database). Unlisted certificates can only be obtained from the certified entity (i.e. only the "owner" will distribute unlisted certificates, but they will be signed by the CA).

Certificates will be RSA Public Key based and/or DSS based.

Revocation lists will be available (initially) only by e-mail request.

USPS also anticipates a couple of related services in the near future:

• digital postmark (you send in a crypto hash of the document that you wish postmarked and they timestamp against WWV-GMT, sign with their private key, and return)
• archiving (they will postmark your document, and then archive it for a period of time specified by the customer - this is just a concept, they do not have a concrete tertiary storage plan yet).

The USPS approach would allow those organizations that want to establish a CA a convenient way (and more neutral than the IPRA) of cross-CA operation.

For more information contact Paul Raines (praines@email.usps.gov), Program Manager, Electronic Commerce Services, USPS.

[Go To Next Section]

[Go To Last Section]

[Go To First Page]