draft-ietf-smime-domsec-02.txt   draft-ietf-smime-domsec-03.txt 
Internet Draft T Dean Internet-Draft T Dean
draft-ietf-smime-domsec-02.txt W Ottaway draft-ietf-smime-domsec-03.txt W Ottaway
Expires March 1, 2000 DERA Expires 19th April 2000 DERA
Domain Security Services using S/MIME Domain Security Services using S/MIME
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with all
all provisions of section 10 of RFC2026. Internet-Drafts are working provisions of section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
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.
To view the entire list of Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net ( Northern Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu(US West Coast).
Abstract Abstract
This document describes how the S/MIME protocol can be processed and This document describes how the S/MIME protocol can be processed and
generated by a number of components of a messaging system, such as generated by a number of components of a communication system, such as
message transfer agents, guards and gateways to deliver security message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to limitations that arise when different security domains wish to
communicate securely - for example when two domains use incompatible communicate securely - for example when two domains use incompatible
messaging technologies such as X.400 and SMTP/MIME. This document is messaging technologies such as X.400 and SMTP/MIME. This document is
also applicable to organisations and enterprises that do not have also applicable to organisations and enterprises that have internal PKIs
encryption or signing capabilities at the desktop, but wish to which are not accessible by the outside world, but wish to interoperate
interoperate securely using the S/MIME protocol. securely using the S/MIME protocol.
This draft is being discussed on the 'ietf-smime' mailing list. To This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to: subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
subscribe subscribe
in the body of the message. There is a Web site for the mailing list at in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>. <http://www.imc.org/ietf-smime/>.
Acknowledgements Acknowledgements
Significant comments were made by Trevor Freeman, Russ Housley, Dave Significant comments were made by Trevor Freeman, Russ Housley,
Kemp and Jim Schaad. Dave Kemp, Jim Schaad, Greg Colla and Michael Zolotarev.
1. Introduction 1. Introduction
The S/MIME [1] series of standards define a data encapsulation format The S/MIME [1] series of standards define a data encapsulation format
for the provision of a number of security services including data for the provision of a number of security services including data
integrity, confidentiality, and authentication. S/MIME is designed for integrity, confidentiality, and authentication. S/MIME is designed for
use by messaging clients to deliver security services to distributed use by messaging clients to deliver security services to distributed
messaging applications. messaging applications.
There are many circumstances when it is not feasible or practical to There are many circumstances when it is not desirable or practical to
provide end-to-end ('desktop-to-desktop') security services, provide end-to-end (desktop-to-desktop) security services, particularly
particularly between different security domains. An organisation which between different security domains. An organisation that is considering
is considering providing end-to-end security services will typically providing end-to-end security services will typically have to deal with
have to deal with some if not all of the following issues: some if not all of the following issues:
1) Heterogeneous Message Access Methods: users are accessing mail using 1) Heterogeneous Message Access Methods: Users are accessing mail using
mechanisms which re-format messages, such as using Web browsers. mechanisms which re-format messages, such as using Web browsers.
Message reformatting in the Message Store makes end-to-end encryption Message reformatting in the Message Store makes end-to-end encryption
and signature validation impossible. and signature validation impossible.
2) Message screening and audit: server-based mechanisms such as 2) Message screening and audit: Server-based mechanisms such as
searching for prohibited words or other content, virus scanning, and searching for prohibited words or other content, virus scanning, and
audit, are incompatible with end-to-end encryption. audit, are incompatible with end-to-end encryption.
3) Cross-certification problems: There may not be any cross-certificate 3) PKI deployment issues: There may not be any certificate paths between
links between two organisations. Or an organisation may be sensitive two organisations. Or an organisation may be sensitive about aspects
about parts of its PKI and unwilling to expose them to outside of its PKI and unwilling to expose them to outside access. For either
access. For either of these reasons, end-to-end encryption and of these reasons, direct end-to-end signature validation and
signature validation are impossible. encryption are impossible.
4) Heterogeneous Message transports: one organisation using X.400 wishes 4) Heterogeneous Message transports: One organisation using X.400 wishes
to communicate with another using SMTP. Message reformatting at to communicate with another using SMTP. Message reformatting at
gateways makes end-to-end encryption and signature validation gateways makes end-to-end encryption and signature validation
impossible. impossible.
5) Cost: providing the necessary key management infrastructure and other This document describes an approach to solving these problems by
items such as hardware tokens for all users may be too expensive. providing message security services at the level of a domain or an
organisation. This document specifies how these 'domain security
One solution to these problems is to provide message security services services' can be provided using the S/MIME protocol. Domain security
at the level of a domain or an organisation. This document specifies how services may replace or complement mechanisms at the desktop. For
these 'domain security services' can be provided using the S/MIME example, a domain may decide to provide desktop-to-desktop signatures
protocol. Domain security services may replace or complement mechanisms but domain-to-domain encryption services. Or it may allow desktop-to-
at the desktop. For example, a domain may decide to provide desktop-to- desktop services for intra-domain use, but enforce domain-based services
desktop signatures but domain-to-domain encryption services. Or it may for communication with other domains.
allow desktop-to-desktop services for intra-domain use, but enforce
domain-based services for communication with other domains.
Messages can be processed and generated by a number of components of a Whether or not a domain based service is inherently better or worse than
messaging system, such as message transfer agents, guards and gateways. desktop based solutions is an open question. Some experts believe that
Any of these agents may provide domain security services. only end-to-end solutions can be truly made secure, while others believe
that the benefits offered by such things as content checking at domain
boundaries offers considerable increase in practical security for many
real systems. The additional service of allowing signature checking at
several points on a communications path is also an extra benefit in many
situations. This debate is outside the scope of this document. What is
offered here is a set of tools that integrators can tailor in different
ways to meet different needs in different circumstances.
The term 'Third Party' as used in this document means any entity in a Message transfer agents (MTAs), guards, firewalls and protocol
messaging system other than the originator and final recipient(s) that translation gateways all provide domain security services. As with
processes messages. This includes Message Transfer Agents (MTAs), desktop based solutions, these components must be resilient against a
domain mail servers, guards and firewalls operating at security wide variety of attacks intended to subvert the security services.
boundaries, and gateways that translate between different protocol Therefore, careful consideration should be given to security of these
formats. A third party may sign, encrypt, decrypt, and check signatures components, to make sure that their siting and configuration minimises
on a message. the possibility of attack.
Throughout this draft the terms MAY, MUST, MUST NOT and SHOULD NOT are Throughout this draft the terms MAY, MUST, MUST NOT and SHOULD are used
used in capital letters. This conforms to the definitions in [2]. in capital letters. This conforms to the definitions in [2].
2. Overview of Domain Security Services 2. Overview of Domain Security Services
In a distributed system, a message is sent from an originator to a set This section gives an informal overview of the security services that
of recipients that may be in the same or different security domains. are provided by S/MIME between different security domains. These
This section first defines what is meant by a security domain. It then services are provided by a combination of mechanisms in the sender's and
gives an informal overview of the security services that are provided by recipient's domains.
S/MIME between different security domains. These services are provided
by a combination of mechanisms in the sender's and recipient's domains.
Later sections describe definitively how these services map onto Later sections describe definitively how these services map onto
elements of the S/MIME protocol. elements of the S/MIME protocol.
2.1 Definition of a Security Domain The following security mechanisms are specified in this document:
1. Domain signature
2. Review signature
3. Additional attributes signature
4. Domain encryption and decryption
The term 'security domain' as used in this document is defined as a
collection of hardware and personnel operating under a single security
authority and performing a common business function. Members of a
security domain will of necessity share a high degree of mutual trust,
due to their shared aims and objectives.
A 'security domain' is defined as a collection of hardware and personnel
operating under a single security authority and performing a common
business function. Members of a security domain will of necessity share
a high degree of mutual trust, due to their shared aims and objectives.
A security domain is typically protected from direct outside attack by A security domain is typically protected from direct outside attack by
physical measures and from indirect (electronic) attack by a combination physical measures and from indirect (electronic) attack by a combination
of firewalls and guards at network boundaries. The interface between two of firewalls and guards at network boundaries. The interface between two
security domains is termed a 'security boundary'. One example of a security domains is termed a 'security boundary'. One example of a
security domain is an organisational network ('Intranet'). security domain is an organisational network ('Intranet').
2.2 Signing by a third party 2.1 Domain Signature
A third-party may sign messages for one or more of the following reasons:
1. When messages need to be reformatted inside the message transfer
system. Message reformatting is needed at gateways between X.400 and
SMTP-MIME domains, or on conversion between HTTP-MIME and SMTP-MIME
message representations. The third party signature is needed because
the reformatting process renders the originator's signature
unverifiable by the recipient(s).
2. To bridge between two domains that have incompatible or disconnected
signature systems, such as when there are no cross-certificate links
between their Public Key Infrastructures (PKIs). The third party
signature is needed because the originator's signature is not
directly verifiable by the recipient(s). It is typically created at
the boundary between the domains.
3. When end users do not have signing capabilities at the desktop. A Domain signature is an S/MIME signature generated on behalf of a set
of users in a domain. A Domain signature can be used to authenticate
information sent between domains, for example, when two 'Intranets' are
connected using the Internet. It can be used when two domains employ
incompatible signature schemes internally or when there are no
certification links between their PKIs. In both cases messages from the
originator's domain are signed over the original message and signature
(if present) using an algorithm, key, and certificate which can be
processed by the recipient(s). A domain signature is sometimes referred
to as an "organisational signature".
A third party may wish to convey the signature semantics to the 2.2 Review Signature
recipient(s) when creating its digital signature. This document
specifies three signature types to convey these semantics, as follows.
A third party may sign a message, and optionally add additional A third party may review messages before they are forwarded to the final
attributes to it. An example is the addition of the 'Equivalent Label' recipient(s) who may be in the same or a different security domain.
attribute defined in ESS [4]. In this case the 'additional attributes' Organisational policy and good security practice often require that
signature is used. messages be reviewed before they are released to external recipients.
Having reviewed a message, an S/MIME signature is added to it - a review
signature. An agent MAY check the review signature at the domain
boundary, to ensure that only reviewed messages are released.
A third party may wish to declare that it is acting as a proxy on 2.3 Additional Attributes Signature
behalf of an originator in a domain. In this case the 'Domain'
Signature is used.
A third party may review messages before they are released from a A third party MAY add additional attributes to a signed message. An
domain. This is used when organisational policy or good security S/MIME signature is used for this purpose - an additional attributes
practice require that messages be reviewed before they are released to signature. An example of an additional attribute is the 'Equivalent
external recipients. Having reviewed a message, a 'review and release' Label' attribute defined in ESS [3].
signature is added to it. The review and release signature may be
checked by a firewall at the domain boundary, to ensure that only
reviewed messages are released.
2.3 Domain Encryption 2.4 Domain Encryption and Decryption
Domain encryption is S/MIME encryption performed on behalf of a Domain encryption is S/MIME encryption performed on behalf of a
collection of users in a domain. Domain encryption can be used to collection of users in a domain. Domain encryption can be used to
protect information between domains, for example, when two 'Intranets' protect information between domains, for example, when two 'Intranets'
are connected using the Internet. It can also be used when end users do are connected using the Internet. It can also be used when end users do
not have encryption capabilities at the desktop, or when two domains not have encryption capabilities at the desktop, or when two domains
employ incompatible encryption schemes. In the latter case messages employ incompatible encryption schemes internally. In the latter case
from the originator's domain are re-encrypted using an algorithm, key, messages from the originator's domain are re-encrypted using an
and certificate which can be decrypted by the recipient(s). algorithm, key, and certificate which can be decrypted by the
recipient(s) or an entity in their domain.
3. Mapping of Domain Security Services to the S/MIME Protocol 3. Mapping of the Signature Services to the S/MIME Protocol
This section describes the S/MIME Protocol elements that are used to This section describes the S/MIME Protocol elements that are used to
provide the security services described above. ESS [4] introduces the provide the security services described above. ESS [3] introduces the
concept of triple-wrapped messages that are first signed, then concept of triple-wrapped messages that are first signed, then
encrypted, then signed again. This document also uses this concept of encrypted, then signed again. This document also uses this concept of
triple-wrapping. In addition, this document also uses the concept of triple-wrapping. In addition, this document also uses the concept of
'signature encapsulation'. 'Signature encapsulation' denotes a complete 'signature encapsulation'. 'Signature encapsulation' denotes a complete
signed message that is wrapped in a second signature, the second signed message that is wrapped in a second signature, the second
signature covering both the content and the first (inner) signature. signature covering both the content and the first (inner) signature.
Signature Encapsulation may be performed on the inner or the outer
Signature Encapsulation MAY be performed on the inner and/or the outer
signature of a triple-wrapped message. The term 'parallel signatures' signature of a triple-wrapped message. The term 'parallel signatures'
means two or more signatures calculated over the same content. This means two or more signatures calculated over the same content. This
capability is described in CMS [3], where a set of one or more capability is described in CMS [3], where a set of one or more
SignerInfos can be attached to signed data. SignerInfos can be attached to signed data.
3.1 Signature Types For example, the originator signs a message which is then encapsulated
with an 'additional attributes' signature. This is then encrypted. A
reviewer then signs this encrypted data, which is then encapsulated by
a domain signature.
An authenticated attribute is used to indicate the type of signature. 3.1 Naming conventions and Signature Types
The ASN.1 [5] notation of this attribute is:-
An entity receiving an S/MIME signed message would normally expect the
signature to be that of the originator of the message. However, the
message security services defined in this draft require the recipient to
be able accept messages signed by other entities and the originator.
When other entities sign the message the name in the certificate will
not match the message senders name. An S/MIME implementation would flag
an error if there were a mismatch between the name in the certificate
and the message sender's name. (This check prevents a number of types of
masquerade attack.)
To resolve this incompatibility, this document defines a naming
convention that specifies the form that the signing agents name SHOULD
take. Adherence to this naming convention avoids the problems of
uncontrolled naming and the possible masquerade attacks that this would
produce.
As an assistance to implementation, a signed attribute is defined to be
included in the S/MIME signature - the 'signature type' attribute. On
receiving a message containing this attribute, the naming convention
checks are invoked.
Implementations conforming to this standard MUST support the naming
convention for signature generation and verification. Implementations
conforming to this standard MUST recognise the signature type attribute
for signature verification. Implementations conforming to this standard
SHOULD support the signature type attribute for signature generation;
however, this is not mandated.
3.1.1 Naming conventions
The following naming conventions are specified for agents generating
signatures specified in this document:
* For a domain signature, an agent generating this signature MUST be
named 'domain-signing-authority'
* For a review signature, an agent generating this signature MUST be
named 'review-authority'.
* For an additional attributes signature, an agent generating this
signature MUST be named 'attribute-authority'.
This name shall appear in the 'common name (CN)' component of the
subject field in the X.509 certificate. Additionally, if the
certificate contains an SMTP e-mail address, this name shall appear in
the end entity component of the address - on the left-hand side of the
'@' symbol.
In the case of a domain signature, an additional naming rule is
defined: the 'name mapping rule'. The name mapping rule states that
for a domain signing authority, the domain component of its name MUST be
the same as, or an ascendant of, the domain name of the message
originator(s) that it is representing. The domain component is defined
as follows:
* In the case of an X.500 distinguished subject name of an X.509
certificate, the domain component is the country, organisation,
organisational unit, state, and locality components of the
distinguished name.
* If the certificate contains an SMTP e-mail address, the domain
component is defined to be the SMTP address component on the right-
hand side of the '@' symbol.
For example, a domain signing authority acting on behalf of John Doe of
the Acme corporation, whose distinguished name is 'cn=John Doe,
ou=marketing,o=acme,c=us' and whose e-mail address is
John.Doe@marketing.acme.com, could have a certificate containing a
distinguished name of 'cn=domain-signing-authority, o=acme,c=us' and an
e-mail address of 'domain-signing-authority@acme.com'.
Any message received where the domain component of the domain signing
agents name does not match, or is not an ascendant of, the originator's
domain name MUST be rejected.
This naming rule prevents agents from one organisation masquerading as
domain signing authorities on behalf of another. For the other types of
signature defined in this document, no such named mapping rule is
defined.
Implementations conforming to this standard MUST support this name
mapping convention as a minimum. Implementations MAY choose to
supplement this convention with other locally defined conventions.
However, these MUST be agreed between sender and recipient domains prior
to secure exchange of messages.
On verifying the signature, a receiving agent MUST ensure that the
naming convention has been adhered to. Any message that violates the
convention shall be rejected as invalid.
3.1.2 Signature type attribute
An S/MIME authenticated attribute is also used to indicate the type of
signature. This should be used in conjunction with the naming
conventions specified in the previous section. When an S/MIME signed
message containing the signature type attribute is received it triggers
the software to verify that the correct naming convention has been used.
The ASN.1 [4] notation of this attribute is: -
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
id-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) id-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2)
us (840) rsadsi (113549) <TBD> } us (840) rsadsi (113549) <TBD> }
If present, the SignatureType attribute MUST be an authenticated If present, the SignatureType attribute MUST be an authenticated
attribute, as defined in [3]. If the SignatureType attribute is absent attribute, as defined in [5]. If the SignatureType attribute is absent
the recipient SHOULD NOT make any assumptions about the type of the recipient SHOULD assume that the signature is that of the message
signature. originator.
This section specifies the following types of signature: Each of the signature types defined here are generated and processed
exactly as described in [5]. They are distinguished by the presence of
the following values in the SignatureType authenticated attribute:
1) Originator Signature id-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-signatureType 2 } for a
2) Domain Signature domain signature.
3) Additional Attributes Signature
4) Review and Release Signature
Each of these signature types is generated and processed exactly as id-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-signatureType 3}
described in [3]. They are distinguished by the presence of the for an additional attributes signature.
following values in the SignatureType authenticated attribute:
id-sigtype-review OBJECT IDENTIFIER ::= { id-signatureType 4} for a
review signature.
For completeness, an attribute type is also specified for an originator
signature. However, this signature type is optional. It is defined as
follows:
id-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-signatureType 1} id-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-signatureType 1}
id-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-signatureType 2 } for an originator's signature.
id-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-signatureType 3}
id-sigtype-review-release-sig OBJECT IDENTIFIER ::= { id-signatureType
4}
These signature types may encapsulate other signatures, or any other The originator signature MUST NOT encapsulate other signatures. The
type of content, or may be added in parallel to other signatures as other signature types specified in this document MAY encapsulate other
documented in [3]. signatures. All the signature types MAY be added in parallel to other
signatures as documented in [5].
A SignerInfo MUST NOT include multiple instances of SignatureType. An A SignerInfo MUST NOT include multiple instances of SignatureType. An
authenticated attribute representing a SignatureType MAY include authenticated attribute representing a SignatureType MAY include
multiple instances of different SignatureType values as an multiple instances of different SignatureType values as an
AttributeValue of attrValues [3], as long as the SignatureType AttributeValue of attrValues [5], as long as the SignatureType
'additional attributes' is not present. 'additional attributes' is not present.
The following sections describe the conditions under which each of The following sections describe the conditions under which each of these
these types of signature may be generated, and how they are processed. types of signature may be generated, and how they are processed.
3.1.1 Originator Signature
The 'originator signature' is used to indicate that the signer is the
originator of the message and its contents. The 'originator signature'
is indicated by the presence of the value id-sigtype-originator-sig in
the 'signature type' authenticated attribute. There MUST be only one
'originator signature' signature present in a S/MIME encoding.
3.1.2 Domain Signature 3.2 Domain Signature Generation and Verification
A 'domain signature' is a proxy signature generated on a user's behalf in A 'domain signature' is a proxy signature generated on a user's behalf
a domain. A 'domain signature' on a message authenticates the fact that in the user's domain. The signature MUST adhere to the naming
the message has originated in that domain. Before signing, a process conventions in 3.1.1, including the name mapping convention. A 'domain
generating a 'domain signature' MUST first satisfy itself of the signature' on a message authenticates the fact that the message has
authenticity of the message originator. This is achieved by one of two originated in that domain. Before signing, a process generating a
methods. Either the 'originator's signature' is checked, if S/MIME 'domain signature' MUST first satisfy itself of the authenticity of the
signatures are used inside a domain. Or if not, some mechanism external message originator. This is achieved by one of two methods. Either the
to S/MIME is used, such as the physical address of the originating 'originator's signature' is checked, if S/MIME signatures are used
client or an authenticated IP link. inside a domain. Or if not, some mechanism external to S/MIME is used,
such as the physical address of the originating client or an
authenticated IP link.
If the originator's authenticity is successfully verified by one of the If the originator's authenticity is successfully verified by one of the
above methods and all other signatures present are valid, a 'domain above methods and all other signatures present are valid, a 'domain
signature' may be added to a message in one of the following ways: signature' MAY be added to a message in one of the following ways:
1) An unsigned message is wrapped in a SignedData, and a SignerInfo is 1) An unsigned message has a null signature added to it (i.e. the
attached containing the 'domain signature'. The originator's message is wrapped in a signedData that has no signerInfo attached),
information is included as part of a header field in the encapsulated and then a 'domain signature' is added as defined in methods 2) or 3)
message. below. The originator's information is included as part of a header
field in the encapsulated message.
2) Signature Encapsulation is used to wrap the original signed message 2) Signature Encapsulation is used to wrap the original signed message
with a 'domain signature'. with a 'domain signature'.
3) The original signed message has a 'domain signature' added in 3) The original signed message has a 'domain signature' added in
parallel. parallel.
An entity generating a domain signature MUST do so using a certificate
containing a subject name that follows the naming convention specified
in 3.1.1.
When a 'domain signature' is applied the mlExpansionHistory and When a 'domain signature' is applied the mlExpansionHistory and
eSSSecurityLabel attributes MUST be copied from other signerInfos as eSSSecurityLabel attributes MUST be copied from other signerInfos as
stated in [4]. stated in [3].
If the originator's authenticity is not successfully verified, a 'domain If the originator's authenticity is not successfully verified or all
signature' MUST NOT be generated. the signatures present are not valid, a 'domain signature' MUST NOT be
generated.
On reception, the 'domain signature' SHOULD be used to verify the
authenticity of a message. A check MUST be made to ensure that both the
naming convention and the name mapping convention have been used as
specified in this standard.
A recipient MAY assume that successful verification of the domain
signature also authenticates the message originator.
If there is an originator signature present, the name in that
certificate SHOULD be used to identify the originator. This information
can then be displayed to the recipient.
On reception, the 'domain signature' may be used to verify the
authenticity of a message. If there is a SignerInfo with the signature
type 'originator', its certificate should be used to identify the
originator. This information can then be displayed to the recipient.
Alternatively, if a 'domain signature' has encapsulated a complete Alternatively, if a 'domain signature' has encapsulated a complete
MIME-encoded message, the originator information (SMTP 'From' field) MIME-encoded message, the originator information (SMTP 'From' field)
contained within it denotes the originator of the message. If neither contained within it denotes the originator of the message.
of these cases is true no assumptions can be made about the originator.
If neither of these cases is true no assumptions can be made about the
originator.
A domain signer can be assumed to have verified any signatures that it A domain signer can be assumed to have verified any signatures that it
encapsulates. Therefore, it is not necessary to verify these signatures encapsulates. Therefore, it is not necessary to verify these signatures
before treating the message as authentic. However, this standard does before treating the message as authentic. However, this standard does
not preclude a recipient from attempting to verify any other signatures not preclude a recipient from attempting to verify any other signatures
that are present. that are present.
The 'domain signature' is indicated by the presence of the value Id-at- The 'domain signature' is indicated by the presence of the value
sigtype-domain-sig in the 'signature type' authenticated attribute. Id-at-sigtype-domain-sig in a 'signature type' authenticated attribute.
There MAY be multiple 'domain signature' signatures in a S/MIME encoding.
3.1.3 Additional Attributes Signature There MAY be multiple 'domain signature' signatures in an S/MIME
encoding.
3.3 Additional Attributes Signature generation and verification
The 'additional attributes' signature type indicates that the
SignerInfo contains additional attributes that are associated with the
message.
The 'additional attributes' signature type indicates that the SignerInfo
contains additional attributes that are associated with the message.
All attributes in the applicable SignerInfo MUST be treated as All attributes in the applicable SignerInfo MUST be treated as
additional attributes. Successful verification of an 'additional additional attributes. Successful verification of an 'additional
attributes' signature means only that the attributes are authentically attributes' signature means only that the attributes are authentically
bound to the message. A recipient MUST NOT assume that its successful bound to the message. A recipient MUST NOT assume that its successful
verification also authenticates the message originator. The authenticity verification also authenticates the message originator.
of the message originator should be verified by checking the signature of
the appropriate type, if present.
A signer may include any of the attributes listed in [3] or this document An entity generating an 'additional attributes' signature MUST do so
when generating an 'additional attributes' signature. The following using a certificate containing a subject name that follows the naming
attributes have a special meaning, when present in an 'additional convention specified in 3.1.1. On reception, a check MUST be made to
attributes' signature: ensure that the naming convention has been used.
A signer MAY include any of the attributes listed in [5] or in this
document when generating an 'additional attributes' signature. The
following attributes have a special meaning, when present in an
'additional attributes' signature:
1) Equivalent Label: label values in this attribute are to be treated as 1) Equivalent Label: label values in this attribute are to be treated as
equivalent to the security label contained in an encapsulated equivalent to the security label contained in an encapsulated
SignerInfo, if present. SignerInfo, if present.
2) Security Label: the label value indicates the aggregate sensitivity 2) Security Label: the label value indicates the aggregate sensitivity
of the inner message content plus any encapsulated signedData and of the inner message content plus any encapsulated signedData and
envelopedData containers. The label on the original data is indicated envelopedData containers. The label on the original data is indicated
by the value in the originator's signature, if present. by the value in the originator's signature, if present.
An 'additional attributes' signature is indicated by the presence of the An 'additional attributes' signature is indicated by the presence of the
value Id-at-sigtype-add-attrib-sig in the 'signature type' authenticated value Id-at-sigtype-add-attrib-sig in a 'signature type' authenticated
attribute. No other Object Identifiers may be included in the sequence attribute. No other Object Identifiers MAY be included in the sequence
of OIDs if this value is present. An 'additional attributes' signature of OIDs if this value is present. An 'additional attributes' signature
may be added in parallel with other signatures in a SET OF SignerInfos. MAY be added in parallel with other signatures in a SET OF SignerInfos.
There MAY be multiple 'additional attributes' signatures in a S/MIME
There MAY be multiple 'additional attributes' signatures in an S/MIME
encoding. encoding.
3.1.4 Review and Release 3.4 Review Signature generation and verification
The 'review and release' signature indicates that the signer has The review signature indicates that the signer has reviewed the message.
reviewed the message. Successful verification of a 'review and release' Successful verification of a review signature means only that the signer
signature means only that the signer has approved the message for has approved the message for onward transmission to the recipient(s).
release from a domain. A device on a domain boundary such as a Mail When the recipient is in another domain, a device on a domain boundary
Guard or firewall may be configured to check review and release such as a Mail Guard or firewall may be configured to check review
signatures. A recipient MUST NOT assume that its successful verification signatures. A recipient MUST NOT assume that its successful verification
also authenticates the message originator. The authenticity of the also authenticates the message originator.
message originator should be verified by checking the signature
identified as the originators, if present.
A 'review and release' signature is indicated by the presence of the An entity generating a signed review signature MUST do so using a
value Id-at-sigtype-review-release-sig in the 'signature type' certificate containing a subject name that follows the naming convention
authenticated attribute. There MAY be multiple 'review and release' specified in 3.1.1. On reception, a check MUST be made to ensure that
signatures in a S/MIME encoding. the naming convention has been used.
3.2 Domain Encryption and Decryption A review signature is indicated by the presence of the value
Id-at-sigtype-review-sig in a 'signature type' authenticated attribute.
There MAY be multiple review signatures in an S/MIME encoding.
3.5 Originator Signature
The 'originator signature' is used to indicate that the signer is the
originator of the message and its contents. It is included in this
document for completeness only. An originator signature is indicated
either by the absence of the signature type attribute, or by the
presence of the value id-sigtype-originator-sig in a 'signature type'
authenticated attribute. There MUST be only one 'originator signature'
signature present in an S/MIME encoding and it MUST be one of the inner
most signatures.
4. Encryption and Decryption
Domain encryption is encryption performed by a third party on behalf of Domain encryption is encryption performed by a third party on behalf of
a set of originators in a domain. Domain decryption is decryption a set of originators in a domain. Domain decryption is decryption
performed by a third party on behalf of a set of recipients in a domain. performed by a third party on behalf of a set of recipients in a domain.
These processes may be performed in combination, as shown below.
Depending on security policy, messages may be encrypted for decryption
by the final recipient and by a domain decryption agent in the
originator's and/or the recipient's domain. This is achieved by
generating a RecipientInfo for each type of agent that is transmitted
along with the encrypted message.
The processes of domain encryption and decryption may be performed in
combination, as shown below.
-------------------------------------------------------------------- --------------------------------------------------------------------
| | Recipient Decryption | Domain Decryption | | | Recipient Decryption | Domain Decryption |
|------------------------|----------------------|--------------------| |------------------------|----------------------|--------------------|
| Originator Encryption | Case(a) | Case(c) | | Originator Encryption | Case(a) | Case(c) |
| Domain Encryption | Case(b) | Case(d) | | Domain Encryption | Case(b) | Case(d) |
-------------------------------------------------------------------- --------------------------------------------------------------------
Case (a), encryption of messages by the originator for decryption by the Case (a), encryption of messages by the originator for decryption by the
final recipient(s), is described in CMS [3]. In Cases (b) and (d), final recipient(s), is described in CMS [5]. In Cases (b) and (d),
encryption is performed not by the originator but by a third party in encryption is performed not by the originator but by a third party in
the sending domain. In Cases (c) and (d), decryption is performed not the sending domain. In Cases (c) and (d), decryption is performed not by
by the recipient(s) but by a third party in the destination domain. the recipient(s) but by a third party in the destination domain.
A client implementation that conforms to this standard MUST support A client implementation that conforms to this standard MUST support
cases (a) and (c) for transmission, and cases (a) and (b) for reception. cases (a) and (c) for transmission, and cases (a) and (b) for reception.
A Domain Encryption implementation that conforms to this standard MUST A Domain Encryption implementation that conforms to this standard MUST
support cases (b) and (d), for transmission, and cases (c) and (d) for support cases (b) and (d), for transmission, and cases (c) and (d) for
reception. reception.
The process of encryption and decryption is documented in CMS [3]. The The process of encryption and decryption is documented in CMS [5]. The
only additional requirement introduced by domain encryption and only additional requirement introduced by domain encryption and
decryption is for greater flexibility in the management of keys, as decryption is for greater flexibility in the management of keys, as
described in the following subsections. described in the following subsections. As with signatures, a naming
convention and name mapping convention are used to locate the correct
key.
The mechanisms described below are applicable both to key agreement and The mechanisms described below are applicable both to key agreement and
key transport systems, as documented in CMS. The phrase 'encryption key transport systems, as documented in CMS [5]. The phrase 'encryption
key' is used as a collective term to cover the key management keys used key' is used as a collective term to cover the key management keys used
by both techniques. by both techniques.
3.2.1 Domain Encryption Key Management 4.1 Domain Encryption Naming Conventions
Domain Encryption is shown as cases (b) and (d) in the above table. A domain encryption agent MUST be named 'domain-confidentiality-
Domain Encryption uses a domain-wide encryption key from the sender's authority'. Also a domain decryption agent MUST be named 'domain-
domain. Information about this key is conveyed to the recipient by confidentiality-authority'. This name MUST appear in the 'common name
one of two methods:- (CN)' component of the subject field in the X.509 certificate.
Additionally, if the certificate contains an SMTP e-mail address, this
name MUST appear in the end entity component of the address - on the
left-hand side of the '@' symbol.
1) Public information about this key is held in a certificate and Along with this naming convention, an additional naming rule is defined:
conveyed to the recipient(s) in the 'Certs' field of the the 'name mapping rule'. The name mapping rule states that for an
OriginatorInfo in the Envelope. encryption agent, the domain component of its name MUST be the same as,
or an ascendant of, the domain name of the set of entities that it
represents. The domain component is defined as follows:
2) The recipient(s) looks up the key for the users domain by replacing * In the case of an X.500 distinguished name of an X.509 certificate,
the originator's name within the address with the domain encryption the domain component is the country, organisation, organisational
name [6]. unit, state, and locality components of the distinguished name.
For example :- * If the certificate contains an SMTP e-mail address, the domain
component is defined to be the SMTP address component on the right-
hand side of the '@' symbol.
a) If the originator is originator@foo.com then lookup key for For example, an encryption authority acting on behalf of John Doe of the
domain-encrypting-authority@foo.com. Acme corporation, whose distinguished name is 'cn=John Doe,ou=marketing,
o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com,
could have a certificate containing a distinguished name of
'cn=domain-confidentiality-authority, o=acme,c=us' and an e-mail address
of 'domain-confidentiality-authority@acme.com'. The key associated with
this certificate would be used for encrypting messages for John Doe.
b) If the originator is c=us;a=com;p=foo;s=originator then look up Any message received where the domain component of the domain encrypting
key for c=us;a=com;p=foo;s=domain-encrypting-authority. agents name does not match, or is not an ascendant of, the domain name
of the entities it represents MUST be rejected.
c) If the originator is c=gb;o=foo;cn=originator then look up key for This naming rule prevents messages being encrypted for the wrong domain
c=gb;o=foo;cn=domain-encrypting-authority. decryption agent.
An implementation conforming to this standard MUST support both methods. Implementations conforming to this standard MUST support this name
mapping convention as a minimum. Implementations may choose to
supplement this convention with other locally defined conventions.
However, these MUST be agreed between sender and recipient domains
prior to sending any messages.
The name in the encryption certificate may not match the name in any 4.2 Domain Encryption Key Management
encapsulated signatures. For example, when a message is signed by the
originator and is encrypted by the domain. An implementation that
conforms to this standard MUST allow for this possibility. This includes
both a client and a third party implementation.
3.2.2 Domain Decryption Key Management Domain encryption is encryption performed by a third party on behalf of
a set of originators in a domain. Domain Encryption is shown as cases
(b) and (d) in the above table.
Domain Decryption is shown as cases (c) and (d) in the above table. In Domain encryption uses a domain-wide encryption key from the sender's
these cases, the encryption process uses a domain-wide encryption key domain. Information about this key is conveyed to the recipient in the
for the recipient(s)' domain. The selection of this key is achieved by RecipientInfo field as specified in CMS [5]. A domain encryption agent
one of two methods: MUST be named according to the naming convention specified in section
4.1. This is so that the same key can be used on reply to a domain-
encrypted message.
1) The sending process explicitly searches for a certificate containing The domain encryption agent extracts the recipients address from the
the domain encryption key of the recipient(s)' domain. This is message and uses this to obtain the recipients domain-confidentiality-
achieved by mapping the recipient(s)' name to a domain name and then authority public key and/or the recipients public key. For example,
locating the encryption certificate containing that domain name. the recipients address is used as an index for a directory search. The
Mapping from recipient names to Domain names, and conventions for directory search MAY return the recipients certificate and/or a domain-
domain names are outside the scope of this standard. confidentiality-authority attribute that contains the location of the
recipient's domain decrytping agents certificate. If the directory
search returns no certificates then encryption can not be performed and
the message MUST NOT be sent. If one or both certificates are available
then the originator's domain encrypting agent encrypts the message for
the recipient and the recipient's domain decrypting agent.
2) All the members of the receiving domain are issued with certificates 4.3 Domain Decryption Key Management
containing a single key. The private component of that key is held
by an entity in the domain that performs the decryption process
on their behalf. By selecting the appropriate certificate, a sending
process will implicitly encrypt for decryption by the Domain
Decryption process.
An implementation that conforms to this standard MUST support mechanism Domain decryption is decryption performed by a third party on behalf of
(1). It may also support mechanism (2). This includes both a client and a set of recipients in a domain.
a third party implementation.
4. Security Considerations Domain Decryption is shown as cases (c) and (d) in the above table. In
these cases, the encryption process has used a domain-wide encryption
key for the recipient(s)' domain, that has been obtained by using the
recipient's address (See example in section 4.2).
Domain Security Services provide a method for digitally 5. Security Considerations
signing data, digesting data, encrypting data, and authenticating
data.
Implementations must protect the signer's private key. Compromise of Implementations MUST protect all private keys. Compromise of the
the signer's private key permits masquerade. signer's private key permits masquerade.
Implementations must protect the key management private key and the
content-encryption key. Compromise of the key management private key
may result in the disclosure of all messages protected with that key.
Similarly, compromise of the content-encryption key may result in Similarly, compromise of the content-encryption key may result in
disclosure of the encrypted content. disclosure of the encrypted content.
5. References Compromise of key material is regarded as an even more serious issue for
domain security services than for an S/MIME client. This is because
compromise of the private key may in turn compromise the security of a
whole domain. Therefore, great care should be used when considering its
protection.
[1] Ramsdell, B., "S/MIME Version 3 Message Specification", Internet 6. References
Draft draft-ietf-smime-msg-04, May 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC2633,
Levels", BCP 14, RFC 2119, March 1997. June 1999.
[3] Housley, R., "Cryptographic Message Syntax", Internet Draft [2] Bradner, S., "Key words for use in RFCs to Indicate
draft-ietf-smime-cms-05.txt, March 1998. Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Hoffman, P., "Enhanced Security Services for S/MIME", Internet Draft [3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634,
draft-ietf-smime-ess-06.txt, May 1998. June 1999.
[5] International Telecommunications Union, Recommendation X.208, "Open [4] International Telecommunications Union, Recommendation X.208, "Open
systems interconnection: specification of Abstract Syntax Notation systems interconnection: specification of Abstract Syntax Notation
(ASN.1)", CCITT Blue Book, 1989. (ASN.1)", CCITT Blue Book, 1989.
[6] Ramsdell, B., "Role Names in X.509 Certificates", Internet Draft [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
draft-ramsdell-role-names, April 29 1998.
6. Authors' Addresses 7. Authors' Addresses
Tim Dean Tim Dean
DERA Malvern DERA Malvern
St. Andrews Road St. Andrews Road
Malvern Malvern
Worcs Worcs
WR14 3PS WR14 3PS
Phone: +44 (0)1684 894239 Phone: +44 (0)1684 894239
Fax: +44 (0)1684 6113 Fax: +44 (0) 1684 896660
Email: t.dean@eris.dera.gov.uk Email: t.dean@eris.dera.gov.uk
William Ottaway William Ottaway
DERA Malvern DERA Malvern
St. Andrews Road St. Andrews Road
Malvern Malvern
Worcs Worcs
WR14 3PS WR14 3PS
Phone: +44 (0)1684 894079 Phone: +44 (0)1684 894079
Fax: +44 (0)1684 896113 Fax: +44 (0) 1684 896660
Email: w.ottaway@eris.dera.gov.uk Email: w.ottaway@eris.dera.gov.uk
This draft expires March 1, 2000 This draft expires 19th April 2000
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/