idnits 2.17.1
draft-ietf-smime-domsec-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-03-29) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== There are 3 instances of lines with non-ascii characters in the document.
== 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 519 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 are 2 instances of too long lines in the document, the longest one
being 1 character in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== 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)
== Outdated reference: A later version (-08) exists of
draft-ietf-smime-msg-04
== Outdated reference: A later version (-13) exists of
draft-ietf-smime-cms-05
== Outdated reference: A later version (-12) exists of
draft-ietf-smime-ess-06
-- Possible downref: Non-RFC (?) normative reference: ref. '5'
-- Possible downref: Normative reference to a draft: ref. '6'
Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 4 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-00.txt W Ottaway
3 July 15, 1998 DERA
4 Expires in six months
6 Domain Security Services using S/MIME
8 Status of this memo
10 This document is an Internet-Draft. 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 To view the entire list of Internet-Drafts, please check the
21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
22 Directories on ftp.is.co.za (Africa), ftp.nordu.net ( Northern Europe),
23 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
24 ftp.isi.edu(US West Coast).
26 Abstract
28 This document describes how the S/MIME protocol can be processed and
29 generated by a number of components of a messaging 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 do not have
38 encryption or signing capabilities at the desktop, but wish to
39 interoperate 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, Dave Kemp
52 and Jim Schaad.
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 feasible or practical to
63 provide end-to-end (�desktop-to-desktop�) security services,
64 particularly between different security domains. An organisation which
65 is considering providing end-to-end security services will typically
66 have to deal with 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) Cross-certification problems: There may not be any cross-certificate
78 links between two organisations. Or an organisation may be sensitive
79 about parts of its PKI and unwilling to expose them to outside
80 access. For either of these reasons, end-to-end encryption and
81 signature validation 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 5) Cost: providing the necessary key management infrastructure and other
89 items such as hardware tokens for all users may be too expensive.
91 One solution to these problems is to provide message security services
92 at the level of a domain or an organisation. This document specifies how
93 these �domain security services� can be provided using the S/MIME
94 protocol. Domain security services may replace or complement mechanisms
95 at the desktop. For example, a domain may decide to provide desktop-to-
96 desktop signatures but domain-to-domain encryption services. Or it may
97 allow desktop-to-desktop services for intra-domain use, but enforce
98 domain-based services for communication with other domains.
100 Messages can be processed and generated by a number of components of a
101 messaging system, such as message transfer agents, guards and gateways.
102 Any of these agents may provide domain security services.
104 The term 'Third Party' as used in this document means any entity in a
105 messaging system other than the originator and final recipient(s) that
106 processes messages. This includes Message Transfer Agents (MTAs),
107 domain mail servers, guards and firewalls operating at security
108 boundaries, and gateways that translate between different protocol
109 formats. A third party may sign, encrypt, decrypt, and check signatures
110 on a message.
112 Throughout this draft the terms MUST, MUST NOT and SHOULD NOT are used
113 in capital letters. This conforms to the definitions in [2].
115 2. Overview of Domain Security Services
117 In a distributed system, a message is sent from an originator to a set
118 of recipients that may be in the same or different security domains.
119 This section first defines what is meant by a security domain. It then
120 gives an informal overview of the security services that are provided by
121 S/MIME between different security domains. These services are provided
122 by a combination of mechanisms in the sender's and recipient's domains.
123 Later sections describe definitively how these services map onto
124 elements of the S/MIME protocol.
126 2.1 Definition of a Security Domain
128 A 'security domain' is defined as a collection of hardware and personnel
129 operating under a single security authority and performing a common
130 business function. Members of a security domain will of necessity share
131 a high degree of mutual trust, due to their shared aims and objectives.
132 A security domain is typically protected from direct outside attack by
133 physical measures and from indirect (electronic) attack by a combination
134 of firewalls and guards at network boundaries. The interface between two
135 security domains is termed a 'security boundary'. One example of a
136 security domain is an organisational network ('Intranet').
138 2.2 Domain Signature
140 A domain signature is a S/MIME SignerInfo [3] created on behalf of a
141 collection of users in a domain. A domain signature can be used when
142 end users do not have signing capabilities at the desktop. It can also
143 be used to bridge between two domains that have incompatible or
144 disconnected signature systems, such as when there are no cross-
145 certificate links between their Public Key Infrastructures (PKIs). In
146 this case a process which creates a Domain Signature first checks the
147 originator's signature using the source Domain's PKI. It then re-signs
148 the message using its key and certificate from the destination Domain's
149 PKI, which can then be verified by the recipient(s).
151 A domain signature can also be used in situations when messages need to
152 be reformatted inside the message transfer system. Message reformatting
153 is needed at gateways between X.400 and SMTP-MIME domains, or on
154 conversion between HTTP-MIME and SMTP-MIME message representations. In
155 both cases the recipient is unable to verify the originator's signature.
156 Therefore, a Domain Signature is generated at the reformatting point to
157 indicate that the originator's signature has been authenticated.
159 2.3 Domain Encryption
161 Domain encryption is S/MIME encryption performed on behalf of a
162 collection of users in a domain. Domain encryption can be used to
163 protect information between domains, for example, when two 'Intranets'
164 are connected using the Internet. It can also be used when end users do
165 not have encryption capabilities at the desktop, or when two domains
166 employ incompatible encryption schemes. In the latter case messages
167 from the originator's domain are re-encrypted using an algorithm, key,
168 and certificate which can be decrypted by the recipient(s).
170 2.4 Additional Attributes
172 A third party in a domain may attach additional signed attributes to a
173 message. This is for one of the following reasons:
175 1) To add domain-wide attributes such as a domain security label of a
176 'system-high' domain.
178 2) To add mapped attributes, for processing by recipients in a domain
179 different from that of the originator. An example is the addition of
180 the 'Equivalent Label' attribute defined in ESS [4].
182 2.5 Message Review and Release
184 A third party may review messages before they are released from a
185 domain. This is used when organisational policy or good security
186 practice require that messages be reviewed before they are released to
187 external recipients. Having reviewed a message, a review and release
188 signature is added to it. The review and release signature may be
189 checked by a firewall at the domain boundary, to ensure that only
190 reviewed messages are released.
192 Details of the review process are outside the scope of this document,
193 but may involve scanning message contents for viruses or other malicious
194 code, searching for prohibited words or other content, or checking for
195 the presence or absence of certain security labels. Review and release
196 may be performed by a human reviewer or an automated process.
198 3. Mapping of Domain Security Services to the S/MIME Protocol
200 This section describes the S/MIME Protocol elements that are used to
201 provide the security services described above. ESS [4] introduces the
202 concept of triple-wrapped messages that are first signed, then
203 encrypted, then signed again. This document also uses this concept of
204 triple-wrapping. In addition, this document also uses the concept of
205 'signature encapsulation'. 'Signature encapsulation' denotes a complete
206 signed message that is wrapped in a second signature, the second
207 signature covering both the content and the first (inner) signature.
208 Signature Encapsulation may be performed on the inner or the outer
209 signature of a triple-wrapped message. The term 'parallel signatures'
210 means two or more signatures calculated over the same content. This
211 capability is described in CMS [3], where a set of one or more
212 SignerInfos can be attached to signed data.
214 3.1 Signature Types
216 An authenticated attribute is used to indicate the type of signature.
217 The ASN.1 [5] notation of this attribute is:-
219 SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
221 id-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2)
222 us (840) rsadsi (113549) }
224 If present, the SignatureType attribute MUST be an authenticated
225 attribute, as defined in CMS [3]; it MUST NOT be an unauthenticated
226 attribute. If the SignatureType attribute is absent the recipient
227 SHOULD NOT make any assumptions about the type of signature.
229 A SignerInfo MUST NOT include multiple instances of SignatureType. An
230 authenticated attribute representing a SignatureType MUST only include
231 a single instance of SignatureType as an AttributeValue of attrValues
232 [3].
234 This document specifies the following types of signature:
236 1) Originator Signature
237 2) Domain Signature
238 3) Additional Attributes Signature
239 4) Review and Release Signature
241 Each of these signature types is generated and processed exactly as
242 described in CMS [3]. They are distinguished by the presence of the
243 following values in the SignatureType authenticated attribute:
245 id-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-signatureType 1}
246 id-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-signatureType 2 }
247 id-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-signatureType 3}
248 id-sigtype-review-release-sig OBJECT IDENTIFIER ::= { id-signatureType
249 4}
251 Any of these signature types may encapsulate another signature of the
252 same or a different type, or any other type of content, as documented in
253 CMS [3]. The following sections describe the conditions under which
254 each of these types of signature may be generated, and how they are
255 processed.
257 3.1.1 Originator Signature
259 The 'originator signature' is used to indicate that the signer is the
260 originator of the message and its contents. The 'originator signature'
261 is indicated by the presence of the value id-sigtype-originator-sig in
262 the 'signature type' authenticated attribute. No other Object
263 Identifiers may be included in the sequence of OIDs if this value is
264 present.
266 3.1.2 Domain Signature
268 A 'domain signature' is generated on behalf of a collection of users in
269 a domain. A 'domain signature' on a message authenticates the fact that
270 the message has originated in that domain. Before signing, a process
271 generating a 'domain signature' MUST first satisfy itself of the
272 authenticity of the message originator. This is achieved by one of two
273 methods. Either the 'originator's signature' is checked, if S/MIME
274 signatures are used inside a domain. Or if not, some mechanism external
275 to S/MIME is used, such as the physical address of the originating
276 client or an authenticated IP link.
278 If the originator's authenticity is successfully verified by one of the
279 above methods, a 'domain signature' may be added to a message in one of
280 the following ways:
282 1) An unsigned message is wrapped in a SignedData, and a SignerInfo is
283 attached containing the 'domain signature'. The originator's
284 information is included as part of a header field in the encapsulated
285 message.
287 2) Signature Encapsulation is used to wrap the original signed message
288 with a 'domain signature'. As stated above, the originator's
289 signature MUST first be checked by the domain signer.
291 When a 'domain signature' is applied the mlExpansionHistory and
292 eSSSecurityLabel attributes MUST be copied from other signerInfos as
293 stated in [4].
295 If the originator's authenticity is not successfully verified, a 'domain
296 signature' MUST NOT be generated.
298 On reception, the 'domain signature' may be used to verify the
299 authenticity of a message. If it encapsulates a SignedData, the
300 certificate(s) of the inner SignerInfo should be used to identify the
301 originator. This information can then be displayed to the recipient. A
302 domain signer can be assumed to have verified any signatures that it
303 encapsulates. Therefore, it is not necessary to verify these signatures
304 before treating the message as authentic. However, this standard does
305 not preclude a recipient from attempting to verify any other signatures
306 that are present.
308 The 'domain signature' is indicated by the presence of the value Id-at-
309 sigtype-domain-sig in the 'signature type' authenticated attribute. No
310 other Object Identifiers may be included in the sequence of OIDs if this
311 value is present.
313 3.1.3 Additional Attributes Signature
315 The 'additional attributes' signature type indicates that the SignerInfo
316 contains additional attributes that are associated with the message.
317 All attributes in the applicable SignerInfo MUST be treated as
318 additional attributes. Successful verification of an 'additional
319 attributes' signature means only that the attributes are authentically
320 bound to the message. A recipient MUST NOT assume that its successful
321 verification also authenticates the message originator. The authenticity
322 of the message originator should be verified by checking an encapsulated
323 signature of the appropriate type.
325 A signer may include any of the attributes listed in CMS [3] or ESS [4]
326 when generating an 'additional attributes' signature. The following
327 attributes have a special meaning, when present in an 'additional
328 attributes' signature:
330 1) Equivalent Label: label values in this attribute are to be treated as
331 equivalent to the security label contained in an encapsulated
332 SignerInfo, if present.
334 2) Security Label: the label value indicates the aggregate sensitivity
335 of the inner message content plus any encapsulated signedData and
336 envelopedData containers. The label on the original data is indicated
337 by the value in the originator's signature, if present.
339 An 'additional attributes' signature is indicated by the presence of the
340 value Id-at-sigtype-add-attrib-sig in the 'signature type' authenticated
341 attribute. No other Object Identifiers may be included in the sequence
342 of OIDs if this value is present. An 'additional attributes' signature
343 may be added in parallel with other signatures in a SET OF SignerInfos.
345 3.1.4 Review and Release
347 The 'Review And Release' signature indicates that the signer has
348 reviewed the message. Successful verification of a 'Review and Release'
349 signature means only that the signer has approved the message for
350 release from a domain. A device on a domain boundary such as a Mail
351 Guard or firewall may be configured to check review and release
352 signatures. A recipient MUST NOT assume that its successful verification
353 also authenticates the message originator. The authenticity of the
354 message originator should be verified by checking an encapsulated
355 signature of the appropriate type.
357 A 'Review and Release' signature is indicated by the presence of the
358 value Id-at-sigtype-review-release-sig in the 'signature type'
359 authenticated attribute. No other Object Identifiers may be included in
360 the sequence of OIDs if this value is present.
362 3.2 Domain Encryption and Decryption
364 Domain encryption is encryption performed by a third party on behalf of
365 a set of originators in a domain. Domain decryption is decryption
366 performed by a third party on behalf of a set of recipients in a domain.
367 These processes may be performed in combination, as shown below.
369 --------------------------------------------------------------------
370 | | Recipient Decryption | Domain Decryption |
371 |------------------------|----------------------|--------------------|
372 | Originator Encryption | Case(a) | Case(c) |
373 | Domain Encryption | Case(b) | Case(d) |
374 --------------------------------------------------------------------
376 Case (a), encryption of messages by the originator for decryption by the
377 final recipient(s), is described in CMS [3]. In Cases (b) and (d),
378 encryption is performed not by the originator but by a third party in
379 the sending domain. In Cases (c) and (d), decryption is performed not
380 by the recipient(s) but by a third party in the destination domain.
382 A client implementation that conforms to this standard MUST support
383 cases (a) and (c) for transmission, and cases (a) and (b) for reception.
384 A Domain Encryption implementation that conforms to this standard MUST
385 support cases (b) and (d), for transmission, and cases (c) and (d) for
386 reception.
388 The process of encryption and decryption is documented in CMS [3]. The
389 only additional requirement introduced by domain encryption and
390 decryption is for greater flexibility in the management of keys, as
391 described in the following subsections.
393 The mechanisms described below are applicable both to key agreement and
394 key transport systems, as documented in CMS. The phrase 'encryption
395 key' is used as a collective term to cover the key management keys used
396 by both techniques.
398 3.2.1 Domain Encryption Key Management
400 Domain Encryption is shown as cases (b) and (d) in the above table.
401 Domain Encryption uses a domain-wide encryption key from the sender's
402 domain. Information about this key is conveyed to the recipient by
403 one of two methods:-
405 1) Public information about this key is held in a certificate and
406 conveyed to the recipient(s) in the 'Certs' field of the
407 OriginatorInfo in the Envelope.
409 2) The recipient(s) looks up the key for the users domain by replacing
410 the originator's name within the address with the domain encryption
411 name [6].
413 For example :-
415 a) If the originator is originator@foo.com then lookup key for
416 domain-encrypting-authority@foo.com.
418 b) If the originator is c=us;a=com;p=foo;s=originator then look up
419 key for c=us;a=com;p=foo;s=domain-encrypting-authority.
421 c) If the originator is c=gb;o=foo;cn=originator then look up key for
422 c=gb;o=foo;cn=domain-encrypting-authority.
424 An implementation conforming to this standard MUST support both methods.
426 The name in the encryption certificate may not match the name in any
427 encapsulated signatures. For example, when a message is signed by the
428 originator and is encrypted by the domain. An implementation that
429 conforms to this standard MUST allow for this possibility. This includes
430 both a client and a third party implementation.
432 3.2.2 Domain Decryption Key Management
434 Domain Decryption is shown as cases (c) and (d) in the above table. In
435 these cases, the encryption process uses a domain-wide encryption key
436 for the recipient(s)' domain. The selection of this key is achieved by
437 one of two methods:
439 1) The sending process explicitly searches for a certificate containing
440 the domain encryption key of the recipient(s)' domain. This is
441 achieved by mapping the recipient(s)' name to a domain name and then
442 locating the encryption certificate containing that domain name.
443 Mapping from recipient names to Domain names, and conventions for
444 domain names are outside the scope of this standard.
446 2) All the members of the receiving domain are issued with certificates
447 containing a single key. The private component of that key is held
448 by an entity in the domain that performs the decryption process
449 on their behalf. By selecting the appropriate certificate, a sending
450 process will implicitly encrypt for decryption by the Domain
451 Decryption process.
453 An implementation that conforms to this standard MUST support mechanism
454 (1). It may also support mechanism (2). This includes both a client and a
455 third party implementation.
457 4. Security Considerations
459 Domain Security Services provide a method for digitally
460 signing data, digesting data, encrypting data, and authenticating
461 data.
463 Implementations must protect the signer's private key. Compromise of
464 the signer's private key permits masquerade.
466 Implementations must protect the key management private key and the
467 content-encryption key. Compromise of the key management private key
468 may result in the disclosure of all messages protected with that key.
469 Similarly, compromise of the content-encryption key may result in
470 disclosure of the encrypted content.
472 5. References
474 [1] Ramsdell, B., "S/MIME Version 3 Message Specification", Internet
475 Draft draft-ietf-smime-msg-04, May 1998.
477 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
478 Levels", BCP 14, RFC 2119, March 1997.
480 [3] Housley, R., "Cryptographic Message Syntax", Internet Draft
481 draft-ietf-smime-cms-05.txt, March 1998.
483 [4] Hoffman, P., "Enhanced Security Services for S/MIME", Internet Draft
484 draft-ietf-smime-ess-06.txt, May 1998.
486 [5] International Telecommunications Union, Recommendation X.208, "Open
487 systems interconnection: specification of Abstract Syntax Notation
488 (ASN.1)", CCITT Blue Book, 1989.
490 [6] Ramsdell, B., "Role Names in X.509 Certificates", Internet Draft
491 draft-ramsdell-role-names, April 29 1998.
493 6. Authors' Addresses
495 Tim Dean
496 DERA Malvern
497 St. Andrews Road
498 Malvern
499 Worcs
500 WR14 3PS
502 Phone: +44 (0)1684 894239
503 Fax: +44 (0)1684 6113
504 Email: t.dean@eris.dera.gov.uk
506 William Ottaway
507 DERA Malvern
508 St. Andrews Road
509 Malvern
510 Worcs
511 WR14 3PS
513 Phone: +44 (0)1684 894079
514 Fax: +44 (0)1684 896113
515 Email: w.ottaway@eris.dera.gov.uk
517