draft-ietf-smime-domsec-06.txt   draft-ietf-smime-domsec-07.txt 
INTERNET-DRAFT T Dean INTERNET-DRAFT T Dean
draft-ietf-smime-domsec-06.txt W Ottaway draft-ietf-smime-domsec-07.txt W Ottaway
Expires 12th January 2001 DERA Expires 22 May 2001 DERA
Domain Security Services using S/MIME Domain Security Services using S/MIME
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of section 10 of RFC2026. Internet-Drafts are working provisions of section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at line 167 skipping to change at line 167
security domain is an organisational network ('Intranet'). security domain is an organisational network ('Intranet').
2.1 Domain Signature 2.1 Domain Signature
A Domain signature is an S/MIME signature generated on behalf of a set A Domain signature is an S/MIME signature generated on behalf of a set
of users in a domain. A Domain signature can be used to authenticate 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 information sent between domains or between a certain domain and one of
its individuals, for example, when two 'Intranets' are connected using its individuals, for example, when two 'Intranets' are connected using
the Internet, or when an Intranet is connected to a remote user over the 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 Internet. It can be used when two domains employ incompatible signature
schemes internally or when there are no certification links between their schemes internally or when there are no certification links between
PKIs. In both cases messages from the originator's domain are signed over their PKIs. In both cases messages from the originator's domain are
the original message and signature (if present) using an algorithm, key, signed over the original message and signature (if present) using an
and certificate which can be processed by the recipient(s). A domain algorithm, key, and certificate which can be processed by the
signature is sometimes referred to as an "organisational signature". recipient(s). A domain signature is sometimes referred to as an
"organisational signature".
2.2 Review Signature 2.2 Review Signature
A third party may review messages before they are forwarded to the final A third party may review messages before they are forwarded to the final
recipient(s) who may be in the same or a different security domain. recipient(s) who may be in the same or a different security domain.
Organisational policy and good security practice often require that Organisational policy and good security practice often require that
messages be reviewed before they are released to external recipients. messages be reviewed before they are released to external recipients.
Having reviewed a message, an S/MIME signature is added to it - a review 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 signature. An agent could check the review signature at the domain
boundary, to ensure that only reviewed messages are released. boundary, to ensure that only reviewed messages are released.
skipping to change at line 223 skipping to change at line 224
covering both the content and the first (inner) signature, if present. covering both the content and the first (inner) signature, if present.
Signature encapsulation MAY be performed on the inner and/or the outer Signature encapsulation MAY be performed on the inner and/or the outer
signature of a triple-wrapped message. signature of a triple-wrapped message.
For example, the originator signs a message which is then encapsulated For example, the originator signs a message which is then encapsulated
with an 'additional attributes' signature. This is then encrypted. A with an 'additional attributes' signature. This is then encrypted. A
reviewer then signs this encrypted data, which is then encapsulated by reviewer then signs this encrypted data, which is then encapsulated by
a domain signature. a domain signature.
There is a possiblity 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 signature MAY encapsulate a message in one of the following A DOMSEC signature MAY encapsulate a message in one of the following
ways: ways:
1) An unsigned message has an empty signature layer added to it (i.e. 1) An unsigned message has an empty signature layer added to it (i.e.
the message is wrapped in a signedData that has a signerInfos which the message is wrapped in a signedData that has a signerInfos which
contains no elements). This is to enable backward compatibility with contains no elements). This is to enable backward compatibility with
S/MIME software that does not have a DOMSEC capability. Since the S/MIME software that does not have a DOMSEC capability. Since the
signerInfos will contain no signers the eContentType, within the signerInfos will contain no signers the eContentType, within the
EncapsulatedContentInfo, MUST be id-data as described in CMS [5]. EncapsulatedContentInfo, MUST be id-data as described in CMS [5].
However, the eContent field will contain the unsigned message instead 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 of being left empty as suggested in section 5.2 in CMS [5]. This is
that when the DOMSEC signature is added, as defined in method 2) so that when the DOMSEC signature is added, as defined in method 2)
below, the signature will cover the unsigned message. below, the signature will cover the unsigned message.
2) Signature Encapsulation is used to wrap the original signed message 2) Signature Encapsulation is used to wrap the original signed message
with a 'domain signature'. with a 'domain signature'. This is so that the 'domain signature'
covers the message and all the previously added signatures. Also, it
is possible to determine that the 'domain signature' was added after
the signatures that are already there.
3.1 Naming Conventions and Signature Types 3.1 Naming Conventions and Signature Types
An entity receiving an S/MIME signed message would normally expect the An entity receiving an S/MIME signed message would normally expect the
signature to be that of the originator of the message. However, the signature to be that of the originator of the message. However, the
message security services defined in this document require the recipient message security services defined in this document require the recipient
to be able to accept messages signed by other entities and/or the to be able to accept messages signed by other entities and/or the
originator. When other entities sign the message the name in the originator. When other entities sign the message the name in the
certificate will not match the message sender's name. An S/MIME certificate will not match the message sender's name. An S/MIME
compliant implementation would normally flag a warning if there were a compliant implementation would normally flag a warning if there were a
skipping to change at line 331 skipping to change at line 340
For example, a domain signing authority acting on behalf of John Doe of For example, a domain signing authority acting on behalf of John Doe of
the Acme corporation, whose distinguished name is 'cn=John Doe, the Acme corporation, whose distinguished name is 'cn=John Doe,
ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is
John.Doe@marketing.defence.acme.com, could have a certificate containing John.Doe@marketing.defence.acme.com, could have a certificate containing
a distinguished name of 'cn=domain-signing-authority,ou=defence,o=acme, a distinguished name of 'cn=domain-signing-authority,ou=defence,o=acme,
c=us' and a RFC 822 address of c=us' and a RFC 822 address of
'domain-signing-authority@defence.acme.com'. 'domain-signing-authority@defence.acme.com'.
Any message received where the domain component of the domain signing 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 agents name does not match, or is not an ascendant of, the originator's
domain name MUST be rejected. domain name MUST be flagged.
This naming rule prevents agents from one organisation masquerading as This naming rule prevents agents from one organisation masquerading as
domain signing authorities on behalf of another. For the other types of domain signing authorities on behalf of another. For the other types of
signature defined in this document, no such named mapping rule is signature defined in this document, no such named mapping rule is
defined. defined.
Implementations conforming to this standard MUST support this name Implementations conforming to this standard MUST support this name
mapping convention as a minimum. Implementations MAY choose to mapping convention as a minimum. Implementations MAY choose to
supplement this convention with other locally defined conventions. supplement this convention with other locally defined conventions.
However, these MUST be agreed between sender and recipient domains prior However, these MUST be agreed between sender and recipient domains prior
to secure exchange of messages. to secure exchange of messages.
On verifying the signature, a receiving agent MUST ensure that the On verifying the signature, a receiving agent MUST ensure that the
naming convention has been adhered to. Any message that violates the naming convention has been adhered to. Any message that violates the
convention should be flagged. convention MUST be flagged.
3.1.2 Signature Type Attribute 3.1.2 Signature Type Attribute
An S/MIME signed attribute is used to indicate the type of signature. An S/MIME signed attribute is used to indicate the type of signature.
This should be used in conjunction with the naming conventions specified This should be used in conjunction with the naming conventions specified
in the previous section. When an S/MIME signed message containing the in the previous section. When an S/MIME signed message containing the
signature type attribute is received it triggers the software to verify signature type attribute is received it triggers the software to verify
that the correct naming convention has been used. that the correct naming convention has been used.
The ASN.1 [4] notation of this attribute is: - The ASN.1 [4] notation of this attribute is: -
skipping to change at line 384 skipping to change at line 393
id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-aa-signatureType id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-aa-signatureType
3} -- additional attributes signature. 3} -- additional attributes signature.
id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} -- id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} --
review signature. review signature.
For completeness, an attribute type is also specified for an originator For completeness, an attribute type is also specified for an originator
signature. However, this signature type is optional. It is defined as signature. However, this signature type is optional. It is defined as
follows: follows:
id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 1} id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-aa-signatureType
1} -- originator's signature.
All signature types, except the originator type, MUST encapsulate other All signature types, except the originator type, MUST encapsulate other
signature types specified in this document MUST encapsulate other signature types specified in this document MUST encapsulate other
signatures. Note the domain signature could be encapsulating an empty signatures. Note the domain signature could be encapsulating an empty
signature as defined in section 3. signature as defined in section 3.
A SignerInfo MUST NOT include multiple instances of SignatureType. A A SignerInfo MUST NOT include multiple instances of SignatureType. A
signed attribute representing a SignatureType MAY include multiple signed attribute representing a SignatureType MAY include multiple
instances of different SignatureType values as an AttributeValue of instances of different SignatureType values as an AttributeValue of
attrValues [5], as long as the SignatureType 'additional attributes' is attrValues [5], as long as the SignatureType 'additional attributes' is
skipping to change at line 420 skipping to change at line 429
signature' on a message authenticates the fact that the message has signature' on a message authenticates the fact that the message has
originated in that domain. Before signing, a process generating a originated in that domain. Before signing, a process generating a
'domain signature' MUST first satisfy itself of the authenticity of the 'domain signature' MUST first satisfy itself of the authenticity of the
message originator. This is achieved by one of two methods. Either the message originator. This is achieved by one of two methods. Either the
'originator's signature' is checked, if S/MIME signatures are used '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, 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 such as the physical address of the originating client or an
authenticated IP link. authenticated IP link.
If the originator's authenticity is successfully verified by one of the If the originator's authenticity is successfully verified by one of the
above methods and all other signatures present are valid, a 'domain above methods and all other signatures present are valid, including
signature' MAY be added to a message. 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 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 An entity generating a domain signature MUST do so using a certificate
containing a subject name that follows the naming convention specified containing a subject name that follows the naming convention specified
in 3.1.1. 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 If the originator's authenticity is not successfully verified or all
the signatures present are not valid, a 'domain signature' MUST NOT be the signatures present are not valid, a 'domain signature' MUST NOT be
generated. generated.
On reception, the 'domain signature' SHOULD be used to verify the On reception, the 'domain signature' SHOULD be used to verify the
authenticity of a message. A check MUST be made to ensure that both the authenticity of a message. A check MUST be made to ensure that both the
naming convention and the name mapping convention have been used as naming convention and the name mapping convention have been used as
specified in this standard. specified in this standard.
A recipient can assume that successful verification of the domain A recipient can assume that successful verification of the domain
signature also authenticates the message originator. signature also authenticates the message originator.
If there is an originator signature present, the name in that If there is an originator signature present, the name in that
certificate SHOULD be used to identify the originator. This information certificate SHOULD be used to identify the originator. This information
can then be displayed to the recipient. can then be displayed to the recipient.
If there is no originator signature present, the only assumption that can If there is no originator signature present, the only assumption that
be made is the domain the message originated from. can be made is the domain the message originated from.
A domain signer can be assumed to have verified any signatures that it A domain signer can be assumed to have verified any signatures that it
encapsulates. Therefore, it is not necessary to verify these signatures encapsulates. Therefore, it is not necessary to verify these signatures
before treating the message as authentic. However, this standard does before treating the message as authentic. However, this standard does
not preclude a recipient from attempting to verify any other signatures not preclude a recipient from attempting to verify any other signatures
that are present. that are present.
The 'domain signature' is indicated by the presence of the value The 'domain signature' is indicated by the presence of the value
id-aa-sigtype-domain-sig in a 'signature type' signed attribute. id-aa-sigtype-domain-sig in a 'signature type' signed attribute.
skipping to change at line 567 skipping to change at line 578
final recipient(s), is described in CMS [5]. In cases (c) and (d), 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 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 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. by the recipient(s) but by the DCA in the recipient's domain.
A client implementation that conforms to this standard MUST support A client implementation that conforms to this standard MUST support
case (b) for transmission, case (c) for reception and case (a) for case (b) for transmission, case (c) for reception and case (a) for
transmission and reception. transmission and reception.
A DCA implementation that conforms to this standard MUST support cases A DCA implementation that conforms to this standard MUST support cases
(c) and (d), for transmission, and cases (b) and (d) for reception. (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 The process of encryption and decryption is documented in CMS [5]. The
only additional requirement introduced by domain encryption and only additional requirement introduced by domain encryption and
decryption is for greater flexibility in the management of keys, as decryption is for greater flexibility in the management of keys, as
described in the following subsections. As with signatures, a naming described in the following subsections. As with signatures, a naming
convention and name mapping convention are used to locate the correct convention and name mapping convention are used to locate the correct
public key. public key.
The mechanisms described below are applicable both to key agreement and The mechanisms described below are applicable both to key agreement and
key transport systems, as documented in CMS [5]. The phrase 'encryption key transport systems, as documented in CMS [5]. The phrase 'encryption
skipping to change at line 617 skipping to change at line 631
corporation, whose distinguished name is 'cn=John Doe, ou=marketing, corporation, whose distinguished name is 'cn=John Doe, ou=marketing,
o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com, o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com,
could have a certificate containing a distinguished name of could have a certificate containing a distinguished name of
'cn=domain-confidentiality-authority, o=acme,c=us' and an e-mail 'cn=domain-confidentiality-authority, o=acme,c=us' and an e-mail
address of 'domain-confidentiality-authority@acme.com'. The key address of 'domain-confidentiality-authority@acme.com'. The key
associated with this certificate would be used for encrypting messages associated with this certificate would be used for encrypting messages
for John Doe. for John Doe.
Any message received where the domain component of the domain encrypting 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 agents name does not match, or is not an ascendant of, the domain name
of the entities it represents MUST be rejected. of the entities it represents MUST be flagged.
This naming rule prevents messages being encrypted for the wrong domain This naming rule prevents messages being encrypted for the wrong domain
decryption agent. decryption agent.
Implementations conforming to this standard MUST support this name Implementations conforming to this standard MUST support this name
mapping convention as a minimum. Implementations may choose to mapping convention as a minimum. Implementations may choose to
supplement this convention with other locally defined conventions. supplement this convention with other locally defined conventions.
However, these MUST be agreed between sender and recipient domains However, these MUST be agreed between sender and recipient domains
prior to sending any messages. prior to sending any messages.
skipping to change at line 639 skipping to change at line 653
At the sender's domain, DCA encryption is achieved using the recipient At the sender's domain, DCA encryption is achieved using the recipient
DCA's certificate or the end recipient's certificate. For this, the DCA's certificate or the end recipient's certificate. For this, the
encrypting process must be able to correctly locate the certificate to encrypting process must be able to correctly locate the certificate to
the corresponding DCA in the recipient's domain or the one corresponding the corresponding DCA in the recipient's domain or the one corresponding
to the end recipient. Having located the correct certificate, the to the end recipient. Having located the correct certificate, the
encryption process is then performed and additional information required encryption process is then performed and additional information required
for decryption is conveyed to the recipient in the recipientInfo field for decryption is conveyed to the recipient in the recipientInfo field
as specified in CMS [5]. A DCA encryption agent MUST be named according 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 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 corresponding certificate can be found.
encrypted message.
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 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 or end recipient is then
generated, as described in CMS [5].
DCA encryption may be performed for decryption by the end recipient DCA encryption may be performed for decryption by the end recipient
and/or by a DCA. End recipient decryption is described in CMS [5]. DCA and/or by a DCA. End recipient decryption is described in CMS [5]. DCA
decryption is described in section 4.3. decryption is described in section 4.3.
4.3 Key Management for DCA Decryption 4.3 Key Management for DCA Decryption
DCA decryption uses a private-key from the recipient's domain and the DCA decryption uses a private-key belonging to the DCA and the necessary
necessary information conveyed in the recipientInfo field. The information conveyed in the DCA's recipientInfo field.
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 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. 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 In the first case, the encryption process is described in CMS [5]; in
the second case, the encryption process is described in 4.2. the second case, the encryption process is described in 4.2.
No specific method for locating this certificate is mandated in this 5. Applying a Domain Signature when Mail List Agents are present.
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 It is possible that a message leaving a DOMSEC domain may encounter a
directory entry. When the user certificate attribute is requested, Mail List Agent (MLA) before it reaches the final recipient. There is a
this certificate is returned. 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.
2. The encrypting agent maps the recipient`s name to the DCA name in the A MLA will search a message for the "outer" signedData layer, as defined
manner specified in 4.1. The user certificate attribute associated in ESS [3] section 4.2, and strip off all signedData layers that
with this directory entry is then obtained. 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.
This document does not mandate either of these processes. Whichever one There is a possibility that a message leaving a DOMSEC domain has
is used, the name mapping conventions must be adhered to, in order to already been processed by a MLA, in which case a 'mlExpansionHistory'
maintain confidentiality. attribute will be present within the message.
Having located the correct certificate, the encryption process is then There is a possibility that the message will contain an envelopedData
performed. A recipientInfo for the DCA is then generated, as described layer. This will be the case when the message has been encrypted within
in CMS [5]. the domain for the domain's "Domain Confidentiality Authority", see
section 4.0, and, possibly, the final recipient.
5. Security Considerations 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'
- Encapsulate the 'domain signature' with an envelopedData
layer containing RecipientInfo structures for each of the
recipients and a originatorInfo value built from information
describing this DCA.
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 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: -
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. The signedData, S1, is verified. There
is not an original, received "outer" signedData layer since the
envelopedData, E1, is found at the outer layer. The encryptedContent
is decrypted. 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 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 objects S2 and S1 are 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
decrypted message is wrapped in a signedData layer, S3, which
contains a 'domain signature'. This new message is then wrapped in
an envelopedData layer, E2. A new signedData layer, S4, is then
wrapped around the envelopedData, E2, resulting in the following
message sent out of the domain (S4 (E2 (S3 (S1 (Original Content))
))). The signedData S4 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, S2 and
S1 are verified. When the envelopedData E1 is found the signedData
objects S3 and S2 are stripped off. The encryptedContent is
decrypted. 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 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.
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, S2 and S1 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 decrypted
content is wrapped in a new signedData layer, S4, which contains a
'domain signature'. This new message is then 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))))). The
signedData S5 contains the signed attributes from S3.
6. Security Considerations
Implementations MUST protect all private keys. Compromise of the Implementations MUST protect all private keys. Compromise of the
signer's private key permits masquerade. signer's private key permits masquerade.
Similarly, compromise of the content-encryption key may result in Similarly, compromise of the content-encryption key may result in
disclosure of the encrypted content. disclosure of the encrypted content.
Compromise of key material is regarded as an even more serious issue for Compromise of key material is regarded as an even more serious issue for
domain security services than for an S/MIME client. This is because 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 compromise of the private key may in turn compromise the security of a
whole domain. Therefore, great care should be used when considering its whole domain. Therefore, great care should be used when considering its
protection. protection.
Domain encryption alone is not secure and should be used in conjuction Domain encryption alone is not secure and should be used in conjuction
with a domain signature to avoid a masquerade attack, where an attacker 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 that has obtain a DCA cert can fake a message to that domain pretending
to be another domain. to be another domain.
6. DOMSEC ASN.1 Module 7. DOMSEC ASN.1 Module
DOMSECSyntax DOMSECSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) } pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
-- The types and values defined in this module are exported for -- The types and values defined in this module are exported for
skipping to change at line 732 skipping to change at line 910
id-aa-signatureType 3} -- additional attributes signature. id-aa-signatureType 3} -- additional attributes signature.
id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4}
-- review signature. -- review signature.
id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= {
id-aa-signatureType 1} -- originator's signature. id-aa-signatureType 1} -- originator's signature.
END -- of DOMSECSyntax END -- of DOMSECSyntax
7. References 8. References
[1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC2633, [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC2633,
June 1999. June 1999.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, [3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634,
June 1999. June 1999.
[4] International Telecommunications Union, Recommendation X.208, "Open [4] International Telecommunications Union, Recommendation X.208, "Open
systems interconnection: specification of Abstract Syntax Notation systems interconnection: specification of Abstract Syntax Notation
(ASN.1)", CCITT Blue Book, 1989. (ASN.1)", CCITT Blue Book, 1989.
[5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
8. Authors' Addresses 9. Authors' Addresses
Tim Dean Tim Dean
DERA Malvern DERA Malvern
St. Andrews Road St. Andrews Road
Malvern Malvern
Worcs Worcs
WR14 3PS WR14 3PS
Phone: +44 (0) 1684 894239 Phone: +44 (0) 1684 894239
Fax: +44 (0) 1684 896660 Fax: +44 (0) 1684 896660
skipping to change at line 773 skipping to change at line 951
DERA Malvern DERA Malvern
St. Andrews Road St. Andrews Road
Malvern Malvern
Worcs Worcs
WR14 3PS WR14 3PS
Phone: +44 (0) 1684 894079 Phone: +44 (0) 1684 894079
Fax: +44 (0) 1684 896660 Fax: +44 (0) 1684 896660
Email: w.ottaway@eris.dera.gov.uk Email: w.ottaway@eris.dera.gov.uk
8. Full Copyright Statement 10. Full Copyright Statement
"Copyright (C) The Internet Society (2000). All Rights Reserved. "Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself 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 may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE." FITNESS FOR A PARTICULAR PURPOSE."
This draft expires 12th January 2001 This draft expires 22 May 2001
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/