< draft-ietf-tls-https-00.txt		draft-ietf-tls-https-01.txt >
	E. Rescorla		E. Rescorla
	INTERNET-DRAFT Terisa Systems, Inc.		INTERNET-DRAFT Terisa Systems, Inc.
	<draft-ietf-tls-https-00.txt> January 1998 (Expires July-98)		<draft-ietf-tls-https-01.txt> March 1998 (Expires September-98)
	HTTP Over TLS		HTTP Over TLS
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	skipping to change at line 30 ¶		skipping to change at line 30 ¶
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, please check the
	``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow		``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
	Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),		Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
	munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or		munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
	ftp.isi.edu (US West Coast).		ftp.isi.edu (US West Coast).
	Abstract		Abstract
	This memo describes how to use TLS to secure HTTP connections over		This memo describes how to use TLS to secure HTTP connections over
	the Internet. Current practice is to layer HTTP over SSL (the prede-		the Internet. Current practice is to layer HTTP over SSL (the prede-
	cessor to TLS), distinguishing secured traffic from insecure traffic		cessor to TLS), distinguishing secured traffic from insecure traffic
	by the use of a different server port. This document standardizes		by the use of a different server port. This document documents that
	that practice using TLS. A companion document describes a method for		practice using TLS. A companion document describes a method for using
	using HTTP/TLS over the same port as normal HTTP.		HTTP/TLS over the same port as normal HTTP.
	1. Introduction		1. Introduction
	HTTP [RFC2068] was originally used in the clear on the Internet.		HTTP [RFC2068] was originally used in the clear on the Internet.
	However, increased use of HTTP for sensitive applications has		However, increased use of HTTP for sensitive applications has
	required security measures. SSL, and its successor TLS [TLS] were		required security measures. SSL, and its successor TLS [TLS] were
	designed to provide channel-oriented security. This document		designed to provide channel-oriented security. This document
	describes how to use HTTP over TLS.		describes how to use HTTP over TLS.
	1.1. Discussion of this Draft		1.1. Discussion of this Draft
	skipping to change at line 179 ¶		skipping to change at line 179 ¶
	3. Endpoint Identification		3. Endpoint Identification
	3.1. Server Identity		3.1. Server Identity
	In general, HTTP/TLS requests are generated by dereferencing a URI.		In general, HTTP/TLS requests are generated by dereferencing a URI.
	As a consequence, the hostname for the server is known to the client.		As a consequence, the hostname for the server is known to the client.
	If the hostname is available, the client MUST check it against the		If the hostname is available, the client MUST check it against the
	server's identity as presented in the server's Certificate message,		server's identity as presented in the server's Certificate message,
	in order to prevent man-in-the-middle attacks.		in order to prevent man-in-the-middle attacks.
			If the client has external information as to the expected identity of
			the server, the hostname check MAY be omitted. (For instance, a
			client may be connecting to a machine whose address and hostname are
			dynamic but the client knows the certificate that the server will
			present.) In such cases, it is important to narrow the scope of
			acceptable certificates as much as possible in order to prevent man
			in the middle attacks.
	If a subjectAltName extension of type dNSName is present, that MUST		If a subjectAltName extension of type dNSName is present, that MUST
	be used as the identity. Otherwise, the (most specific) Common Name		be used as the identity. Otherwise, the (most specific) Common Name
	field in the Subject field of the certificate MUST be used. Although		field in the Subject field of the certificate MUST be used. Although
	the use of the Common Name is existing practice, it is deprecated and		the use of the Common Name is existing practice, it is deprecated and
	Certification Authorities are encouraged to use the dNSName instead.		Certification Authorities are encouraged to use the dNSName instead.
	Matching is performed using the matching rules specified by [PKIX],		Matching is performed using the matching rules specified by [PKIX],
	including wildcard matches. E.g. *.bar.com would match a.bar.com,		including wildcard matches. E.g. *.bar.com would match a.bar.com,
	b.bar.com, etc. but not bar.com. If more than one identity of a given		b.bar.com, etc. but not bar.com. If more than one identity of a given
	type is present in the certificate (e.g. more than one dNSName name,		type is present in the certificate (e.g. more than one dNSName name,
End of changes. 3 change blocks.
	4 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/