idnits 2.17.1 draft-ietf-pem-mime-07.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-19) 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 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 49 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-6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 1994) is 10748 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 ** 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' Summary: 16 errors (**), 0 flaws (~~), 1 warning (==), 4 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-07.txt Jim Galvin 4 Sandy Murphy 5 November 1994 7 PEM Security Services and MIME 9 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 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 RFC822 [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 specifies a number of changes to the message encryption 51 and signature procedures of PEM and broadens the name forms that may be 52 used to identify public keys. Many of the changes represent a departure 53 in mechanism, not in effect. 55 1. Introduction 57 This document updates the message encryption and signature procedures 58 defined by [3] and replaces the key certification and related services 59 defined by [6]. The changes to [3] include the separation of the 60 encryption and signature services, the removal of the limitation to 61 enhance only text-based messages, the removal of the transfer encoding 62 operation, the deprecation of the Content-Domain: and Proc-Type: 63 headers, and the separation of certificate and certificate revocation 64 list transmission from the security enhancements. These changes 65 represent a departure in mechanism, not in effect, and are detailed in 66 Section 8. 68 In addition, this document specifies four technical changes to PEM: 69 symmetric key management in [3] is deprecated, the canonicalization 70 operation in [3] is generalized, the allowable name forms for the 71 identification of public keys is broadened to include arbitrary strings 72 and email addresses, and users may distribute their public keys directly 73 in lieu of certificates. 75 The key certification and related services are replaced by the 76 specification of two new MIME content types: application/key-request and 77 application/key-data. These new content types are used to transmit 78 requests for key operations (storage, retrieval, certification, 79 revocation list retrieval, etc.) and the responses to those requests. 80 These two content types are independent body parts and are not required 81 to be encapsulated in any other body part. These changes represent a 82 departure in mechanism, not in effect, and are detailed in Section 8. 84 In order to make use of the PEM services, a user is required to have at 85 least one public/private key pair. Prior to this specification, the 86 public key was required to be embodied in a certificate, an object that 87 binds a public key with a distinguished name, a name form that 88 identified the owner of the public key. The embodiment was issued by a 89 certification authority, a role that was expected to be trustworthy 90 insofar as it verified the identity of the owner prior to issuing the 91 certificate. However, the deployment of certificates and the creation 92 of the hierarchy of certification authorities has been problematic. 94 Instead, this specification bases the PEM services on a public/private 95 key pair. Each key pair is required to belong to a user (where user is 96 not limited to being a human, e.g., it could be a process or a role) 97 which has a name. There are 3 name forms specified by this document. 98 For backward compatibility (and forward compatibility if the X.500 99 Directory becomes a ubiquitous service) one of the name forms is a 100 distinguished name. In addition, email addresses and arbitrary strings 101 are allowed. 103 Since a user may have more than one key pair, a name form is 104 insufficient for uniquely identifying a key pair. A unique key selector 105 must be assigned to each key pair. The combination of a name form and a 106 key selector uniquely identifies a key pair and each key pair is 107 uniquely identified by a name form and key selector combination. 108 Throughout this document, this combination is called an identifier. 109 There are 5 identifiers specified by this document. 111 NOTE: In the simplest case, key selectors will be assigned by 112 the owners of the key pairs. This works best when users 113 generate their own key pairs for personal use, which they 114 distribute to others asserting by declaration that the public 115 key belongs to them. When the assertion that the public key 116 belongs to them is made by a third party, for example when a 117 certification authority issues a certificate to a user according 118 to [4], the key selector may be assigned by that third party. 120 With a key pair for one's self and software that is both MIME and PEM 121 aware, an originating user may digitally sign arbitrary data and send it 122 to one or more recipients. With the public keys of the recipients, a 123 user may encrypt the data so that only the intended recipients can 124 decrypt and read it. This specification separates these two services so 125 that an originator may apply either or both, in either order. 127 The name forms and identifiers are described in detail in the next 128 section. Succeeding sections specify how PEM and MIME are used together 129 and other ancillary details. 131 2. Name Forms and Identifiers 133 Currently, [3] requires the use of certificates to create and receive 134 PEM messages. Within certificates, [4] requires the use of 135 distinguished names as specified by the X.500 Series of Recommendations. 136 However, the Internet community has a great deal more experience with 137 the use of electronic mail addresses as a name form and there is a 138 desire to be able to use arbitrary strings to identify the owners of 139 public keys. Hence, there is a need to support name forms which do not 140 conform to the expected usage of distinguished names. 142 When receiving PEM messages it is necessary to be able to uniquely 143 identify the key pair used to create the message. A certificate is one 144 mechanism that accomplishes this, since it is uniquely identified by the 145 combination of its issuer's distinguished name and its serial number. 146 In any case, an identifier is required that consists of both a name form 147 and key selector. 149 In addition, users may distribute their public keys via mechanisms 150 outside the scope of the PEM specification, for example, in a file via 151 FTP. Users receiving such keys will probably assign name forms to them 152 to be displayed when receiving messages created with them. As a result, 153 it is desirable to be able to explicitly specify the public key used 154 rather than an identifier of the public key. 156 NOTE: A feature of being able to specify the public key 157 explicitly is that it allows users to exchange encrypted, 158 anonymous mail. In particular, receiving users will always know 159 a message comes from the same originating user. 161 The principal objective of the various Originator and Recipient fields 162 specified in [3] is to identify which public key has been used or is 163 required. This document reduces the set of fields by specifying exactly 164 two: Originator-ID: for originators and Recipient-ID: for recipients. 165 This specification defines 5 identifiers with which the public key used 166 may be indicated in each of these fields. 168 In the next section the 3 name forms are described in detail. Following 169 that is the specification of the 5 identifiers. 171 2.1. Name Forms 173 There are 3 name forms specified by this document: email addresses, 174 distinguished names, and arbitrary strings. 176 2.1.1. Email Addresses 178 The email address (grammar token ) used must be a valid RFC822 179 address, which is defined in terms of the two grammar tokens 180 and . The grammar for these two tokens is included in the 181 Appendix as a convenience; the definitive source for these tokens is 182 necessarily RFC822 [1]. 184 ::= / 185 ; an electronic mail address as defined by 186 ; these two tokens from RFC822 188 For example, the strings "crocker@tis.com", "galvin@tis.com", 189 "murphy@tis.com", and "ned@innosoft.com" are all email addresses. 191 2.1.2. Arbitrary Strings 193 The arbitrary string (grammar token ) must have a length of at 194 least 1. There are no other restrictions on the value chosen. 196 ::= ; a non-null sequence of characters 198 For example, the string 200 Jim "the SAAG mailing list maintainer" Galvin 202 is an arbitrary string. 204 2.1.3. Distinguished Names 206 The distinguished name (grammar token ) must be constructed 207 according to the guidelines of the X.500 Directory. The actual syntax 208 of the distinguished name is outside the scope of this specification. 209 However, RFC1422, for example, specifies syntactic restrictions based on 210 a particular choice of a certification hierarchy for certificates. 212 For the purposes of conveying a distinguished name from an originator to 213 a recipient, it must be ASN.1 encoded and then printably encoded 214 according to the base64 encoding defined by MIME. 216 ::= 217 ; a printably encoded, ASN.1 encoded 218 ; distinguished name (as defined by the 'Name' 219 ; production specified in X.501) 221 For example, 223 /Country Name=US 224 /State or Province Name=MD 225 /Organization Name=Trusted Information Systems 226 /Organizational Unit Name=Glenwood 227 /Common Name=James M. Galvin/ 229 is a distinguished name in a user friendly format (line breaks and 230 leading spaces present only to improve readability). When encoded, it 231 would appear as follows (line breaks present only to improve 232 readability): 234 MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3RlZCBJ 235 bmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMP 236 SmFtZXMgTS4gR2Fsdmlu 238 2.2. Identifiers 240 There are 5 types of identifiers specified by this document: email 241 address identifiers, arbitrary string identifiers, distinguished name 242 identifiers, the public keys themselves, and issuer name serial number 243 pairs from a certificate. All of these have approximately the same 244 structure (except issuer name and serial number which has 'TYPE, STRING, 245 KEYSEL' for historical reasons): 247 TYPE, KEYSEL, STRING 249 The TYPE field is a literal string, one for each of the possible 250 identifiers. 252 The KEYSEL field is used to distinguish between the multiple public keys 253 that may be associated with the name form in the STRING field. Its 254 value must be distinct from all other KEYSELs assigned by whomever 255 assigned this KEYSEL. A suggested value is to use a portion (low-order 256 16 or 32 bits) or all of the actual public key used. 258 The STRING field is the name form and has a different syntax according 259 to the value of the TYPE field. 261 The identifier used in each of the originator and recipient fields is 262 described by the following grammar. The definition of the key selector 263 token is included here since it used by several of the identifiers 264 below. 266 ::= / / 267 / / 269 ::= 270 ; a printably encoded non-null sequence of octets 272 Each of the identifier name forms is described below. 274 2.2.1. Email Address 276 The email address identifier has the following syntax. 278 ::= "EN" "," "," CRLF 280 The syntax of the token is defined in Section 2.1.1. 282 2.2.2. Arbitrary String 284 The arbitrary string identifier has the following syntax. 286 ::= "STR" "," "," CRLF 288 The syntax of the token is defined in Section 2.1.2. 290 2.2.3. Distinguished Name 292 The distinguished name identifier has the following syntax. 294 ::= "DN" "," "," CRLF 296 The syntax of the token is defined in Section 2.1.3. 298 2.2.4. Public Key 300 The public key identifier has the following syntax. 302 ::= "PK" "," [ "," ] CRLF 304 ::= 305 ; a printably encoded, ASN.1 encoded public key (as 306 ; defined by the 'SubjectPublicKeyInfo' production 307 ; specified in X.509) 309 ::= / / 311 The object subjectPublicKeyInfo is imported from the X.500 Directory 312 from the certificate object. It is currently the best choice for a 313 general purpose public key encoding. 315 In normal usage, the token is expected to be absent. When 316 present, it represents a mechanism by which an identifier (name form and 317 key selector) can be associated with a public key. Recipients of a 318 public key identifier must take care to verify the accuracy of the 319 purported association. If not, it may be possible for a malicious 320 originator to assert an identifier that accords the originator 321 unauthorized privileges. See Section 5.2 for more details. 323 2.2.5. Issuer Name and Serial Number 325 The issuer name and serial number identifier has the following syntax. 327 ::= "IS" "," "," CRLF 329 ::= 1* 330 ; hex dump of the serial number of a certificate 332 The identifier is included for backward compatibility (and 333 forward compatibility if X.500 Directory certificates become 334 ubiquitously available) with the ID-ASymmetric fields defined in [3]. 335 Its syntax was chosen such that the older fields are easily converted to 336 this new form by prefixing the old value with "IS," and replacing the 337 field name with an appropriate new ID field name. 339 3. Applying PEM Security Services to MIME Body Parts 341 The next section describes the processing steps necessary to prepare a 342 MIME body part for the application of PEM security services. The 343 succeeding two sections describe the content of the multipart/signed and 344 multipart/encrypted body parts resulting from the application of PEM 345 security services to MIME body parts. 347 3.1. PEM Processing Steps 349 The definition of the multipart/signed and multipart/encrypted body 350 parts in [7] specifies three steps for creating both body parts. 352 (1) The body part to be protected is created according to a local 353 convention. 355 (2) The body part is prepared for protection according to the protocol 356 parameter. 358 (3) The prepared body part is protected according to the protocol 359 parameter. 361 This specification makes no changes to step one in the sequence. For 362 step two, there is no preparation necessary for the encryption service. 363 For the digital signature service, the body part must be canonicalized 364 as described below. This specification makes no changes to step three 365 in the sequence. 367 Prior to the application of the digital signature service, the body part 368 must be in a canonical form. Transforming the body part to be signed 369 into a canonical form is a necessary and essential step in the digital 370 signature process. The canonical form must satisfy the property that it 371 is uniquely and unambiguously representable in both the originator and 372 recipient's local environment. This is required in order to ensure that 373 both the originator and recipient have the same data with which to 374 calculate the digital signature; the originator needs to be able to 375 include the digital signature value when transferring the body part, 376 while the recipient needs to be able to compare a re-computed value with 377 the received value. Further, the canonical form should satisfy the 378 property that it is representable on as many different host computers as 379 possible. By satisfying this property, signed data may be forwarded by 380 recipients to additional recipients, who will also be able to verify the 381 original signature. This service is called forwardable authentication. 383 The canonicalization transformation is a two step process. First, the 384 body part must be converted to a form that is uniquely and unambiguously 385 representable on as many different host computers as possible. Second, 386 the body part must have its line delimiters converted to a unique and 387 unambigous representation prior to computing the digital signature and 388 prior to each verification of the digital signature. 390 The representation of all body parts in the first step is specified to 391 be 7bit, as defined by [2]. Since the headers of body parts are already 392 required to be representable in 7bit, this step requires that if the 393 data to be signed is not already 7bit then it must be encoded with an 394 appropriate MIME content transfer encoding. Note: since the MIME 395 standard explicitly disallows nested content transfer encodings, i.e., 396 the content types multipart and message may not themselves be encoded, 397 body parts enclosed within, for example, a multipart content type must 398 be encoded in a 7bit representation. Any valid MIME encoding may be 399 selected for encoding the content of each of the non-7bit body parts. 401 As may be required by MIME, an appropriate Content-Transfer-Encoding: 402 header is added and included with the data to be signed. Upon receipt, 403 a MIME implementation would verify the signature of the data prior to 404 decoding the data and displaying it to the recipient. 406 Representing all complex content types as 7bit transforms them into 407 text-based content types. However, text-based content types present a 408 unique problem. In particular, the line delimiter used for a text-based 409 content type is specific to a local environment; different environments 410 use the single character carriage-return (), the single character 411 line-feed (), or the two character sequence "carriage-return line- 412 feed ()". 414 The application of the digital signature service requires that the same 415 line delimiter be used by both the originator and the recipient. This 416 document specifies that the two character sequence "" must be 417 used as the line delimiter. Thus, the second step of the 418 canonicalization transformation includes the conversion of the local 419 line delimiter to the two character sequence "". 421 The conversion to the canonical line delimiter is only required for the 422 purposes of computing the digital signature. Thus, originators must 423 apply the line delimiter conversion before computing the digital 424 signature but must transfer the data without the line delimiter 425 conversion. Similarly, recipients must apply the line delimiter 426 conversion before computing the digital signature. 428 NOTE: An originator can not transfer the content with the line 429 delimiter conversion intact because the conversion process is 430 not idempotent. In particular, SMTP servers may themselves 431 convert the line delimiter to a local line delimiter, prior to 432 the message being delivered to the user. Thus, a recipient has 433 no way of knowing if the conversion is present or not. Thus, if 434 the recipient applies the conversion to a content in which it is 435 already present, the resulting content may have two line 436 delimiters present, which would cause the verification of the 437 signature to fail. 439 IMPLEMENTORS NOTE: Implementors should be aware that the 440 conversion to a 7bit representation is a function that is 441 available in a minimally compliant MIME user agent. Further, 442 the line delimiter conversion required here is distinct from the 443 same conversion included in that function. Specifically, the 444 line delimiter conversion applied when a body part is converted 445 to a 7bit representation is performed prior to application of 446 the transfer encoding. The line delimiter conversion applied 447 when a body part is signed is performed after the body is 448 converted to 7bit. 450 3.2. Use of multipart/signed Content Type 452 Using this content type requires the specification of a control 453 information content type, the label of which is used as the value for 454 the required protocol parameter. Section 3.4 defines the control 455 information content type of application/pem-signature. The value of the 456 required parameter "protocol" is "application/pem-signature" and the 457 value of the required parameter "micalg" is one of the valid choices 458 from [5], for example: 460 Content-Type: multipart/signed; protocol="application/pem-signature"; 461 micalg="rsa-md5"; boundary="Signed Message" 463 --Signed Message 464 Content-Type: text/plain 466 This is some example text. 468 --Signed Message 469 Content-Type: application/pem-signature 471 SIGNATURE INFORMATION 472 --Signed Message-- 474 where SIGNATURE INFORMATION is descriptive of the content that would 475 appear in a real body part. 477 3.3. Use of multipart/encrypted Content Type 479 Using this content type requires the specification of a control 480 information content type, the label of which is used as the value for 481 the required protocol parameter. Section 3.5 defines the control 482 information content type of application/pem-keys. The value of the 483 required parameter "protocol" is "application/pem-keys", for example: 485 Content-Type: multipart/encrypted; protocol="application/pem-keys"; 486 boundary="Encrypted Message" 488 --Encrypted Message 489 Content-Type: application/pem-keys 491 KEY DATA 493 --Encrypted Message 494 Content-Type: application/octet-stream 496 ENCRYPTED DATA WOULD BE HERE 497 --Encrypted Message-- 499 3.4. application/pem-signature Content Type Definition 501 (1) MIME type name: application 503 (2) MIME subtype name: pem-signature 505 (3) Required parameters: none 507 (4) Optional parameters: none 509 (5) Encoding considerations: quoted-printable is always sufficient 511 (6) Security considerations: none 513 This content type is used on the second body part of an enclosing 514 multipart/signed when the protocol used is PEM. It is comprised of the 515 digital signature of the data, which is the first body part of the 516 enclosing multipart/signed, and the information required to verify that 517 signature. The label application/pem-signature is used as the value of 518 the protocol parameter of the enclosing multipart/signed. It is an 519 error for the protocol parameter to be missing from the enclosing 520 multipart/signed body part or for its value to be different from 521 application/pem-signature when this body part is used. 523 Included in the signature verification information will be the Message 524 Integrity Check (MIC) algorithm used during the signature creation 525 process. The MIC algorithm identified in this body part must match the 526 MIC algorithm identified in the micalg parameter of the enclosing 527 multipart/signed. If it does not, a user agent should identify the 528 discrepancy to a user and may choose to either halt or continue 529 processing, giving precedence to the algorithm identified in this body 530 part. 532 An application/pem-signature body part is constructed as follows: 534 Content-Type: application/pem-signature 536 538 where the token is defined as follows. 540 ::= ( 1* ) 542 ::= "Version:" "5" CRLF 544 ::= 546 ::= "Originator-ID:" CRLF 548 The token is defined in Section 2.2. 550 3.5. application/pem-keys Content Type Definition 552 (1) MIME type name: application 554 (2) MIME subtype name: pem-keys 556 (3) Required parameters: none 558 (4) Optional parameters: none 560 (5) Encoding considerations: quoted-printable is always sufficient 562 (6) Security considerations: none 563 This content type is used on the first body part of an enclosing 564 multipart/encrypted. It is comprised of the data encryption key used to 565 encrypt the data, located in the second body part of the enclosing 566 multipart/encrypted, and the information required to perform the 567 decryption. The label application/pem-keys is used as the value of the 568 protocol parameter of the enclosing multipart/encrypted. It is an error 569 for the protocol parameter to be missing in the enclosing 570 multipart/encrypted body part or for its value to be different from 571 application/pem-keys when this body part is used. 573 An application/pem-keys body part is constructed as follows: 575 Content-Type: application/pem-keys 577 579 where the token is defined as follows. 581 ::= 1* 583 ::= "Version:" "5" CRLF 585 ::= 587 ::= "Recipient-ID:" CRLF 589 ::= "Key-Info" ":" "," CRLF 591 The token is defined in Section 2.2. 593 4. Removing PEM Security Services from PEM Body Parts 595 This section describes the processing steps necessary to verify or 596 decrypt the PEM security services that have been applied to MIME body 597 parts. Outer layers of PEM security services must be processed prior to 598 processing inner layers of PEM security services. Processing includes a 599 user choosing to display a content without removing the PEM security 600 services. 602 The definition of the multipart/signed and multipart/encrypted body 603 parts in [7] specifies three steps for receiving both body parts. 605 (1) The protected body part and the control information body part are 606 prepared for processing. 608 (2) The prepared body parts are made available to the protection 609 removal process. 611 (3) The results of the protection removal process are made available to 612 the user and processing continues with the unprotected body part, 613 as returned by the protection removal process. 615 For step one, the preparation for digitally signed and encrypted body 616 parts is different, as described below. No changes are required to 617 steps two and three in the sequence. 619 For multipart/signed body parts, the control information is prepared by 620 removing any content transfer encodings that may be present. The 621 digitally signed body part is prepared by leaving the content transfer 622 encodings intact and converting the line delimiters according to Step 2 623 of Section 3.1. 625 Multipart/encrypted body parts are prepared by removing the content 626 transfer encodings, if present, from both the control information and 627 the encrypted body part. 629 5. Key Management Content Types 631 This document defines two key management content types, the contents of 632 which comprise a replacement mechanism for those defined in [6]. The 633 first content type is application/pemkey-request, which replaces the 634 certification and CRL-retrieval request messages. The second content 635 type is application/pemkey-data, which replaces the certification reply 636 message, the crl-storage request message, and the crl-retrieval reply 637 message. There are no requirements for a crl-storage reply message and 638 none are specified in this document. This document includes a 639 specification for a public key and certificate request message, which 640 were previously undefined. 642 5.1. application/pemkey-request Content Type Definition 644 (1) MIME type name: application 646 (2) MIME subtype name: pemkey-request 648 (3) Required parameters: none 649 (4) Optional parameters: none 651 (5) Encoding considerations: quoted-printable is always sufficient 653 (6) Security Considerations: none 655 The content of this body part corresponds to the following production. 657 ::= 658 ( / / ) 659 ::= "Version:" "5" CRLF 660 ::= "Subject:" CRLF 661 ::= "Issuer:" CRLF 662 ::= "Certification:" CRLF 664 This content type is used to provide for some of the request messages 665 described in [6]. The information in the body part is entirely 666 independent of any other body part. As such, the application/pemkey- 667 request content type is an independent body part. 669 The certification request, certificate-retrieval request and crl- 670 retrieval request are provided for directly. If the content contains a 671 Certification: field it requests certification of the self-signed 672 certificate in the field value. If the content contains an Issuer: 673 field it requests the Certificate Revocation List (CRL) chain beginning 674 with the CRL of the issuer identified in the field value. If the 675 content contains a Subject: field it requests either the public key of 676 the subject or a certificate chain beginning with the subject identified 677 in the field value, or both if both exist. 679 The Subject: and Issuer: fields each contain a value of type , which 680 is defined in Section 2.2. 682 The crl-storage request is provided for by the application/pemkey-data 683 content type described in the Section 5.2. 685 In each case, the response is transmitted in an application/pemkey-data 686 content type. When returning public keys, certificate chains, and 687 certificate revocation list chains, if there exists more than one, 688 several application/pemkey-data body parts are to be returned in the 689 reply message, one for each. 691 5.2. application/pemkey-data Content Type Definition 693 The principal objective of this content type is to convey cryptographic 694 keying material from a source to a destination. However, no explicit 695 provision is made for determining the authenticity or accuracy of the 696 data being conveyed. In particular, when a public key and its 697 identifier is conveyed, there is nothing to prevent the source or an 698 interloper along the path from the source to the destination from 699 substituting alternate values for either the public key or the 700 identifier, thus setting up the destination such that when the data is 701 used sensitive information may be intercepted and disclosed 702 inappropriately. 704 It is incumbent upon a recipient to verify the authenticity and accuracy 705 of the data received prior to its use. The problem is addressed by the 706 use of certificates, since a certification hierarchy is a well-defined 707 mechanism that conveniently supports the automatic verification of the 708 data. Alternatively, the application/key-data body part could be 709 digitally signed by the source. In this way, if the destination 710 believes that a correct source's public key is available locally and if 711 the destination believes the source would convey accurate data, then the 712 key data received from the source can be believed. 714 NOTE: Insofar as a certificate represents a mechanism by which a 715 third party vouches for the binding between a name and a public 716 key, the signing of an application/pemkey-data body part is a 717 similar mechanism. 719 (1) MIME type name: application 721 (2) MIME subtype name: pemkey-data 723 (3) Required parameters: none 725 (4) Optional parameters: none 727 (5) Encoding considerations: quoted-printable is always sufficient. 729 (6) Security Considerations: none 731 The content of this body part corresponds to the following production. 733 ::= 734 ( / / ) 735 ::= "Version:" "5" CRLF 736 ::= "Key:" "PK" "," "," CRLF 737 ::= *( [ ] ) 738 ::= 1*( [ ] ) 739 ::= "Certificate:" CRLF 740 ::= "CRL:" CRLF 742 This content type is used to transfer public keys, certificate chains, 743 or Certificate Revocation List (CRL) chains. The information in the 744 body part is entirely independent of any other body part. (Note that 745 the converse is not true: the validity of a protected body part cannot 746 be determined without the proper public keys, certificates, or current 747 CRL information.) As such, the application/pemkey-data content type is 748 an independent body part. 750 The production contains exactly one public key. It is 751 used to bind a public key with its corresponding name form and key 752 selector. It is recommended that when responders are returning this 753 information that the enclosing body part be digitally signed by the 754 responder in order to protect the information. The token is 755 defined in Section 2.2.4. 757 The production contains one certificate chain. A 758 certificate chain starts with a certificate and continues with the 759 certificates of subsequent issuers. Each issuer certificate included 760 must have issued the preceding certificate. For each issuer, a CRL may 761 be supplied. A CRL in the chain belongs to the immediately following 762 issuer. Therefore, it potentially contains the immediately preceding 763 certificate. 765 The production contains one certificate revocation list 766 chain. The CRLs in the chain begin with the requested CRL and continue 767 with the CRLs of subsequent issuers. The issuer of each CRL is presumed 768 to have issued a certificate for the issuer of the preceding CRL. For 769 each CRL, the issuer's certificate may be supplied. A certificate in 770 the chain must belong to the issuer of the immediately preceding CRL. 772 The relationship between a certificate and an immediately preceding CRL 773 is the same in both and . In a the 774 CRLs are optional. In a the certificates are optional. 776 6. Examples 778 Given the following email message prepared for submission: 780 To: Ned Freed 781 Subject: Hi Ned! 783 How do you like the new MIME/PEM? 785 Jim 787 When the text of the message is signed, it will look like this (note the 788 use of the public key identifier with the included email name 789 identifier): 791 To: Ned Freed 792 Subject: Hi Ned! 793 MIME-Version: 1.0 794 Content-Type: multipart/signed; protocol="application/pem-signature"; 795 micalg="rsa-md5"; boundary="Signed Boundary" 797 --Signed Boundary 798 Content-Type: text/plain; charset="us-ascii" 799 Content-ID: <21436.785186814.2@tis.com> 801 How do you like the new MIME/PEM? 803 Jim 805 --Signed Boundary 806 Content-Type: application/pem-signature 807 Content-ID: <21436.785186814.1@tis.com> 808 Content-Transfer-Encoding: quoted-printable 810 Version: 5 811 Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6B= 812 ekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8g= 813 G67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com 814 MIC-Info: RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERfMZXUKzFsHbmK= 815 tIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfbsOVJjleV7vTe9yoNp2P8mi/h= 816 s7 818 --Signed Boundary-- 820 If, instead, we choose to protect the headers with the text, it will 821 look like this: 823 To: Ned Freed 824 Subject: Hi Ned! 825 MIME-Version: 1.0 826 Content-Type: multipart/signed; protocol="application/pem-signature"; 827 micalg="rsa-md5"; boundary="Signed Boundary" 829 --Signed Boundary 830 Content-Type: message/rfc822 831 Content-ID: <21468.785187044.2@tis.com> 833 To: Ned Freed 834 Subject: Hi Ned! 836 How do you like the new MIME/PEM? 838 Jim 840 --Signed Boundary 841 Content-Type: application/pem-signature 842 Content-ID: <21468.785187044.1@tis.com> 843 Content-Transfer-Encoding: quoted-printable 845 Version: 5 846 Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6B= 847 ekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8g= 848 G67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com 849 MIC-Info: RSA-MD5,RSA,ctbDBgkYtFW1sisb5w4/Y/p94LftgQ0IrEn3d6WTwjfxFBvAceVW= 850 fawsZPLijVKZUYtbIqJmjKtzTJlagBawfA/KhUsvTZdR6Dj+4Gd8dBBwMKvqMKTHAUxGXYxwNd= 851 bK 853 --Signed Boundary-- 855 If we choose to encrypt the text of the following message, that is, 856 encrypt the lines marked with asterick (*): 858 To: Jim Galvin 859 Subject: an encrypted message 861 * How do you like the new MIME/PEM? 862 * 863 * Jim 865 the message would look as follows (note the use of the email name 866 identifier): 868 To: Jim Galvin 869 Subject: an encrypted message 870 MIME-Version: 1.0 871 Content-Type: multipart/encrypted; protocol="application/pem-keys"; 872 boundary="Encrypted Boundary" 874 --Encrypted Boundary 875 Content-Type: application/pem-keys 876 Content-ID: <21535.785187667.1@tis.com> 877 Content-Transfer-Encoding: quoted-printable 879 Version: 5 880 DEK-Info: DES-CBC,D488AAAE271C8159 881 Recipient-ID: EN,2,galvin@tis.com 882 Key-Info: RSA,ISbC3IR01BrYq2rp493X+Dt7WrVq3V3/U/YXbxOTY5cmiy1/7NvSqqXSK/WZ= 883 q05lN99RDUQhdNxXI64ePAbFWQ6RGoiCrRs+Dc95oQh7EFEPoT9P6jyzcV1NzZVwfp+u 885 --Encrypted Boundary 886 Content-Type: application/octet-stream 887 Content-Transfer-Encoding: base64 889 AfR1WSeyLhy5AtcX0ktUVlbFC1vvcoCjYWy/yYjVj48eqzUVvGTGMsV6MdlynUd4jcJgRnQIQvIx 890 m2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F3K3n4wonUUP265UvvMj23RSTguZ/nl/Oxn 891 FM6SzDgV39V/i/RofqI= 893 --Encrypted Boundary-- 895 If, instead, we choose to sign the text before we encrypt it, the 896 structure would be as follows (where lines with an asterick '*' are 897 digitally signed and lines with an ampersand '&' are encrypted): 899 Content-Type: multipart/encrypted; boundary="Encrypted Boundary" 901 --Encrypted Boundary 902 Content-Type: application/pem-keys 904 KEY INFORMATION 906 --Encrypted Boundary 907 Content-Type: application/octet-stream 909 & Content-Type: multipart/signed; boundary="Signed Boundary" 910 & 911 & --Signed Boundary 912 & * Content-Type: text/plain 913 & * 914 & * How do you like the new MIME/PEM? 915 & * 916 & * Jim 917 & 918 & --Signed Boundary 919 & Content-Type: application/pem-signature 920 & 921 & SIGNATURE INFORMATION 922 & 923 & --Signed Boundary-- 925 --Encrypted Boundary-- 927 where KEY INFORMATION and SIGNATURE INFORMATION are descriptive of the 928 actual content that would appear in a real body part. The actual 929 message would be like this: 931 To: Jim Galvin 932 Subject: an encrypted message 933 MIME-Version: 1.0 934 Content-Type: multipart/encrypted; protocol="application/pem-keys"; 935 boundary="Encrypted Boundary" 937 --Encrypted Boundary 938 Content-Type: application/pem-keys 939 Content-ID: <21546.785188458.1@tis.com> 940 Content-Transfer-Encoding: quoted-printable 942 Version: 5 943 DEK-Info: DES-CBC,11CC89F8D90F1DFE 944 Recipient-ID: EN,2,galvin@tis.com 945 Key-Info: RSA,AZTtlEc6xm0vjkvtVUITUh7sz+nOuOwP0tsym6CQozD9IwVIJzY8+vIfbh5B= 946 pR0kS6prq3EGFBFR8gRMUvbgHtEKPD/4ICQ7b6ssZ7FmKhl/cJC5rVjpb4EOUlwOXwRZ 948 --Encrypted Boundary 949 Content-Type: application/octet-stream 950 Content-Transfer-Encoding: base64 952 ZvWvtosDzRBXJzkDFFRb9Qjrgm2nDWg3zotJ3ZpExpWUG/aRJ7Vwd+PWkSfrDPJ52V/wkxwMrum6 953 xJHZonrtyd0AvaztvriMm2zXTefzwpGG1i5zK47PBqreLA3HDTK2U6B13vzpE8wMSVefzaCTSpXR 954 SCh08ceVEZrIYS53/CKZV2/Sga71pGNlux8MsJpYLwdj5Q3NKocg1LMngMo8yrMAe+avMjfOnhui 955 49Xon1Gft+N5XDH/+wI9qxI9fkQvNZVDlWIhCYEkxd5ke549tLkJjEqHQbgJW5C+K/uxdiD2dBt+ 956 nRCXcuO0Px3yKRyYg/9BgTf36padSHuv48xBg5YaqaEWpEzLI0Qd31vAyP23rqiPhfBn6sjhQ2Kr 957 WhiF2l3TV8kQsIGHHZUkaUbqkXJe6PEdWWhwsqCFPDdkpjzQRrTuJH6xleNUFg+CG1V+tL4IgMjQ 958 qm3KVojRXx8bG2auVN89NfwFswmoq4fXTrh3xyVS1VgxjKkcYI8SVVmkYjCxVviJP3zO2UzBvCoM 959 fADtBVBz1njYETtVGDO97uT39MqL85uEgiF4E5TkOj/m04+88G0/vvN/RISKJiFQJ3FyVIB/ShX9 960 Dixl8WCx3rxwN5g2QFLiyQVulzuNhimSD4ZxEo7smcTsAXUjwSLRtdjmTTutw2GmFESUaIrY81Nc 961 pQJRPNAvF0IkN6ddwL4qvzUS99vjQp15g9FUv82lHtHwhM18a9GokVG8xYOjBBsn9anp9abh4Tp/ 962 c/vpbunQUqnpV29rF4wj+8OwUOMi9ymGabBXAjw7DhNH2RdRVr1upQO896OX81VWB0LsA0cp+ymx 963 hTrEI+wCHcrsNMoRK/7zAeuAi0f1t9bN594EFlLoIrBnKEa1/OUAhMT7kG1fNkSRnc8BZswIoPyR 964 etsTurQfD40nsVHvNwE9Jz7wbBo00gd6blPADOUYFxfW5zu6ubygBqJiKPM4II2fCdNj7CptfQco 965 RTeguKMVPLVmFg/EINuWBFm10GqlYT7p4zhfzysV/3r5LVZ1E8armTCRJ2GoYG5h+SKcytaQ0IT8 966 S2nLPCZl1hzdajsrqHFe8omQ 968 --Encrypted Boundary-- 970 In addition to text, the PEM services as defined here will protect 971 arbitrary body parts, for example, the following audio body part: 973 Content-Type: audio/basic 975 AUDIO DATA HERE 977 when signed would appear as follows: 979 Content-Type: multipart/signed; protocol="application/pem-signature"; 980 micalg="rsa-md5"; boundary="Signed Boundary" 982 --Signed Boundary 983 Content-Type: audio/basic 984 Content-Transfer-Encoding: base64 986 base64(AUDIO DATA HERE) 988 --Signed Boundary 989 Content-Type: application/pem-signature 991 SIGNATURE INFORMATION HERE 993 and when encrypted would appear as follows: 995 Content-Type: multipart/encrypted; protocol="application/pem-keys"; 996 boundary="Encrypted Boundary" 998 --Encrypted Boundary 999 Content-Type: application/pem-keys 1001 KEY INFORMATION HERE 1003 --Encrypted Boundary 1004 Content-Type: application/octet-stream 1005 Content-Transfer-Encoding: base64 1007 base64(encrypted(AUDIO DATA HERE)) 1009 --Encrypted Boundary-- 1011 7. Observations 1013 The use of the pre-submission and post-delivery processing steps to 1014 combine PEM and MIME capabilities exhibits several properties: 1016 (1) It allows privacy-enhancement of an arbitrary content, not just the 1017 body of an RFC822 message. 1019 (2) For a multipart or message content, it allows the user to specify 1020 different privacy enhancements to be applied to different 1021 components of the structure of the content. 1023 (3) It provides for messages containing several privacy enhanced 1024 contents, thereby removing the requirement for PEM software to be 1025 able to generate or interpret a single content which intermixes 1026 both unenhanced and enhanced components. 1028 The use of a MIME-capable user agent makes complex nesting of enhanced 1029 message body parts much easier. For example, the user can separately 1030 sign and encrypt a message. This motivates a complete separation of the 1031 confidentiality security service from the digital signature security 1032 service. That is, different key pairs could be used for the different 1033 services and could be protected separately. 1035 This is useful for at least two reasons. First, some public key 1036 algorithms do not support both digital signatures and encryption, for 1037 example, the way that the RSA algorithm does; two key pairs would be 1038 required in this case. Second, an employee's company could be given 1039 access to the (private) decryption key but not the (private) signature 1040 key, thereby granting the company the ability to decrypt messages 1041 addressed to the employee in emergencies without also granting the 1042 company the ability to sign messages as the employee. 1044 8. Summary of Changes to PEM Specification 1046 This document updates the message encryption and signature procedures 1047 defined by [3] and replaces the key certification and related services 1048 defined by [6]. The changes are enumerated below. 1050 (1) The PEM specification currently requires that encryption services 1051 be applied only to message bodies that have been signed. By 1052 providing for each of the services separately, they may be applied 1053 recursively in any order according to the needs of the requesting 1054 application. 1056 (2) PEM implementations are currently restricted to processing only 1057 text-based electronic mail messages. In fact, the message text is 1058 required to be represented by the ASCII character set with 1059 "" line delimiters. This restriction no longer applies. 1061 (3) MIME includes transfer encoding operations to ensure the unmodified 1062 transfer of body parts, which obviates these services in PEM. 1064 (4) PEM specifies a Proc-Type: header field to identify the type of 1065 processing that was performed on the message. This functionality 1066 is subsumed by the MIME Content-Type: headers. The Proc-Type: 1067 header also included a decimal number that was used to distinguish 1068 among incompatible encapsulated header field interpretations which 1069 may arise as changes are made to the PEM standard. This 1070 functionality is replaced by the Version: header specified in this 1071 document. 1073 (5) PEM specifies a Content-Domain: header, the purpose of which is to 1074 describe the type of the content which is represented within a PEM 1075 message's encapsulated text. This functionality is subsumed by the 1076 MIME Content-Type: headers. 1078 (6) The PEM specifications include a document that defines new types of 1079 PEM messages, specified by unique values used in the Proc-Type: 1080 header, to be used to request certificate and certificate 1081 revocation list information. This functionality is subsumed by two 1082 new content types specified in this document. 1084 (7) The header fields having to do with certificates (Originator- 1085 Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated 1086 for use only in the application/pemkey-data and 1087 application/pemkey-request content types and are no longer allowed 1088 in the header portion of a PEM signed or encrypted message. 1090 (8) The grammar specified here explicitly separates the header fields 1091 that may appear for the encryption and signature security services. 1092 It is the intent of this document to specify a precise expression 1093 of the allowed header fields; there is no intent to disallow the 1094 functionality of combinations of encryption and signature security 1095 found in [3]. 1097 (9) With the separation of the encryption and signature security 1098 services, there is no need for a MIC-Info: field in the headers 1099 associated with an encrypted message. 1101 (10) In [3], when asymmetric key management is used, an Originator-ID 1102 field is required in order to identify the private key used to sign 1103 the MIC argument in the MIC-Info: field. Because no MIC-Info: 1104 field is associated with the encryption security service under 1105 asymmetric key managment, there is no requirement in that case to 1106 include an Originator-ID field. 1108 These changes represent a departure in mechanism, not in effect, from 1109 those specified in [3] and [6]. The following technical changes to [3] 1110 and [4] are also specified by this document. 1112 (1) The grammar specified here explicitly excludes symmetric key 1113 management. Currently, there are no generally available 1114 implementations of symmetric key management nor are there any known 1115 plans for implementing it. As a result, the IETF standards process 1116 will require this feature to be dropped when the documents are 1117 promoted to draft standard status from proposed standard status. 1119 (2) This document requires all data that is to be digitally signed to 1120 be represented in 7bit form. 1122 (3) This document broadens the allowable name forms that users may use 1123 to identify their public keys. Users may use arbitrary strings and 1124 email addresses as their name. Further, users may distribute their 1125 public key directly in lieu of using certificates. In support of 1126 this change the Originator-ID-ASymmetric: and Recipient-ID- 1127 ASymmetric: fields are deprecated in favor of Originator-ID: and 1128 Recipient-ID: fields, respectively. 1130 9. Collected Grammar 1132 The version of the grammar in this document is as follows: 1134 ::= "Version:" "5" CRLF 1136 The content of an application/pem-signature body part is as follows: 1138 ::= ( 1* ) 1140 ::= 1142 ::= "Originator-ID:" CRLF 1144 The content of an application/pem-keys body part is as follows: 1146 ::= 1* 1148 ::= 1150 ::= "Recipient-ID:" CRLF 1152 ::= "Key-Info" ":" "," CRLF 1154 Identifiers are defined as follows: 1156 ::= / / 1158 ::= / / 1160 ::= "EN" "," "," CRLF 1162 ::= "STR" "," "," CRLF 1164 ::= "DN" "," "," CRLF 1166 ::= "PK" "," [ "," ] CRLF 1168 ::= "IS" "," "," CRLF 1170 ::= 1171 ; a printably encoded non-null sequence of octets 1173 ::= / 1174 ; an electronic mail address as defined by 1175 ; these two tokens from RFC822 1177 ::= ; a non-null sequence of characters 1179 ::= 1180 ; a printably encoded, ASN.1 encoded 1181 ; distinguished name 1183 ::= 1184 ; a printably encoded, ASN.1 encoded 1185 ; subjectPublicKeyInfo 1187 ::= 1* 1188 ; hex dump of the serial number of a certificate 1190 The content of an application/pemkey-request body part is as follows: 1192 ::= 1193 ( / / ) 1195 ::= "Subject:" CRLF 1197 ::= "Issuer:" CRLF 1199 ::= "Certification:" CRLF 1201 The content of an application/pemkey-data body part is as follows: 1203 ::= 1204 ( / / ) 1206 ::= "Key:" "PK" "," "," CRLF 1208 ::= *( [ ] ) 1210 ::= 1*( [ ] ) 1212 ::= "Certificate:" CRLF 1214 ::= "CRL:" CRLF 1216 10. Security Considerations 1218 This entire document is about security. 1220 11. Acknowledgements 1222 David H. Crocker suggested the use of a multipart structure for MIME-PEM 1223 interaction. 1225 12. References 1227 [1] David H. Crocker. Standard for the Format of ARPA Internet Text 1228 Messages. RFC 822, University of Delaware, August 1982. 1230 [2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet 1231 Mail Extension) Part One: Mechanisms for Specifying and Describing 1232 the Format of Internet Message Bodies. RFC 1521, Bellcore and 1233 Innosoft, September 1993. Obsoletes RFC 1341. 1235 [3] John Linn. Privacy Enhancement for Internet Electronic Mail: Part 1236 I: Message Encryption and Authentication Procedures. RFC 1421, 1237 February 1993. Obsoletes RFC 1113. 1239 [4] Steve Kent. Privacy Enhancement for Internet Electronic Mail: Part 1240 II: Certificate-Based Key Management. RFC 1422, BBN 1241 Communications, February 1993. 1243 [5] David M. Balenson. Privacy Enhancement for Internet Electronic 1244 Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423, 1245 Trusted Information Systems, February 1993. 1247 [6] Burton S. Kaliski. Privacy Enhancement for Internet Electronic 1248 Mail: Part IV: Key Certification and Related Services. RFC 1424, 1249 RSA Laboratories, February 1993. 1251 [7] James Galvin, Sandy Murphy, Steve Crocker, and Ned Freed. Security 1252 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. 1253 RFC XXXX, Trusted Information Systems and Innosoft, XXXX 1994. 1255 13. Authors' Addresses 1257 Steve Crocker 1258 email: crocker@tis.com 1260 James M. Galvin 1261 email: galvin@tis.com 1263 Sandra Murphy 1264 email: murphy@tis.com 1266 Trusted Information Systems 1267 3060 Washington Road 1268 Glenwood, MD 21738 1269 Tel: +1 301 854 6889 1270 FAX: +1 301 854 5363 1271 Ned Freed 1272 Innosoft International, Inc. 1273 1050 East Garvey Avenue South 1274 West Covina, CA 91790 1275 Tel: +1 818 919 3600 1276 FAX: +1 818 919 3614 1277 email: ned@innosoft.com 1279 14. Appendix: Imported Grammar 1281 The following productions are taken from [3]. The grammar presented in 1282 [3] remains the authoritative source for these productions; they are 1283 repeated here for the convenience of the reader. 1285 ::= "DEK-Info" ":" [ "," ] CRLF 1287 ::= "MIC-Info" ":" "," "," 1288 CRLF 1290 ::= 1* 1291 ::= 4*4 1292 ::= ALPHA / DIGIT / "+" / "/" / "=" 1294 The following productions are taken from [5]. The grammar presented in 1295 [5] remains the authoritative source for these productions; they are 1296 repeated here for the convenience of the reader. 1298 ::= "DES-CBC" 1299 ::= "DES-EDE" / "DES-ECB" / "RSA" 1300 ::= "RSA-MD2" / "RSA-MD5" 1302 ::= 1303 ::= 1304 ::= 1306 ::= 1307 ::= 1309 ::= 1310 ::= 1312 ::= 16*16 1313 ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 1314 ; no lower case 1316 The following productions are taken from [1]. The grammar presented in 1317 [1] remains the authorative source for these productions; they are 1318 repeated here for the convenience of the reader. 1320 ::= "@" ; global address 1322 ::= *( "." ) ; uninterpreted 1323 ; case-preserved 1325 ::= *( "." ) 1327 ::= / 1329 ::= ; symbolic reference 1331 ::= "<" [ ] ">" 1333 ::= 1# ( "@" ) ":" ; path-relative 1335 ::= / 1337 ::= """ *( / ) """ 1339 ::= (any excepting """, " 1340 and including ) 1342 ::= " 1344 ::= 1*( [ CRLF ] ) ; semantics = SPACE 1345 ; CRLF => folding 1346 ::= SPACE / HTAB ; semantics = SPACE 1348 ::= 1*(any except , SPACE and s) 1350 ::= 1352 ::= 1354 ::= "(" / ")" / "<" / ">" / "@" ; Must be in quoted- 1355 / "," / ";" / ":" / " 1356 / "." / "[" / "]" ; within a word. 1358 Table of Contents 1360 Status of this Memo ............................................. 1 1361 Abstract ........................................................ 1 1362 1 Introduction ................................................... 2 1363 2 Name Forms and Identifiers ..................................... 4 1364 2.1 Name Forms ................................................... 4 1365 2.1.1 Email Addresses ............................................ 5 1366 2.1.2 Arbitrary Strings .......................................... 5 1367 2.1.3 Distinguished Names ........................................ 5 1368 2.2 Identifiers .................................................. 6 1369 2.2.1 Email Address .............................................. 7 1370 2.2.2 Arbitrary String ........................................... 7 1371 2.2.3 Distinguished Name ......................................... 7 1372 2.2.4 Public Key ................................................. 7 1373 2.2.5 Issuer Name and Serial Number .............................. 8 1374 3 Applying PEM Security Services to MIME Body Parts .............. 8 1375 3.1 PEM Processing Steps ......................................... 9 1376 3.2 Use of multipart/signed Content Type ......................... 11 1377 3.3 Use of multipart/encrypted Content Type ...................... 12 1378 3.4 application/pem-signature Content Type Definition ............ 12 1379 3.5 application/pem-keys Content Type Definition ................. 13 1380 4 Removing PEM Security Services from PEM Body Parts ............. 14 1381 5 Key Management Content Types ................................... 15 1382 5.1 application/pemkey-request Content Type Definition ........... 15 1383 5.2 application/pemkey-data Content Type Definition .............. 17 1384 6 Examples ....................................................... 19 1385 7 Observations ................................................... 24 1386 8 Summary of Changes to PEM Specification ........................ 25 1387 9 Collected Grammar .............................................. 27 1388 10 Security Considerations ....................................... 29 1389 11 Acknowledgements .............................................. 29 1390 12 References .................................................... 29 1391 13 Authors' Addresses ............................................ 30 1392 14 Appendix: Imported Grammar .................................... 32