< draft-ramsdell-enc-smime-gateway-00.txt		draft-ramsdell-enc-smime-gateway-01.txt >
	Internet Draft Authors: Blake Ramsdell,		Internet Draft Authors: Blake Ramsdell,
	draft-ramsdell-enc-smime-gateway-00.txt Tumbleweed Communications		draft-ramsdell-enc-smime-gateway-01.txt Brute Squad Labs
	July 12, 2001 Ben Littauer, Consultant		June 30, 2002 Ben Littauer, Consultant
	Expires January 12, 2002 Massachusetts Health Data		Expires December 30, 2002 Massachusetts Health Data
	Consortium		Consortium
	S/MIME Gateway Protocol		S/MIME Gateway Protocol
	Status of this memo		Status of this memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026.		provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other		Force (IETF), its areas, and its working groups. Note that other
	skipping to change at line 34 ¶		skipping to change at line 34 ¶
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	1. Overview		1. Overview
	In addition to desktop-to-desktop security, S/MIME can be used for		In addition to desktop-to-desktop security, S/MIME can be used for
	server-to-server encryption between cooperating domains. This document		server-to-server encryption between cooperating domains. This document
	will describe a method for implementing server-to-server (gateway)		will describe a method for implementing server-to-server (gateway)
	encryption with S/MIME.		encryption with S/MIME as a profile of [DOMSEC].
	1.1 Terminology		1.1 Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [MUSTSHOULD].		document are to be interpreted as described in [MUSTSHOULD].
	1.2 Discussion of This Draft		1.2 Discussion of This Draft
	<TBD>		This draft is being discussed on the "ietf-smime" mailing list.
			To subscribe, send a message to:
			ietf-smime-request@imc.org
			with the single word
			subscribe
			in the body of the message. There is a Web site for the mailing list
			at <http://www.imc.org/ietf-smime/>.
	2. Problem Overview		2. Problem Overview
	In order to prevent exposure of confidential content in e-mail		In order to prevent exposure of confidential content in e-mail
	messages traversing the Internet, it is desirable to encrypt such		messages traversing the Internet, it is desirable to encrypt such
	traffic between cooperating domains. S/MIME provides the protocol and		traffic between cooperating domains. S/MIME provides the protocol and
	message format for such encryption, but conventions must be		message format for such encryption, but conventions must be
	established for domain-level certificates to enable an encrypting		established for domain-level certificates to enable an encrypting
	gateway to recognize when a message is going to a foreign domain that		gateway to recognize when a message is going to a foreign domain that
	requires encryption.		requires encryption.
	Note that an encryption gateway is not a signing entity for purposes		Note that an encryption gateway is not a signing entity for purposes
	of this protocol. Signing at the domain level is an important		of this protocol. Signing at the domain level is an important
	function, but it is beyond the scope of this memo, and is being		function, but it is beyond the scope of this memo, and is being
	addressed by the Domain Security effort as published in [DOMSEC].		addressed by the Domain Security effort as published in [DOMSEC]. This
			document is meant to be an encrypting only profile of [DOMSEC].
	3. Message Structure Overview		3. Message Structure Overview
	An encrypted message as described in [SMIMEV3MSG] or [SMIMEv2MSG] is		An encrypted message as described in [SMIMEV3MSG] or [SMIMEv2MSG] is
	used in an S/MIME gateway context. A gateway-encrypted message will		used in an S/MIME gateway context. A gateway-encrypted message will
	simply encapsulate an existing MIME or S/MIME message in an encryption		simply encapsulate an existing MIME or S/MIME message in an encryption
	"wrapper".		"wrapper".
	4. Domain Certificates		4. Domain Certificates
	A gateway is associated with one or more domains or sub-domains.		A gateway is associated with one or more domains or sub-domains.
	Messages between gateways are handled based on their domains, not on		Messages between gateways are handled based on their domains, not on
	the basis of individual addressees. Gateway certificates are called		the basis of individual addressees. Gateway certificates are called
	"Domain Certificates", and have the same format as S/MIME Version 3		"Domain Certificates", and have the same format as S/MIME Version 3
	certificates [SMIMEV3CERT] with the exception that the subject DN or a		certificates [SMIMEV3CERT] as further specified by section 4.1 of
	subjectAltName extension MUST list at least one Internet mail domain		[DOMSEC]. [DOMSEC] specifies certain naming restrictions MUST be used
	of the form "smg_encryptor@domain". Multiple domains that are handled		and that are specifically inherited by this profile. A summary of the
	by a gateway MAY be listed in a single certificate, or multiple		certificate naming considerations is as follows:
	certificates MAY be used.
			1. Inclusion of a CN attribute in the subject of the certificate
			containing the value "domain-confidentiality-authority".
			2. The subject DN or a subjectAltName extension MUST list at least one
			Internet mail domain of the form
			"domain-confidentiality-authority@domain". This differs slightly
			from [DOMSEC] in that this profile requires the inclusion of an
			email address in order to determine certificate suitability for a
			particular domain.
			Multiple domains that are handled by a gateway MAY be listed in a
			single certificate, or multiple certificates MAY be used.
	Note that the naming convention in use here uses the same notion of		Note that the naming convention in use here uses the same notion of
	domain "membership" as that used in [DOMSEC] section 3.1.1. Loosely,		domain "membership" as that used in [DOMSEC] section 3.1.1. Loosely,
	an entity is a member of a domain if its RFC-822 address has the		an entity is a member of a domain if its RFC-822 address has the
	domain as its rightmost component. Note further that the gateway must		domain as its rightmost component. Note further that the gateway must
	process ô@domainö components in order from most specific to least		process "@domain" components in order from most specific to least
	specific, i.e. if it holds domain certificates for both <sub.domain>		specific, i.e. if it holds domain certificates for both <sub.domain>
	and domain, it MUST use the certificate for <sub.domain> when sending		and domain, it MUST use the certificate for <sub.domain> when sending
	to a recipient in <sub.domain>, even though the recipient is also a		to a recipient in <sub.domain>, even though the recipient is also a
	member of <domain>.		member of <domain>.
	5. Message Processing		5. Message Processing
	An S/MIME Gateway must be associated with one or more domains. A		An S/MIME Gateway must be associated with one or more domains. A
	message received for processing by the gateway is defined to be		message received for processing by the gateway is defined to be
	"outbound" if the originator of the message is a member of one of the		"outbound" if the originator of the message is a member of one of the
	skipping to change at line 112 ¶		skipping to change at line 135 ¶
	When a message is received with a destination within a domain for		When a message is received with a destination within a domain for
	which the gateway has a domain certificate, the gateway MUST perform		which the gateway has a domain certificate, the gateway MUST perform
	S/MIME encryption with the domain certificate for that destination.		S/MIME encryption with the domain certificate for that destination.
	Mechanisms for the lookup and validity checking of destination mail		Mechanisms for the lookup and validity checking of destination mail
	gateway certificates are beyond the scope of this document.		gateway certificates are beyond the scope of this document.
	5.2 Inbound Message Processing		5.2 Inbound Message Processing
	S/MIME gateway inbound processing is as follows, if a message is		S/MIME gateway inbound processing is as follows, if a message is
	received encrypted using the public key contained in the gatewayÆs		received encrypted using the public key contained in the gateway's
	domain certificate:		domain certificate:
	1. The gateway MUST perform S/MIME decryption of the message.		1. The gateway MUST perform S/MIME decryption of the message.
	2. If the decryption is unsuccessful, the gateway will process the
	failure according to local convention (log an event, etc.) The gateway		2. If the decryption is unsuccessful, the gateway will process the
	MUST NOT relay the encrypted message onto the next hop.		failure according to local convention (log an event, etc.) The
	3. The gateway MUST relay the decrypted message to the next hop.		gateway MUST NOT relay the encrypted message onto the next hop.
			3. The gateway MUST relay the decrypted message to the next hop.
	Any other message SHOULD be relayed unaltered.		Any other message SHOULD be relayed unaltered.
	6. Security Considerations		6. Security Considerations
	If the gateway has valid certificates for some, but not all of the		If the gateway has valid certificates for some, but not all of the
	domains represented by recipients of the outbound message, there is a		domains represented by recipients of the outbound message, there is a
	security issue, namely that the message may be encrypted on the		security issue, namely that the message may be encrypted on the
	Internet for some destinations, but not others. Of course, this		Internet for some destinations, but not others. Of course, this
	increases the risk of exposure for that message. A gateway SHOULD		increases the risk of exposure for that message. A gateway SHOULD
	provide an administrative option to prevent transmission of a message		provide an administrative option to prevent transmission of a message
	to a secured and un-secured recipient in order to reduce this risk.		to a secured and un-secured recipient in order to reduce this risk.
	A. References		A. References
			[DOMSEC] "Domain Security Services using S/MIME", RFC 3183
			[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
			Levels", RFC 2119
	[SMIMEV3MSG] "S/MIME Version 3 Message Specification", RFC 2633		[SMIMEV3MSG] "S/MIME Version 3 Message Specification", RFC 2633
	[SMIMEV2MSG] "S/MIME Version 2 Message Specification", RFC 2311		[SMIMEV2MSG] "S/MIME Version 2 Message Specification", RFC 2311
	[DOMSEC] "Domain Security Services using S/MIME",
	http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-08.txt
	[SMIMEV3CERT] "S/MIME Version 3 Certificate Handling", RFC 2632		[SMIMEV3CERT] "S/MIME Version 3 Certificate Handling", RFC 2632
	[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119
	B. Acknowledgements		B. Acknowledgements
	Comments were made by members of the staffs of: CareGroup,		Comments were made by members of the staffs of: CareGroup,
	Massachusetts Health Data Consortium, Tumbleweed Communications,		Massachusetts Health Data Consortium, Brute Squad Labs, Tumbleweed
	Baltimore Technologies, Dica Technologies, .TFS Technologies, Vanguard		Communications, Baltimore Technologies, Dica Technologies, .TFS
	Security Technologies, and Viasec (RIP).		Technologies, Vanguard Security Technologies, and Viasec (RIP).
	C. Changes from last draft
	Revision û01 (Littauer)
	Moved handling of message to multiple domains, some secured, some not,
	to ôSecurity Considerations Sectionö.
	Added note regarding of handling of sub-domains in Domain Certificates
	section.
	Revision û02 (Littauer and Ramsdell)		William Ottaway also provided significant insight into [DOMSEC] and
	Changed status from draft to informational.		helped clarify the role of this document as a [DOMSEC] profile.
	Cleaned up formatting
	Revised reference to latest domsec draft (-08)
	Added acknowledgements
	D. AuthorsÆ addresses		C. Authors' addresses
	Blake Ramsdell		Blake Ramsdell
	Tumbleweed Communications		Brute Squad Labs
	17720 NE 65th St Ste 201		Suite 217-C
	Redmond, WA 98052		16451 Redmond Way
	+1 425 376 0225		Redmond, WA 98052-4482
	blake.ramsdell@tumbleweed.com		blake@brutesquadlabs.com
	Ben Littauer		Ben Littauer
	Consultant for Massachusetts Health Data Consortium		Consultant for Massachusetts Health Data Consortium
	1 Moon Hill Road		1 Moon Hill Road
	Lexington, MA 02421		Lexington, MA 02421
	+1 781 862 8784		+1 781 862 8784
	littauer@blkk.com		littauer@blkk.com
			D. Changes from last draft
			Lots of piddly stuff (high-bit characters, author's address,
			formatting) (Blake Ramsdell)
			Rewording to profile of DOMSEC (Blake Ramsdell, William Ottaway)
End of changes. 17 change blocks.
	49 lines changed or deleted		62 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/