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