therefore, careful consideration should be given to security of these components, to make sure that their siting and configuration minimises the possibility of attack. -throughout this draft the terms may, must, must not and should are used -in capital letters. 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. a domain signature is sometimes referred to as an organisational signature".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 may check the review signature at the domain +signature. an agent could check the review signature at the domain boundary, to ensure that only reviewed messages are released.3 additional attributes signature -a third party may add additional attributes to a signed message. an +a third party can add additional attributes to a signed message. an s/mime signature is used for this purpose - an additional attributes signature. | |
an example of an additional attribute is the 'equivalent label' attribute defined in ess [3].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. for example, the originator signs a message which is then encapsulated with an additional attributes' signature. a reviewer then signs this encrypted data, which is then encapsulated by a domain signature. the - message is wrapped in a signeddata that has a signerinfos which +1) an unsigned message has an empty signature layer added to it (i. + 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, will 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. this is so that when the domsec signature is added, as defined in method 2) - below, the signature will cover the unsigned message. the originator's - information is included as part of a header field in the encapsulated - message. + below, the signature will cover the unsigned message. 2) signature encapsulation is used to wrap the original signed message with a domain signature'.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. * for an additional attributes signature, an agent generating this signature must be named 'attribute-authority'. | |
| there must be only one cn +component present. 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. | |
| implementations conforming to this standard must support this name mapping convention as a minimum. implementations may choose to supplement this convention with other locally defined conventions. however, these must be agreed between sender and recipient domains prior to secure exchange of messages. on verifying the signature, a receiving agent must ensure that the naming convention has been adhered to. any message that violates the -convention shall be rejected as invalid.2 signature type attribute an s/mime signed attribute is used to indicate the type of signature. this should be used in conjunction with naming conventions specified in previous section. when an /mime signed message containing the signature type attribute is it triggers the software to that correct naming convention has been used. if the signaturetype attribute is the recipient should assume that signature is of message originator. | |
 . .. |