idnits 2.17.1
draft-ietf-smime-domsec-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 731 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 715 has weird spacing: '...for the purpo...'
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- Couldn't find a document date in the document -- date freshness check
skipped.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 2633 (ref. '1') (Obsoleted by RFC 3851)
-- Possible downref: Non-RFC (?) normative reference: ref. '4'
** Obsolete normative reference: RFC 2630 (ref. '5') (Obsoleted by RFC
3369, RFC 3370)
Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 INTERNET-DRAFT T Dean
2 draft-ietf-smime-domsec-04.txt W Ottaway
3 Expires 8th September 2000 DERA
5 Domain Security Services using S/MIME
7 Status of this memo
9 This document is an Internet-Draft and is in full conformance with all
10 provisions of section 10 of RFC2026. Internet-Drafts are working
11 documents of the Internet Engineering Task Force (IETF), its areas, and
12 its working groups. Note that other groups may also distribute working
13 documents as Internet-Drafts.
15 Internet-Drafts are draft documents valid for a maximum of six months
16 and may be updated, replaced, or obsoleted by other documents at any
17 time. It is inappropriate to use Internet-Drafts as reference material
18 or to cite them other than as "work in progress."
20 The list of current Internet-Drafts can be accessed at
21 http://www.ietf.org/ietf/1id-abstracts.txt
23 The list of Internet-Draft Shadow Directories can be accessed at
24 http://www.ietf.org/shadow.html.
26 Abstract
28 This document describes how the S/MIME protocol can be processed and
29 generated by a number of components of a communication system, such as
30 message transfer agents, guards and gateways to deliver security
31 services. These services are collectively referred to as 'Domain
32 Security Services'. The mechanisms described in this document are
33 designed to solve a number of interoperability problems and technical
34 limitations that arise when different security domains wish to
35 communicate securely - for example when two domains use incompatible
36 messaging technologies such as X.400 and SMTP/MIME. This document is
37 also applicable to organisations and enterprises that have internal PKIs
38 which are not accessible by the outside world, but wish to interoperate
39 securely using the S/MIME protocol.
41 This draft is being discussed on the 'ietf-smime' mailing list. To
42 subscribe, send a message to:
43 ietf-smime-request@imc.org
44 with the single word
45 subscribe
46 in the body of the message. There is a Web site for the mailing list at
47 .
49 Acknowledgements
51 Significant comments were made by Trevor Freeman, Russ Housley,
52 Dave Kemp, Jim Schaad, Greg Colla and Michael Zolotarev.
54 1. Introduction
56 The S/MIME [1] series of standards define a data encapsulation format
57 for the provision of a number of security services including data
58 integrity, confidentiality, and authentication. S/MIME is designed for
59 use by messaging clients to deliver security services to distributed
60 messaging applications.
62 There are many circumstances when it is not desirable or practical to
63 provide end-to-end (desktop-to-desktop) security services, particularly
64 between different security domains. An organisation that is considering
65 providing end-to-end security services will typically have to deal with
66 some if not all of the following issues:
68 1) Heterogeneous Message Access Methods: Users are accessing mail using
69 mechanisms which re-format messages, such as using Web browsers.
70 Message reformatting in the Message Store makes end-to-end encryption
71 and signature validation impossible.
73 2) Message screening and audit: Server-based mechanisms such as
74 searching for prohibited words or other content, virus scanning, and
75 audit, are incompatible with end-to-end encryption.
77 3) PKI deployment issues: There may not be any certificate paths between
78 two organisations. Or an organisation may be sensitive about aspects
79 of its PKI and unwilling to expose them to outside access. For either
80 of these reasons, direct end-to-end signature validation and
81 encryption are impossible.
83 4) Heterogeneous Message transports: One organisation using X.400 wishes
84 to communicate with another using SMTP. Message reformatting at
85 gateways makes end-to-end encryption and signature validation
86 impossible.
88 This document describes an approach to solving these problems by
89 providing message security services at the level of a domain or an
90 organisation. This document specifies how these 'domain security
91 services' can be provided using the S/MIME protocol. Domain security
92 services may replace or complement mechanisms at the desktop. For
93 example, a domain may decide to provide desktop-to-desktop signatures
94 but domain-to-domain encryption services. Or it may allow desktop-to-
95 desktop services for intra-domain use, but enforce domain-based services
96 for communication with other domains.
98 Whether or not a domain based service is inherently better or worse than
99 desktop based solutions is an open question. Some experts believe that
100 only end-to-end solutions can be truly made secure, while others believe
101 that the benefits offered by such things as content checking at domain
102 boundaries offers considerable increase in practical security for many
103 real systems. The additional service of allowing signature checking at
104 several points on a communications path is also an extra benefit in many
105 situations. This debate is outside the scope of this document. What is
106 offered here is a set of tools that integrators can tailor in different
107 ways to meet different needs in different circumstances.
109 Message transfer agents (MTAs), guards, firewalls and protocol
110 translation gateways all provide domain security services. As with
111 desktop based solutions, these components must be resilient against a
112 wide variety of attacks intended to subvert the security services.
113 Therefore, careful consideration should be given to security of these
114 components, to make sure that their siting and configuration minimises
115 the possibility of attack.
117 Throughout this draft the terms MAY, MUST, MUST NOT and SHOULD are used
118 in capital letters. This conforms to the definitions in [2].
120 2. Overview of Domain Security Services
122 This section gives an informal overview of the security services that
123 are provided by S/MIME between different security domains. These
124 services are provided by a combination of mechanisms in the sender's and
125 recipient's domains.
127 Later sections describe definitively how these services map onto
128 elements of the S/MIME protocol.
130 The following security mechanisms are specified in this document:
132 1. Domain signature
133 2. Review signature
134 3. Additional attributes signature
135 4. Domain encryption and decryption
137 The term 'security domain' as used in this document is defined as a
138 collection of hardware and personnel operating under a single security
139 authority and performing a common business function. Members of a
140 security domain will of necessity share a high degree of mutual trust,
141 due to their shared aims and objectives.
143 A security domain is typically protected from direct outside attack by
144 physical measures and from indirect (electronic) attack by a combination
145 of firewalls and guards at network boundaries. The interface between two
146 security domains is termed a 'security boundary'. One example of a
147 security domain is an organisational network ('Intranet').
149 2.1 Domain Signature
151 A Domain signature is an S/MIME signature generated on behalf of a set
152 of users in a domain. A Domain signature can be used to authenticate
153 information sent between domains, for example, when two 'Intranets' are
154 connected using the Internet. It can be used when two domains employ
155 incompatible signature schemes internally or when there are no
156 certification links between their PKIs. In both cases messages from the
157 originator's domain are signed over the original message and signature
158 (if present) using an algorithm, key, and certificate which can be
159 processed by the recipient(s). A domain signature is sometimes referred
160 to as an "organisational signature".
162 2.2 Review Signature
164 A third party may review messages before they are forwarded to the final
165 recipient(s) who may be in the same or a different security domain.
166 Organisational policy and good security practice often require that
167 messages be reviewed before they are released to external recipients.
168 Having reviewed a message, an S/MIME signature is added to it - a review
169 signature. An agent MAY check the review signature at the domain
170 boundary, to ensure that only reviewed messages are released.
172 2.3 Additional Attributes Signature
174 A third party MAY add additional attributes to a signed message. An
175 S/MIME signature is used for this purpose - an additional attributes
176 signature. An example of an additional attribute is the 'Equivalent
177 Label' attribute defined in ESS [3].
179 2.4 Domain Encryption and Decryption
181 Domain encryption is S/MIME encryption performed on behalf of a
182 collection of users in a domain. Domain encryption can be used to
183 protect information between domains, for example, when two 'Intranets'
184 are connected using the Internet. It can also be used when end users do
185 not have encryption capabilities at the desktop, or when two domains
186 employ incompatible encryption schemes internally. In the latter case
187 messages from the originator's domain are re-encrypted using an
188 algorithm, key, and certificate which can be decrypted by the
189 recipient(s) or an entity in their domain.
191 3. Mapping of the Signature Services to the S/MIME Protocol
193 This section describes the S/MIME protocol elements that are used to
194 provide the security services described above. ESS [3] introduces the
195 concept of triple-wrapped messages that are first signed, then
196 encrypted, then signed again. This document also uses this concept of
197 triple-wrapping. In addition, this document also uses the concept of
198 'signature encapsulation'. 'Signature encapsulation' denotes a signed
199 or unsigned message that is wrapped in a signature, this signature
200 covering both the content and the first (inner) signature, if present.
202 Signature encapsulation MAY be performed on the inner and/or the outer
203 signature of a triple-wrapped message.
205 For example, the originator signs a message which is then encapsulated
206 with an 'additional attributes' signature. This is then encrypted. A
207 reviewer then signs this encrypted data, which is then encapsulated by
208 a domain signature.
210 A DOMSEC signature MAY encapsulate a message in one of the following
211 ways:
213 1) An unsigned message has a null signature added to it (i.e. the
214 message is wrapped in a signedData that has a signerInfos which
215 contains no elements). This is to enable backward compatibility with
216 S/MIME software that does not have a DOMSEC capability. Since the
217 signerInfos will contain no signers the eContentType, within the
218 EncapsulatedContentInfo will be id-data as described in CMS [5].
219 However, the eContent field will contain the unsigned message instead
220 of being left empty as suggested in section 5.2 in CMS [5]. This is so
221 that when the DOMSEC signature is added, as defined in method 2)
222 below, the signature will cover the unsigned message The originator's
223 information is included as part of a header field in the encapsulated
224 message.
226 2) Signature Encapsulation is used to wrap the original signed message
227 with a 'domain signature'.
229 3.1 Naming conventions and Signature Types
231 An entity receiving an S/MIME signed message would normally expect the
232 signature to be that of the originator of the message. However, the
233 message security services defined in this document require the recipient
234 to be able accept messages signed by other entities and the originator.
235 When other entities sign the message the name in the certificate will
236 not match the message senders name. An S/MIME compliant implementation
237 would normally flag a warning if there were a mismatch between the name
238 in the certificate and the message sender's name. (This check prevents a
239 number of types of masquerade attack.)
241 In the case of domain security services, this warning condition SHOULD
242 be suppressed under certain circumstances. These circumstances are
243 defined by a naming convention that specifies the form that the signers
244 name SHOULD adher to. Adherence to this naming convention avoids the
245 problems of uncontrolled naming and the possible masquerade attacks that
246 this would produce.
248 As an assistance to implementation, a signed attribute is defined to be
249 included in the S/MIME signature - the 'signature type' attribute. On
250 receiving a message containing this attribute, the naming convention
251 checks are invoked.
253 Implementations conforming to this standard MUST support the naming
254 convention for signature generation and verification. Implementations
255 conforming to this standard MUST recognise the signature type attribute
256 for signature verification. Implementations conforming to this standard
257 MUST support the signature type attribute for signature generation.
259 3.1.1 Naming conventions
261 The following naming conventions are specified for agents generating
262 signatures specified in this document:
264 * For a domain signature, an agent generating this signature MUST be
265 named 'domain-signing-authority'
267 * For a review signature, an agent generating this signature MUST be
268 named 'review-authority'.
270 * For an additional attributes signature, an agent generating this
271 signature MUST be named 'attribute-authority'.
273 This name shall appear in the 'common name (CN)' component of the
274 subject field in the X.509 certificate. Additionally, if the
275 certificate contains an SMTP e-mail address, this name shall appear in
276 the end entity component of the address - on the left-hand side of the
277 '@' symbol.
279 In the case of a domain signature, an additional naming rule is
280 defined: the 'name mapping rule'. The name mapping rule states that
281 for a domain signing authority, the domain component of its name MUST be
282 the same as, or an ascendant of, the domain name of the message
283 originator(s) that it is representing. The domain component is defined
284 as follows:
286 * In the case of an X.500 distinguished subject name of an X.509
287 certificate, the domain component is the country, organisation,
288 organisational unit, state, and locality components of the
289 distinguished name.
291 * If the certificate contains an SMTP e-mail address, the domain
292 component is defined to be the SMTP address component on the right-
293 hand side of the '@' symbol.
295 For example, a domain signing authority acting on behalf of John Doe of
296 the Acme corporation, whose distinguished name is 'cn=John Doe,
297 ou=marketing,o=acme,c=us' and whose e-mail address is
298 John.Doe@marketing.acme.com, could have a certificate containing a
299 distinguished name of 'cn=domain-signing-authority, o=acme,c=us' and an
300 e-mail address of 'domain-signing-authority@acme.com'.
302 Any message received where the domain component of the domain signing
303 agents name does not match, or is not an ascendant of, the originator's
304 domain name MUST be rejected.
306 This naming rule prevents agents from one organisation masquerading as
307 domain signing authorities on behalf of another. For the other types of
308 signature defined in this document, no such named mapping rule is
309 defined.
311 Implementations conforming to this standard MUST support this name
312 mapping convention as a minimum. Implementations MAY choose to
313 supplement this convention with other locally defined conventions.
314 However, these MUST be agreed between sender and recipient domains prior
315 to secure exchange of messages.
317 On verifying the signature, a receiving agent MUST ensure that the
318 naming convention has been adhered to. Any message that violates the
319 convention shall be rejected as invalid.
321 3.1.2 Signature type attribute
323 An S/MIME authenticated attribute is used to indicate the type of
324 signature. This should be used in conjunction with the naming
325 conventions specified in the previous section. When an S/MIME signed
326 message containing the signature type attribute is received it triggers
327 the software to verify that the correct naming convention has been used.
329 The ASN.1 [4] notation of this attribute is: -
331 SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
333 id-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2)
334 us (840) rsadsi (113549) }
336 If present, the SignatureType attribute MUST be an authenticated
337 attribute, as defined in [5]. If the SignatureType attribute is absent
338 the recipient SHOULD assume that the signature is that of the message
339 originator.
341 Each of the signature types defined here are generated and processed
342 exactly as described in [5]. They are distinguished by the presence of
343 the following values in the SignatureType authenticated attribute:
345 id-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-signatureType 2 } for a
346 domain signature.
348 id-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-signatureType 3}
349 for an additional attributes signature.
351 id-sigtype-review OBJECT IDENTIFIER ::= { id-signatureType 4} for a
352 review signature.
354 For completeness, an attribute type is also specified for an originator
355 signature. However, this signature type is optional. It is defined as
356 follows:
358 id-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-signatureType 1}
359 for an originator's signature.
361 The originator signature MUST NOT encapsulate other signatures. The
362 other signature types specified in this document MUST encapsulate other
363 signatures.
365 A SignerInfo MUST NOT include multiple instances of SignatureType. An
366 authenticated attribute representing a SignatureType MAY include
367 multiple instances of different SignatureType values as an
368 AttributeValue of attrValues [5], as long as the SignatureType
369 'additional attributes' is not present.
371 The following sections describe the conditions under which each of these
372 types of signature may be generated, and how they are processed.
374 3.2 Domain Signature Generation and Verification
376 A 'domain signature' is a proxy signature generated on a user's behalf
377 in the user's domain. The signature MUST adhere to the naming
378 conventions in 3.1.1, including the name mapping convention. A 'domain
379 signature' on a message authenticates the fact that the message has
380 originated in that domain. Before signing, a process generating a
381 'domain signature' MUST first satisfy itself of the authenticity of the
382 message originator. This is achieved by one of two methods. Either the
383 'originator's signature' is checked, if S/MIME signatures are used
384 inside a domain. Or if not, some mechanism external to S/MIME is used,
385 such as the physical address of the originating client or an
386 authenticated IP link.
388 If the originator's authenticity is successfully verified by one of the
389 above methods and all other signatures present are valid, a 'domain
390 signature' MAY be added to a message.
392 An entity generating a domain signature MUST do so using a certificate
393 containing a subject name that follows the naming convention specified
394 in 3.1.1.
396 When a 'domain signature' is applied the mlExpansionHistory and
397 eSSSecurityLabel attributes MUST be copied from other signerInfos as
398 stated in [3].
400 If the originator's authenticity is not successfully verified or all
401 the signatures present are not valid, a 'domain signature' MUST NOT be
402 generated.
404 On reception, the 'domain signature' SHOULD be used to verify the
405 authenticity of a message. A check MUST be made to ensure that both the
406 naming convention and the name mapping convention have been used as
407 specified in this standard.
409 A recipient MAY assume that successful verification of the domain
410 signature also authenticates the message originator.
412 If there is an originator signature present, the name in that
413 certificate SHOULD be used to identify the originator. This information
414 can then be displayed to the recipient.
416 Alternatively, if a 'domain signature' has encapsulated a complete
417 MIME-encoded message, the originator information (e.g. The SMTP 'From'
418 field) contained within it denotes the originator of the message.
420 If neither of these cases is true the only assumption that can be made
421 is the domain the message originated from.
423 A domain signer can be assumed to have verified any signatures that it
424 encapsulates. Therefore, it is not necessary to verify these signatures
425 before treating the message as authentic. However, this standard does
426 not preclude a recipient from attempting to verify any other signatures
427 that are present.
429 The 'domain signature' is indicated by the presence of the value
430 Id-at-sigtype-domain-sig in a 'signature type' authenticated attribute.
432 There MAY be multiple 'domain signature' signatures in an S/MIME
433 encoding.
435 3.3 Additional Attributes Signature generation and verification
437 The 'additional attributes' signature type indicates that the
438 SignerInfo contains additional attributes that are associated with the
439 message.
441 All attributes in the applicable SignerInfo MUST be treated as
442 additional attributes. Successful verification of an 'additional
443 attributes' signature means only that the attributes are authentically
444 bound to the message. A recipient MUST NOT assume that its successful
445 verification also authenticates the message originator.
447 An entity generating an 'additional attributes' signature MUST do so
448 using a certificate containing a subject name that follows the naming
449 convention specified in 3.1.1. On reception, a check MUST be made to
450 ensure that the naming convention has been used.
452 A signer MAY include any of the attributes listed in [5] or in this
453 document when generating an 'additional attributes' signature. The
454 following attributes have a special meaning, when present in an
455 'additional attributes' signature:
457 1) Equivalent Label: label values in this attribute are to be treated as
458 equivalent to the security label contained in an encapsulated
459 SignerInfo, if present.
461 2) Security Label: the label value indicates the aggregate sensitivity
462 of the inner message content plus any encapsulated signedData and
463 envelopedData containers. The label on the original data is indicated
464 by the value in the originator's signature, if present.
466 An 'additional attributes' signature is indicated by the presence of the
467 value Id-at-sigtype-add-attrib-sig in a 'signature type' authenticated
468 attribute. No other Object Identifiers MAY be included in the sequence
469 of OIDs if this value is present.
471 There MAY be multiple 'additional attributes' signatures in an S/MIME
472 encoding.
474 3.4 Review Signature generation and verification
476 The review signature indicates that the signer has reviewed the message.
477 Successful verification of a review signature means only that the signer
478 has approved the message for onward transmission to the recipient(s).
479 When the recipient is in another domain, a device on a domain boundary
480 such as a Mail Guard or firewall may be configured to check review
481 signatures. A recipient MUST NOT assume that its successful verification
482 also authenticates the message originator.
484 An entity generating a signed review signature MUST do so using a
485 certificate containing a subject name that follows the naming convention
486 specified in 3.1.1. On reception, a check MUST be made to ensure that
487 the naming convention has been used.
489 A review signature is indicated by the presence of the value
490 Id-at-sigtype-review-sig in a 'signature type' authenticated attribute.
492 There MAY be multiple review signatures in an S/MIME encoding.
494 3.5 Originator Signature
496 The 'originator signature' is used to indicate that the signer is the
497 originator of the message and its contents. It is included in this
498 document for completeness only. An originator signature is indicated
499 either by the absence of the signature type attribute, or by the
500 presence of the value id-sigtype-originator-sig in a 'signature type'
501 authenticated attribute. There MUST be only one 'originator signature'
502 signature present in an S/MIME encoding and it MUST be the inner most
503 signature.
505 4. Encryption and Decryption
507 Message encryption may be performed by a third party on behalf of a set
508 of originators in a domain. This is referred to as domain encryption.
509 Message decryption may be performed by a third party on behalf of a set
510 of recipients in a domain. This is referred to as domain decryption.
511 The third party that performs these processes is referred to in this
512 section as a "Domain Confidentiality Authority" (DCA). Both of these
513 processes are described in this section.
515 Messages may be encrypted for decryption by the final recipient and/or
516 by a DCA in the recipient's domain. The message may also be encrypted
517 for decryption by a DCA in the originator's domain (e.g. for content
518 analysis, audit, key word scanning, etc.). The choice of which of these
519 is actually performed is a system specific issue that depends on system
520 security policy. It is therefore outside the scope of this document.
521 These processes of encryption and decryption processes are shown in the
522 following table.
524 --------------------------------------------------------------------
525 | | Recipient Decryption | Domain Decryption |
526 |------------------------|----------------------|--------------------|
527 | Originator Encryption | Case(a) | Case(b) |
528 | Domain Encryption | Case(c) | Case(d) |
529 --------------------------------------------------------------------
531 Case (a), encryption of messages by the originator for decryption by the
532 final recipient(s), is described in CMS [5]. In cases (c) and (d),
533 encryption is performed not by the originator but by the DCA in the
534 originator's domain. In Cases (b) and (d), decryption is performed not
535 by the recipient(s) but by the DCA in the recipient's domain.
537 A client implementation that conforms to this standard MUST support
538 case (b) for transmission, case (c) for reception and case (a) for
539 transmission and reception.
541 A DCA implementation that conforms to this standard MUST support cases
542 (c) and (d), for transmission, and cases (b) and (d) for reception.
544 The process of encryption and decryption is documented in CMS [5]. The
545 only additional requirement introduced by domain encryption and
546 decryption is for greater flexibility in the management of keys, as
547 described in the following subsections. As with signatures, a naming
548 convention and name mapping convention are used to locate the correct
549 key.
551 The mechanisms described below are applicable both to key agreement and
552 key transport systems, as documented in CMS [5]. The phrase 'encryption
553 key' is used as a collective term to cover the key management keys used
554 by both techniques.
556 4.1 Domain Confidentiality Naming Conventions
558 A DCA MUST be named 'domain-confidentiality-authority'. This name MUST
559 appear in the 'common name(CN)' component of the subject field in the
560 X.509 certificate. Additionally, if the certificate contains an SMTP
561 e-mail address, this name MUST appear in the end entity component of
562 the address - on the left-hand side of the '@' symbol.
564 Along with this naming convention, an additional naming rule is defined:
565 the 'name mapping rule'. The name mapping rule states that for a DCA,
566 the domain component of its name MUST be the same as, or an ascendant
567 of, the domain name of the set of entities that it represents. The
568 domain component is defined as follows:
570 * In the case of an X.500 distinguished name of an X.509 certificate,
571 the domain component is the country, organisation, organisational
572 unit, state, and locality components of the distinguished name.
574 * If the certificate contains an SMTP e-mail address, the domain
575 component is defined to be the SMTP address component on the right-
576 hand side of the '@' symbol.
578 For example, a DCA acting on behalf of John Doe of the Acme
579 corporation, whose distinguished name is 'cn=John Doe, ou=marketing,
580 o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com,
581 could have a certificate containing a distinguished name of
582 'cn=domain-confidentiality-authority, o=acme,c=us' and an e-mail
583 address of 'domain-confidentiality-authority@acme.com'. The key
584 associated with this certificate would be used for encrypting messages
585 for John Doe.
587 Any message received where the domain component of the domain encrypting
588 agents name does not match, or is not an ascendant of, the domain name
589 of the entities it represents MUST be rejected.
591 This naming rule prevents messages being encrypted for the wrong domain
592 decryption agent.
594 Implementations conforming to this standard MUST support this name
595 mapping convention as a minimum. Implementations may choose to
596 supplement this convention with other locally defined conventions.
597 However, these MUST be agreed between sender and recipient domains
598 prior to sending any messages.
600 4.2 Key Management for Domain Encryption
602 Domain encryption may be performed for decryption by the end recipient
603 and/or by a DCA. End recipient decryption is described in CMS [5]. DCA
604 decryption is described in the next section.
606 Domain encryption uses a domain-wide encryption key from the sender's
607 domain. This Key is owned by the DCA for the sender's domain.
608 Information about this key is conveyed to the recipient in the
609 recipientInfo field as specified in CMS [5]. A domain encryption agent
610 MUST be named according to the naming convention specified in section
611 4.1. This is so that the same key can be used on reply to a domain-
612 encrypted message.
614 4.3 Key Management for Domain Decryption
616 Domain decryption can be performed on messages encrypted by the
617 originator and/or by a DCA in the originator's domain. In the first
618 case, the encryption process is described in CMS [5]; in the second
619 case, the encryption process is described in 4.2.
621 Domain decryption uses a domain-wide decryption key from the recipient's
622 domain. This key is owned by the DCA for the recipient domain. In order
623 to locate the correct key, the certificate corresponding to the DCA must
624 be located. It is vital that the naming conventions specified in 4.1 are
625 adhered to, in order to maintain confidentiality.
627 No specific method for locating this certificate is mandated in this
628 document. An implementation may choose to access a local certificate
629 store to locate the correct certificate. Alternatively, a directory may
630 be used in one of the following ways:
632 1. The directory may store the DCA certificate in the recipient's
633 directory entry. When the user certificate attribute is requested,
634 this certificate is returned.
636 2. The encrypting agent maps the recipient`s name to the DCA name in the
637 manner specified in 4.1. The user certificate attribute associated
638 with this directory entry is then obtained.
640 This document does not mandate either of these processes. Whichever one
641 is used, the name mapping conventions must be adhered to, in order to
642 maintain confidentiality.
644 Having located the correct certificate, the encryption process is then
645 performed. A recipientInfo for the DCA is then generated, as described
646 in CMS [5].
648 5. Security Considerations
650 Implementations MUST protect all private keys. Compromise of the
651 signer's private key permits masquerade.
653 Similarly, compromise of the content-encryption key may result in
654 disclosure of the encrypted content.
656 Compromise of key material is regarded as an even more serious issue for
657 domain security services than for an S/MIME client. This is because
658 compromise of the private key may in turn compromise the security of a
659 whole domain. Therefore, great care should be used when considering its
660 protection.
662 6. References
664 [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC2633,
665 June 1999.
667 [2] Bradner, S., "Key words for use in RFCs to Indicate
668 Requirement Levels", BCP 14, RFC 2119, March 1997.
670 [3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634,
671 June 1999.
673 [4] International Telecommunications Union, Recommendation X.208, "Open
674 systems interconnection: specification of Abstract Syntax Notation
675 (ASN.1)", CCITT Blue Book, 1989.
677 [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
679 7. Authors' Addresses
681 Tim Dean
682 DERA Malvern
683 St. Andrews Road
684 Malvern
685 Worcs
686 WR14 3PS
688 Phone: +44 (0) 1684 894239
689 Fax: +44 (0) 1684 896660
690 Email: t.dean@eris.dera.gov.uk
692 William Ottaway
693 DERA Malvern
694 St. Andrews Road
695 Malvern
696 Worcs
697 WR14 3PS
699 Phone: +44 (0) 1684 894079
700 Fax: +44 (0) 1684 896660
701 Email: w.ottaway@eris.dera.gov.uk
703 8. Full Copyright Statement
705 "Copyright (C) The Internet Society (2000). All Rights Reserved.
707 This document and translations of it may be copied and furnished to
708 others, and derivative works that comment on or otherwise explain it or
709 assist in its implmentation may be prepared, copied, published and
710 distributed, in whole or in part, without restriction of any kind,
711 provided that the above copyright notice and this paragraph are included
712 on all such copies and derivative works. However, this document itself
713 may not be modified in any way, such as by removing the copyright notice
714 or references to the Internet Society or other Internet organizations,
715 except as needed for the purpose of developing Internet standards in
716 which case the procedures for copyrights defined in the Internet
717 Standards process must be followed, or as required to translate it into
718 languages other than English.
720 The limited permissions granted above are perpetual and will not be
721 revoked by the Internet Society or its successors or assigns.
723 This document and the information contained herein is provided on an
724 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
725 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
726 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
727 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
728 FITNESS FOR A PARTICULAR PURPOSE."
730 This draft expires 8th September 2000