draft-ietf-smime-domsec-09.txt   rfc3183.txt 
INTERNET-DRAFT T Dean
draft-ietf-smime-domsec-09.txt W Ottaway
Expires 01 September 2001 DERA
Domain Security Services using S/MIME Network Working Group T. Dean
Request for Comments: 3183 W. Ottaway
Category: Experimental QinetiQ
October 2001
Status of this memo Domain Security Services using S/MIME
This document is an Internet-Draft and is in full conformance with all Status of this Memo
provisions of section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This memo defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. It does not specify an Internet standard of any kind.
time. It is inappropriate to use Internet-Drafts as reference material Discussion and suggestions for improvement are requested.
or to cite them other than as "work in progress." Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2001). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes how the S/MIME protocol can be processed and This document describes how the S/MIME (Secure/Multipurpose Internet
generated by a number of components of a communication system, such as Mail Extensions) protocol can be processed and generated by a number
message transfer agents, guards and gateways to deliver security of components of a communication system, such as message transfer
services. These services are collectively referred to as 'Domain agents, guards and gateways to deliver security services. These
Security Services'. The mechanisms described in this document are services are collectively referred to as 'Domain Security Services'.
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
communications. This document is also applicable to organisations and
enterprises that have internal PKIs which are not accessible by the
outside world, but wish to interoperate securely using the S/MIME
protocol.
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/>.
Acknowledgements Acknowledgements
Significant comments were made by Luis Barriga, Greg Colla, Trevor Significant comments were made by Luis Barriga, Greg Colla, Trevor
Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev. Freeman, Russ Housley, Dave Kemp, Jim Schaad 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
use by messaging clients to deliver security services to distributed for use by messaging clients to deliver security services to
messaging applications. distributed messaging applications.
There are many circumstances when it is not desirable or practical to The mechanisms described in this document are designed to solve a
provide end-to-end (desktop-to-desktop) security services, particularly number of interoperability problems and technical limitations that
between different security domains. An organisation that is considering arise when different security domains wish to communicate securely,
providing end-to-end security services will typically have to deal with for example when two domains use incompatible messaging technologies
some if not all of the following issues: 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
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.
1) Heterogeneous message access methods: Users are accessing mail using There are many circumstances when it is not desirable or practical to
mechanisms which re-format messages, such as using Web browsers. provide end-to-end (desktop-to-desktop) security services,
Message reformatting in the Message Store makes end-to-end encryption particularly between different security domains. An organization
and signature validation impossible. that is considering providing end-to-end security services will
typically have to deal with some if not all of the following issues:
2) Message screening and audit: Server-based mechanisms such as 1) Heterogeneous message access methods: Users are accessing mail
searching for prohibited words or other content, virus scanning, and using mechanisms which re-format messages, such as using Web
audit, are incompatible with end-to-end encryption. browsers. Message reformatting in the Message Store makes end-
to-end encryption and signature validation impossible.
3) PKI deployment issues: There may not be any certificate paths between 2) Message screening and audit: Server-based mechanisms such as
two organisations. Or an organisation may be sensitive about aspects searching for prohibited words or other content, virus scanning,
of its PKI and unwilling to expose them to outside access. Also, full and audit, are incompatible with end-to-end encryption.
PKI deployment for all employees, may be expensive, not necessary or
impractical for large organisations. For any of these reasons, direct
end-to-end signature validation and encryption are impossible.
4) Heterogeneous message formats: One organisation using X.400 series 3) PKI deployment issues: There may not be any certificate paths
protocols wishes to communicate with another using SMTP. Message between two organizations. Or an organization may be sensitive
reformatting at gateways makes end-to-end encryption and signature about aspects of its PKI and unwilling to expose them to outside
validation impossible. 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.
This document describes an approach to solving these problems by 4) Heterogeneous message formats: One organization using X.400 series
providing message security services at the level of a domain or an protocols wishes to communicate with another using SMTP. Message
organisation. This document specifies how these 'domain security reformatting at gateways makes end-to-end encryption and signature
services' can be provided using the S/MIME protocol. Domain security validation impossible.
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 This document describes an approach to solving these problems by
who are geographically remote and who wish to exchange encrypted and/or providing message security services at the level of a domain or an
signed messages with their base. 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.
Whether or not a domain based service is inherently better or worse than Domain services can also be used by individual members of a
desktop based solutions is an open question. Some experts believe that corporation who are geographically remote and who wish to exchange
only end-to-end solutions can be truly made secure, while others believe encrypted and/or signed messages with their base.
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.
Message transfer agents (MTAs), guards, firewalls and protocol Whether or not a domain based service is inherently better or worse
translation gateways all provide domain security services. As with than desktop based solutions is an open question. Some experts
desktop based solutions, these components must be resilient against a believe that only end-to-end solutions can be truly made secure,
wide variety of attacks intended to subvert the security services. while others believe that the benefits offered by such things as
Therefore, careful consideration should be given to security of these content checking at domain boundaries offers considerable increase in
components, to make sure that their siting and configuration minimises practical security for many real systems. The additional service of
the possibility of attack. 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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Message transfer agents (MTAs), guards, firewalls and protocol
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this translation gateways all provide domain security services. As with
document are to be interpreted as described in [2]. desktop based solutions, these components must be resilient against a
wide variety of attacks intended to subvert the security services.
Therefore, careful consideration should be given to security of these
components, to make sure that their siting and configuration
minimises the possibility of attack.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2].
2. Overview of Domain Security Services 2. Overview of Domain Security Services
This section gives an informal overview of the security services that This section gives an informal overview of the security services that
are provided by S/MIME between different security domains. These are provided by S/MIME between different security domains. These
services are provided by a combination of mechanisms in the sender's and services are provided by a combination of mechanisms in the sender's
recipient's domains. 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.
The following security mechanisms are specified in this document: The following security mechanisms are specified in this document:
1. Domain signature 1. Domain signature
2. Review signature 2. Review signature
3. Additional attributes signature 3. Additional attributes signature
4. Domain encryption and decryption 4. Domain encryption and decryption
The signature types defined in this document are referred to as DOMSEC The signature types defined in this document are referred to as
defined signatures. DOMSEC defined signatures.
The term 'security domain' as used in this document is defined as a The term 'security domain' as used in this document is defined as a
collection of hardware and personnel operating under a single security collection of hardware and personnel operating under a single
authority and performing a common business function. Members of a security authority and performing a common business function.
security domain will of necessity share a high degree of mutual trust, Members of a security domain will of necessity share a high degree of
due to their shared aims and objectives. 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
physical measures and from indirect (electronic) attack by a combination by physical measures and from indirect (electronic) attack by a
of firewalls and guards at network boundaries. The interface between two combination of firewalls and guards at network boundaries. The
security domains is termed a 'security boundary'. One example of a interface between two security domains is termed a 'security
security domain is an organisational network ('Intranet'). boundary'. One example of a security domain is an organizational
network ('Intranet').
2.1 Domain Signature 2.1 Domain Signature
A domain signature is an S/MIME signature generated on behalf of a set A domain signature is an S/MIME signature generated on behalf of a
of users in a domain. A domain signature can be used to authenticate set of users in a domain. A domain signature can be used to
information sent between domains or between a certain domain and one of authenticate information sent between domains or between a certain
its individuals, for example, when two 'Intranets' are connected using domain and one of its individuals, for example, when two 'Intranets'
the Internet, or when an Intranet is connected to a remote user over the are connected using the Internet, or when an Intranet is connected to
Internet. It can be used when two domains employ incompatible signature a remote user over the Internet. It can be used when two domains
schemes internally or when there are no certification links between employ incompatible signature schemes internally or when there are no
their PKIs. In both cases messages from the originator's domain are certification links between their PKIs. In both cases messages from
signed over the original message and signature (if present) using an the originator's domain are signed over the original message and
algorithm, key, and certificate which can be processed by the signature (if present) using an algorithm, key, and certificate which
recipient(s) or the recipient(s) domain. A domain signature is sometimes can be processed by the recipient(s) or the recipient(s) domain. A
referred to as an "organisational signature". domain signature is sometimes referred to as an "organizational
signature".
2.2 Review Signature 2.2 Review Signature
A third party may review messages before they are forwarded to the final A third party may review messages before they are forwarded to the
recipient(s) who may be in the same or a different security domain. final recipient(s) who may be in the same or a different security
Organisational policy and good security practice often require that domain. Organizational policy and good security practice often
messages be reviewed before they are released to external recipients. require that messages be reviewed before they are released to
Having reviewed a message, an S/MIME signature is added to it - a review external recipients. Having reviewed a message, an S/MIME signature
signature. An agent could check the review signature at the domain is added to it - a review signature. An agent could check the review
boundary, to ensure that only reviewed messages are released. signature at the domain boundary, to ensure that only reviewed
messages are released.
2.3 Additional Attributes Signature 2.3 Additional Attributes Signature
A third party can add additional attributes to a signed message. An A third party can add additional attributes to a signed message. An
S/MIME signature is used for this purpose - an additional attributes S/MIME signature is used for this purpose - an additional attributes
signature. An example of an additional attribute is the 'Equivalent signature. An example of an additional attribute is the 'Equivalent
Label' attribute defined in ESS [3]. Label' attribute defined in ESS [3].
2.4 Domain Encryption and Decryption 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
are connected using the Internet. It can also be used when end users do 'Intranets' are connected using the Internet. It can also be used
not have PKI/encryption capabilities at the desktop, or when two when end users do not have PKI/encryption capabilities at the
domains employ incompatible encryption schemes internally. In the latter desktop, or when two domains employ incompatible encryption schemes
case messages from the originator's domain are encrypted (or internally. In the latter case messages from the originator's domain
re-encrypted) using an algorithm, key, and certificate which can be are encrypted (or re-encrypted) using an algorithm, key, and
decrypted by the recipient(s) or an entity in their domain. This scheme certificate which can be decrypted by the recipient(s) or an entity
also applies to protecting information between a single domain and one in their domain. This scheme also applies to protecting information
of its members when both are connected using an untrusted network, between a single domain and one of its members when both are
e.g. the Internet. connected using an untrusted network, e.g., the Internet.
3. Mapping of the Signature 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 [3] introduces the provide the security services described above. ESS [3] introduces
concept of triple-wrapped messages that are first signed, then the 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
triple-wrapping. In addition, this document also uses the concept of of triple-wrapping. In addition, this document also uses the concept
'signature encapsulation'. 'Signature encapsulation' denotes a signed of 'signature encapsulation'. 'Signature encapsulation' denotes a
or unsigned message that is wrapped in a signature, this signature signed or unsigned message that is wrapped in a signature, this
covering both the content and the first (inner) signature, if present. signature covering both the content and the first (inner) signature,
if present.
Signature encapsulation MAY be performed on the inner and/or the outer Signature encapsulation MAY be performed on the inner and/or the
signature of a triple-wrapped message. outer signature of a triple-wrapped message.
For example, the originator signs a message which is then encapsulated For example, the originator signs a message which is then
with an 'additional attributes' signature. This is then encrypted. A encapsulated with an 'additional attributes' signature. This is then
reviewer then signs this encrypted data, which is then encapsulated by encrypted. A reviewer then signs this encrypted data, which is then
a domain signature. encapsulated by a domain signature.
There is a possibility that some policies will require signatures to be There is a possibility that some policies will require signatures to
added in a specific order. By only allowing signatures to be added by be added in a specific order. By only allowing signatures to be
encapsulation it is possible to determine the order in which the added by encapsulation it is possible to determine the order in which
signatures have been added. the signatures have been added.
A DOMSEC defined signature MAY encapsulate a message in one of the A DOMSEC defined signature MAY encapsulate a message in one of the
following ways: following ways:
1) An unsigned message has an empty signature layer added to it (i.e. 1) An unsigned message has an empty signature layer added to it
the message is wrapped in a signedData that has a signerInfos which (i.e., the message is wrapped in a signedData that has a
contains no elements). This is to enable backward compatibility with signerInfos which contains no elements). This is to enable
S/MIME software that does not have a DOMSEC capability. Since the backward compatibility with S/MIME software that does not have a
signerInfos will contain no signers the eContentType, within the DOMSEC capability. Since the signerInfos will contain no signers
EncapsulatedContentInfo, MUST be id-data as described in CMS [5]. the eContentType, within the EncapsulatedContentInfo, MUST be id-
However, the eContent field will contain the unsigned message instead data as described in CMS [5]. However, the eContent field will
of being left empty as suggested in section 5.2 in CMS [5]. This is contain the unsigned message instead of being left empty as
so that when the DOMSEC defined signature is added, as defined in suggested in section 5.2 in CMS [5]. This is so that when the
method 2) below, the signature will cover the unsigned message. DOMSEC defined signature is added, as defined in method 2) below,
the signature will cover the unsigned message.
2) Signature Encapsulation is used to wrap the original signed message 2) Signature Encapsulation is used to wrap the original signed
with a DOMSEC defined signature. This is so that the DOMSEC defined message with a DOMSEC defined signature. This is so that the
signature covers the message and all the previously added signatures. DOMSEC defined signature covers the message and all the previously
Also, it is possible to determine that the DOMSEC defined signature added signatures. Also, it is possible to determine that the
was added after the signatures that are already there. DOMSEC defined signature was added after the signatures that are
already there.
3.1 Naming Conventions and Signature Types 3.1 Naming Conventions and Signature Types
An entity receiving an S/MIME signed message would normally expect the An entity receiving an S/MIME signed message would normally expect
signature to be that of the originator of the message. However, the the signature to be that of the originator of the message. However,
message security services defined in this document require the recipient the message security services defined in this document require the
to be able to accept messages signed by other entities and/or the recipient to be able to accept messages signed by other entities
originator. When other entities sign the message the name in the and/or the originator. When other entities sign the message the name
certificate will not match the message sender's name. An S/MIME in the certificate will not match the message sender's name. An
compliant implementation would normally flag a warning if there were a S/MIME compliant implementation would normally flag a warning if
mismatch between the name in the certificate and the message sender's there were a mismatch between the name in the certificate and the
name. (This check prevents a number of types of masquerade attack.) message sender's name. (This check prevents a number of types of
masquerade attack.)
In the case of domain security services, this warning condition SHOULD In the case of domain security services, this warning condition
be suppressed under certain circumstances. These circumstances are SHOULD be suppressed under certain circumstances. These
defined by a naming convention that specifies the form that the signers circumstances are defined by a naming convention that specifies the
name SHOULD adhere to. Adherence to this naming convention avoids the form that the signers name SHOULD adhere to. Adherence to this
problems of uncontrolled naming and the possible masquerade attacks that naming convention avoids the problems of uncontrolled naming and the
this would produce. possible masquerade attacks that this would produce.
As an assistance to implementation, a signed attribute is defined to be As an assistance to implementation, a signed attribute is defined to
included in the S/MIME signature - the 'signature type' attribute. On be included in the S/MIME signature - the 'signature type' attribute.
receiving a message containing this attribute, the naming convention On receiving a message containing this attribute, the naming
checks are invoked. convention checks are invoked.
Implementations conforming to this standard MUST support the naming Implementations conforming to this standard MUST support the naming
convention for signature generation and verification. Implementations convention for signature generation and verification.
conforming to this standard MUST recognise the signature type attribute Implementations conforming to this standard MUST recognize the
for signature verification. Implementations conforming to this standard signature type attribute for signature verification. Implementations
MUST support the signature type attribute for signature generation. conforming to this standard MUST support the signature type attribute
for signature generation.
3.1.1 Naming Conventions 3.1.1 Naming Conventions
The following naming conventions are specified for agents generating The following naming conventions are specified for agents generating
signatures specified in this document: signatures specified in this document:
* For a domain signature, an agent generating this signature MUST be * For a domain signature, an agent generating this signature MUST be
named 'domain-signing-authority' named 'domain-signing-authority'
* For a review signature, an agent generating this signature MUST be * For a review signature, an agent generating this signature MUST be
named 'review-authority'. named 'review-authority'.
* For an additional attributes signature, an agent generating this * For an additional attributes signature, an agent generating this
signature MUST be named 'attribute-authority'. signature MUST be named 'attribute-authority'.
This name shall appear as the 'common name (CN)' component of the This name shall appear as the 'common name (CN)' component of the
subject field in the X.509 certificate. There MUST be only one CN subject field in the X.509 certificate. There MUST be only one CN
component present. Additionally, if the certificate contains an RFC 822 component present. Additionally, if the certificate contains an RFC
address, this name shall appear in the end entity component of the 822 address, this name shall appear in the end entity component of
address - on the left-hand side of the '@' symbol. the address - on the left-hand side of the '@' symbol.
In the case of a domain signature, an additional naming rule is In the case of a domain signature, an additional naming rule is
defined: the 'name mapping rule'. The name mapping rule states that defined: the 'name mapping rule'. The name mapping rule states that
for a domain signing authority, the domain part of its name MUST be the for a domain signing authority, the domain part of its name MUST be
same as, or an ascendant of, the domain name of the message the same as, or an ascendant of, the domain name of the message
originator(s) that it is representing. The domain part is defined originator(s) that it is representing. The domain part is defined as
as follows: follows:
* In the case of an X.500 distinguished subject name of an X.509 * In the case of an X.500 distinguished subject name of an X.509
certificate, the domain part is the country, organisation, certificate, the domain part is the country, organization,
organisational unit, state, and locality components of the organizational unit, state, and locality components of the
distinguished name. distinguished name.
* In the case of an RFC 2247 distinguished name, the domain part * In the case of an RFC 2247 distinguished name, the domain part is
is the domain components of the distinguished name. the domain components of the distinguished name.
* If the certificate contains an RFC 822 address, the domain * If the certificate contains an RFC 822 address, the domain part is
part is defined to be the RFC 822 address component on the right- defined to be the RFC 822 address component on the right-hand side
hand side of the '@' symbol. of the '@' symbol.
For example, a domain signing authority acting on behalf of John Doe of For example, a domain signing authority acting on behalf of John Doe
the Acme corporation, whose distinguished name is 'cn=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 ou=marketing,o=acme,c=us' and whose e-mail address is
John.Doe@marketing.acme.com, could have a certificate containing a John.Doe@marketing.acme.com, could have a certificate containing a
distinguished name of 'cn=domain-signing-authority,o=acme,c=us' and an distinguished name of
RFC 822 address of 'domain-signing-authority@acme.com'. If John Doe has 'cn=domain-signing-authority,o=acme,c=us' and an RFC 822 address of
an RFC 2247 defined address of 'cn=John Doe,dc=marketing,dc=acme,dc=us' 'domain-signing-authority@acme.com'. If John Doe has an RFC 2247
then an address of 'cn=domain-signing-authority,dc=acme,dc=us' could be defined address of 'cn=John Doe,dc=marketing,dc=acme,dc=us' then an
used to represent the domain signing authority. address of 'cn=domain-signing-authority,dc=acme,dc=us' could be used
to represent the domain signing authority.
When the X.500 distinguished subject name has consecutive organisational When the X.500 distinguished subject name has consecutive
units and/or localities it is important to understand the ordering of organizational units and/or localities it is important to understand
these values in order to determine if the domain part of the domain the ordering of these values in order to determine if the domain part
signature is an ascendant. In this case, when parsing the distinguished of the domain signature is an ascendant. In this case, when parsing
subject name from the most significant component (i.e. country, locality the distinguished subject name from the most significant component
or organisation) the parsed organisational unit or locality is deemed to (i.e., country, locality or organization) the parsed organizational
be the ascendant of consecutive (unparsed) organisational units or unit or locality is deemed to be the ascendant of consecutive
localities. (unparsed) organizational units or localities.
When parsing an RFC 2247 subject name from the most significant When parsing an RFC 2247 subject name from the most significant
component (i.e. the 'dc' entry that represents the country, locality or component (i.e., the 'dc' entry that represents the country, locality
organisation) the parsed 'dc' entry is deemed to be the ascendant of or organization) the parsed 'dc' entry is deemed to be the ascendant
consecutive (unparsed) 'dc' entries. of consecutive (unparsed) 'dc' entries.
For example, a domain signing authority acting on behalf of John Doe of For example, a domain signing authority acting on behalf of John Doe
the Acme corporation, whose distinguished name is 'cn=John Doe, of the Acme corporation, whose distinguished name is 'cn=John Doe,
ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is
John.Doe@marketing.defence.acme.com, could have a certificate containing John.Doe@marketing.defence.acme.com, could have a certificate
a distinguished name of 'cn=domain-signing-authority,ou=defence,o=acme, containing a distinguished name of 'cn=domain-signing-
c=us' and an RFC 822 address of authority,ou=defence,o=acme,c=us' and an RFC 822 address of 'domain-
'domain-signing-authority@defence.acme.com'. If John Doe has an RFC 2247 signing-authority@defence.acme.com'. If John Doe has an RFC 2247
defined address of 'cn=John Doe,dc=marketing,dc=defense,dc=acme,dc=us' defined address of 'cn=John
then the domain signing authority could have a distinguished name of Doe,dc=marketing,dc=defense,dc=acme,dc=us' then the domain signing
'cn=domain-signing-authority,dc=defence,dc=acme,dc=us'. authority could have a distinguished name of 'cn=domain-signing-
authority,dc=defence,dc=acme,dc=us'.
Any message received where the domain part of the domain signing agent's Any message received where the domain part of the domain signing
name does not match, or is not an ascendant of, the originator's domain agent's name does not match, or is not an ascendant of, the
name MUST be flagged. originator's domain name MUST be flagged.
This naming rule prevents agents from one organisation masquerading as This naming rule prevents agents from one organization masquerading
domain signing authorities on behalf of another. For the other types of as domain signing authorities on behalf of another. For the other
signature defined in this document, no such named mapping rule is types of signature defined in this document, no such named mapping
defined. rule is defined.
Implementations conforming to this standard MUST support this name Implementations conforming to this standard MUST support this name
mapping convention as a minimum. Implementations MAY choose to mapping convention as a minimum. Implementations MAY choose to
supplement this convention with other locally defined conventions. supplement this convention with other locally defined conventions.
However, these MUST be agreed between sender and recipient domains prior However, these MUST be agreed between sender and recipient domains
to secure exchange of messages. prior to secure exchange of messages.
On verifying the signature, a receiving agent MUST ensure that the On verifying the signature, a receiving agent MUST ensure that the
naming convention has been adhered to. Any message that violates the naming convention has been adhered to. Any message that violates the
convention MUST be flagged. convention MUST be flagged.
3.1.2 Signature Type Attribute 3.1.2 Signature Type Attribute
An S/MIME signed attribute is used to indicate the type of signature. An S/MIME signed attribute is used to indicate the type of signature.
This should be used in conjunction with the naming conventions specified This should be used in conjunction with the naming conventions
in the previous section. When an S/MIME signed message containing the specified in the previous section. When an S/MIME signed message
signature type attribute is received it triggers the software to verify containing the signature type attribute is received it triggers the
that the correct naming convention has been used. software to verify that the correct naming convention has been used.
The ASN.1 [4] notation of this attribute is: - The ASN.1 [4] notation of this attribute is: -
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
id-sti OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) id-sti OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 9 } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 9 }
-- signature type identifier
If present, the SignatureType attribute MUST be a signed attribute, as -- signature type identifier
defined in [5]. If the SignatureType attribute is absent and there are
no further encapsulated signatures the recipient SHOULD assume that the
signature is that of the message originator.
All of the signatures defined here are generated and processed as If present, the SignatureType attribute MUST be a signed attribute,
described in [5]. They are distinguished by the presence of the as defined in [5]. If the SignatureType attribute is absent and
following values in the SignatureType signed attribute: there are no further encapsulated signatures the recipient SHOULD
assume that the signature is that of the message originator.
id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 } All of the signatures defined here are generated and processed as
-- domain signature. described in [5]. They are distinguished by the presence of the
following values in the SignatureType signed attribute:
id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 } id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
-- additional attributes signature. -- domain signature.
id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 } id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
-- review signature. -- additional attributes signature.
For completeness, an attribute type is also specified for an originator id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
signature. However, this signature type is optional. It is defined as -- review signature.
follows:
id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 } For completeness, an attribute type is also specified for an
-- originator's signature. originator signature. However, this signature type is optional. It
is defined as follows:
All signature types, except the originator type, MUST encapsulate other id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
signatures. Note a DOMSEC defined signature could be encapsulating an -- originator's signature.
empty signature as defined in section 3.
A SignerInfo MUST NOT include multiple instances of SignatureType. A All signature types, except the originator type, MUST encapsulate
signed attribute representing a SignatureType MAY include multiple other signatures. Note a DOMSEC defined signature could be
instances of different SignatureType values as an AttributeValue of encapsulating an empty signature as defined in section 3.
attrValues [5], as long as the SignatureType 'additional attributes' is
not present.
If there is more than one SignerInfo in a signerInfos (i.e. when A SignerInfo MUST NOT include multiple instances of SignatureType. A
different algorithms are used) then the SignatureType attribute in all signed attribute representing a SignatureType MAY include multiple
the SignerInfos MUST contain the same content. instances of different SignatureType values as an AttributeValue of
attrValues [5], as long as the SignatureType 'additional attributes'
is not present.
The following sections describe the conditions under which each of these If there is more than one SignerInfo in a signerInfos (i.e., when
types of signature may be generated, and how they are processed. different algorithms are used) then the SignatureType attribute in
all the SignerInfos MUST contain the same content.
The following sections describe the conditions under which each of
these types of signature may be generated, and how they are
processed.
3.2 Domain Signature Generation and Verification 3.2 Domain Signature Generation and Verification
A 'domain signature' is a proxy signature generated on a user's behalf A 'domain signature' is a proxy signature generated on a user's
in the user's domain. The signature MUST adhere to the naming behalf in the user's domain. The signature MUST adhere to the naming
conventions in 3.1.1, including the name mapping convention. A 'domain conventions in 3.1.1, including the name mapping convention. A
signature' on a message authenticates the fact that the message has 'domain signature' on a message authenticates the fact that the
been released from that domain. Before signing, a process generating a message has been released from that domain. Before signing, a
'domain signature' MUST first satisfy itself of the authenticity of the process generating a 'domain signature' MUST first satisfy itself of
message originator. This is achieved by one of two methods. Either the the authenticity of the message originator. This is achieved by one
'originator's signature' is checked, if S/MIME signatures are used of two methods. Either the 'originator's signature' is checked, if
inside a domain. Or if not, some mechanism external to S/MIME is used, S/MIME signatures are used inside a domain. Or if not, some
such as the physical address of the originating client or an mechanism external to S/MIME is used, such as the physical address of
authenticated IP link. 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
above methods and all other signatures present are valid, including the above methods and all other signatures present are valid,
those that have been encrypted, a 'domain signature' can be added to a including those that have been encrypted, a 'domain signature' can be
message. added to a message.
If a 'domain signature' is added and the message is received by a Mail If a 'domain signature' is added and the message is received by a
List Agent (MLA) there is a possibility that the 'domain signature' Mail List Agent (MLA) there is a possibility that the 'domain
will be removed. To stop the 'domain signature' from being removed the signature' will be removed. To stop the 'domain signature' from
steps in section 5 MUST be followed. being removed the steps in section 5 MUST be followed.
An entity generating a domain signature MUST do so using a certificate An entity generating a domain signature MUST do so using a
containing a subject name that follows the naming convention specified certificate containing a subject name that follows the naming
in 3.1.1. convention specified in 3.1.1.
If the originator's authenticity is not successfully verified or all If the originator's authenticity is not successfully verified or all
the signatures present are not valid, a 'domain signature' MUST NOT be the signatures present are not valid, a 'domain signature' MUST NOT
generated. be generated.
On reception, the 'domain signature' SHOULD be used to verify the 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 authenticity of a message. A check MUST be made to ensure that both
naming convention and the name mapping convention have been used as the naming convention and the name mapping convention have been used
specified in this standard. as specified in this standard.
A recipient can assume that successful verification of the domain A recipient can assume that successful verification of the domain
signature also authenticates the message originator. signature also authenticates the message originator.
If there is an originator signature present, the name in that If there is an originator signature present, the name in that
certificate SHOULD be used to identify the originator. This information certificate SHOULD be used to identify the originator. This
can then be displayed to the recipient. information can then be displayed to the recipient.
If there is no originator signature present, the only assumption that If there is no originator signature present, the only assumption that
can be made is the domain the message originated from. can be made is the domain the message originated from.
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
encapsulates. Therefore, it is not necessary to verify these signatures it encapsulates. Therefore, it is not necessary to verify these
before treating the message as authentic. However, this standard does signatures before treating the message as authentic. However, this
not preclude a recipient from attempting to verify any other signatures standard does not preclude a recipient from attempting to verify any
that are present. other signatures that are present.
The 'domain signature' is indicated by the presence of the value The 'domain signature' is indicated by the presence of the value id-
id-sti-domainSig in a 'signature type' signed attribute. sti-domainSig in a 'signature type' signed attribute.
There MAY be one or more 'domain signature' signatures in an S/MIME There MAY be one or more 'domain signature' signatures in an S/MIME
encoding. encoding.
3.3 Additional Attributes Signature Generation and Verification 3.3 Additional Attributes Signature Generation and Verification
The 'additional attributes' signature type indicates that the The 'additional attributes' signature type indicates that the
SignerInfo contains additional attributes that are associated with the SignerInfo contains additional attributes that are associated with
message. 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
bound to the message. A recipient MUST NOT assume that its successful authentically bound to the message. A recipient MUST NOT assume that
verification also authenticates the message originator. its successful verification also authenticates the message
originator.
An entity generating an 'additional attributes' signature MUST do so An entity generating an 'additional attributes' signature MUST do so
using a certificate containing a subject name that follows the naming using a certificate containing a subject name that follows the naming
convention specified in 3.1.1. On reception, a check MUST be made to convention specified in 3.1.1. On reception, a check MUST be made to
ensure that the naming convention has been used. ensure that the naming convention has been used.
A signer MAY include any of the attributes listed in [3] or in this A signer MAY include any of the attributes listed in [3] or in this
document when generating an 'additional attributes' signature. The document when generating an 'additional attributes' signature. The
following attributes have a special meaning, when present in an following attributes have a special meaning, when present in an
'additional attributes' signature: '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
equivalent to the security label contained in an encapsulated as 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
of the inner message content plus any encapsulated signedData and sensitivity of the inner message content plus any encapsulated
envelopedData containers. The label on the original data is indicated signedData and envelopedData containers. The label on the
by the value in the originator's signature, if present. original data is indicated 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
value id-sti-addAttribSig in a 'signature type' signed the value id-sti-addAttribSig in a 'signature type' signed attribute.
attribute. Other Object Identifiers MUST NOT be included in the sequence Other Object Identifiers MUST NOT be included in the sequence of OIDs
of OIDs if this value is present. if this value is present.
There MAY be multiple 'additional attributes' signatures in an S/MIME There MAY be multiple 'additional attributes' signatures in an S/MIME
encoding. encoding.
3.4 Review Signature Generation and Verification 3.4 Review Signature Generation and Verification
The review signature indicates that the signer has reviewed the message. The review signature indicates that the signer has reviewed the
Successful verification of a review signature means only that the signer message. Successful verification of a review signature means only
has approved the message for onward transmission to the recipient(s). that the signer has approved the message for onward transmission to
When the recipient is in another domain, a device on a domain boundary the recipient(s). When the recipient is in another domain, a device
such as a Mail Guard or firewall may be configured to check review on a domain boundary such as a Mail Guard or firewall may be
signatures. A recipient MUST NOT assume that its successful verification configured to check review signatures. A recipient MUST NOT assume
also authenticates the message originator. that its successful verification also authenticates the message
originator.
An entity generating a signed review signature MUST do so using a An entity generating a signed review signature MUST do so using a
certificate containing a subject name that follows the naming convention certificate containing a subject name that follows the naming
specified in 3.1.1. On reception, a check MUST be made to ensure that convention specified in 3.1.1. On reception, a check MUST be made to
the naming convention has been used. ensure that the naming convention has been used.
A review signature is indicated by the presence of the value A review signature is indicated by the presence of the value id-sti-
id-sti-reviewSig in a 'signature type' signed attribute. reviewSig in a 'signature type' signed attribute.
There MAY be multiple review signatures in an S/MIME encoding. There MAY be multiple review signatures in an S/MIME encoding.
3.5 Originator Signature 3.5 Originator Signature
The 'originator signature' is used to indicate that the signer is the The 'originator signature' is used to indicate that the signer is the
originator of the message and its contents. It is included in this originator of the message and its contents. It is included in this
document for completeness only. An originator signature is indicated document for completeness only. An originator signature is indicated
either by the absence of the signature type attribute, or by the either by the absence of the signature type attribute, or by the
presence of the value id-sti-originatorSig in a 'signature type' presence of the value id-sti-originatorSig in a 'signature type'
signed attribute. signed attribute.
4. Encryption and Decryption 4. Encryption and Decryption
Message encryption may be performed by a third party on behalf of a set Message encryption may be performed by a third party on behalf of a
of originators in a domain. This is referred to as domain encryption. set of originators in a domain. This is referred to as domain
Message decryption may be performed by a third party on behalf of a set encryption. Message decryption may be performed by a third party on
of recipients in a domain. This is referred to as domain decryption. behalf of a set of recipients in a domain. This is referred to as
The third party that performs these processes is referred to in this domain decryption. The third party that performs these processes is
section as a "Domain Confidentiality Authority" (DCA). Both of these referred to in this section as a "Domain Confidentiality Authority"
processes are described in this section. (DCA). Both of these processes are described in this section.
Messages may be encrypted for decryption by the final recipient and/or Messages may be encrypted for decryption by the final recipient
by a DCA in the recipient's domain. The message may also be encrypted and/or by a DCA in the recipient's domain. The message may also be
for decryption by a DCA in the originator's domain (e.g. for content encrypted for decryption by a DCA in the originator's domain (e.g.,
analysis, audit, key word scanning, etc.). The choice of which of these for content analysis, audit, key word scanning, etc.). The choice of
is actually performed is a system specific issue that depends on system which of these is actually performed is a system specific issue that
security policy. It is therefore outside the scope of this document. depends on system security policy. It is therefore outside the scope
These processes of encryption and decryption processes are shown in the of this document. These processes of encryption and decryption
following table. processes are shown in the following table.
-------------------------------------------------------------------- --------------------------------------------------------------------
| | Recipient Decryption | Domain Decryption | | | Recipient Decryption | Domain Decryption |
|------------------------|----------------------|--------------------| |------------------------|----------------------|--------------------|
| Originator Encryption | Case(a) | Case(b) | | Originator Encryption | Case(a) | Case(b) |
| Domain Encryption | Case(c) | Case(d) | | Domain Encryption | Case(c) | 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
final recipient(s), is described in CMS [5]. In cases (c) and (d), the final recipient(s), is described in CMS [5]. In cases (c) and
encryption is performed not by the originator but by the DCA in the (d), encryption is performed not by the originator but by the DCA in
originator's domain. In Cases (b) and (d), decryption is performed not the originator's domain. In cases (b) and (d), decryption is
by the recipient(s) but by the DCA in the recipient's domain. performed not by the recipient(s) but by the DCA in the recipient's
domain.
A client implementation that conforms to this standard MUST support A client implementation that conforms to this standard MUST support
case (b) for transmission, case (c) for reception and case (a) for case (b) for transmission, case (c) for reception and case (a) for
transmission and reception. transmission and reception.
A DCA implementation that conforms to this standard MUST support cases A DCA implementation that conforms to this standard MUST support
(c) and (d), for transmission, and cases (b) and (d) for reception. In cases (c) and (d), for transmission, and cases (b) and (d) for
cases (c) and (d) the 'domain signature' SHOULD be applied before the reception. In cases (c) and (d) the 'domain signature' SHOULD be
encryption. In cases (b) and (d) the message SHOULD be decrypted before applied before the encryption. In cases (b) and (d) the message
the originators 'domain signature' is obtained and verified. SHOULD be decrypted before the originators 'domain signature' is
obtained and verified.
The process of encryption and decryption is documented in CMS [5]. The The process of encryption and decryption is documented in CMS [5].
only additional requirement introduced by domain encryption and The 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. As with signatures, a naming described in the following subsections. As with signatures, a naming
convention and name mapping convention are used to locate the correct convention and name mapping convention are used to locate the correct
public key. public key.
The mechanisms described below are applicable both to key agreement and The mechanisms described below are applicable both to key agreement
key transport systems, as documented in CMS [5]. The phrase 'encryption and key transport systems, as documented in CMS [5]. The phrase
key' is used as a collective term to cover the key management keys used 'encryption key' is used as a collective term to cover the key
by both techniques. management keys used by both techniques.
The mechanisms below are also applicable to individual roving users who The mechanisms below are also applicable to individual roving users
wish to encrypt messages that are sent back to base. who wish to encrypt messages that are sent back to base.
4.1 Domain Confidentiality Naming Conventions 4.1 Domain Confidentiality Naming Conventions
A DCA MUST be named 'domain-confidentiality-authority'. This name MUST A DCA MUST be named 'domain-confidentiality-authority'. This name
appear in the 'common name(CN)' component of the subject field in the MUST appear in the 'common name(CN)' component of the subject field
X.509 certificate. Additionally, if the certificate contains an RFC 822 in the X.509 certificate. Additionally, if the certificate contains
address, this name MUST appear in the end entity part of the address, an RFC 822 address, this name MUST appear in the end entity part of
i.e. on the left-hand side of the '@' symbol. the address, i.e., on the left-hand side of the '@' symbol.
Along with this naming convention, an additional naming rule is defined: Along with this naming convention, an additional naming rule is
the 'name mapping rule'. The name mapping rule states that for a DCA, defined: the 'name mapping rule'. The name mapping rule states that
the domain part of its name MUST be the same as, or an ascendant of (as for a DCA, the domain part of its name MUST be the same as, or an
defined in section 3.1.1), the domain name of the set of entities that ascendant of (as defined in section 3.1.1), the domain name of the
it represents. The domain part is defined as follows: set of entities that it represents. The domain part is defined as
follows:
* In the case of an X.500 distinguished name of an X.509 certificate, * In the case of an X.500 distinguished name of an X.509
the domain part is the country, organisation, organisational certificate, the domain part is the country, organization,
unit, state, and locality components of the distinguished name. organizational unit, state, and locality components of the
distinguished name.
* In the case of an RFC 2247 distinguished name, the domain part * In the case of an RFC 2247 distinguished name, the domain part is
is the domain components of the distinguished name. the domain components of the distinguished name.
* If the certificate contains an RFC 822 address, the domain part is * If the certificate contains an RFC 822 address, the domain part is
defined to be the RFC 822 address part on the right-hand side of the defined to be the RFC 822 address part on the right-hand side of
'@' symbol. the '@' symbol.
For example, a DCA acting on behalf of John Doe of the Acme For example, a DCA acting on behalf of John Doe of the Acme
corporation, whose distinguished name is 'cn=John Doe, ou=marketing, 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, o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com,
could have a certificate containing a distinguished name of could have a certificate containing a distinguished name of
'cn=domain-confidentiality-authority,o=acme,c=us' and an e-mail 'cn=domain-confidentiality-authority,o=acme,c=us' and an e-mail
address of 'domain-confidentiality-authority@acme.com'. If John Doe address of 'domain-confidentiality-authority@acme.com'. If John Doe
has an RFC 2247 defined address of 'cn=John Doe,dc=marketing, has an RFC 2247 defined address of 'cn=John Doe,dc=marketing,
dc=defense,dc=acme,dc=us' then the domain signing authority could have dc=defense,dc=acme,dc=us' then the domain signing authority could
a distinguished name of 'cn=domain-signing-authority,dc=defence,dc=acme, have a distinguished name of
dc=us'. The key associated with this certificate would be used for 'cn=domain-signing-authority,dc=defence,dc=acme,dc=us'. The key
encrypting messages for John Doe. associated with this certificate would be used for encrypting
messages for John Doe.
Any message received where the domain part of the domain encrypting Any message received where the domain part of the domain encrypting
agents name does not match, or is not an ascendant of, the domain name agents name does not match, or is not an ascendant of, the domain
of the entities it represents MUST be flagged. name of the entities it represents MUST be flagged.
This naming rule prevents messages being encrypted for the wrong domain This naming rule prevents messages being encrypted for the wrong
decryption agent. domain decryption agent.
Implementations conforming to this standard MUST support this name Implementations conforming to this standard MUST support this name
mapping convention as a minimum. Implementations may choose to mapping convention as a minimum. Implementations may choose to
supplement this convention with other locally defined conventions. supplement this convention with other locally defined conventions.
However, these MUST be agreed between sender and recipient domains However, these MUST be agreed between sender and recipient domains
prior to sending any messages. prior to sending any messages.
4.2 Key Management for DCA Encryption 4.2 Key Management for DCA Encryption
At the sender's domain, DCA encryption is achieved using the recipient At the sender's domain, DCA encryption is achieved using the
DCA's certificate or the end recipient's certificate. For this, the recipient DCA's certificate or the end recipient's certificate. For
encrypting process must be able to correctly locate the certificate for this, the encrypting process must be able to correctly locate the
the corresponding DCA in the recipient's domain or the one corresponding certificate for the corresponding DCA in the recipient's domain or
to the end recipient. Having located the correct certificate, the the one corresponding to the end recipient. Having located the
encryption process is then performed and additional information required correct certificate, the encryption process is then performed and
for decryption is conveyed to the recipient in the recipientInfo field additional information required for decryption is conveyed to the
as specified in CMS [5]. A DCA encryption agent MUST be named according recipient in the recipientInfo field as specified in CMS [5]. A DCA
to the naming convention specified in section 4.1. This is so that the encryption agent MUST be named according to the naming convention
corresponding certificate can be found. specified in section 4.1. This is so that the corresponding
certificate can be found.
No specific method for locating the certificate to the corresponding No specific method for locating the certificate to the corresponding
DCA in the recipient's domain or the one corresponding to the end DCA in the recipient's domain or the one corresponding to the end
recipient is mandated in this document. An implementation may choose recipient is mandated in this document. An implementation may choose
to access a local certificate store to locate the correct certificate. to access a local certificate store to locate the correct
Alternatively, a X.500 or LDAP directory may be used in one of the certificate. Alternatively, a X.500 or LDAP directory may be used in
following ways: one of the following ways:
1. The directory may store the DCA certificate in the recipient's 1. The directory may store the DCA certificate in the recipient's
directory entry. When the user certificate attribute is requested, directory entry. When the user certificate attribute is
this certificate is returned. requested, this certificate is returned.
2. The encrypting agent maps the recipient's name to the DCA name in the 2. The encrypting agent maps the recipient's name to the DCA name in
manner specified in 4.1. The user certificate attribute associated the manner specified in 4.1. The user certificate attribute
with this directory entry is then obtained. associated with this directory entry is then obtained.
This document does not mandate either of these processes. Whichever one This document does not mandate either of these processes. Whichever
is used, the name mapping conventions must be adhered to, in order to one is used, the name mapping conventions must be adhered to, in
maintain confidentiality. order to maintain confidentiality.
Having located the correct certificate, the encryption process is then Having located the correct certificate, the encryption process is
performed. A recipientInfo for the DCA or end recipient is then then performed. A recipientInfo for the DCA or end recipient is then
generated, as described in CMS [5]. generated, as described in CMS [5].
DCA encryption may be performed for decryption by the end recipient DCA encryption may be performed for decryption by the end recipient
and/or by a DCA. End recipient decryption is described in CMS [5]. DCA and/or by a DCA. End recipient decryption is described in CMS [5].
decryption is described in section 4.3. DCA decryption is described in section 4.3.
4.3 Key Management for DCA Decryption 4.3 Key Management for DCA Decryption
DCA decryption uses a private-key belonging to the DCA and the necessary DCA decryption uses a private-key belonging to the DCA and the
information conveyed in the DCA's recipientInfo field. necessary information conveyed in the DCA's recipientInfo field.
It should be noted that domain decryption can be performed on messages It should be noted that domain decryption can be performed on
encrypted by the originator and/or by a DCA in the originator's domain. messages encrypted by the originator and/or by a DCA in the
In the first case, the encryption process is described in CMS [5]; in originator's domain. In the first case, the encryption process is
the second case, the encryption process is described in 4.2. described in CMS [5]; in the second case, the encryption process is
described in 4.2.
5. Applying a Domain Signature when Mail List Agents are Present. 5. Applying a Domain Signature when Mail List Agents are Present.
It is possible that a message leaving a DOMSEC domain may encounter a It is possible that a message leaving a DOMSEC domain may encounter a
Mail List Agent (MLA) before it reaches the final recipient. There is a Mail List Agent (MLA) before it reaches the final recipient. There
possibility that this would result in the 'domain signature' being is a possibility that this would result in the 'domain signature'
stripped off the message. We do not want a MLA to remove the 'domain being stripped off the message. We do not want a MLA to remove the
signature'. Therefore, the 'domain signature' must be applied to the 'domain signature'. Therefore, the 'domain signature' must be
message in such a way that will prevent a MLA from removing it. applied to the message in such a way that will prevent a MLA from
removing it.
A MLA will search a message for the "outer" signedData layer, as defined A MLA will search a message for the "outer" signedData layer, as
in ESS [3] section 4.2, and strip off all signedData layers that defined in ESS [3] section 4.2, and strip off all signedData layers
encapsulate this "outer" signedData layer. Where this "outer" signedData that encapsulate this "outer" signedData layer. Where this "outer"
layer is found will depend on whether the message contains a signedData layer is found will depend on whether the message contains
mlExpansionHistory attribute or an envelopedData layer. a mlExpansionHistory attribute or an envelopedData layer.
There is a possibility that a message leaving a DOMSEC domain has There is a possibility that a message leaving a DOMSEC domain has
already been processed by a MLA, in which case a 'mlExpansionHistory' already been processed by a MLA, in which case a 'mlExpansionHistory'
attribute will be present within the message. attribute will be present within the message.
There is a possibility that the message will contain an envelopedData There is a possibility that the message will contain an envelopedData
layer. This will be the case when the message has been encrypted within layer. This will be the case when the message has been encrypted
the domain for the domain's "Domain Confidentiality Authority", see within the domain for the domain's "Domain Confidentiality
section 4.0, and, possibly, the final recipient. Authority", see section 4.0, and, possibly, the final recipient.
How the 'domain signature' is applied will depend on what is already How the 'domain signature' is applied will depend on what is already
present within the message. Before the 'domain signature' can be present within the message. Before the 'domain signature' can be
applied the message MUST be searched for the "outer" signedData layer, applied the message MUST be searched for the "outer" signedData
this search is complete when one of the following is found: - layer, this search is complete when one of the following is found: -
- The "outer" signedData layer that includes an mlExpansionHistory - The "outer" signedData layer that includes an
attribute or encapsulates an envelopedData object. mlExpansionHistory attribute or encapsulates an envelopedData
- An envelopedData layer. object.
- The original content (that is, a layer that is neither - An envelopedData layer.
envelopedData nor signedData. - The original content (that is, a layer that is neither
envelopedData nor signedData).
If a signedData layer containing a mlExpansionHistory attribute has If a signedData layer containing a mlExpansionHistory attribute has
been found then: - been found then: -
1) Strip off the signedData layer (after remembering the included 1) Strip off the signedData layer (after remembering the included
signedAttributes). signedAttributes).
2) Search the rest of the message until an envelopedData layer or 2) Search the rest of the message until an envelopedData layer or
the original content is found. the original content is found.
3) a) If an envelopedData layer has been found then: - 3) a) If an envelopedData layer has been found then: -
- Strip off all the signedData layers down to the envelopedData - Strip off all the signedData layers down to the
layer. envelopedData layer.
- Locate the RecipientInfo for the local DCA and use the - Locate the RecipientInfo for the local DCA and use the
information it contains to obtain the message key. information it contains to obtain the message key.
- Decrypt the encryptedContent using the message key. - Decrypt the encryptedContent using the message key.
- Encapsulate the decrypted message with a 'domain - Encapsulate the decrypted message with a 'domain
signature' signature'
- If local policy requires the message to be encrypted using - If local policy requires the message to be encrypted
S/MIME encryption before leaving the domain then encapsulate using S/MIME encryption before leaving the domain then
the 'domain signature' with an envelopedData layer containing encapsulate the 'domain signature' with an envelopedData
RecipientInfo structures for each of the recipients and an layer containing RecipientInfo structures for each of the
originatorInfo value built from information describing this recipients and an originatorInfo value built from
DCA. information describing this DCA.
If local policy does not require the message to be encrypted If local policy does not require the message to be
using S/MIME encryption but there is an envelopedData at a encrypted using S/MIME encryption but there is an
lower level within the message then the 'domain signature' envelopedData at a lower level within the message then
MUST be encapsulated by an envelopedData as described above. the 'domain signature' MUST be encapsulated by an
envelopedData as described above.
An example when it may not be local policy to require S/MIME An example when it may not be local policy to require
encryption is when there is a link crypto present. S/MIME encryption is when there is a link crypto present.
b) If an envelopedData layer has not been found then: - b) If an envelopedData layer has not been found then: -
- Encapsulate the new message with a 'domain signature'. - Encapsulate the new message with a 'domain signature'.
4) Encapsulate the new message in a signedData layer, adding the 4) Encapsulate the new message in a signedData layer, adding the
signedAttributes from the signedData layer that contained the signedAttributes from the signedData layer that contained the
mlExpansionHistory attribute. mlExpansionHistory attribute.
If no signedData layer containing a mlExpansionHistory attribute has If no signedData layer containing a mlExpansionHistory attribute has
been found but an envelopedData has been found then: - been found but an envelopedData has been found then: -
1) Strip off all the signedData layers down to the envelopedData 1) Strip off all the signedData layers down to the envelopedData
layer. layer.
2) Locate the RecipientInfo for the local DCA and use the information 2) Locate the RecipientInfo for the local DCA and use the
it contains to obtain the message key. information it contains to obtain the message key.
3) Decrypt the encryptedContent using the message key. 3) Decrypt the encryptedContent using the message key.
4) Encapsulate the decrypted message with a 'domain signature' 4) Encapsulate the decrypted message with a 'domain signature'
5) If local policy requires the message to be encrypted before 5) If local policy requires the message to be encrypted before
leaving the domain then encapsulate the 'domain signature' with an leaving the domain then encapsulate the 'domain signature' with
envelopedData layer containing RecipientInfo structures for each an envelopedData layer containing RecipientInfo structures for
of the recipients and an originatorInfo value built from each of the recipients and an originatorInfo value built from
information describing this DCA. information describing this DCA.
If local policy does not require the message to be encrypted using If local policy does not require the message to be encrypted
S/MIME encryption but there is an envelopedData at a lower level using S/MIME encryption but there is an envelopedData at a
within the message then the 'domain signature' MUST be lower level within the message then the 'domain signature' MUST
encapsulated by an envelopedData as described above. be encapsulated by an envelopedData as described above.
If no signedData layer containing a mlExpansionHistory attribute has If no signedData layer containing a mlExpansionHistory attribute has
been found and no envelopedData has been found then: - been found and no envelopedData has been found then: -
1) Encapsulate the message in a 'domain signature'. 1) Encapsulate the message in a 'domain signature'.
5.1 Examples of Rule Processing 5.1 Examples of Rule Processing
The following examples help explain the above rules. All of the signedData The following examples help explain the above rules. All of the
objects are valid and none of them are a domain signature. If a signedData signedData objects are valid and none of them are a domain signature.
object was a domain signature then it would not be necessary to validate any If a signedData object was a domain signature then it would not be
further signedData objects. necessary to validate any further signedData objects.
1) A message (S1 (Original Content)) (where S = signedData) in which the 1) A message (S1 (Original Content)) (where S = signedData) in which
signedData does not include an mlExpansionHistory attribute is to the signedData does not include an mlExpansionHistory attribute is
have a 'domain signature' applied. The signedData, S1, is verified. to have a 'domain signature' applied. The signedData, S1, is
No "outer" signedData is found, after searching for one as defined verified. No "outer" signedData is found, after searching for one
above, since the original content is found, nor is an envelopedData as defined above, since the original content is found, nor is an
or a mlExpansionHistory attribute found. A new signedData layer, S2, envelopedData or a mlExpansionHistory attribute found. A new
is created that contains a 'domain signature', resulting in the signedData layer, S2, is created that contains a 'domain
following message sent out of the domain (S2 (S1 (Original Content))). signature', resulting in the following message sent out of the
domain (S2 (S1 (Original Content))).
2) A message (S3 (S2 (S1 (Original Content))) in which none of the 2) A message (S3 (S2 (S1 (Original Content))) in which none of the
signedData layers includes an mlExpansionHistory attribute is to have signedData layers includes an mlExpansionHistory attribute is to
a 'domain signature' applied. The signedData objects S1, S2 and S3 have a 'domain signature' applied. The signedData objects S1, S2
are verified. There is not an original, "outer" signedData layer and S3 are verified. There is not an original, "outer" signedData
since the original content is found, nor is an envelopedData or a layer since the original content is found, nor is an envelopedData
mlExpansionHistory attribute found. A new signedData layer, S4, is or a mlExpansionHistory attribute found. A new signedData layer,
created that contains a 'domain signature', resulting in the S4, is created that contains a 'domain signature', resulting in
following message sent out of the domain (S4 (S3 (S2 (S1 (Original the following message sent out of the domain (S4 (S3 (S2 (S1
Content))). (Original Content))).
3) A message (E1 (S1 (Original Content))) (where E = envelopedData) in 3) A message (E1 (S1 (Original Content))) (where E = envelopedData)
which S1 does not include a mlExpansionHistory attribute is to have in which S1 does not include a mlExpansionHistory attribute is to
a 'domain signature' applied. There is not an original, received have a 'domain signature' applied. There is not an original,
"outer" signedData layer since the envelopedData, E1, is found at the received "outer" signedData layer since the envelopedData, E1, is
outer layer. The encryptedContent is decrypted. The signedData, S1, found at the outer layer. The encryptedContent is decrypted. The
is verified. The decrypted content is wrapped in a new signedData signedData, S1, is verified. The decrypted content is wrapped in
layer, S2, which contains a 'domain signature'. If local policy a new signedData layer, S2, which contains a 'domain signature'.
requires the message to be encrypted, using S/MIME encryption, before If local policy requires the message to be encrypted, using S/MIME
it leaves the domain then this new message is wrapped in an encryption, before it leaves the domain then this new message is
envelopedData layer, E2, resulting in the following message sent out wrapped in an envelopedData layer, E2, resulting in the following
of the domain (E2 (S2 (S1 (Original Content)))), else the message is message sent out of the domain (E2 (S2 (S1 (Original Content)))),
not wrapped in an envelopedData layer resulting in the following else the message is not wrapped in an envelopedData layer
message (S2 (S1 (Original Content))) being sent. resulting in the following message (S2 (S1 (Original Content)))
being sent.
4) A message (S2 (E1 (S1 (Original Content)))) in which S2 includes a 4) A message (S2 (E1 (S1 (Original Content)))) in which S2 includes a
mlExpansionHistory attribute is to have a 'domain signature' mlExpansionHistory attribute is to have a 'domain signature'
applied. The signedData object S2 is verified. The mlExpansionHistory applied. The signedData object S2 is verified. The
attribute is found in S2, so S2 is the "outer" signedData. The signed mlExpansionHistory attribute is found in S2, so S2 is the "outer"
attributes in S2 are remembered for later inclusion in the new outer signedData. The signed attributes in S2 are remembered for later
signedData that is applied to the message. S2 is stripped off and the inclusion in the new outer signedData that is applied to the
message is decrypted. The signedData object S1 is verified. The message. S2 is stripped off and the message is decrypted. The
decrypted message is wrapped in a signedData layer, S3, which signedData object S1 is verified. The decrypted message is
contains a 'domain signature'. If local policy requires the message wrapped in a signedData layer, S3, which contains a 'domain
to be encrypted, using S/MIME encryption, before it leaves the signature'. If local policy requires the message to be encrypted,
domain then this new message is wrapped in an envelopedData layer, using S/MIME encryption, before it leaves the domain then this new
E2. A new signedData layer, S4, is then wrapped around the message is wrapped in an envelopedData layer, E2. A new
envelopedData, E2, resulting in the following message sent out of signedData layer, S4, is then wrapped around the envelopedData,
the domain (S4 (E2 (S3 (S1 (Original Content))))). If local policy E2, resulting in the following message sent out of the domain (S4
does not require the message to be encrypted, using S/MIME (E2 (S3 (S1 (Original Content))))). If local policy does not
encryption, before it leaves the domain then the message is not require the message to be encrypted, using S/MIME encryption,
wrapped in an envelopedData layer but is wrapped in a new signedData before it leaves the domain then the message is not wrapped in an
layer, S4, resulting in the following message sent out of the domain envelopedData layer but is wrapped in a new signedData layer, S4,
(S4 (S3 (S1 (Original Content). The signedData S4, in both cases, resulting in the following message sent out of the domain (S4 (S3
contains the signed attributes from S2. (S1 (Original Content). The signedData S4, in both cases,
contains the signed attributes from S2.
5) A message (S3 (S2 (E1 (S1 (Original Content))))) in which none of 5) A message (S3 (S2 (E1 (S1 (Original Content))))) in which none of
the signedData layers include a mlExpansionHistory attribute is to the signedData layers include a mlExpansionHistory attribute is to
have a 'domain signature' applied. The signedData objects S3 and S2 have a 'domain signature' applied. The signedData objects S3 and
are verified. When the envelopedData E1 is found the signedData S2 are verified. When the envelopedData E1 is found the
objects S3 and S2 are stripped off. The encryptedContent is signedData objects S3 and S2 are stripped off. The
decrypted. The signedData object S1 is verified. The decrypted encryptedContent is decrypted. The signedData object S1 is
content is wrapped in a new signedData layer, S4, which contains a verified. The decrypted content is wrapped in a new signedData
'domain signature'. If local policy requires the message to be layer, S4, which contains a 'domain signature'. If local policy
encrypted, using S/MIME encryption, before it leaves the domain requires the message to be encrypted, using S/MIME encryption,
then this new message is wrapped in an envelopedData layer, E2, before it leaves the domain then this new message is wrapped in an
resulting in the following message sent out of the domain (E2 (S4 envelopedData layer, E2, resulting in the following message sent
(S1 (Original Content)))), else the message is not wrapped in an out of the domain (E2 (S4 (S1 (Original Content)))), else the
envelopedData layer resulting in the following message (S4 (S1 message is not wrapped in an envelopedData layer resulting in the
(Original Content))) being sent. following message (S4 (S1 (Original Content))) being sent.
6) A message (S3 (S2 (E1 (S1 (Original Content))))) in which S3 6) A message (S3 (S2 (E1 (S1 (Original Content))))) in which S3
includes a mlExpansionHistory attribute is to have a 'domain includes a mlExpansionHistory attribute is to have a 'domain
signature' applied. The signedData objects S3 and S2 are verified. signature' applied. The signedData objects S3 and S2 are
The mlExpansionHistory attribute is found in S3, so S3 is the verified. The mlExpansionHistory attribute is found in S3, so S3
"outer" signedData. The signed attributes in S3 are remembered is the "outer" signedData. The signed attributes in S3 are
for later inclusion in the new outer signedData that is applied to remembered for later inclusion in the new outer signedData that
the message. The signedData object S3 is stripped off. When the is applied to the message. The signedData object S3 is stripped
envelopedData layer, E1, is found the signedData object S2 is off. When the envelopedData layer, E1, is found the signedData
stripped off. The encryptedContent is decrypted. The signedData object S2 is stripped off. The encryptedContent is decrypted.
object S1 is verified. The decrypted content is wrapped in a new The signedData object S1 is verified. The decrypted content is
signedData layer, S4, which contains a 'domain signature'. If local wrapped in a new signedData layer, S4, which contains a 'domain
policy requires the message to be encrypted, using S/MIME encryption, signature'. If local policy requires the message to be encrypted,
before it leaves the domain then this new message is wrapped in an using S/MIME encryption, before it leaves the domain then this new
envelopedData layer, E2. A new signedData layer, S5, is then wrapped message is wrapped in an envelopedData layer, E2. A new
around the envelopedData, E2, resulting in the following message sent signedData layer, S5, is then wrapped around the envelopedData,
out of the domain (S5 (E2 (S4 (S1 (Original Content))))). If local E2, resulting in the following message sent out of the domain (S5
policy does not require the message to be encrypted, using S/MIME (E2 (S4 (S1 (Original Content))))). If local policy does not
encryption, before it leaves the domain then the message is not require the message to be encrypted, using S/MIME encryption,
wrapped in an envelopedData layer but is wrapped in a new signedData before it leaves the domain then the message is not wrapped in an
layer, S5, resulting in the following message sent out of the domain envelopedData layer but is wrapped in a new signedData layer, S5,
(S5 (S4 (S1 (Original Content). The signedData S5, in both cases, resulting in the following message sent out of the domain (S5 (S4
contains the signed attributes from S3. (S1 (Original Content). The signedData S5, in both cases,
contains the signed attributes from S3.
7) A message (S3 (E2 (S2 (E1 (S1 (Original Contnent)))))) in which S3 7) A message (S3 (E2 (S2 (E1 (S1 (Original Content)))))) in which S3
does not include a mlExpansionHistory attribute is to have a does not include a mlExpansionHistory attribute is to have a
'domain signature' applied. The signedData object S3 is verified. 'domain signature' applied. The signedData object S3 is verified.
When the envelopedData E2 is found the signedData object S3 is When the envelopedData E2 is found the signedData object S3 is
stripped off. The encryptedContent is decrypted. The signedData stripped off. The encryptedContent is decrypted. The signedData
object S2 is verified, the envelopedData E1 is decrytped and the object S2 is verified, the envelopedData E1 is decrypted and the
signedData object S1 is verified. The signedData object S2 is signedData object S1 is verified. The signedData object S2 is
wrapped in a new signedData layer S4, which contains a wrapped in a new signedData layer S4, which contains a 'domain
'domain signature'. Since there is an envelopedData E1 lower down signature'. Since there is an envelopedData E1 lower down in the
in the message, the new message is wrapped in an envelopedData message, the new message is wrapped in an envelopedData layer, E3,
layer, E3, resulting in the following message sent out of the domain resulting in the following message sent out of the domain (E3 (S4
(E3 (S4 (S2 (E1 (S1 (Original Content)))))). (S2 (E1 (S1 (Original Content)))))).
6. Security Considerations 6. Security Considerations
This specification relies on the existence of several well known names, This specification relies on the existence of several well known
such as domain-confidentiality-authority. Organisations must take care names, such as domain-confidentiality-authority. Organizations must
with these names, even if they do not support DOMSEC, so that take care with these names, even if they do not support DOMSEC, so
certificates issued in these names are only issued to legitimate that certificates issued in these names are only issued to legitimate
entities. If this is not true then an individual could get a certificate entities. If this is not true then an individual could get a
associated with domain-confidentiality-authority@acme.com and as a certificate associated with domain-confidentiality-authority@acme.com
result might be able to read messages the a DOMSEC client intended for and as a result might be able to read messages the a DOMSEC client
others. intended for others.
Implementations MUST protect all private keys. Compromise of the Implementations MUST protect all private keys. Compromise of the
signer's private key permits masquerade. signer's private key permits masquerade.
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.
Compromise of key material is regarded as an even more serious issue for Compromise of key material is regarded as an even more serious issue
domain security services than for an S/MIME client. This is because for domain security services than for an S/MIME client. This is
compromise of the private key may in turn compromise the security of a because compromise of the private key may in turn compromise the
whole domain. Therefore, great care should be used when considering its security of a whole domain. Therefore, great care should be used
protection. when considering its protection.
Domain encryption alone is not secure and should be used in conjunction Domain encryption alone is not secure and should be used in
with a domain signature to avoid a masquerade attack, where an attacker conjunction with a domain signature to avoid a masquerade attack,
that has obtained a DCA certificate can fake a message to that domain where an attacker that has obtained a DCA certificate can fake a
pretending to be another domain. message to that domain pretending to be another domain.
When an encrypted DOMSEC message is sent to an end user in such a way When an encrypted DOMSEC message is sent to an end user in such a way
that the message is decrypted by the end users DCA the message will be that the message is decrypted by the end users DCA the message will
in plain text and therefore confidentiality could be compromised. be in plain text and therefore confidentiality could be compromised.
If the recipient's DCA is compromised then the recipient can not If the recipient's DCA is compromised then the recipient can not
guarantee the integrity of the message. Furthemore, even if the guarantee the integrity of the message. Furthermore, even if the
recipient's DCA correctly verifies a message's signatures, then a recipient's DCA correctly verifies a message's signatures, then a
message could be undetectably modified, when there are no signatures on message could be undetectably modified, when there are no signatures
a message that the recipient can verify. on a message that the recipient can verify.
7. DOMSEC ASN.1 Module 7. DOMSEC ASN.1 Module
DOMSECSyntax DOMSECSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) } pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
-- The types and values defined in this module are exported for -- The types and values defined in this module are exported for
-- use in the other ASN.1 modules. Other applications may use -- use in the other ASN.1 modules. Other applications may use
-- them for their own purposes. -- them for their own purposes.
skipping to change at line 1002 skipping to change at page 23, line 7
id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 } id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 } id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 } id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 } id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
END -- of DOMSECSyntax END -- of DOMSECSyntax
8. References 8. References
[1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633,
June 1999. June 1999.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, [3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634,
June 1999. June 1999.
[4] International Telecommunications Union, Recommendation X.208, "Open [4] International Telecommunications Union, Recommendation X.208,
systems interconnection: specification of Abstract Syntax Notation "Open systems interconnection: specification of Abstract Syntax
(ASN.1)", CCITT Blue Book, 1989. Notation (ASN.1)", CCITT Blue Book, 1989.
[5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
9. Authors' Addresses 9. Authors' Addresses
Tim Dean Tim Dean
DERA Malvern QinetiQ
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 896660 Fax: +44 (0) 1684 896660
Email: t.dean@eris.dera.gov.uk EMail: tbdean@QinetiQ.com
William Ottaway William Ottaway
DERA Malvern QinetiQ
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 896660 Fax: +44 (0) 1684 896660
Email: w.ottaway@eris.dera.gov.uk EMail: wjottaway@QinetiQ.com
10. Full Copyright Statement 10. Full Copyright Statement
"Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it
assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are included kind, provided that the above copyright notice and this paragraph are
on all such copies and derivative works. However, this document itself included on all such copies and derivative works. However, this
may not be modified in any way, such as by removing the copyright notice document itself may not be modified in any way, such as by removing
or references to the Internet Society or other Internet organizations, the copyright notice or references to the Internet Society or other
except as needed for the purpose of developing Internet standards in Internet organizations, except as needed for the purpose of
which case the procedures for copyrights defined in the Internet developing Internet standards in which case the procedures for
Standards process must be followed, or as required to translate it into copyrights defined in the Internet Standards process must be
languages other than English. followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This draft expires 01 September 2001 Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 177 change blocks. 
810 lines changed or deleted 830 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/