draft-ietf-smime-domsec-03.txt   draft-ietf-smime-domsec-04.txt 
Internet-Draft T Dean INTERNET-DRAFT T Dean
draft-ietf-smime-domsec-03.txt W Ottaway draft-ietf-smime-domsec-04.txt W Ottaway
Expires 19th April 2000 DERA Expires 8th September 2000 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 193 skipping to change at line 193
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 encryption capabilities at the desktop, or when two domains not have encryption capabilities at the desktop, or when two domains
employ incompatible encryption schemes internally. In the latter case employ incompatible encryption schemes internally. In the latter case
messages from the originator's domain are re-encrypted using an messages from the originator's domain are re-encrypted using an
algorithm, key, and certificate which can be decrypted by the algorithm, key, and certificate which can be decrypted by the
recipient(s) or an entity in their domain. recipient(s) or an entity in their domain.
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 complete 'signature encapsulation'. 'Signature encapsulation' denotes a signed
signed message that is wrapped in a second signature, the second or unsigned message that is wrapped in a signature, this signature
signature covering both the content and the first (inner) signature. 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. The term 'parallel signatures' signature of a triple-wrapped message.
means two or more signatures calculated over the same content. This
capability is described in CMS [3], where a set of one or more
SignerInfos can be attached to signed data.
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
ways:
1) An unsigned message has a null signature added to it (i.e. the
message is wrapped in a signedData that has a signerInfos which
contains no elements). This is to enable backward compatibility with
S/MIME software that does not have a DOMSEC capability. Since the
signerInfos will contain no signers the eContentType, within the
EncapsulatedContentInfo will be id-data as described in CMS [5].
However, the eContent field will contain the unsigned message instead
of being left empty as suggested in section 5.2 in CMS [5]. This is so
that when the DOMSEC signature is added, as defined in method 2)
below, the signature will cover the unsigned message The originator's
information is included as part of a header field in the encapsulated
message.
2) Signature Encapsulation is used to wrap the original signed message
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 draft require the recipient to message security services defined in this document require the recipient
be able accept messages signed by other entities and the originator. to be able accept messages signed by other entities and the originator.
When other entities sign the message the name in the certificate will When other entities sign the message the name in the certificate will
not match the message senders name. An S/MIME implementation would flag not match the message senders name. An S/MIME compliant implementation
an error if there were a mismatch between the name in the certificate would normally flag a warning if there were a mismatch between the name
and the message sender's name. (This check prevents a number of types of in the certificate and the message sender's name. (This check prevents a
masquerade attack.) number of types of masquerade attack.)
To resolve this incompatibility, this document defines a naming In the case of domain security services, this warning condition SHOULD
convention that specifies the form that the signing agents name SHOULD be suppressed under certain circumstances. These circumstances are
take. Adherence to this naming convention avoids the problems of defined by a naming convention that specifies the form that the signers
uncontrolled naming and the possible masquerade attacks that this would name SHOULD adher to. Adherence to this naming convention avoids the
produce. problems of uncontrolled naming and the possible masquerade attacks that
this would produce.
As an assistance to implementation, a signed attribute is defined to be As an assistance to implementation, a signed attribute is defined to be
included in the S/MIME signature - the 'signature type' attribute. On included in the S/MIME signature - the 'signature type' attribute. On
receiving a message containing this attribute, the naming convention receiving a message containing this attribute, the naming convention
checks are invoked. checks are invoked.
Implementations conforming to this standard MUST support the naming Implementations conforming to this standard MUST support the naming
convention for signature generation and verification. Implementations convention for signature generation and verification. Implementations
conforming to this standard MUST recognise the signature type attribute conforming to this standard MUST recognise the signature type attribute
for signature verification. Implementations conforming to this standard for signature verification. Implementations conforming to this standard
SHOULD support the signature type attribute for signature generation; MUST support the signature type attribute for signature generation.
however, this is not mandated.
3.1.1 Naming conventions 3.1.1 Naming conventions
The following naming conventions are specified for agents generating The following naming conventions are specified for agents generating
signatures specified in this document: signatures specified in this document:
* 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
skipping to change at line 307 skipping to change at line 323
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 shall be rejected as invalid.
3.1.2 Signature type attribute 3.1.2 Signature type attribute
An S/MIME authenticated attribute is also used to indicate the type of An S/MIME authenticated attribute is used to indicate the type of
signature. This should be used in conjunction with the naming signature. This should be used in conjunction with the naming
conventions specified in the previous section. When an S/MIME signed conventions specified in the previous section. When an S/MIME signed
message containing the signature type attribute is received it triggers message containing the signature type attribute is received it triggers
the software to verify that the correct naming convention has been used. the software to verify 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-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) id-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2)
skipping to change at line 346 skipping to change at line 362
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-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-signatureType 1} id-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-signatureType 1}
for an originator's signature. for an originator's signature.
The originator signature MUST NOT encapsulate other signatures. The The originator signature MUST NOT encapsulate other signatures. The
other signature types specified in this document MAY encapsulate other other signature types specified in this document MUST encapsulate other
signatures. All the signature types MAY be added in parallel to other signatures.
signatures as documented in [5].
A SignerInfo MUST NOT include multiple instances of SignatureType. An A SignerInfo MUST NOT include multiple instances of SignatureType. An
authenticated attribute representing a SignatureType MAY include authenticated attribute representing a SignatureType MAY include
multiple instances of different SignatureType values as an multiple instances of different SignatureType values as an
AttributeValue of attrValues [5], as long as the SignatureType AttributeValue of attrValues [5], as long as the SignatureType
'additional attributes' is not present. 'additional attributes' is not present.
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.
skipping to change at line 375 skipping to change at line 390
originated in that domain. Before signing, a process generating a originated in that domain. Before signing, a process generating a
'domain signature' MUST first satisfy itself of the authenticity of the 'domain signature' MUST first satisfy itself of the authenticity of the
message originator. This is achieved by one of two methods. Either the message originator. This is achieved by one of two methods. Either the
'originator's signature' is checked, if S/MIME signatures are used 'originator's signature' is checked, if S/MIME signatures are used
inside a domain. Or if not, some mechanism external to S/MIME is used, inside a domain. Or if not, some mechanism external to S/MIME is used,
such as the physical address of the originating client or an such as the physical address of the originating client or an
authenticated IP link. authenticated IP link.
If the originator's authenticity is successfully verified by one of the If the originator's authenticity is successfully verified by one of the
above methods and all other signatures present are valid, a 'domain above methods and all other signatures present are valid, a 'domain
signature' MAY be added to a message in one of the following ways: signature' MAY be added to a message.
1) An unsigned message has a null signature added to it (i.e. the
message is wrapped in a signedData that has no signerInfo attached),
and then a 'domain signature' is added as defined in methods 2) or 3)
below. The originator's information is included as part of a header
field in the encapsulated message.
2) Signature Encapsulation is used to wrap the original signed message
with a 'domain signature'.
3) The original signed message has a 'domain signature' added in
parallel.
An entity generating a domain signature MUST do so using a certificate An entity generating a domain signature MUST do so using a certificate
containing a subject name that follows the naming convention specified containing a subject name that follows the naming convention specified
in 3.1.1. in 3.1.1.
When a 'domain signature' is applied the mlExpansionHistory and When a 'domain signature' is applied the mlExpansionHistory and
eSSSecurityLabel attributes MUST be copied from other signerInfos as eSSSecurityLabel attributes MUST be copied from other signerInfos as
stated in [3]. stated in [3].
If the originator's authenticity is not successfully verified or all If the originator's authenticity is not successfully verified or all
skipping to change at line 414 skipping to change at line 417
specified in this standard. specified in this standard.
A recipient MAY assume that successful verification of the domain A recipient MAY 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 Alternatively, if a 'domain signature' has encapsulated a complete
MIME-encoded message, the originator information (SMTP 'From' field) MIME-encoded message, the originator information (e.g. The SMTP 'From'
contained within it denotes the originator of the message. field) contained within it denotes the originator of the message.
If neither of these cases is true no assumptions can be made about the If neither of these cases is true the only assumption that can be made
originator. 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-at-sigtype-domain-sig in a 'signature type' authenticated attribute. Id-at-sigtype-domain-sig in a 'signature type' authenticated attribute.
skipping to change at line 466 skipping to change at line 469
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-at-sigtype-add-attrib-sig in a 'signature type' authenticated value Id-at-sigtype-add-attrib-sig in a 'signature type' authenticated
attribute. No other Object Identifiers MAY be included in the sequence attribute. No other Object Identifiers MAY be included in the sequence
of OIDs if this value is present. An 'additional attributes' signature of OIDs if this value is present.
MAY be added in parallel with other signatures in a SET OF SignerInfos.
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).
When the recipient is in another domain, a device on a domain boundary When the recipient is in another domain, a device on a domain boundary
skipping to change at line 500 skipping to change at line 502
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-sigtype-originator-sig in a 'signature type' presence of the value id-sigtype-originator-sig in a 'signature type'
authenticated attribute. There MUST be only one 'originator signature' authenticated attribute. There MUST be only one 'originator signature'
signature present in an S/MIME encoding and it MUST be one of the inner signature present in an S/MIME encoding and it MUST be the inner most
most signatures. signature.
4. Encryption and Decryption 4. Encryption and Decryption
Domain encryption is encryption performed by a third party on behalf of Message encryption may be performed by a third party on behalf of a set
a set of originators in a domain. Domain decryption is decryption of originators in a domain. This is referred to as domain encryption.
performed by a third party on behalf of a set of recipients in a domain. 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.
Depending on security policy, messages may be encrypted for decryption The third party that performs these processes is referred to in this
by the final recipient and by a domain decryption agent in the section as a "Domain Confidentiality Authority" (DCA). Both of these
originator's and/or the recipient's domain. This is achieved by processes are described in this section.
generating a RecipientInfo for each type of agent that is transmitted
along with the encrypted message.
The processes of domain encryption and decryption may be performed in Messages may be encrypted for decryption by the final recipient and/or
combination, as shown below. by a DCA in the recipient's domain. The message may also be encrypted
for decryption by a DCA in the originator's domain (e.g. for content
analysis, audit, key word scanning, etc.). The choice of which of these
is actually performed is a system specific issue that depends on system
security policy. It is therefore outside the scope of this document.
These processes of encryption and decryption processes are shown in the
following table.
-------------------------------------------------------------------- --------------------------------------------------------------------
| | Recipient Decryption | Domain Decryption | | | Recipient Decryption | Domain Decryption |
|------------------------|----------------------|--------------------| |------------------------|----------------------|--------------------|
| Originator Encryption | Case(a) | Case(c) | | Originator Encryption | Case(a) | Case(b) |
| Domain Encryption | Case(b) | Case(d) | | Domain Encryption | Case(c) | Case(d) |
-------------------------------------------------------------------- --------------------------------------------------------------------
Case (a), encryption of messages by the originator for decryption by the Case (a), encryption of messages by the originator for decryption by the
final recipient(s), is described in CMS [5]. In Cases (b) and (d), final recipient(s), is described in CMS [5]. In cases (c) and (d),
encryption is performed not by the originator but by a third party in encryption is performed not by the originator but by the DCA in the
the sending domain. In Cases (c) and (d), decryption is performed not by originator's domain. In Cases (b) and (d), decryption is performed not
the recipient(s) but by a third party in the destination domain. by the recipient(s) but by the DCA in the recipient's domain.
A client implementation that conforms to this standard MUST support A client implementation that conforms to this standard MUST support
cases (a) and (c) for transmission, and cases (a) and (b) for reception. case (b) for transmission, case (c) for reception and case (a) for
transmission and reception.
A Domain Encryption implementation that conforms to this standard MUST A DCA implementation that conforms to this standard MUST support cases
support cases (b) and (d), for transmission, and cases (c) and (d) for (c) and (d), for transmission, and cases (b) and (d) for reception.
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. 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.
4.1 Domain Encryption Naming Conventions 4.1 Domain Confidentiality Naming Conventions
A domain encryption agent MUST be named 'domain-confidentiality- A DCA MUST be named 'domain-confidentiality-authority'. This name MUST
authority'. Also a domain decryption agent MUST be named 'domain- appear in the 'common name(CN)' component of the subject field in the
confidentiality-authority'. This name MUST appear in the 'common name X.509 certificate. Additionally, if the certificate contains an SMTP
(CN)' component of the subject field in the X.509 certificate. e-mail address, this name MUST appear in the end entity component of
Additionally, if the certificate contains an SMTP e-mail address, this the address - on the left-hand side of the '@' symbol.
name MUST appear in the end entity component of the address - 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 an the 'name mapping rule'. The name mapping rule states that for a DCA,
encryption agent, the domain component of its name MUST be the same as, the domain component of its name MUST be the same as, or an ascendant
or an ascendant of, the domain name of the set of entities that it of, the domain name of the set of entities that it represents. The
represents. The domain component is defined as follows: domain component 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 component 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 SMTP e-mail address, the domain * If the certificate contains an SMTP e-mail address, the domain
component is defined to be the SMTP address component on the right- component is defined to be the SMTP address component on the right-
hand side of the '@' symbol. hand side of the '@' symbol.
For example, an encryption authority acting on behalf of John Doe of the For example, a DCA acting on behalf of John Doe of the Acme
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 address 'cn=domain-confidentiality-authority, o=acme,c=us' and an e-mail
of 'domain-confidentiality-authority@acme.com'. The key associated with address of 'domain-confidentiality-authority@acme.com'. The key
this certificate would be used for encrypting messages for John Doe. 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 component of the domain encrypting
agents name does not match, or is not an ascendant of, the domain name agents name does not match, or is not an ascendant of, the domain name
of the entities it represents MUST be rejected. of the entities it represents MUST be rejected.
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 Domain Encryption Key Management 4.2 Key Management for Domain Encryption
Domain encryption is encryption performed by a third party on behalf of Domain encryption may be performed for decryption by the end recipient
a set of originators in a domain. Domain Encryption is shown as cases and/or by a DCA. End recipient decryption is described in CMS [5]. DCA
(b) and (d) in the above table. decryption is described in the next section.
Domain encryption uses a domain-wide encryption key from the sender's Domain encryption uses a domain-wide encryption key from the sender's
domain. Information about this key is conveyed to the recipient in the domain. This Key is owned by the DCA for the sender's domain.
RecipientInfo field as specified in CMS [5]. A domain encryption agent Information about this key is conveyed to the recipient in the
recipientInfo field as specified in CMS [5]. A domain encryption agent
MUST be named according to the naming convention specified in section MUST be named according to the naming convention specified in section
4.1. This is so that the same key can be used on reply to a domain- 4.1. This is so that the same key can be used on reply to a domain-
encrypted message. encrypted message.
The domain encryption agent extracts the recipients address from the 4.3 Key Management for Domain Decryption
message and uses this to obtain the recipients domain-confidentiality-
authority public key and/or the recipients public key. For example,
the recipients address is used as an index for a directory search. The
directory search MAY return the recipients certificate and/or a domain-
confidentiality-authority attribute that contains the location of the
recipient's domain decrytping agents certificate. If the directory
search returns no certificates then encryption can not be performed and
the message MUST NOT be sent. If one or both certificates are available
then the originator's domain encrypting agent encrypts the message for
the recipient and the recipient's domain decrypting agent.
4.3 Domain Decryption Key Management Domain decryption can be performed on messages encrypted by the
originator and/or by a DCA in the originator's domain. In the first
case, the encryption process is described in CMS [5]; in the second
case, the encryption process is described in 4.2.
Domain decryption is decryption performed by a third party on behalf of Domain decryption uses a domain-wide decryption key from the recipient's
a set of recipients in a domain. domain. This key is owned by the DCA for the recipient domain. In order
to locate the correct key, the certificate corresponding to the DCA must
be located. It is vital that the naming conventions specified in 4.1 are
adhered to, in order to maintain confidentiality.
Domain Decryption is shown as cases (c) and (d) in the above table. In No specific method for locating this certificate is mandated in this
these cases, the encryption process has used a domain-wide encryption document. An implementation may choose to access a local certificate
key for the recipient(s)' domain, that has been obtained by using the store to locate the correct certificate. Alternatively, a directory may
recipient's address (See example in section 4.2). be used in one of the following ways:
1. The directory may store the DCA certificate in the recipient's
directory entry. When the user certificate attribute is requested,
this certificate is returned.
2. The encrypting agent maps the recipient`s name to the DCA name in the
manner specified in 4.1. The user certificate attribute associated
with this directory entry is then obtained.
This document does not mandate either of these processes. Whichever one
is used, the name mapping conventions must be adhered to, in order to
maintain confidentiality.
Having located the correct certificate, the encryption process is then
performed. A recipientInfo for the DCA is then generated, as described
in CMS [5].
5. Security Considerations 5. Security Considerations
Implementations MUST protect all private keys. Compromise of the Implementations MUST protect all private keys. Compromise of the
signer's private key permits masquerade. signer's private key permits masquerade.
Similarly, compromise of the content-encryption key may result in Similarly, compromise of the content-encryption key may result in
disclosure of the encrypted content. disclosure of the encrypted content.
Compromise of key material is regarded as an even more serious issue for Compromise of key material is regarded as an even more serious issue for
skipping to change at line 685 skipping to change at line 703
DERA Malvern DERA Malvern
St. Andrews Road St. Andrews Road
Malvern Malvern
Worcs Worcs
WR14 3PS WR14 3PS
Phone: +44 (0) 1684 894079 Phone: +44 (0) 1684 894079
Fax: +44 (0) 1684 896660 Fax: +44 (0) 1684 896660
Email: w.ottaway@eris.dera.gov.uk Email: w.ottaway@eris.dera.gov.uk
This draft expires 19th April 2000 8. Full Copyright Statement
"Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
This draft expires 8th September 2000
 End of changes. 

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