draft-ietf-smime-domsec-05.txt   draft-ietf-smime-domsec-06.txt 
INTERNET-DRAFT T Dean INTERNET-DRAFT T Dean
draft-ietf-smime-domsec-05.txt W Ottaway draft-ietf-smime-domsec-06.txt W Ottaway
Expires 26th November 2000 DERA Expires 12th January 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 and SMTP/MIME, or when a single messaging technologies such as X.400 series and SMTP/MIME, or when a
domain wishes to communicate securely with one of its members residing single domain wishes to communicate securely with one of its members
on an untrusted domain. The scenarios covered by this document are residing on an untrusted domain. The scenarios covered by this document
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 72 skipping to change at line 72
integrity, confidentiality, and authentication. S/MIME is designed for integrity, confidentiality, and authentication. S/MIME is designed for
use by messaging clients to deliver security services to distributed use by messaging clients to deliver security services to distributed
messaging applications. messaging applications.
There are many circumstances when it is not desirable or practical to There are many circumstances when it is not desirable or practical to
provide end-to-end (desktop-to-desktop) security services, particularly provide end-to-end (desktop-to-desktop) security services, particularly
between different security domains. An organisation that is considering between different security domains. An organisation that is considering
providing end-to-end security services will typically have to deal with providing end-to-end security services will typically have to deal with
some if not all of the following issues: some if not all of the following issues:
1) Heterogeneous Message Access Methods: Users are accessing mail using 1) Heterogeneous message access methods: Users are accessing mail using
mechanisms which re-format messages, such as using Web browsers. mechanisms which re-format messages, such as using Web browsers.
Message reformatting in the Message Store makes end-to-end encryption Message reformatting in the Message Store makes end-to-end encryption
and signature validation impossible. and signature validation impossible.
2) Message screening and audit: Server-based mechanisms such as 2) Message screening and audit: Server-based mechanisms such as
searching for prohibited words or other content, virus scanning, and searching for prohibited words or other content, virus scanning, and
audit, are incompatible with end-to-end encryption. audit, are incompatible with end-to-end encryption.
3) PKI deployment issues: There may not be any certificate paths between 3) PKI deployment issues: There may not be any certificate paths between
two organisations. Or an organisation may be sensitive about aspects two organisations. Or an organisation may be sensitive about aspects
of its PKI and unwilling to expose them to outside access. Also, full of its PKI and unwilling to expose them to outside access. Also, full
PKI deployment for all employees, may be expensive, not necessary or PKI deployment for all employees, may be expensive, not necessary or
impractical for large organisations. For any of these reasons, direct impractical for large organisations. For any of these reasons, direct
end-to-end signature validation and encryption are impossible. end-to-end signature validation and encryption are impossible.
4) Heterogeneous Message transports: One organisation using X.400 wishes 4) Heterogeneous message formats: One organisation using X.400 series
to communicate with another using SMTP. Message reformatting at protocols wishes to communicate with another using SMTP. Message
gateways makes end-to-end encryption and signature validation reformatting at gateways makes end-to-end encryption and signature
impossible. validation impossible.
This document describes an approach to solving these problems by This document describes an approach to solving these problems by
providing message security services at the level of a domain or an providing message security services at the level of a domain or an
organisation. This document specifies how these 'domain security organisation. This document specifies how these 'domain security
services' can be provided using the S/MIME protocol. Domain security services' can be provided using the S/MIME protocol. Domain security
services may replace or complement mechanisms at the desktop. For services may replace or complement mechanisms at the desktop. For
example, a domain may decide to provide desktop-to-desktop signatures example, a domain may decide to provide desktop-to-desktop signatures
but domain-to-domain encryption services. Or it may allow desktop-to- but domain-to-domain encryption services. Or it may allow desktop-to-
desktop services for intra-domain use, but enforce domain-based services desktop services for intra-domain use, but enforce domain-based services
for communication with other domains. for communication with other domains.
skipping to change at line 126 skipping to change at line 126
ways to meet different needs in different circumstances. ways to meet different needs in different circumstances.
Message transfer agents (MTAs), guards, firewalls and protocol Message transfer agents (MTAs), guards, firewalls and protocol
translation gateways all provide domain security services. As with translation gateways all provide domain security services. As with
desktop based solutions, these components must be resilient against a desktop based solutions, these components must be resilient against a
wide variety of attacks intended to subvert the security services. wide variety of attacks intended to subvert the security services.
Therefore, careful consideration should be given to security of these Therefore, careful consideration should be given to security of these
components, to make sure that their siting and configuration minimises components, to make sure that their siting and configuration minimises
the possibility of attack. the possibility of attack.
Throughout this draft the terms MAY, MUST, MUST NOT and SHOULD are used The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
in capital letters. This conforms to the definitions in [2]. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2].
2. Overview of Domain Security Services 2. Overview of Domain Security Services
This section gives an informal overview of the security services that This section gives an informal overview of the security services that
are provided by S/MIME between different security domains. These are provided by S/MIME between different security domains. These
services are provided by a combination of mechanisms in the sender's and services are provided by a combination of mechanisms in the sender's and
recipient's domains. recipient's domains.
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.
skipping to change at line 179 skipping to change at line 180
and certificate which can be processed by the recipient(s). A domain and certificate which can be processed by the recipient(s). A domain
signature is sometimes referred to as an "organisational signature". 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 MAY check the review signature at the domain signature. An agent could check the review signature at the domain
boundary, to ensure that only reviewed messages are released. boundary, to ensure that only reviewed messages are released.
2.3 Additional Attributes Signature 2.3 Additional Attributes Signature
A third party MAY add additional attributes to a signed message. An A third party can add additional attributes to a signed message. An
S/MIME signature is used for this purpose - an additional attributes S/MIME signature is used for this purpose - an additional attributes
signature. An example of an additional attribute is the 'Equivalent signature. An example of an additional attribute is the 'Equivalent
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
skipping to change at line 225 skipping to change at line 226
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.
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 a null signature added to it (i.e. the 1) An unsigned message has an empty signature layer added to it (i.e.
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, will 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 so
that when the DOMSEC signature is added, as defined in method 2) that when the DOMSEC signature is added, as defined in method 2)
below, the signature will cover the unsigned message. The originator's below, the signature will cover the unsigned message.
information is included as part of a header field in the encapsulated
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'.
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
skipping to change at line 285 skipping to change at line 284
* For a domain signature, an agent generating this signature MUST be * For a domain signature, an agent generating this signature MUST be
named 'domain-signing-authority' named 'domain-signing-authority'
* For a review signature, an agent generating this signature MUST be * For a review signature, an agent generating this signature MUST be
named 'review-authority'. named 'review-authority'.
* For an additional attributes signature, an agent generating this * For an additional attributes signature, an agent generating this
signature MUST be named 'attribute-authority'. signature MUST be named 'attribute-authority'.
This name shall appear in 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. Additionally, if the subject field in the X.509 certificate. There MUST be only one CN
certificate contains an RFC 822 address, this name shall appear in component present. Additionally, if the certificate contains an RFC 822
the end entity component of the address - on the left-hand side of the address, this name shall appear in the end entity component 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 component of its name MUST be
the same as, or an ascendant of, the domain name of the message the 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 component 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 component is the country, organisation,
skipping to change at line 347 skipping to change at line 346
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 shall be rejected as invalid. convention should 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: -
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) id-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2)
us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28} us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28}
If present, the SignatureType attribute MUST be a signed attribute, as 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 the recipient
SHOULD assume that the signature is that of the message originator. SHOULD assume that the signature is that of the message originator.
Each of the signature types defined here are generated and processed All of the signatures defined here are generated and processed as
exactly as described in [5]. They are distinguished by the presence of described in [5]. They are distinguished by the presence of the
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-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 2 }
for a domain signature. -- domain signature.
id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-aa-signatureType id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-aa-signatureType
3} for an additional attributes signature. 3} -- additional attributes signature.
id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} for a 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}
for an originator's signature. -- originator's signature.
The originator signature MUST NOT encapsulate other signatures. The All signature types, except the originator type, MUST encapsulate other
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 a null 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
not present. not present.
If there is more than one SignerInfo in a signerInfos (i.e. when
different algorithms are used) then the SignatureType attribute in all
the SignerInfos MUST contain the same content.
The following sections describe the conditions under which each of these 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 originated in that domain. Before signing, a process generating a
skipping to change at line 437 skipping to change at line 440
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 MAY 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.
Alternatively, if a 'domain signature' has encapsulated a complete If there is no originator signature present, the only assumption that can
MIME-encoded message, the originator information (e.g. The SMTP 'From' be made is the domain the message originated from.
field) contained within it denotes the originator of the message.
If neither of these cases is true the only assumption that can be made
is the domain the message originated from.
A domain signer can be assumed to have verified any signatures that it 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.
There MAY be multiple '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.
All attributes in the applicable SignerInfo MUST be treated as All attributes in the applicable SignerInfo MUST be treated as
additional attributes. Successful verification of an 'additional additional attributes. Successful verification of an 'additional
attributes' signature means only that the attributes are authentically attributes' signature means only that the attributes are authentically
bound to the message. A recipient MUST NOT assume that its successful bound to the message. A recipient MUST NOT assume that its successful
verification also authenticates the message originator. verification also authenticates the message originator.
An entity generating an 'additional attributes' signature MUST do so An entity generating an 'additional attributes' signature MUST do so
using a certificate containing a subject name that follows the naming using a certificate containing a subject name that follows the naming
convention specified in 3.1.1. On reception, a check MUST be made to convention specified in 3.1.1. On reception, a check MUST be made to
ensure that the naming convention has been used. ensure that the naming convention has been used.
A signer MAY include any of the attributes listed in [5] or in this A signer MAY include any of the attributes listed in [3] or in this
document when generating an 'additional attributes' signature. The document when generating an 'additional attributes' signature. The
following attributes have a special meaning, when present in an following attributes have a special meaning, when present in an
'additional attributes' signature: 'additional attributes' signature:
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-aa-sigtype-add-attrib-sig in a 'signature type' signed
attribute. No other Object Identifiers MAY 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
has approved the message for onward transmission to the recipient(s). has approved the message for onward transmission to the recipient(s).
skipping to change at line 529 skipping to change at line 528
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-aa-sigtype-originator-sig in a 'signature type'
signed attribute. There MUST be only one 'originator signature' signed attribute.
signature present in an S/MIME encoding and it MUST be the inner most
signature.
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
processes are described in this section. processes are described in this section.
skipping to change at line 577 skipping to change at line 574
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.
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
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
key' is used as a collective term to cover the key management keys used key' is used as a collective term to cover the key management keys used
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
skipping to change at line 702 skipping to change at line 699
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. References 6. DOMSEC ASN.1 Module
DOMSECSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules. Other applications may use
-- them for their own purposes.
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2)
us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28}
id-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType
2 } -- domain signature.
id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= {
id-aa-signatureType 3} -- additional attributes signature.
id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4}
-- review signature.
id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= {
id-aa-signatureType 1} -- originator's signature.
END -- of DOMSECSyntax
7. References
[1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC2633, [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.
7. Authors' Addresses 8. 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 770 skipping to change at line 800
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 26th November 2000 This draft expires 12th January 2001
 End of changes. 

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