idnits 2.17.1 draft-ietf-pem-mime-05.txt: ** The Abstract section seems to be numbered 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-28) 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 6 months document validity. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 9 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [6], [3-6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 495: '...ssion processing MUST be trustworthy, ...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (June 1994) is 10879 days in the past. Is this intentional? 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: '3-6' on line 42 == Unused Reference: '7' is defined on line 767, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 769, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 772, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '1') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1341 (ref. '2') (Obsoleted by RFC 1521) ** Obsolete normative reference: RFC 1113 (ref. '3') (Obsoleted by RFC 1421) ** Downref: Normative reference to an Historic RFC: RFC 1422 (ref. '4') ** Downref: Normative reference to an Historic RFC: RFC 1423 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1424 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 821 (ref. '9') (Obsoleted by RFC 2821) Summary: 20 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Steve Crocker 2 INTERNET DRAFT Ned Freed 3 draft-ietf-pem-mime-05.txt Jim Galvin 4 Sandy Murphy 5 June 1994 7 PEM Security Services and MIME 9 1. Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute working 14 documents as Internet Drafts. 16 Internet Drafts are valid for a maximum of six months and may be 17 updated, replaced, or obsoleted by other documents at any time. It is 18 inappropriate to use Internet Drafts as reference material or to cite 19 them other than as ``work in progress''. 21 To learn the current status of any Internet Draft, please check the 22 1id-abstracts.txt listing contained in one of the Internet Drafts Shadow 23 Directories on ds.internic.net (US East Coast), venera.isi.edu (US West 24 Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe). 26 2. Abstract 28 This document specifies how the services of MIME and PEM can be used in 29 a complementary fashion. MIME, an acronym for "Multipurpose Internet 30 Mail Extensions", defines the format of the contents of Internet mail 31 messages and provides for multi-part textual and non-textual message 32 bodies. PEM, an acronym for "Privacy Enhanced Mail", provides message 33 authentication/integrity and message encryption services for Internet 34 mail messages. 36 An Internet electronic mail message consists of two parts: the headers 37 and the body. The headers form a collection of field/value pairs 38 structured according to RFC 822 [1], whilst the body, if structured, is 39 defined according to MIME [2]. MIME does not provide for the 40 application of security services. 42 PEM [3-6] specifies how to apply encryption and authentication/integrity 43 services to the contents of a textual electronic mail message but does 44 not provide message structuring or type labelling facilities. This 45 document specifies how to use PEM with the multipart/signed and 46 multipart/encrypted MIME content types to provide 47 authentication/integrity and encryption services. We refer to the 48 authentication/integrity service as a digital signature service. 50 This document updates the message encryption and signature procedures 51 defined by [3] and obsoletes the key certification and related services 52 defined by [6]. The changes to [3] include the separation of the 53 encryption and signature services, the removal of the limitation to 54 enhance only text-based messages, the removal of the transfer encoding 55 operation, the deprecation of the Content-Domain: and Proc-Type: 56 headers, and the separation of certificate and certificate revocation 57 list transmission from the security enhancements. These changes 58 represent a departure in mechanism, not in effect, and are detailed in 59 Section ??. 61 In addition, this document proposes three technical changes: in [3] 62 symmetric key management is deprecated, also in [3] the canonicalization 63 operation is generalized, and in [4] the allowable name forms for the 64 subjects of certificates is broadened to include arbitrary strings and 65 email addresses, and users may distribute their public keys directly in 66 lieu of certificates. 68 The key certification and related services document [6] is obsoleted by 69 the specification of two new MIME content types: application/key-request 70 and application/key-data. These new content types are used to transmit 71 requests for key operations (retrieval, certification, revocation list 72 retrieval, etc.) and the responses to those requests. These two 73 content types are independent body parts and are not required to be 74 encapsulated in any other body part. These changes represent a 75 departure in mechanism, not in effect, and are detailed in Section ??. 77 The relationship between MIME and PEM is described in terms of two 78 functions: message composition and message delivery. 80 3. Applying PEM Security Services to MIME Body Parts 82 The next section describes the processing steps necessary to prepare a 83 MIME body part for the application of PEM security services. The 84 succeeding two sections describe the content of the multipart/signed and 85 multipart/encrypted body parts resulting from the application of PEM 86 security services to MIME body parts. 88 3.1. PEM Processing Steps 90 The following three steps describe the preparation of outbound PEM 91 messages. These steps may be repeated as necessary to prepare a message 92 for submission. 94 (1) Local Form -- the content of the message is prepared in the native 95 format of the user's local environment 97 (2) Canonical Form -- the content of the message is transformed to a 98 canonical form for the digital signature service; no 99 canonicalization is required for the encryption service 101 (3) Security Form -- either of the signature or encryption services may 102 be applied 104 Each of these steps is described in detail below. Their relationship to 105 message composition and delivery is described in Section ??. 107 3.1.1. Step 1: Local Form 109 The message content is created in the native format of the user's local 110 environment. 112 3.1.2. Step 2: Canonical Form 114 Prior to the application of the digital signature service, the content 115 must be in a canonical form. No canonicalization is required for the 116 encryption service and therefore processing continues with the next 117 step. 119 Transforming the content to be signed into a canonical form is a 120 necessary and essential step in the digital signature process. The 121 canonical form must satisfy the property that it is uniquely and 122 unambiguously representable on both the originator and recipient's local 123 environment. This is required in order to ensure that both the 124 originator and recipient have the same data with which to calculate the 125 digital signature; the originator needs to be able to include the 126 digital signature value when transferring the body part, while the 127 recipient needs to be able to compare a re-calculated value with the 128 received value. Further, the canonical form should satisfy the property 129 that it is representable on as many different host computers as 130 possible. By satisfying this property, signed data may be forwarded by 131 recipients to additional recipients, who will also be able to verify the 132 original signature. This service is called forwardable authentication. 134 The canonical form of all content types is defined to be 7bit. The data 135 to be signed must be represented as 7bit. Since the MIME standard 136 explicitly disallows nested encodings, the body parts enclosed in a 137 multipart content type, for example, must be encoded in a 7bit 138 representation. Any valid MIME encoding may be selected. 140 The 7bit representation of the data is transferred to the recipient. As 141 may be required by MIME, an appropriate Content-Transfer-Encoding: 142 header is included with the data. Upon receipt, a MIME implementation 143 would verify the signature of the data prior to decoding the data and 144 displaying it to the recipient. 146 Representing all complex content types as 7bit transforms them into 147 text-based content types. However, text-based content types present a 148 unique problem. In particular, there are far too many broken message 149 transfer agents that make arbitrary changes to text-based messages as 150 they are relayed, including adding, deleting, or changing TAB and SPACE 151 characters, and line delimiters are altered by message transfer agent 152 protocols. These changes will make it impossible for recipients to 153 verify the signature on a message. 155 The application of the digital signature service requires that the same 156 line delimiter be used by both the originator and the recipient. This 157 document specifies that the two character sequence "" must be 158 used as the line delimiter. Thus, the canonicalization transformation 159 is to transform the local line delimiter to the two character sequence 160 "". 162 The transformation to the universal line delimiter is only required for 163 the purposes of computing the digital signature. Thus, originators must 164 apply the universal line delimiter transformation before calculating the 165 digital signature but must transfer the data without the universal line 166 delimiter transformation. Similarly, recipients must apply the 167 universal line delimiter transformation before calculating the digital 168 signature. 170 NOTE: An originator can not transfer the content with the 171 universal line delimiter transformation intact because the 172 transformation process is not idempotent. In particular, SMTP 173 servers may themselves convert the universal line delimiter to a 174 local line delimiter, prior to the message being delivered to 175 the user. Thus, a recipient has no way of knowing if the 176 transformation is present or not. Thus, if the recipient 177 applies the transformation to a content in which it is already 178 present, the resulting content may have two line delimiters 179 present, which would cause the verification of the signature to 180 fail. 182 3.1.3. Step 3: Security Form 184 Either of the digital signature or encryption services is applied to a 185 content. The content to be protected is prepared by a MIME 186 implementation and made available to a PEM implementation according to a 187 local convention. The PEM implementation must produce two outputs: the 188 data that has been protected and the control information necessary to 189 verify or remove the protection. These outputs must be made available 190 to the MIME implementation which will construct a multipart/signed or 191 multipart/encrypted content, according to the service requested. The 192 multipart content replaces the content that was selected for protection. 194 3.2. Use of multipart/signed Content Type 196 When this content type is used, the value of the required parameter 197 "protocol" is "pem" and the value of the required parameter "hashalg" is 198 one of the valid choices from [5], for example: 200 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; 201 boundary="Signed Message" 203 --Signed Message 204 Content-Type: text/plain 206 This is some example text. 208 --Signed Message 209 Content-Type: application/signature 211 212 --Signed Message-- 214 where the token is defined as follows. 216 ::= (1*) 218 ::= "Version:" "5" CRLF 220 ::= 222 ::= "Originator-ID:" CRLF 224 The token is defined in Section ??. 226 The only valid value for a Content-Transfer-Encoding: header, if 227 included, is "7bit". 229 3.3. Use of multipart/encrypted Content Type 231 When this content type is used, the value of the required parameter 232 "protocol" is "pem", for example: 234 Content-Type: multipart/encrypted; protocol="pem"; 235 boundary="Encrypted Message" 237 --Encrypted Message 238 Content-Type: application/keys 240 242 --Encrypted Message 243 Content-Type: application/octet-stream 245 246 --Encrypted Message-- 248 where the token is defined as follows. 250 ::= 1* 252 ::= "Version:" "5" CRLF 254 ::= 256 ::= "Recipient-ID:" CRLF 258 ::= "Key-Info" ":" "," CRLF 260 The token is defined in Section ??. 262 4. Removing PEM Security Services from PEM Body Parts 264 Upon receipt of a multipart/signed or multipart/encrypted body part, the 265 PEM security services are removed by reversing the sequence of steps 266 specified in Section ??, modifying step 2 as follows. 268 (1) All content types must have their line delimiters canonicalized 269 prior to removing the PEM security services. 271 (2) Outer layers of PEM security services must be processed prior to 272 processing inner layers of PEM security services. Processing 273 includes a user choosing to display a content without removing the 274 PEM security services. 276 5. Definition of New Name Forms 278 WARNING: This is the first draft of this section. Although 279 conceptually it represents a direction that will not change, 280 while this document is an internet draft the details of the 281 specification are subject to change at any time, without notice, 282 owing to comments and implementation experience. Implementors 283 are encouraged to contact the authors for the current status. 285 Currently, [3] requires the use of certificates to specify the public 286 key used to create a PEM message. Within certificates, [4] requires the 287 use of distinguished names as specified by the X.500 Series of 288 Recommendations. However, the Internet community has a great deal more 289 experience with the use of electronic mail addresses as identifiers and 290 there is a desire to be able to use arbitrary strings to identify the 291 owners of public keys. Hence, there is a need to support name forms 292 which do not conform to the expected usage of distinguished names. 294 In addition, users may distribute their public keys via mechanisms 295 outside the scope of the PEM specification, for example, in a file via 296 FTP as opposed to in a certificate. As a result, it is desirable to be 297 able to explicitly specify the public key used rather than an identifier 298 of the public key. 300 The objective of the various Originator and Recipient fields specified 301 in [3] is to indicate which public key has been used or is required. 302 This document simplifies the set of fields by specifying exactly two: 303 Originator-ID: for originators and Recipient-ID: for recipients. The 304 value of each of these fields is indicated by the token , which is 305 defined as follows. 307 ::= / / 308 / / 310 ::= "EN" "," 311 "," "," 312 ::= "STR" "," 313 "," "," 314 ::= "DN" "," 315 "," "," 316 ::= "PK" "," 317 "," "," 318 "," ( / ) 319 ::= "IS" "," "," 321 ::= 322 ; a printably encoded, ASN.1 encoded 323 ; string containing exactly one '@' 324 ::= 325 ; "a sequence of characters excluding '@'" 326 ; a printably encoded, ASN.1 value 328 ::= "to be defined by RFC 1423" 329 ::= 1* 330 ; hex dump of the hash of the 331 ; public key 333 ::= "to be defined by RFC 1423" 334 ::= 335 ; a printably encoded, ASN.1 encoded public key 337 ::= 338 ; a printably encoded, ASN.1 encoded 339 ; distinguished name 340 ::= 1* 341 ; hex dump of the serial number of a certificate 343 The inclusion of the hash of the public key is intended to facilitate 344 the recognition of which public key among several that may be associated 345 with the string or distinguished name. 347 The identifiers and are distinguished only by the 348 presence or absence of the character '@'. In all other respects they 349 are equivalent and are encoded strings that are to be used as the 350 subject name in a certificate. This distinguishing characteristic was 351 chosen as opposed to defining a new object identifier to represent email 352 addresses because of the perceived difficulty in distributing and 353 implementing the definition of a new object identifier. 355 The identifier allows for the direct distribution and 356 indication of the public key that was or is to be used to process the 357 message. 359 The identifier is included for backward compatibility with 360 the ID-ASymmetric fields defined in [3]. The older fields are easily 361 converted to this new form by prefixing the old value with "IS," and 362 replacing the field name with an appropriate new ID field. 364 6. Definition of New Content Types 366 This document defines two new content types, the contents of which 367 comprise a replacement mechanism for [6]. The first content type is 368 application/key-request, which replaces the certification and CRL- 369 retrieval request messages. The second content type is 370 application/key-data, which replaces the certification reply message, 371 the crl-storage request message, and the crl-retrieval reply message. 372 There were no requirements for a crl-storage reply message and none are 373 specified in this document. This document includes a specification for 374 a certificate request message, which was previously undefined. 376 NOTE: RFC1424 has some descriptive text, especially for 377 certification messages, that should probably be included. 379 6.1. application/key-request Content Type Definition 381 (1) MIME type name: application 383 (2) MIME subtype name: key-request 385 (3) Required parameters: none 387 (4) Optional parameters: none 389 (5) Encoding considerations: quoted-printable is always sufficient 390 (6) Security Considerations: none 392 The content of this body part corresponds to the following production. 394 ::= 395 ( / / ) 396 ::= "Version:" "5" CRLF 397 ::= "Subject:" CRLF 398 ::= "Issuer:" CRLF 399 ::= "Certification:" CRLF 401 This content type is used to provide for some of the requests described 402 in [6]. The information in the body part is entirely independent of any 403 other body part. As such, the application/key-request content type is 404 an independent body part. 406 The certification request, certificate-retrieval request and crl- 407 retrieval request are provided for directly. If the content contains a 408 Certification: field it requests certification of the self-signed 409 certificate in the field value. If the content contains an Issuer: 410 field it requests the certificate revocation list chain beginning with 411 the issuer identified in the field value. If the content contains a 412 Subject: field it requests the certificate chain beginning with the 413 subject identified in the field value. 415 The Subject: and Issuer: fields each contain a value of type Name, 416 encoded according to the Basic Encoding Rules, then in ASCII, as for the 417 Originator-ID-Asymmetric: field of [3]. 419 The crl-storage request is provided for by the application/key-data 420 content type described in the next section. 422 In each case, the response is transmitted in an application/key-data 423 content type. When returning certificate and certificate revocation 424 list chains, if there exists more than one chain, several 425 application/key-data contents are to be returned in the reply message, 426 one for each chain. 428 6.2. application/key-data Content Type Definition 430 (1) MIME type name: application 431 (2) MIME subtype name: key-data 433 (3) Required parameters: none 435 (4) Optional parameters: none 437 (5) Encoding considerations: quoted-printable is always sufficient. 439 (6) Security Considerations: none 441 The content of this body part corresponds to the following production. 443 ::= / 444 ::= *( [ ] ) 445 ::= 1*( [ ] ) 446 ::= "Certificate:" CRLF 447 ::= "CRL:" CRLF 448 ::= "Version:" "5" CRLF 450 This content type is used to transfer certificate or Certificate 451 Revocation List (CRL) information. The information in the body part is 452 entirely independent of any particular privacy enhanced message. (Note 453 that the converse is not true: the validity of a privacy enhanced 454 message cannot be determined without the proper certificates or current 455 CRL information.) As such, the application/key-data content type is an 456 independent body part. 458 The production contains one certificate chain. A 459 certificate chain starts with a certificate and continues with the 460 certificates of subsequent issuers. Each issuer certificate included 461 must have issued the preceding certificate. For each issuer, a CRL may 462 be supplied. A CRL in the chain belongs to the immediately following 463 issuer. Therefore, it potentially contains the immediately preceding 464 certificate. 466 The production contains one certificate revocation list 467 chain. The CRLs in the chain begin with the requested CRL and continue 468 with the CRLs of subsequent issuers. The issuer of each CRL is presumed 469 to have issued a certificate for the issuer of the preceding CRL. For 470 each CRL, the issuer's certificate may be supplied. A certificate in 471 the chain must belong to the issuer of the immediately preceding CRL. 473 The relationship between a certificate and an immediately preceding CRL 474 is the same in both cases. In a the crl's are optional. In 475 a the certificates are optional. 477 7. Message Processing 479 When a user composes a message, it is the responsibility of the user 480 agent to construct a valid MIME message. In particular, Content-Type: 481 and Content-Transfer-Encoding: headers should be used wherever they are 482 appropriate. This allows the receiving user agent to unambiguously 483 interpret the message body and process it accordingly. 485 Each block of content headers associated with either an RFC822 486 or with a MIME represents a logical place where security 487 enhancement can be requested. A security enhancement request associated 488 with a particular or content is taken to apply to 489 the entire content; it is not possible to security-enhance only a 490 portion of a body part. 492 The mechanism used to communicate security enhancement requests to the 493 pre-submission processor described below is strictly a local 494 implementation issue. However, the interface between the message 495 composer and pre-submission processing MUST be trustworthy, since the 496 message composer relies on pre-submission processing to either perform 497 the requested security enhancement operation or return an error. 498 Regardless of the mechanism chosen, great care should be taken to 499 safeguard against both the release of information that has not received 500 the requested type of security enhancement as well as tampering with the 501 enhancement request itself. 503 7.1. Pre-Submission Algorithm 505 The user agent first composes a MIME-compliant message and then applies 506 this algorithm: 508 (1) If the content at this (initially top) level has NOT been selected 509 for security enhancement, the user agent sees if the content is 510 either multipart or message. If so, it then recursively applies 511 this algorithm to the encapsulated body parts; if not, it 512 terminates processing for this content. 514 (2) If the content at this level has been selected for security 515 enhancement, then the content, including its headers, constitutes 516 the object that is to be made available to the security enhancement 517 process. The headers at a minimum will include a Content-Type 518 header, either explicit or implicit. The object will eventually be 519 replaced with the multipart content that is produced by the 520 security enhancement operation. 522 (3) The selected security enhancement is performed. This enhancement 523 produces two data streams: the enhanced object and a control stream 524 comprised of a set of headers as defined in the or 525 productions. 527 (4) A new body part is then constructed, of content type 528 multipart/signed or multipart/encrypted. The new body part 529 contains two body parts, whose content depends on the enhancement 530 requested, which are constructed according to the specifications in 531 this document. 533 (5) This multipart content replaces the original object. 535 7.2. Post-Delivery Algorithm 537 When a user receives a message containing a multipart content, the user 538 agent may transform the content back into its original form prior to 539 privacy-enhancement. This operation, the post-delivery algorithm, is 540 performed by reversing the steps performed during the pre-submission 541 algorithm. 543 When the original content is reconstituted, it may use octet values 544 outside of the US-ASCII repertoire and may contain body parts without 545 line breaks. If the user agent replaces the multipart content with the 546 original content, then it must select appropriate Content-Transfer- 547 Encodings for each body part and add corresponding Content-Transfer- 548 Encoding: headers. 550 Upon successful completion of the post-delivery algorithm for each 551 content, the type of enhancement that was in effect for that content 552 must be communicated to the user. The mechanism used to do this is a 553 local implementation issue. As with requests for enhancement to the 554 pre-submission algorithm, the path between post-delivery processing and 555 actual display of the message must be a trusted one, lest a message be 556 presented that purports to have undergone some form of enhancement it 557 did not in fact receive. 559 8. Examples 561 NOTE: To be included upon completion of implementation. 563 9. Observations 565 The use of the pre-submission and post-delivery algorithms to combine 566 PEM and MIME capabilities exhibits several properties: 568 (1) It allows privacy-enhancement of an arbitrary content, not just the 569 body of an RFC 822 message. 571 (2) For a multipart or message content, it allows the user to specify 572 different privacy enhancements to be applied to different 573 components of the structure of the content. 575 (3) It provides for messages containing several privacy enhanced 576 contents, thereby removing the requirement for PEM software to be 577 able to generate or interpret a single content which intermixes 578 both unenhanced and enhanced components. 580 The use of a MIME-capable user agent makes complex nesting of enhanced 581 message body parts much easier. For example, the user can separately 582 sign and encrypt a message. This motivates a complete separation of the 583 confidentiality security service from the digital signature security 584 service. That is, different keys could be used for the different 585 services and could be protected separately. In the asymmetric case, 586 this means an employee's company could be given access to the (private) 587 decryption key but not the (private) signature key, thereby granting the 588 company the ability to decrypt messages addressed to the employee in 589 emergencies without also granting the company the ability to sign 590 messages as the employee. 592 The use of two private keys requires the ability to maintain multiple 593 certificates for each user. 595 10. Summary of Changes to PEM Specification 597 This document updates the message encryption and signature procedures 598 defined by [3] and obsoletes the key certification and related services 599 defined by [6]. The changes are enumerated below. 601 (1) The PEM specification currently requires that encryption services 602 be applied only to message bodies that have been signed. By 603 providing for each of the services separately, they may be applied 604 recursively in any order according to the needs of the requesting 605 application. 607 (2) PEM implementations are currently restricted to processing only 608 text-based electronic mail messages. In fact, the message text is 609 required to be represented by the ASCII character set with 610 "" line delimiters. This restriction no longer applies. 612 (3) With the removal of the text restriction it is not possible to 613 specify a universal canonical form. However, canonicalization is 614 required for the digital signature service, so the content of each 615 body part must be transformed into a canonical form according to 616 its type. 618 (4) MIME includes transfer encoding operations to ensure the unmodified 619 transfer of body parts, which obviates these services in PEM. 621 (5) PEM specifies a Proc-Type: header field to identify the type of 622 processing that was performed on the message. This functionality 623 is subsumed by the MIME Content-Type: headers. The Proc-Type: 624 header also included a decimal number that was used to distinguish 625 among incompatible encapsulated header field interpretations which 626 may arise as changes are made to the PEM standard. This 627 functionality is replaced by the Version: header specified in this 628 document. 630 (6) PEM specifies a Content-Domain: header, the purpose of which is to 631 describe the type of the content which is represented within a PEM 632 message's encapsulated text. This functionality is subsumed by the 633 MIME Content-Type: headers. 635 (7) The PEM specifications include a document that defines new types of 636 PEM messages, specified by unique values used in the Proc-Type: 637 header, to be used to request certificate and certificate 638 revocation list information. This functionality is subsumed by two 639 new content types specified in this document. 641 (8) The header fields having to do with certificates (Originator- 642 Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated 643 for use only in the application/key-data and application/key- 644 request content types and are no longer allowed in the header 645 portion of a PEM signed or encrypted message. 647 (9) The grammar specified here explicitly separates the header fields 648 that may appear for the encryption and signature security services. 649 It is the intent of this document to specify a precise expression 650 of the allowed header fields; there is no intent to reduce the 651 functionality of combinations of encryption and signature security 652 from those of [3]. 654 (10) With the separation of the encryption and signature security 655 services, there is no need for a MIC-Info: field in the headers 656 associated with an encrypted message under asymmetric key 657 management. 659 (11) In [3], when asymmetric key management is used, an Originator-ID 660 field is required in order to identify the private key used to sign 661 the MIC argument in the MIC-Info: field. Because no MIC-Info: 662 field is associated with the encryption security service under 663 asymmetric key managment, there is no requirement in that case to 664 include an Originator-ID field. 666 These changes represent a departure in mechanism, not in effect, from 667 those specified in [3] and [6]. The following technical changes to [3] 668 and [4] are also specified by this document. 670 (1) The grammar specified here explicitly excludes symmetric key 671 management. Currently, there are no generally available 672 implementations of symmetric key management nor are there any known 673 plans for implementing it. As a result, the IETF standards process 674 will require this feature to be dropped when the documents are 675 promoted to draft standard status from proposed standard status. 677 (2) This document requires all data that is to be digitally signed to 678 be represented in 7bit form. 680 (3) This document relaxes the syntax of distinguished names. In 681 particular, distinguished names are not constrained to conform to 682 the X.500 Series of Recommendations. Instead users may use 683 arbitrary strings and email addresses as their name. Further, 684 users may distribute their public key directly in lieu of using 685 certificates. In support of this change the Originator-ID- 686 ASymmetric: and Recipient-ID-ASymmetric: fields are deprecated in 687 favor of Originator-ID: and Recipient-ID: fields, respectively. 689 11. Collected Grammar 691 The following is a summary of the grammar presented in this document. 693 (1) Signature headers 694 ::= (1*) 696 ::= "Version:" "5" CRLF 698 ::= 700 ::= "Originator-ID:" CRLF 702 (2) Encryption Headers 704 ::= 1* 706 ::= "Version:" "5" CRLF 708 ::= 710 ::= "Recipient-ID:" CRLF 712 ::= "Key-Info" ":" "," CRLF 714 (3) Request Headers (certificate, certification, etc.) 716 ::= 717 ( / / ) 718 ::= "Version:" "5" CRLF 719 ::= "Subject:" CRLF 720 ::= "Issuer:" CRLF 721 ::= "Certification:" CRLF 723 (4) Certificate Headers (certificate, certification revocation list) 725 ::= / 726 ::= *( [ ] ) 727 ::= 1*( [ ] ) 728 ::= "Certificate:" CRLF 729 ::= "CRL:" CRLF 730 ::= "Version:" "5" CRLF 732 12. Security Considerations 734 NOTE: to be done 736 13. Acknowledgements 738 David H. Crocker suggested the use of a multipart structure for MIME-PEM 739 interaction. 741 14. References 743 [1] David H. Crocker. Standard for the Format of ARPA Internet Text 744 Messages. RFC 822, University of Delaware, August 1982. 746 [2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet 747 Mail Extension) Part One: Mechanisms for Specifying and Describing 748 the Format of Internet Message Bodies. RFC 1521, Bellcore and 749 Innosoft, September 1993. Obsoletes RFC 1341. 751 [3] John Linn. Privacy Enhancement for Internet Electronic Mail: Part 752 I: Message Encryption and Authentication Procedures. RFC 1421, 753 February 1993. Obsoletes RFC 1113. 755 [4] Steve Kent. Privacy Enhancement for Internet Electronic Mail: Part 756 II: Certificate-Based Key Management. RFC 1422, BBN 757 Communications, February 1993. 759 [5] David M. Balenson. Privacy Enhancement for Internet Electronic 760 Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423, 761 Trusted Information Systems, February 1993. 763 [6] Burton S. Kaliski. Privacy Enhancement for Internet Electronic 764 Mail: Part IV: Key Certification and Related Services. RFC 1424, 765 RSA Laboratories, February 1993. 767 [7] David Crocker. Multipart/Family Content Types. Work in progress. 769 [8] James Galvin. Security Multiparts for MIME: Multipart/Signed and 770 Multipart/Encrypted. Work in progress. 772 [9] Jon Postel. Simple Mail Transfer Protocol. RFC 821, ISI, August 773 1982. 775 15. Authors' Addresses 777 Steve Crocker 778 Trusted Information Systems 779 3060 Washington Road 780 Glenwood, MD 21738 781 Tel: +1 301 854 6889 782 FAX: +1 301 854 5363 783 email: crocker@tis.com 785 Ned Freed 786 Innosoft International, Inc. 787 250 West First Street, Suite 240 788 Claremont, CA 91711 789 Tel: +1 909 624 7907 790 FAX: +1 909 621 5319 791 email: ned@innosoft.com 793 James M. Galvin 794 Trusted Information Systems 795 3060 Washington Road 796 Glenwood, MD 21738 797 Tel: +1 301 854 6889 798 FAX: +1 301 854 5363 799 email: galvin@tis.com 801 Sandra Murphy 802 Trusted Information Systems 803 3060 Washington Road 804 Glenwood, MD 21738 805 Tel: +1 301 854 6889 806 FAX: +1 301 854 5363 807 email: murphy@tis.com 809 16. Appendix: Imported Grammar 811 The following productions are taken from [3]. The grammar presented in 812 [3] remains the authoritative source for these productions; they are 813 repeated here for the convenience of the reader. 815 ::= "DEK-Info" ":" [ "," ] CRLF 817 ::= "MIC-Info" ":" "," "," 818 CRLF 820 ::= 1* 821 ::= 4*4 822 ::= ALPHA / DIGIT / "+" / "/" / "=" 824 The following productions are taken from [5]. The grammar presented in 825 [5] remains the authoritative source for these productions; they are 826 repeated here for the convenience of the reader. 828 ::= "DES-CBC" 829 ::= "DES-EDE" / "DES-ECB" / "RSA" 830 ::= "RSA-MD2" / "RSA-MD5" 832 ::= 833 ::= 834 ::= 836 ::= 837 ::= 839 ::= 840 ::= 842 ::= 16*16 843 ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 844 ; no lower case 846 Table of Contents 848 1 Status of this Memo ............................................. 1 849 2 Abstract ........................................................ 1 850 3 Applying PEM Security Services to MIME Body Parts ............... 2 851 3.1 PEM Processing Steps .......................................... 3 852 3.1.1 Step 1: Local Form .......................................... 3 853 3.1.2 Step 2: Canonical Form ...................................... 3 854 3.1.3 Step 3: Security Form ....................................... 5 855 3.2 Use of multipart/signed Content Type .......................... 5 856 3.3 Use of multipart/encrypted Content Type ....................... 6 857 4 Removing PEM Security Services from PEM Body Parts .............. 7 858 5 Definition of New Name Forms .................................... 7 859 6 Definition of New Content Types ................................. 9 860 6.1 application/key-request Content Type Definition ............... 9 861 6.2 application/key-data Content Type Definition .................. 10 862 7 Message Processing .............................................. 12 863 7.1 Pre-Submission Algorithm ...................................... 12 864 7.2 Post-Delivery Algorithm ....................................... 13 865 8 Examples ........................................................ 13 866 9 Observations .................................................... 14 867 10 Summary of Changes to PEM Specification ........................ 14 868 11 Collected Grammar .............................................. 16 869 12 Security Considerations ........................................ 18 870 13 Acknowledgements ............................................... 18 871 14 References ..................................................... 18 872 15 Authors' Addresses ............................................. 19 873 16 Appendix: Imported Grammar ..................................... 20