idnits 2.17.1 draft-dusse-mime-msg-spec-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-04-24) 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. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 651 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '... content[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Internet-Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 107 -- Looks like a reference, but probably isn't: '3' on line 161 -- Looks like a reference, but probably isn't: '0' on line 126 -- Looks like a reference, but probably isn't: '4' on line 218 -- Looks like a reference, but probably isn't: '5' on line 274 -- Looks like a reference, but probably isn't: '6' on line 330 -- Looks like a reference, but probably isn't: '7' on line 385 -- Looks like a reference, but probably isn't: '8' on line 441 -- Looks like a reference, but probably isn't: '9' on line 497 -- Looks like a reference, but probably isn't: '10' on line 552 -- Looks like a reference, but probably isn't: '11' on line 600 == Unused Reference: 'Conformance' is defined on line 579, but no explicit reference was found in the text -- No information found for draft-ietd-822ext-mime-conf-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Conformance' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Dusse 2 INTERNET DRAFT RSA Data Security, Inc. 3 Category: Internet-Draft SEPTEMBER, 1996 4 Expire in six months 6 S/MIME Message Specification: 7 PKCS Security Services for MIME 8 10 Status of this Memo: 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as work in progress. 22 To learn the current status of any Internet-Draft, please check lid- 23 abstract.txt listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a 31 standard way to send and receive secure electronic mail. Based on the 32 popular Internet MIME standard (RFC 1521), S/MIME provides the 33 following cryptographic security services for electronic messaging 34 applications: authentication, message integrity and non-repudiation of 35 origin (using digital signatures) and privacy and data security (using 36 encryption). 38 1.0 Overview 40 This document describes a protocol for adding cryptographic signature 41 and encryption services to Internet MIME messages. The Internet MIME 42 standard (RFC 1521), provides a general structure for the content type 43 of Internet mail messages and allows extensions for new content type 44 applications. Therefore, this draft defines application/x-pkcs7-mime 45 which specifies that a MIME body part has been cryptographically 46 enhanced according to PKCS #7. This draft also defines 47 application/x-pkcs10 for use in submitting a certification request. 49 This document discusses the use of multipart/signed and 50 application/x-pkcs7-signature, which can be used to display the "clear 51 text" of a signed message for the benefit of readers using an e-mail 52 system with no security services. 54 Dusse [2] 55 This specification is compatible with PKCS #7 in that it uses the data 56 types defined by PKCS #7. It also inherits all the varieties of 57 architectures for certificate-based key management supported by PKCS 58 #7. PKCS #7 describes binary encodings that can be transmitted 59 over 7-bit electronic mail systems. MIME solves that problem by using 60 its content transfer encoding services. 62 1.2 Definitions 64 For the purposes of this draft, the following definitions apply. 66 ASN.1: Abstract Syntax Notation One, as defined in C.C.I.T.T. X.208. 68 BER: Basic Encoding Rules for ASN.1, as defined in C.C.I.T.T. X.209. 70 Certificate: A type that binds an entity's distinguished name to a 71 public key with a digital signature. This type is defined in C.C.I.T.T. 72 X.509. This type also contains the distinguished name of the 73 certificate issuer (the signer), an issuer-specific serial number, the 74 issuer's signature algorithm identifier, and a validity period. 76 CertificateRevocationList (CRL): A type that contains information about 77 certificates whose validity an issuer has prematurely revoked. The 78 information consists of an issuer name, the time of issue, the next 79 scheduled time of issue, and a list of certificate serial numbers and 80 their associated revocation times. The CRL is signed by the issuer. The 81 type intended by this standard is the one defined in RFC 1422. 83 DER: Distinguished Encoding Rules for ASN.1, as defined in C.C.I.T.T. 84 X.509, Section 8.7. 86 MIME: Multipurpose Internet Mail Extensions, as defined in RFC 1521. 88 Data Types: These definitions are those used with the MIME and SMTP 89 standards. 91 7-bit: Text data with lines less than 998 characters long, 92 documents of the Internet Engineering Task Force 93 (IETF), its areas, and characters with the 8th bit 94 set and no NULL characters. and occur 95 only as part of a end of line delimiter. 97 8-bit: Text data with lines less than 998 characters, and 98 no NULL characters. and occur only as 99 part of a end of line delimiter. 101 binary: Arbitrary data. 103 Transfer Encoding: A reversible transformation made on data so 8-bit 104 or binary data may be sent via a channel that only 105 transmits 7-bit data. 107 Dusse Page [2] 109 Dusse [3] 110 2.0 Content-Type application/x-pkcs7-mime 112 This section defines the format of data used in application/ 113 x-pkcs7-mime. First we introduce the data format and discuss various 114 implementation issues. Then we describe the steps an agent must follow 115 to send or receive an application/x-pkcs7-mime body part. Finally, we 116 discuss some security considerations. 118 2.1 Format of the application/x-pkcs7-mime body 120 PKCS #7 defines a general ASN.1 type, ContentInfo, for use in 121 exchanging cryptographic information. For convenience, its definition 122 is repeated here: 124 ContentInfo ::= SEQUENCE { 125 contentType ContentType, 126 content[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 127 ContentType ::= OBJECT IDENTIFIER 129 PKCS #7 also defines several content types which can be used within a 130 ContentInfo. For our purposes here, the most important are SignedData 131 (for exchanging digitally signed data), EnvelopedData (for exchanging 132 digitally enveloped data) and SignedAndEnvelopedData (for exchanging 133 data both digitally signed and enveloped). 135 Therefore, when the MIME content type application/x-pkcs7-mime is used, 136 the body shall be a ContentInfo as defined by PKCS #7, encoded using 137 the Basic Encoding Rules (BER). The PKCS #7 content type will normally 138 be SignedData, EnvelopedData or SignedAndEnvelopedData, but use of 139 other content types defined by PKCS #7 are not disallowed. 141 2.1.1 Notes 143 Since BER is specified, instead of the more restrictive DER, an 144 application may use techniques such as indefinite-length encoding. This 145 is especially useful for transferring large data or streamed data where 146 the total length is not known in advance. 148 Data produced by BER is 8-bit, but many transports are limited to 7-bit 149 data. Therefore, in most situations, a suitable 7-bit 150 Content-Transfer-Encoding is needed, such as base64. This is discussed 151 in a later section. 153 PKCS #7 has a provision for "detached data", where, for example, the 154 SignedData in the ContentInfo contains only the signature information, 155 but not the actual data which is signed (which is transferred 156 separately). Application/x-pkcs7-mime explicitly disallows the use of 157 detached data and requires the data to be present within the 158 ContentInfo. The "detached data" provision is, however, used by the 159 multipart/signed construct described in Section 6. 161 Dusse Page [3] 163 Dusse [4] 164 PKCS #7 provides for a degenerate case of SignedData which can be used 165 for disseminating certificates and CRLs. This is explicitly allowed in 166 application/x-pkcs7-mime. In this case, the content is omitted from 167 the ContentInfo and there are no entries in the SignerInfos, leaving 168 only entries for certificates and crls. Typically, this is used to 169 convey certificates in response to a certification request, or CRLs in 170 response to a CRL retrieval request. The MIME agent should process 171 and/or store the certificates and CRLs and may choose to display a 172 confirmation to the user. 174 2.2 Format of the signed or enveloped data 176 PKCS #7 places no requirements on the format of the data which is 177 signed or enveloped. However, for use in application/x-pkcs7-mime, 178 the signed or enveloped data must itself be a MIME entity. Therefore, 179 when a MIME agent receives an application/x-pkcs7-mime, the result of 180 removing the signature or envelope can be passed directly to the normal 181 MIME-processing software. 183 Because the MIME entity being signed or enveloped is likely to be 184 transferred to and processed on a different platform than it was 185 created it is important that it be in canonical or "on-the-wire" 186 format. The most common difference between platforms is the end of line 187 delimiter. In addition to being in canonical MIME format there are some 188 considerations for the selection of the transfer encoding for the MIME 189 entity that affect the ability to verify the signature of a received 190 MIME entity, especially if it is to be subsequently forwarded. Since 191 the data which is signed or enveloped must be recovered by the 192 recipient in the exact form it was produced by the sender, we must take 193 care that this data be in a canonical format which can be processed by 194 any platform. 196 A rough outline of what is needed to convert a MIME entity into 197 canonical format is given here, but the implementor is referred to the 198 MIME RFCs for complete details. It is also advisable to check for IETF 199 drafts of the MIME specification that are later than the most recent 200 RFCs until MIME is published as a complete IETF standard. This 201 following set of steps is prescriptive to illustrate exactly what the 202 end result must be. An implementation need not perform these steps 203 exactly as long as the end result is the same as if the steps were 204 performed. 206 Given that the data objects to be included in the message are available 207 in the local format, the first step is to convert each object to its 208 canonical format. The canonical format of each object is determined by 209 its MIME type and subtype as it is tagged in the MIME entity. For 210 example, data of MIME type text/plain must have each end of line 211 delimiter converted to , and an isolated or is not 212 permitted. Another canonicalization that may be required is the 213 conversion from the local character set to a standard character set. 214 Many data types such as image/gif or application/postscript have only 215 one format and this serves as both the canonical format and the local 216 format no matter the platform. 218 Dusse Page [4] 220 Dusse [5] 221 The second step is the application of transfer encoding. Transfer 222 encoding is used to transform 8-bit text (e.g., in the ISO-8859-1 223 character set) or binary data (arbitrary line length, may include any 224 octet including NULL) in such a way that it can be transmitted over 225 7-bit or non-binary channels. Note that when transfer encoding is 226 applied in this step the output lines of the transfer encoder will be 227 lines of 7-bit text with canonical line ending. Any transfer encoding 228 to the MIME entity inside the PKCS envelope will be referred to as the 229 "inside transfer encoding." Strictly speaking no transfer encoding is 230 required for a MIME object inside the PKCS envelope since it will be 231 embedded in a PKCS object which is effectively a binary channel, but 232 there are some further considerations. If the PKCS envelope is ever 233 removed and the resulting MIME object is ever to be transmitted by 234 itself without further processing via standard SMTP transport it is 235 advisable to use some transfer encoding. The choice is at the 236 discretion of the implementor. If no Content-Transfer-Encoding header 237 is included, it is assumed that the transfer encoding is 7-bit and that 238 the data will be conformant. If the data is binary, then a 239 Content-Transfer-Encoding: binary header must be included. The same is 240 true for 8-bit data. 242 Third, the encoded sub-entities are inserted in the full MIME entity. 243 This step consists essentially of concatenating the sub-entities 244 interspersed with the appropriate MIME Content-type, Content-Transfer- 245 Encoding and related headers and part boundaries. Note that MIME 246 headers and boundaries are all text with canonical line endings. 248 2.2.1 Notes 250 The requirement that the signed or enveloped data must itself be a MIME 251 body part is why the protocol defined here is called 252 application/x-pkcs7-mime and not just application/x-pkcs7. A protocol 253 for transferring a PKCS #7 object with arbitrary signed or enveloped 254 content could be defined, but is outside the scope of this document. 256 2.3 Outside Content transfer encoding 258 The body of application/x-pkcs7-mime is a BER-encoded PKCS #7 259 ContentInfo. However, as mentioned above, the result of BER-encoding 260 is binary data, not 7-bit text as required by most SMTP mail transport 261 agents. In general, base64 Content-Transfer-Encoding can be used, 262 though all that is required is that the transfer encoding be such that 263 application/x-pkcs7-mime entity can be transferred intact. (It is even 264 possible that the transfer encoding will be changed by the message 265 transfer agent, as this is explicitly permitted.) 267 2.4 Sending an application/x-pkcs7-mime body part 269 Now that we have introduced the various formats and issues, we can 270 describe the steps for sending a message using 271 application/x-pkcs7-mime. In this example, we create a digital 272 envelope, but the same process applies to other PKCS #7 content types. 274 Dusse Page [5] 276 Dusse [6] 277 Note that the first four steps listed here are the steps for preparing 278 a MIME entity for transmission via SMTP with the exception that binary 279 transfer encoding is allowed. The implementor is referred to the MIME 280 conformance document for the precise details. Also, these steps need 281 not be performed exactly as described here as long as the result 282 obtained is identical. 284 Each message part is prepared as usual by the message composition 285 software and becomes available in its local format. 287 Each message part is converted to its canonical format as defined for 288 its MIME content type (e.g., end of line delimiters are converted to 289 for type text/plain). If desired by the implementor, transfer 290 encoding is applied to each message part. It is optional as the default 291 inside transfer encoding for message parts is binary. If the data for a 292 MIME part is not 7-bit data, then a Content-Transfer-Encoding header 293 indicating whether it is either 8-bit or binary must be inserted as 294 part of the following step. 296 MIME Content-xxxx headers are added to each part, and if there are 297 multiple parts each entity is inserted into a multipart message. That 298 is, the message parts are assembled into a complete MIME entity. The 299 MIME entity is encrypted according to PKCS #7 EnvelopedData, where the 300 encrypted message is placed in the EnvelopedData's 301 EncryptedContentInfo. (Note that the EnvelopedData also contains the 302 RecipientInfo data which the recipient will use to open the envelope 303 and decrypt the message.) 305 * The EnvelopedData is placed within a PKCS #7 ContentInfo. 306 * The ContentInfo is encoded according to BER. 308 As a typical step, the BER-encoded ContentInfo is also base64 encoded 309 so that it is 7-bit data suitable for mail transfer agents. This then 310 becomes the body of an application/x-pkcs7-mime body part. The result 311 might look like this: 313 Content-Type: application/x-pkcs7-mime 314 Content-Transfer-Encoding: base64 316 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 317 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 318 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 319 7GhIGfHfYT64VQbnj756 321 2.5 Receiving an application/x-pkcs7-mime body part 323 These are the steps for receiving the application/x-pkcs7-mime message 324 from the previous example. 325 * Any content transfer encoding is removed, which in this 326 example is base64. 327 * The PKCS #7 ContentInfo is examined to determine the PKCS #7 328 content type, which in this case is EnvelopedData. 330 Dusse Page [6] 332 Dusse [7] 333 * The RecipientInfoEnvelopedData is processed in order to 334 decrypt the content, which must be a MIME body part as 335 required by application/x-pkcs7-mime. 336 * The result is passed to a standard MIME processor which 337 removes transfer encoding, splits multipart entities, and 338 possibly converts the parts to local format. In this example, 339 the message "This is an encrypted message" is displayed to 340 the user. 342 3.0 Content-Type application/x-pkcs10 344 A typical application which allows a user to generate cryptographic 345 information must submit that information to a certification authority, 346 who transforms it into a certificate. PKCS #10 describes a syntax for 347 certification requests. We therefore define application/x-pkcs10 which 348 can be used to transfer a PKCS #10 certification request. The details 349 of certification requests and the process of obtaining a certificate 350 are beyond the scope of this document. Here, we only define the format 351 of data used in application/x-pkcs10. First we introduce the data 352 format and discuss various implementation issues. Then we describe the 353 steps an agent must follow to send or receive an application/x-pkcs10 354 body part. 356 3.1 Format of the application/x-pkcs10 body 358 PKCS #10 defines the ASN.1 type CertificationRequest for use in 359 submitting a certification request. Therefore, when the MIME content 360 type application/x-pkcs10 is used, the body shall be a 361 CertificationRequest, encoded using the Basic Encoding Rules (BER). 363 Although BER is specified, instead of the more restrictive DER, a 364 typical application will use DER since the CertificationRequest's 365 CertificationRequestInfo must be DER-encoded anyway in order to be 366 signed. A robust application should output DER, but allow BER or DER 367 on input. 369 Data produced by BER or DER is 8-bit, but many transports are limited 370 to 7-bit data. Therefore, a suitable 7-bit Content-Transfer-Encoding 371 is needed. This document recommends using the base64 372 Content-Transfer-Encoding with application/x-pkcs10, although any 7-bit 373 transfer encoding will work. 375 3.2 Sending and receiving an application/x-pkcs10 body part 377 Now that we have introduced the various formats and issues, we can 378 describe the steps for sending a message using application/x-pkcs10. 379 The application generates the cryptographic information for the user. 380 The details of this are beyond the scope of this document. 382 * The cryptographic information is placed within a PKCS #10 383 CertificationRequest. 385 Dusse Page [7] 387 Dusse [8] 388 * The CertificationRequest is encoded according to BER or DER 389 (typically, DER). 390 * As a typical step, the DER-encoded CertificationRequest is 391 also base64 encoded so that it is 7-bit data suitable for 392 mail transfer agents. This then becomes the body of an 393 application/x-pkcs10 body part. The result might look like 394 this: 395 Content-Type: application/x-pkcs10 396 Content-Transfer-Encoding: base64 398 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 399 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 400 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 401 0GhIGfHfQbnj756YT64V 403 A typical application only needs to send a certification request. It is 404 a certification authority which must receive and process the request. 405 The steps for recovering the CertificationRequest from the message are 406 straightforward and are not presented here. The procedures for 407 processing the certification request are beyond the scope of this 408 document. 410 4.0 Use of the Multipart/Signed Content-Type 412 RFC 1847 defines the multipart/signed content type explicitly for 413 clear-signed messages. Clear signing means the content is in the clear 414 so that recipients with older e-mail systems that cannot process PKCS 415 information can still read the message even if they cannot verify the 416 signature. The multipart/signed MIME type is a multipart type with 417 exactly two parts. The first part carries the MIME entity being signed. 418 The second part carries the signature. 420 The multipart/signed Content type has the following parameters: 421 * The protocol parameter (required): "application/x-pkcs7- 422 signature" 423 * The micalg parameter: rsa-md5 425 Note that quoting is required around the protocol parameter as a "/" 426 character in a parameter value must be quoted. 428 The micalg parameter allows for one-pass processing when the signature 429 is being verified. The value of the micalg parameter is dependent on 430 the message digest algorithm used in the calculation of the Message 431 Integrity Check, rsa-md5 is included as an example. This specification 432 does not require or recommend any particular choice of mic algorithm. 434 4.1 Preparation of the data for signing 436 The data is prepared as described in section 2 with the following extra 437 considerations for transfer encoding. All parts of the MIME entity must 438 have transfer encoding of 7-bit, quoted-printable, or base64. No binary 439 or 8-bit data is permitted. This is required because 441 Dusse Page [8] 443 Dusse [9] 444 the current Internet mail transport infrastructure cannot guarantee 445 transport of unencoded binary or 8-bit data and because the digest for 446 the signature is computed on the fully encoded message. If a message 447 with 8-bit data were to encounter a transfer agent that can not 448 transmit 8-bit or binary data it has three options, none of which are 449 acceptable for a clear-signed message. First, it could change the 450 transfer encoding, but that would invalidate the signature. It could 451 transmit anyway which would most likely result in the 8th bit being 452 stripped, also resulting in the signature being invalidated. Last it 453 could return the message to the sender. Thus transfer encoding to make 454 the data 7-bit text is required before computing the signature. Note 455 RFC 1847 prohibits an MTA from changing the transfer encoding of the 456 first part of a multipart/signed message. If a compliant MTA 457 encountered a multipart/signed message with 8-bit or binary data in the 458 first part, it would have to return the message to the sender as 459 undeliverable. 461 Note that is it is advisable to use quoted printable transfer encoding 462 in some situations that may not otherwise seem necessary to better 463 preserve the data so the signature can be verified. For example, 464 trailing spaces should always be quoted-printable encoded as some mail 465 systems strip them if they are not transferred with encoding. Also the 466 word "From" followed by a space at the beginning of a line should be 467 encoded as some mail systems convert this to ">From". Because of the 468 restriction on 8-bit transport it is also necessary to use quoted 469 printable encoding for text using an 8-bit character set such as ISO- 470 8859-1. 472 4.2 The application/x-pkcs7-signature type 474 The second part of the multipart/signed message must have type 475 application/x pkcs7-signature. The data in the second part is the PKCS 476 #7 detached signature. A detached signature is a PKCS #7 data object of 477 type SignedData with the signerInfos field containing signatures on 478 some external data and the ContentInfo field empty. In this case the 479 external data is the fully encoded MIME entity described above and 480 placed in the first part of the multipart/signed message. 482 4.3 Procedure for sending a clear signed message 484 The data is prepared as described above so the transfer encoding of all 485 the parts is either 7-bit, quoted-printable or base64. The PKCS #7 486 detached signature for the data is computed. The content data is 487 inserted into the first part of the multipart/signed MIME entity. The 488 detached signature is inserted into the second part of the 489 multipart/signed message using appropriate transfer encoding (most 490 likely base64). The MIME type of the detached signature part must be 491 application/x-pkcs7-signature. 493 4.4 Procedure for receiving a clear signed message 495 The message digest of the first part of the multipart/signed message 497 Dusse Page [9] 499 Dusse [10] 500 is computed before any further MIME decoding or processing other than 501 separating the two parts of the multipart/signed entity. 503 The application/x-pkcs7-signature information in the second part is 504 processed along with the digest obtained in the first step to verify 505 the signature. The MIME processing and decoding of the first part 506 proceeds and the message is presented to the user along with the result 507 of the signature verification. 509 Example multipart/signed message 511 Content-Type: multipart/signed; 512 protocol="application/x-pkcs7-signature"; 513 micalg=rsa-md5; boundary=boundary42 514 --boundary42 516 Content-Type: text/plain 517 This is a clear-signed message 518 --boundary42 520 Content-Type: application/x-pkcs7-signature 521 Content-Transfer-Encoding: base64 523 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 524 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 525 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 526 7GhIGfHfYT64VQbnj756 527 --boundary42-- 529 5.0 Security considerations 531 All of the security issues faced by any cryptographic application must 532 be faced by a MIME agent which supports application/x-pkcs7-mime. Among 533 these are protecting the user's private key, preventing various 534 attacks, and helping the user avoid mistakes such as inadvertently 535 encrypting a message for the wrong recipient. These issues are beyond 536 the scope of this document, however we can make the following notes: 538 An implementor may choose not to present data which has been digitally 539 signed if the signature verification fails. The reasoning is that if 540 the signature fails, the data very likely has been tampered with and 541 should be considered untrustworthy. This is consistent with the fact 542 that the signed data within an application/x-pkcs7-mime entity cannot 543 be seen by viewing the "raw" MIME message, since it is base64 encoded 544 (unless is it sent clear signed as described in section 6). The message 545 must be processed and the signature verified before the data is 546 presented. If the implementor does choose to present the data even if 547 the signature verification fails, it is advisable to strongly warn the 548 user. 550 A MIME agent which supports application/x-pkcs7-mime inherits the 552 Dusse Page [10] 554 Dusse [11] 555 certificate-based key management supported by PKCS #7. In particular, a 556 typical agent must be able to process certificates and CRLs which may 557 be included inside a SignedData or SignedAndEnvelopedData type. The 558 agent may also include auxiliary services to allow the user to generate 559 keys, submit and process certification requests and to request updated 560 CRLs. 562 6.0 References 564 RFC 1521 N. Borenstein, N. Freed. RFC 1521: MIME 565 (Multipurpose Internet Mail Extensions) Part One: 566 Mechanisms for Specifying and Describing the Format 567 of Internet Message Bodies. September 1993. 569 PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message 570 Syntax Standard. Version 1.5, November 1993. 572 PKCS #10 RSA Laboratories. PKCS #10: Certification Request 573 Syntax Standard. Version 1.0, November 1993. 575 RFC 1847 J. Galvin, S.Murphy, S. Crocker, N. Freed. RFC 1847 576 Security Multiparts for MIME: Multipart/Signed and 577 Multipart/Encrypted. October 1995. 579 [Conformance] N Freed. IETF draft-ietd-822ext-mime-conf-XX.txt. 580 Multipart Internet Mail Extensions (MIME) Part Five: 581 Conformance Criteria and Examples. September 1995. 583 7.0 Acknowledgements 585 The S/MIME Message specification is the result of numerous interactions 586 and gatherings between RSA and various email vendors. Significant 587 contributions were made by Jeff Thompson, author of RIPEM and Lawrence 588 Lundblade. 590 8.0 Author's Address 592 Steve Dusse 593 RSA Data Security, Inc 594 100 Marine Parkway, Suite 500 595 Redwood City, CA. 94065 596 Phone: 415-595-8782 597 Fax: 415-595-1873 598 Email: Steve@rsa.com 600 Dusse Page [11]