RFC 3183 (rfc3183) - Page 2 of 24
Domain Security Services using S/MIME
Alternative Format: Original Text Document
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