Domain Security Services using S/MIME
RFC 3183
Document | Type | RFC - Experimental (October 2001) Errata | |
---|---|---|---|
Authors | Tim Dean , William Ottaway | ||
Last updated | 2020-01-21 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
IESG | Responsible AD | (None) | |
Send notices to | (None) |
RFC 3183
#x27;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]