INTERNET-DRAFT T Dean draft-ietf-smime-domsec-06.txt W Ottaway Expires 12th January 2001 DERA Domain Security Services using S/MIME Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes how the S/MIME 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'. 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 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 . 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. 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 organisation 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 organisations. Or an organisation 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 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 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 organisation. 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. 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 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 organisational 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). A domain signature is sometimes referred to as an "organisational 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. Organisational 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]. 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 (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. A DOMSEC 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 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 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 'domain signature'. 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 recognise the signature type attribute for signature verification. Implementations conforming to this standard MUST support the signature type attribute for signature generation. 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 component of its name MUST be the same as, or an ascendant of, the domain name of the message originator(s) that it is representing. The domain component is defined as follows: * In the case of an X.500 distinguished subject name of an X.509 certificate, the domain component is the country, organisation, organisational unit, state, and locality components of the distinguished name. * If the certificate contains an RFC 822 address, the domain component 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 a RFC 822 address of 'domain-signing-authority@acme.com'. When the X.500 distinguished subject name has consecutive organisational units and/or localities it is important to understand the ordering of these values in order to determine if the domain component of the domain signature is an ascendant. In this case, when parsing the distinguished subject name from the root (i.e. country, locality or organisation) the parsed organisational unit or locality is deemed to be the ascendant of consecutive (unparsed) organisational units or localities. 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 a RFC 822 address of 'domain-signing-authority@defence.acme.com'. Any message received where the domain component of the domain signing agents name does not match, or is not an ascendant of, the originator's domain name MUST be rejected. This naming rule prevents agents from one organisation masquerading as domain signing authorities on behalf of another. For the other types of signature defined in this document, no such named mapping rule is defined. Implementations conforming to this standard MUST support this name mapping convention as a minimum. Implementations MAY choose to supplement this convention with other locally defined conventions. However, these MUST be agreed between sender and recipient domains prior to secure exchange of messages. On verifying the signature, a receiving agent MUST ensure that the naming convention has been adhered to. Any message that violates the convention should be flagged. 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-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28} If present, the SignatureType attribute MUST be a signed attribute, as defined in [5]. If the SignatureType attribute is absent 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-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 2 } -- domain signature. id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 3} -- additional attributes signature. id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 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-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 1} -- originator's signature. All signature types, except the originator type, MUST encapsulate other signature types specified in this document MUST encapsulate other signatures. Note the domain signature could be encapsulating an empty signature as defined in section 3. 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 originated in 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, a 'domain signature' MAY be added to a message. An entity generating a domain signature MUST do so using a certificate containing a subject name that follows the naming convention specified in 3.1.1. When a 'domain signature' is applied the mlExpansionHistory and eSSSecurityLabel attributes MUST be copied from other signerInfos as stated in [3]. If the originator's authenticity is not successfully verified or all the signatures present are not valid, a 'domain signature' MUST NOT be generated. On reception, the 'domain signature' SHOULD be used to verify the authenticity of a message. A check MUST be made to ensure that both the naming convention and the name mapping convention have been used as specified in this standard. A recipient 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-aa-sigtype-domain-sig 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. 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-aa-sigtype-add-attrib-sig 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-aa-sigtype-review-sig in a 'signature type' signed attribute. There MAY be multiple review signatures in an S/MIME encoding. 3.5 Originator Signature The 'originator signature' is used to indicate that the signer is the originator of the message and its contents. It is included in this document for completeness only. An originator signature is indicated either by the absence of the signature type attribute, or by the presence of the value id-aa-sigtype-originator-sig 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. A DCA implementation that conforms to this standard MUST support cases (c) and (d), for transmission, and cases (b) and (d) for reception. 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 component of the address - 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 component of its name MUST be the same as, or an ascendant of, the domain name of the set of entities that it represents. The domain component is defined as follows: * In the case of an X.500 distinguished name of an X.509 certificate, the domain component is the country, organisation, organisational unit, state, and locality components of the distinguished name. * If the certificate contains an RFC 822 address, the domain component is defined to be the RFC 822 address component on the right-hand side of the '@' symbol. 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'. The key associated with this certificate would be used for encrypting messages for John Doe. Any message received where the domain component 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 rejected. 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 to 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 used on eventual reply to a DCA encrypted message. 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 from the recipient's domain and the necessary information conveyed in the recipientInfo field. The private-key is owned by the DCA for the recipient domain. This is achieved using the naming conventions specified in 4.1. It is vital that these conventions are adhered to, in order to maintain confidentiality. 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. No specific method for locating this certificate is mandated in this document. An implementation may choose to access a local certificate store to locate the correct certificate. Alternatively, a directory may be used in one of the following ways: 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 is then generated, as described in CMS [5]. 5. Security Considerations 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 conjuction with a domain signature to avoid a masquerade attack, where an attacker that has obtain a DCA cert can fake a message to that domain pretending to be another domain. 6. 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-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28} id-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 2 } -- domain signature. id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 3} -- additional attributes signature. id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} -- review signature. id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 1} -- originator's signature. END -- of DOMSECSyntax 7. References [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC2633, 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. 8. Authors' Addresses Tim Dean DERA Malvern St. Andrews Road Malvern Worcs WR14 3PS Phone: +44 (0) 1684 894239 Fax: +44 (0) 1684 896660 Email: t.dean@eris.dera.gov.uk William Ottaway DERA Malvern St. Andrews Road Malvern Worcs WR14 3PS Phone: +44 (0) 1684 894079 Fax: +44 (0) 1684 896660 Email: w.ottaway@eris.dera.gov.uk 8. Full Copyright Statement "Copyright (C) The Internet Society (2000). 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 implmentation 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." This draft expires 12th January 2001