Domain Security Services using S/MIME
RFC 3183

Document Type RFC - Experimental (October 2001; Errata)
Last updated 2013-10-19
Stream IETF
Formats plain text pdf htmlized with errata bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3183 (Experimental)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                            T. Dean
Request for Comments: 3183                                    W. Ottaway
Category: Experimental                                           QinetiQ
                                                            October 2001

                 Domain Security Services using S/MIME

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes how the S/MIME (Secure/Multipurpose Internet
   Mail Extensions) protocol can be processed and generated by a number
   of components of a communication system, such as message transfer
   agents, guards and gateways to deliver security services.  These
   services are collectively referred to as 'Domain Security Services'.

Acknowledgements

   Significant comments were made by Luis Barriga, Greg Colla, Trevor
   Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev.

1. Introduction

   The S/MIME [1] series of standards define a data encapsulation format
   for the provision of a number of security services including data
   integrity, confidentiality, and authentication.  S/MIME is designed
   for use by messaging clients to deliver security services to
   distributed messaging applications.

   The mechanisms described in this document are designed to solve a
   number of interoperability problems and technical limitations that
   arise when different security domains wish to communicate securely,
   for example when two domains use incompatible messaging technologies
   such as the X.400 series and SMTP/MIME, or when a single domain
   wishes to communicate securely with one of its members residing on an
   untrusted domain.  The scenarios covered by this document are
   domain-to-domain, individual-to-domain and domain-to-individual

Dean & Ottaway                Experimental                      [Page 1]
RFC 3183         Domain Security Services using S/MIME      October 2001

   communications.  This document is also applicable to organizations
   and enterprises that have internal PKIs which are not accessible by
   the outside world, but wish to interoperate securely using the S/MIME
   protocol.

   There are many circumstances when it is not desirable or practical to
   provide end-to-end (desktop-to-desktop) security services,
   particularly between different security domains.  An organization
   that is considering providing end-to-end security services will
   typically have to deal with some if not all of the following issues:

   1) Heterogeneous message access methods: Users are accessing mail
      using mechanisms which re-format messages, such as using Web
      browsers.  Message reformatting in the Message Store makes end-
      to-end encryption and signature validation impossible.

   2) Message screening and audit: Server-based mechanisms such as
      searching for prohibited words or other content, virus scanning,
      and audit, are incompatible with end-to-end encryption.

   3) PKI deployment issues: There may not be any certificate paths
      between two organizations.  Or an organization may be sensitive
      about aspects of its PKI and unwilling to expose them to outside
      access.  Also, full PKI deployment for all employees, may be
      expensive, not necessary or impractical for large organizations.
      For any of these reasons, direct end-to-end signature validation
      and encryption are impossible.

   4) Heterogeneous message formats: One organization using X.400 series
      protocols wishes to communicate with another using SMTP.  Message
      reformatting at gateways makes end-to-end encryption and signature
      validation impossible.

   This document describes an approach to solving these problems by
   providing message security services at the level of a domain or an
   organization.  This document specifies how these 'domain security
   services' can be provided using the S/MIME protocol.  Domain security
   services may replace or complement mechanisms at the desktop.  For
   example, a domain may decide to provide desktop-to-desktop signatures
   but domain-to-domain encryption services.  Or it may allow desktop-
   to-desktop services for intra-domain use, but enforce domain-based
   services for communication with other domains.

   Domain services can also be used by individual members of a
   corporation who are geographically remote and who wish to exchange
   encrypted and/or signed messages with their base.

Dean & Ottaway                Experimental                      [Page 2]
RFC 3183         Domain Security Services using S/MIME      October 2001

   Whether or not a domain based service is inherently better or worse
Show full document text