THE SSL PROTOCOL

　　RC2, RC4

　　Proprietary bulk ciphers invented by RSA (There is no good reference to these as they are unpublished works; however, see [9]). RC2 is block cipher and RC4 is a stream cipher.

　　Server

　　The server is the application entity that responds to requests for connections from clients. The server is passive, waiting for requests from clients.

　　Session cipher

　　A session cipher is a "bulk" cipher that is capable of encrypting or decrypting arbitrarily large amounts of data. Session ciphers are used primarily for performance reasons. The session ciphers used by this protocol are symmetric. Symmetric ciphers have the property of using a single key for encryption and decryption.

　　Session identifier

　　A session identifier is a random value generated by a client that identifies itself to a particular server. The session identifier can be thought of as a handle that both parties use to access a recorded secret key (in our case a session key). If both parties remember the session identifier then the implication is that the secret key is already known and need not be negotiated.

　　Session key

　　The key to the session cipher. In SSL there are four keys that are called session keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY, and SERVER-WRITE-KEY.

　　SERVER-READ-KEY

　　The session key that the server uses to initialize the server read cipher. This key has the same value as the CLIENT-WRITE-KEY.

　　SERVER-WRITE-KEY

　　The session key that the server uses to initialize the server write cipher. This key has the same value as the CLIENT-READ-KEY.

　　Symmetric Cipher

　　A symmetric cipher has the property that the same key can be used for decryption and encryption. An asymmetric cipher does not have this behavior. Some examples of symmetric ciphers: IDEA, RC2, RC4.

References

[1] CCITT. Recommendation X.208: "Specification of Abstract Syntax Notation One (ASN.1). 1988.
[2] CCITT. Recommendation X.209: "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.

[3] CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988.

[4] CCITT. Recommendation X.520: "The Directory - Selected Attribute Types". 1988.

[5] RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5, November 1993.

[6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5, November 1993.

[7] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 1992.

[8] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 1992.

[9] B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C, Published by John Wiley & Sons, Inc. 1994.

[10] M. Abadi and R. Needham. Prudent engineering practice for cryptographic protocols. 1994.

Patent Statement

　　This version of the SSL protocol relies on the use of patented public key encryption technology for authentication and encryption. The Internet Standards Process as defined in RFC 1310 requires a written statement from the Patent holder that a license will be made available to applicants under reasonable terms and conditions prior to approving a specification as a Proposed, Draft or Internet Standard.
The Massachusetts Institute of Technology and the Board of Trustees of the Leland Stanford Junior University have granted Public Key Partners (PKP) exclusive sub-licensing rights to the following patents issued in the United States, and all of their corresponding foreign patents:

Cryptographic Apparatus and Method
("Diffie-Hellman")............................... No. 4,200,770

Public Key Cryptographic Apparatus
and Method ("Hellman-Merkle").................... No. 4,218,582

Cryptographic Communications System and
Method ("RSA")................................... No. 4,405,829

Exponential Cryptographic Apparatus
and Method ("Hellman-Pohlig").................... No. 4,424,414

　　These patents are stated by PKP to cover all known methods of practicing the art of Public Key encryption, including the variations collectively known as El Gamal.
Public Key Partners has provided written assurance to the Internet Society that parties will be able to obtain, under reasonable, nondiscriminatory terms, the right to use the technology covered by these patents. This assurance is documented in RFC 1170 titled "Public Key Standards and Licenses". A copy of the written assurance dated April 20, 1990, may be obtained from the Internet Assigned Number Authority (IANA).

　　The Internet Society, Internet Architecture Board, Internet Engineering Steering Group and the Corporation for National Research Initiatives take no position on the validity or scope of the patents and patent applications, nor on the appropriateness of the terms of the assurance. The Internet Society and other groups mentioned above have not made any determination as to any other intellectual property rights which may apply to the practice of this standard. Any further consideration of these matters is the user's own responsibility.

　　Security Considerations
　　This entire document is about security.

Author's Address
Kipp E.B. Hickman
Netscape Communications Corp.
501 East Middlefield Rd.
Mountain View, CA 94043
kipp@netscape.com