draft-ietf-smime-domsec-07.txt   draft-ietf-smime-domsec-08.txt 
INTERNET-DRAFT T Dean INTERNET-DRAFT T Dean
draft-ietf-smime-domsec-07.txt W Ottaway draft-ietf-smime-domsec-08.txt W Ottaway
Expires 22 May 2001 DERA Expires 01 September 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 36 skipping to change at line 36
Abstract Abstract
This document describes how the S/MIME protocol can be processed and This document describes how the S/MIME protocol can be processed and
generated by a number of components of a communication system, such as generated by a number of components of a communication system, such as
message transfer agents, guards and gateways to deliver security message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to limitations that arise when different security domains wish to
communicate securely, for example when two domains use incompatible communicate securely, for example when two domains use incompatible
messaging technologies such as X.400 series and SMTP/MIME, or when a messaging technologies such as the X.400 series and SMTP/MIME, or when
single domain wishes to communicate securely with one of its members a single domain wishes to communicate securely with one of its members
residing on an untrusted domain. The scenarios covered by this document residing on an untrusted domain. The scenarios covered by this document
are domain to domain, individual to domain and domain to individual are domain-to-domain, individual-to-domain and domain-to-individual
communications. This document is also applicable to organisations and communications. This document is also applicable to organisations and
enterprises that have internal PKIs which are not accessible by the enterprises that have internal PKIs which are not accessible by the
outside world, but wish to interoperate securely using the S/MIME outside world, but wish to interoperate securely using the S/MIME
protocol. protocol.
This draft is being discussed on the 'ietf-smime' mailing list. To This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to: subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
subscribe subscribe
skipping to change at line 147 skipping to change at line 147
Later sections describe definitively how these services map onto Later sections describe definitively how these services map onto
elements of the S/MIME protocol. elements of the S/MIME protocol.
The following security mechanisms are specified in this document: The following security mechanisms are specified in this document:
1. Domain signature 1. Domain signature
2. Review signature 2. Review signature
3. Additional attributes signature 3. Additional attributes signature
4. Domain encryption and decryption 4. Domain encryption and decryption
The signature types defined in this document are referred to as DOMSEC
defined signatures.
The term 'security domain' as used in this document is defined as a The term 'security domain' as used in this document is defined as a
collection of hardware and personnel operating under a single security collection of hardware and personnel operating under a single security
authority and performing a common business function. Members of a authority and performing a common business function. Members of a
security domain will of necessity share a high degree of mutual trust, security domain will of necessity share a high degree of mutual trust,
due to their shared aims and objectives. due to their shared aims and objectives.
A security domain is typically protected from direct outside attack by A security domain is typically protected from direct outside attack by
physical measures and from indirect (electronic) attack by a combination physical measures and from indirect (electronic) attack by a combination
of firewalls and guards at network boundaries. The interface between two of firewalls and guards at network boundaries. The interface between two
security domains is termed a 'security boundary'. One example of a security domains is termed a 'security boundary'. One example of a
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 schemes internally or when there are no certification links between
their PKIs. In both cases messages from the originator's domain are their PKIs. In both cases messages from the originator's domain are
signed over the original message and signature (if present) using an signed over the original message and signature (if present) using an
algorithm, key, and certificate which can be processed by the algorithm, key, and certificate which can be processed by the
recipient(s). A domain signature is sometimes referred to as an recipient(s) or the recipient(s) domain. A domain signature is sometimes
"organisational signature". 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 199 skipping to change at line 202
Label' attribute defined in ESS [3]. Label' attribute defined in ESS [3].
2.4 Domain Encryption and Decryption 2.4 Domain Encryption and Decryption
Domain encryption is S/MIME encryption performed on behalf of a Domain encryption is S/MIME encryption performed on behalf of a
collection of users in a domain. Domain encryption can be used to collection of users in a domain. Domain encryption can be used to
protect information between domains, for example, when two 'Intranets' protect information between domains, for example, when two 'Intranets'
are connected using the Internet. It can also be used when end users do 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 not have PKI/encryption capabilities at the desktop, or when two
domains employ incompatible encryption schemes internally. In the latter domains employ incompatible encryption schemes internally. In the latter
case messages from the originator's domain are (re-)encrypted using an case messages from the originator's domain are encrypted (or
algorithm, key, and certificate which can be decrypted by the re-encrypted) using an algorithm, key, and certificate which can be
recipient(s) or an entity in their domain. This scheme also applies to decrypted by the recipient(s) or an entity in their domain. This scheme
protecting information between a single domain and one of its members also applies to protecting information between a single domain and one
when both are connected using an untrusted network, e.g the Internet. 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 3. Mapping of the Signature Services to the S/MIME Protocol
This section describes the S/MIME protocol elements that are used to This section describes the S/MIME protocol elements that are used to
provide the security services described above. ESS [3] introduces the provide the security services described above. ESS [3] introduces the
concept of triple-wrapped messages that are first signed, then concept of triple-wrapped messages that are first signed, then
encrypted, then signed again. This document also uses this concept of encrypted, then signed again. This document also uses this concept of
triple-wrapping. In addition, this document also uses the concept of triple-wrapping. In addition, this document also uses the concept of
'signature encapsulation'. 'Signature encapsulation' denotes a signed 'signature encapsulation'. 'Signature encapsulation' denotes a signed
or unsigned message that is wrapped in a signature, this signature or unsigned message that is wrapped in a signature, this signature
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 There is a possibility that some policies will require signatures to be
added in a specific order. By only allowing signatures to be added by added in a specific order. By only allowing signatures to be added by
encapsulation it is possible to determine the order in which the encapsulation it is possible to determine the order in which the
signatures have been added. signatures have been added.
A DOMSEC signature MAY encapsulate a message in one of the following A DOMSEC defined signature MAY encapsulate a message in one of the
ways: following 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 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) so that when the DOMSEC defined signature is added, as defined in
below, the signature will cover the unsigned message. method 2) 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'. This is so that the 'domain signature' with a DOMSEC defined signature. This is so that the DOMSEC defined
covers the message and all the previously added signatures. Also, it signature covers the message and all the previously added signatures.
is possible to determine that the 'domain signature' was added after Also, it is possible to determine that the DOMSEC defined signature
the signatures that are already there. 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 301 skipping to change at line 305
signature MUST be named 'attribute-authority'. signature MUST be named 'attribute-authority'.
This name shall appear as the 'common name (CN)' component of the 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 subject field in the X.509 certificate. There MUST be only one CN
component present. Additionally, if the certificate contains an RFC 822 component present. Additionally, if the certificate contains an RFC 822
address, this name shall appear in the end entity component of the address, this name shall appear in the end entity component of the
address - on the left-hand side of the '@' symbol. address - on the left-hand side of the '@' symbol.
In the case of a domain signature, an additional naming rule is In the case of a domain signature, an additional naming rule is
defined: the 'name mapping rule'. The name mapping rule states that defined: the 'name mapping rule'. The name mapping rule states that
for a domain signing authority, the domain component of its name MUST be for a domain signing authority, the domain part of its name MUST be the
the same as, or an ascendant of, the domain name of the message same as, or an ascendant of, the domain name of the message
originator(s) that it is representing. The domain component is defined originator(s) that it is representing. The domain part is defined
as follows: as follows:
* In the case of an X.500 distinguished subject name of an X.509 * In the case of an X.500 distinguished subject name of an X.509
certificate, the domain component is the country, organisation, certificate, the domain part is the country, organisation,
organisational unit, state, and locality components of the organisational unit, state, and locality components of the
distinguished name. 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 * If the certificate contains an RFC 822 address, the domain
component is defined to be the RFC 822 address component on the right- part is defined to be the RFC 822 address component on the right-
hand side of the '@' symbol. hand side of the '@' symbol.
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,o=acme,c=us' and whose e-mail address is ou=marketing,o=acme,c=us' and whose e-mail address is
John.Doe@marketing.acme.com, could have a certificate containing a John.Doe@marketing.acme.com, could have a certificate containing a
distinguished name of 'cn=domain-signing-authority,o=acme,c=us' and a distinguished name of 'cn=domain-signing-authority,o=acme,c=us' and an
RFC 822 address of 'domain-signing-authority@acme.com'. RFC 822 address of 'domain-signing-authority@acme.com'. If John Doe has
an RFC 2247 defined address of 'cn=John Doe,dc=marketing,dc=acme,dc=us'
then an address of 'cn=domain-signing-authority,dc=acme,dc=us' could be
used to represent the domain signing authority.
When the X.500 distinguished subject name has consecutive organisational When the X.500 distinguished subject name has consecutive organisational
units and/or localities it is important to understand the ordering of 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 these values in order to determine if the domain part of the domain
signature is an ascendant. In this case, when parsing the distinguished signature is an ascendant. In this case, when parsing the distinguished
subject name from the root (i.e. country, locality or organisation) the subject name from the most significant component (i.e. country, locality
parsed organisational unit or locality is deemed to be the ascendant of or organisation) the parsed organisational unit or locality is deemed to
consecutive (unparsed) organisational units or localities. be the ascendant of consecutive (unparsed) organisational units or
localities.
When parsing an RFC 2247 subject name from the most significant
component (i.e. the 'dc' entry that represents the country, locality or
organisation) the parsed 'dc' entry is deemed to be the ascendant of
consecutive (unparsed) 'dc' entries.
For example, a domain signing authority acting on behalf of John Doe of 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 an RFC 822 address of
'domain-signing-authority@defence.acme.com'. 'domain-signing-authority@defence.acme.com'. If John Doe has an RFC 2247
defined address of 'cn=John Doe,dc=marketing,dc=defense,dc=acme,dc=us'
then the domain signing authority could have a distinguished name of
'cn=domain-signing-authority,dc=defence,dc=acme,dc=us'.
Any message received where the domain component of the domain signing Any message received where the domain part of the domain signing agent's
agents name does not match, or is not an ascendant of, the originator's name does not match, or is not an ascendant of, the originator's domain
domain name MUST be flagged. 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
skipping to change at line 369 skipping to change at line 388
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: -
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) id-sti OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 9 }
-- signature type identifier
If present, the SignatureType attribute MUST be a signed attribute, as If present, the SignatureType attribute MUST be a signed attribute, as
defined in [5]. If the SignatureType attribute is absent the recipient defined in [5]. If the SignatureType attribute is absent and there are
SHOULD assume that the signature is that of the message originator. 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 All of the signatures defined here are generated and processed as
described in [5]. They are distinguished by the presence of the described in [5]. They are distinguished by the presence of the
following values in the SignatureType signed attribute: following values in the SignatureType signed attribute:
id-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 2 } id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
-- domain signature. -- domain signature.
id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-aa-signatureType id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
3} -- additional attributes signature. -- additional attributes signature.
id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} -- id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 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 id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
1} -- originator's signature. -- 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 signatures. Note a DOMSEC defined signature could be encapsulating an
signatures. Note the domain signature could be encapsulating an empty 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
not present. not present.
If there is more than one SignerInfo in a signerInfos (i.e. when If there is more than one SignerInfo in a signerInfos (i.e. when
different algorithms are used) then the SignatureType attribute in all different algorithms are used) then the SignatureType attribute in all
the SignerInfos MUST contain the same content. the SignerInfos MUST contain the same content.
The following sections describe the conditions under which each of these The following sections describe the conditions under which each of these
types of signature may be generated, and how they are processed. types of signature may be generated, and how they are processed.
3.2 Domain Signature Generation and Verification 3.2 Domain Signature Generation and Verification
A 'domain signature' is a proxy signature generated on a user's behalf 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 in the user's domain. The signature MUST adhere to the naming
conventions in 3.1.1, including the name mapping convention. A 'domain conventions in 3.1.1, including the name mapping convention. A 'domain
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 been released from 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, including above methods and all other signatures present are valid, including
those that have been encrypted, a 'domain signature' can be added to a those that have been encrypted, a 'domain signature' can be added to a
message. message.
If a 'domain signature' is added and the message is received by a Mail 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' List Agent (MLA) there is a possibility that the 'domain signature'
will removed. To stop the 'domain signature' from being removed the will be removed. To stop the 'domain signature' from being removed the
steps in section 5 MUST be followed. 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.
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.
skipping to change at line 468 skipping to change at line 488
If there is no originator signature present, the only assumption that If there is no originator signature present, the only assumption that
can 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-sti-domainSig in a 'signature type' signed attribute.
There MAY be one or more 'domain signature' signatures in an S/MIME There MAY be one or more 'domain signature' signatures in an S/MIME
encoding. encoding.
3.3 Additional Attributes Signature Generation and Verification 3.3 Additional Attributes Signature Generation and Verification
The 'additional attributes' signature type indicates that the The 'additional attributes' signature type indicates that the
SignerInfo contains additional attributes that are associated with the SignerInfo contains additional attributes that are associated with the
message. message.
skipping to change at line 505 skipping to change at line 525
1) Equivalent Label: label values in this attribute are to be treated as 1) Equivalent Label: label values in this attribute are to be treated as
equivalent to the security label contained in an encapsulated equivalent to the security label contained in an encapsulated
SignerInfo, if present. SignerInfo, if present.
2) Security Label: the label value indicates the aggregate sensitivity 2) Security Label: the label value indicates the aggregate sensitivity
of the inner message content plus any encapsulated signedData and of the inner message content plus any encapsulated signedData and
envelopedData containers. The label on the original data is indicated envelopedData containers. The label on the original data is indicated
by the value in the originator's signature, if present. by the value in the originator's signature, if present.
An 'additional attributes' signature is indicated by the presence of the An 'additional attributes' signature is indicated by the presence of the
value id-aa-sigtype-add-attrib-sig in a 'signature type' signed value id-sti-addAttribSig in a 'signature type' signed
attribute. Other Object Identifiers MUST NOT be included in the sequence attribute. Other Object Identifiers MUST NOT be included in the sequence
of OIDs if this value is present. of OIDs if this value is present.
There MAY be multiple 'additional attributes' signatures in an S/MIME There MAY be multiple 'additional attributes' signatures in an S/MIME
encoding. encoding.
3.4 Review Signature Generation and Verification 3.4 Review Signature Generation and Verification
The review signature indicates that the signer has reviewed the message. The review signature indicates that the signer has reviewed the message.
Successful verification of a review signature means only that the signer Successful verification of a review signature means only that the signer
skipping to change at line 528 skipping to change at line 548
such as a Mail Guard or firewall may be configured to check review such as a Mail Guard or firewall may be configured to check review
signatures. A recipient MUST NOT assume that its successful verification signatures. A recipient MUST NOT assume that its successful verification
also authenticates the message originator. also authenticates the message originator.
An entity generating a signed review signature MUST do so using a An entity generating a signed review signature MUST do so using a
certificate containing a subject name that follows the naming convention 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 specified in 3.1.1. On reception, a check MUST be made to ensure that
the naming convention has been used. the naming convention has been used.
A review signature is indicated by the presence of the value A review signature is indicated by the presence of the value
id-aa-sigtype-review-sig in a 'signature type' signed attribute. id-sti-reviewSig in a 'signature type' signed attribute.
There MAY be multiple review signatures in an S/MIME encoding. There MAY be multiple review signatures in an S/MIME encoding.
3.5 Originator Signature 3.5 Originator Signature
The 'originator signature' is used to indicate that the signer is the The 'originator signature' is used to indicate that the signer is the
originator of the message and its contents. It is included in this originator of the message and its contents. It is included in this
document for completeness only. An originator signature is indicated document for completeness only. An originator signature is indicated
either by the absence of the signature type attribute, or by the 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' presence of the value id-sti-originatorSig in a 'signature type'
signed attribute. signed attribute.
4. Encryption and Decryption 4. Encryption and Decryption
Message encryption may be performed by a third party on behalf of a set 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. 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 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. of recipients in a domain. This is referred to as domain decryption.
The third party that performs these processes is referred to in this The third party that performs these processes is referred to in this
section as a "Domain Confidentiality Authority" (DCA). Both of these section as a "Domain Confidentiality Authority" (DCA). Both of these
skipping to change at line 603 skipping to change at line 623
by both techniques. by both techniques.
The mechanisms below are also applicable to individual roving users who The mechanisms below are also applicable to individual roving users who
wish to encrypt messages that are sent back to base. wish to encrypt messages that are sent back to base.
4.1 Domain Confidentiality Naming Conventions 4.1 Domain Confidentiality Naming Conventions
A DCA MUST be named 'domain-confidentiality-authority'. This name MUST A DCA MUST be named 'domain-confidentiality-authority'. This name MUST
appear in the 'common name(CN)' component of the subject field in the appear in the 'common name(CN)' component of the subject field in the
X.509 certificate. Additionally, if the certificate contains an RFC 822 X.509 certificate. Additionally, if the certificate contains an RFC 822
address, this name MUST appear in the end entity component of the address, this name MUST appear in the end entity part of the address,
address - on the left-hand side of the '@' symbol. i.e. on the left-hand side of the '@' symbol.
Along with this naming convention, an additional naming rule is defined: 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 '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 the domain part of its name MUST be the same as, or an ascendant of (as
of, the domain name of the set of entities that it represents. The defined in section 3.1.1), the domain name of the set of entities that
domain component is defined as follows: it represents. The domain part is defined as follows:
* In the case of an X.500 distinguished name of an X.509 certificate, * In the case of an X.500 distinguished name of an X.509 certificate,
the domain component is the country, organisation, organisational the domain part is the country, organisation, organisational
unit, state, and locality components of the distinguished name. unit, state, and locality components of the distinguished name.
* If the certificate contains an RFC 822 address, the domain component * In the case of an RFC 2247 distinguished name, the domain part
is defined to be the RFC 822 address component on the right-hand side is the domain components of the distinguished name.
of the '@' symbol.
* 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.
For example, a DCA acting on behalf of John Doe of the Acme For example, a DCA acting on behalf of John Doe of the Acme
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'. If John Doe
associated with this certificate would be used for encrypting messages has an RFC 2247 defined address of 'cn=John Doe,dc=marketing,
for John Doe. 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 component of the domain encrypting 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 agents name does not match, or is not an ascendant of, the domain name
of the entities it represents MUST be flagged. 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.
4.2 Key Management for DCA Encryption 4.2 Key Management for DCA Encryption
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 for
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 found. corresponding certificate can be found.
No specific method for locating the certificate to the corresponding No specific method for locating the certificate to the corresponding
DCA in the recipient's domain or the one corresponding to the end DCA in the recipient's domain or the one corresponding to the end
recipient is mandated in this document. An implementation may choose recipient is mandated in this document. An implementation may choose
to access a local certificate store to locate the correct certificate. to access a local certificate store to locate the correct certificate.
Alternatively, a directory may be used in one of the following ways: Alternatively, a X.500 or LDAP directory may be used in one of the
following ways:
1. The directory may store the DCA certificate in the recipient's 1. The directory may store the DCA certificate in the recipient's
directory entry. When the user certificate attribute is requested, directory entry. When the user certificate attribute is requested,
this certificate is returned. this certificate is returned.
2. The encrypting agent maps the recipient`s name to the DCA name in the 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 manner specified in 4.1. The user certificate attribute associated
with this directory entry is then obtained. with this directory entry is then obtained.
This document does not mandate either of these processes. Whichever one This document does not mandate either of these processes. Whichever one
is used, the name mapping conventions must be adhered to, in order to is used, the name mapping conventions must be adhered to, in order to
maintain confidentiality. maintain confidentiality.
Having located the correct certificate, the encryption process is then Having located the correct certificate, the encryption process is then
performed. A recipientInfo for the DCA or end recipient is then performed. A recipientInfo for the DCA or end recipient is then
generated, as described in CMS [5]. generated, as described in CMS [5].
skipping to change at line 691 skipping to change at line 718
4.3 Key Management for DCA Decryption 4.3 Key Management for DCA Decryption
DCA decryption uses a private-key belonging to the DCA and the necessary DCA decryption uses a private-key belonging to the DCA and the necessary
information conveyed in the DCA's recipientInfo field. information conveyed in the DCA's recipientInfo field.
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.
5. Applying a Domain Signature when Mail List Agents are present. 5. Applying a Domain Signature when Mail List Agents are Present.
It is possible that a message leaving a DOMSEC domain may encounter a 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 Mail List Agent (MLA) before it reaches the final recipient. There is a
possibility that this would result in the 'domain signature' being possibility that this would result in the 'domain signature' being
stripped off the message. We do not want a MLA to remove the 'domain stripped off the message. We do not want a MLA to remove the 'domain
signature'. Therefore, the 'domain signature' must be applied to the signature'. Therefore, the 'domain signature' must be applied to the
message in such a way that will prevent a MLA from removing it. 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 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 in ESS [3] section 4.2, and strip off all signedData layers that
skipping to change at line 744 skipping to change at line 771
3) a) If an envelopedData layer has been found then: - 3) a) If an envelopedData layer has been found then: -
- Strip off all the signedData layers down to the envelopedData - Strip off all the signedData layers down to the envelopedData
layer. layer.
- Locate the RecipientInfo for the local DCA and use the - Locate the RecipientInfo for the local DCA and use the
information it contains to obtain the message key. information it contains to obtain the message key.
- Decrypt the encryptedContent using the message key. - Decrypt the encryptedContent using the message key.
- Encapsulate the decrypted message with a 'domain - Encapsulate the decrypted message with a 'domain
signature' signature'
- Encapsulate the 'domain signature' with an envelopedData - If local policy requires the message to be encrypted using
layer containing RecipientInfo structures for each of the S/MIME encryption before leaving the domain then encapsulate
recipients and a originatorInfo value built from information the 'domain signature' with an envelopedData layer containing
describing this DCA. 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.
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: - b) If an envelopedData layer has not been found then: -
- Encapsulate the new message with a 'domain signature'. - Encapsulate the new message with a 'domain signature'.
4) Encapsulate the new message in a signedData layer, adding the 4) Encapsulate the new message in a signedData layer, adding the
signedAttributes from the signedData layer that contained the signedAttributes from the signedData layer that contained the
mlExpansionHistory attribute. mlExpansionHistory attribute.
If no signedData layer containing a mlExpansionHistory attribute has If no signedData layer containing a mlExpansionHistory attribute has
skipping to change at line 772 skipping to change at line 809
2) Locate the RecipientInfo for the local DCA and use the information 2) Locate the RecipientInfo for the local DCA and use the information
it contains to obtain the message key. it contains to obtain the message key.
3) Decrypt the encryptedContent using the message key. 3) Decrypt the encryptedContent using the message key.
4) Encapsulate the decrypted message with a 'domain signature' 4) Encapsulate the decrypted message with a 'domain signature'
5) If local policy requires the message to be encrypted before 5) If local policy requires the message to be encrypted before
leaving the domain then encapsulate the 'domain signature' with an leaving the domain then encapsulate the 'domain signature' with an
envelopedData layer containing RecipientInfo structures for each envelopedData layer containing RecipientInfo structures for each
of the recipients and an originatorInfo value built from of the recipients and an originatorInfo value built from
information describing this DCA. 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 If no signedData layer containing a mlExpansionHistory attribute has
been found and no envelopedData has been found then: - been found and no envelopedData has been found then: -
1) Encapsulate the message in a 'domain signature'. 1) Encapsulate the message in a 'domain signature'.
5.1 Examples of Rule Processing 5.1 Examples of Rule Processing
The following examples help explain the above rules: - 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.
1) A message (S1 (Original Content)) (where S = signedData) in which the 1) A message (S1 (Original Content)) (where S = signedData) in which the
signedData does not include an mlExpansionHistory attribute is to signedData does not include an mlExpansionHistory attribute is to
have a 'domain signature' applied. The signedData, S1, is verified. have a 'domain signature' applied. The signedData, S1, is verified.
No "outer" signedData is found, after searching for one as defined No "outer" signedData is found, after searching for one as defined
above, since the original content is found, nor is an envelopedData above, since the original content is found, nor is an envelopedData
or a mlExpansionHistory attribute found. A new signedData layer, S2, or a mlExpansionHistory attribute found. A new signedData layer, S2,
is created that contains a 'domain signature', resulting in the is created that contains a 'domain signature', resulting in the
following message sent out of the domain (S2 (S1 (Original Content))). following message sent out of the domain (S2 (S1 (Original Content))).
skipping to change at line 802 skipping to change at line 847
a 'domain signature' applied. The signedData objects S1, S2 and S3 a 'domain signature' applied. The signedData objects S1, S2 and S3
are verified. There is not an original, "outer" signedData layer are verified. There is not an original, "outer" signedData layer
since the original content is found, nor is an envelopedData or a since the original content is found, nor is an envelopedData or a
mlExpansionHistory attribute found. A new signedData layer, S4, is mlExpansionHistory attribute found. A new signedData layer, S4, is
created that contains a 'domain signature', resulting in the created that contains a 'domain signature', resulting in the
following message sent out of the domain (S4 (S3 (S2 (S1 (Original following message sent out of the domain (S4 (S3 (S2 (S1 (Original
Content))). Content))).
3) A message (E1 (S1 (Original Content))) (where E = envelopedData) in 3) A message (E1 (S1 (Original Content))) (where E = envelopedData) in
which S1 does not include a mlExpansionHistory attribute is to have which S1 does not include a mlExpansionHistory attribute is to have
a 'domain signature' applied. The signedData, S1, is verified. There a 'domain signature' applied. There is not an original, received
is not an original, received "outer" signedData layer since the "outer" signedData layer since the envelopedData, E1, is found at the
envelopedData, E1, is found at the outer layer. The encryptedContent outer layer. The encryptedContent is decrypted. The signedData, S1,
is decrypted. The decrypted content is wrapped in a new signedData is verified. The decrypted content is wrapped in a new signedData
layer, S2, which contains a 'domain signature'. If local policy layer, S2, which contains a 'domain signature'. If local policy
requires the message to be encrypted before it leaves the domain requires the message to be encrypted, using S/MIME encryption, before
then this new message is wrapped in an envelopedData layer, E2, it leaves the domain then this new message is wrapped in an
resulting in the following message sent out of the domain (E2 (S2 envelopedData layer, E2, resulting in the following message sent out
(S1 (Original Content)))), else the message is not wrapped in an of the domain (E2 (S2 (S1 (Original Content)))), else the message is
envelopedData layer resulting in the following message (S2 (S1 not wrapped in an envelopedData layer resulting in the following
(Original Content))) being sent. message (S2 (S1 (Original Content))) being sent.
4) A message (S2 (E1 (S1 (Original Content)))) in which S2 includes a 4) A message (S2 (E1 (S1 (Original Content)))) in which S2 includes a
mlExpansionHistory attribute is to have a 'domain signature' mlExpansionHistory attribute is to have a 'domain signature'
applied. The signedData objects S2 and S1 are verified. The applied. The signedData object S2 is verified. The mlExpansionHistory
mlExpansionHistory attribute is found in S2, so S2 is the "outer" attribute is found in S2, so S2 is the "outer" signedData. The signed
signedData. The signed attributes in S2 are remembered for later attributes in S2 are remembered for later inclusion in the new outer
inclusion in the new outer signedData that is applied to the signedData that is applied to the message. S2 is stripped off and the
message. S2 is stripped off and the message is decrypted. The message is decrypted. The signedData object S1 is verified. The
decrypted message is wrapped in a signedData layer, S3, which decrypted message is wrapped in a signedData layer, S3, which
contains a 'domain signature'. This new message is then wrapped in contains a 'domain signature'. If local policy requires the message
an envelopedData layer, E2. A new signedData layer, S4, is then to be encrypted, using S/MIME encryption, before it leaves the
wrapped around the envelopedData, E2, resulting in the following domain then this new message is wrapped in an envelopedData layer,
message sent out of the domain (S4 (E2 (S3 (S1 (Original Content)) E2. A new signedData layer, S4, is then wrapped around the
))). The signedData S4 contains the signed attributes from S2. envelopedData, 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 5) A message (S3 (S2 (E1 (S1 (Original Content))))) in which none of
the signedData layers include a mlExpansionHistory attribute is to the signedData layers include a mlExpansionHistory attribute is to
have a 'domain signature' applied. The signedData objects S3, S2 and have a 'domain signature' applied. The signedData objects S3 and S2
S1 are verified. When the envelopedData E1 is found the signedData are verified. When the envelopedData E1 is found the signedData
objects S3 and S2 are stripped off. The encryptedContent is objects S3 and S2 are stripped off. The encryptedContent is
decrypted. The decrypted content is wrapped in a new signedData decrypted. The signedData object S1 is verified. The decrypted
layer, S4, which contains a 'domain signature'. If local policy content is wrapped in a new signedData layer, S4, which contains a
requires the message to be encrypted before it leaves the domain '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, then this new message is wrapped in an envelopedData layer, E2,
resulting in the following message sent out of the domain (E2 (S2 resulting in the following message sent out of the domain (E2 (S4
(S1 (Original Content)))), else the message is not wrapped in an (S1 (Original Content)))), else the message is not wrapped in an
envelopedData layer resulting in the following message (S2 (S1 envelopedData layer resulting in the following message (S4 (S1
(Original Content))) being sent. (Original Content))) being sent.
6) A message (S3 (S2 (E1 (S1 (Original Content))))) in which S3 6) A message (S3 (S2 (E1 (S1 (Original Content))))) in which S3
includes a mlExpansionHistory attribute is to have a 'domain includes a mlExpansionHistory attribute is to have a 'domain
signature' applied. The signedData objects S3, S2 and S1 are signature' applied. The signedData objects S3 and S2 are verified.
verified. The mlExpansionHistory attribute is found in S3, so S3 is The mlExpansionHistory attribute is found in S3, so S3 is the
the "outer" signedData. The signed attributes in S3 are remembered "outer" signedData. The signed attributes in S3 are remembered
for later inclusion in the new outer signedData that is applied to for later inclusion in the new outer signedData that is applied to
the message. The signedData object S3 is stripped off. When the the message. The signedData object S3 is stripped off. When the
envelopedData layer, E1, is found the signedData object S2 is envelopedData layer, E1, is found the signedData object S2 is
stripped off. The encryptedContent is decrypted. The decrypted stripped off. The encryptedContent is decrypted. The signedData
content is wrapped in a new signedData layer, S4, which contains a object S1 is verified. The decrypted content is wrapped in a new
'domain signature'. This new message is then wrapped in an 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 envelopedData layer, E2. A new signedData layer, S5, is then wrapped
around the envelopedData, E2, resulting in the following message around the envelopedData, E2, resulting in the following message sent
sent out of the domain (S5 (E2 (S4 (S1 (Original Content))))). The out of the domain (S5 (E2 (S4 (S1 (Original Content))))). If local
signedData S5 contains the signed attributes from S3. 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.
7) A message (S3 (E2 (S2 (E1 (S1 (Original Contnent)))))) 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 decrytped 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 6. Security Considerations
This specification relies on the existence of several well known names,
such as domain-confidentiality-authority. Organisations 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 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 conjunction
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 obtained a DCA certificate can fake a message to that domain
to be another domain. pretending to be another domain.
7. 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
-- use in the other ASN.1 modules. Other applications may use -- use in the other ASN.1 modules. Other applications may use
-- them for their own purposes. -- them for their own purposes.
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
id-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType
2 } -- domain signature.
id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-sti OBJECT IDENTIFIER ::= { id-smime 9 } -- signature type
id-aa-signatureType 3} -- additional attributes signature. identifier
id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} -- Signature Type Identifiers
-- review signature.
id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
id-aa-signatureType 1} -- originator's signature. 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 END -- of DOMSECSyntax
8. 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.
skipping to change at line 978 skipping to change at line 1058
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 22 May 2001 This draft expires 01 September 2001
 End of changes. 

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