idnits 2.17.1 draft-ietf-pem-mime-06.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-04-26) 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 27 instances of too long lines in the document, the longest one being 11 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 (July 1994) is 10878 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: 17 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-06.txt Jim Galvin 4 Sandy Murphy 5 July 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 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 3. Introduction 57 This document updates the message encryption and signature procedures 58 defined by [3] and obsoletes 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 10. 68 In addition, this document specifies three technical changes to PEM: 69 symmetric key management in [3] is deprecated, the canonicalization 70 operation in [3] is generalized, and 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 document [6] is obsoleted by 76 the specification of two new MIME content types: application/key-request 77 and 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 10. 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., a process or a role) which has a 97 name. There are 3 name forms specified by this document. For backward 98 compatibility (and forward compatibility if the X.500 Directory becomes 99 a ubiquitous service) one of the name forms is a distinguished name. In 100 addition, email addresses and arbitrary strings are allowed. 102 Since a user may have more than one key pair, a name form is 103 insufficient for uniquely identifying a key pair. The owner of a key 104 pair must assign a key identifier to each key pair. The combination of 105 a name form and a key identifier uniquely identifies a key pair and each 106 key pair is uniquely identified by a name form and key identifier 107 combination. Throughout this document, this combination is called an 108 identifier. There are 6 identifiers specified by this document. 110 With a key pair for one's self and software that is both MIME and PEM 111 aware, an originating user may digitally sign arbitrary data and send it 112 to one or more recipients. With the public keys of the recipients, a 113 user may encrypt the data so that only the intended recipients can 114 decrypt and read the it. This specification separates these two 115 services so that an originator may apply either or both, in either 116 order. 118 The name forms and identifiers are described in detail in the next 119 section. Succeeding sections specify how PEM and MIME are used together 120 and other ancillary details. 122 4. Name Forms and Identifiers 124 Currently, [3] requires the use of certificates to identify the public 125 key (and corresponding private key) used to create a PEM message. 126 Within certificates, [4] requires the use of distinguished names as 127 specified by the X.500 Series of Recommendations. However, the Internet 128 community has a great deal more experience with the use of electronic 129 mail addresses as a name form and there is a desire to be able to use 130 arbitrary strings to identify the owners of public keys. Hence, there 131 is a need to support name forms which do not conform to the expected 132 usage of distinguished names. 134 When processing PEM messages it is necessary to be able to uniquely 135 identify the key pair used to create the message. A certificate is 136 uniquely identified by the combination of its issuer's distinguished 137 name and its serial number. Thus, the issuer name and serial number 138 uniquely identifies a key pair. Since a user may have more than one key 139 pair, a name form is insufficient for this purpose. An identifier is 140 required that consists of both a name form and key identifier, a value 141 assigned to a key pair by its owner. 143 In addition, users may distribute their public keys via mechanisms 144 outside the scope of the PEM specification, for example, in a file via 145 FTP. As a result, it is desirable to be able to explicitly specify the 146 public key used rather than an identifier of the public key. A 147 significant benefit of this mechanism is the ability to support 148 encrypted, anonymously signed mail. 150 The objective of the various Originator and Recipient fields specified 151 in [3] is to identify which public key has been used or is required. 152 This document simplifies the set of fields by specifying exactly two: 153 Originator-ID: for originators and Recipient-ID: for recipients. This 154 specification defines six (6) identifiers with which the public key used 155 may be indicated in each of these fields. 157 In the next section the 3 name forms are described in detail. Following 158 that is the specification of the 6 identifiers. 160 4.1. Name Forms 162 There are 3 name forms specified by this document: email address, 163 distinguished names, and arbitrary strings. 165 4.1.1. Email Addresses 167 The email address (grammar token ) used must be a valid RFC822 168 address, which is defined in terms of the two grammar tokens 169 and . The grammar for these two tokens is included in the 170 Appendix as a convenience; the definitive source for these tokens is 171 necessarily RFC822 [1]. 173 ::= / 174 ; an electronic mail address as defined by 175 ; these two tokens from RFC822 177 For example, the string "galvin@tis.com" is an email address. 179 4.1.2. Arbitrary Strings 181 The arbitrary string (grammar token ) must chosen from the us- 182 ascii character set and must have a length of at least 1. It is 183 possible to encode the actual string in such a way that only characters 184 from the us-ascii character set are generated, but there is no mechanism 185 for conveying to a recipient the encoding that was used. 187 ::= ; a non-null sequence of us-ascii characters 189 For example, the string 191 Jim "the SAAG mailing list maintainer" Galvin 193 is an arbitrary string. 195 4.1.3. Distinguished Names 197 The distinguished name (grammar token ) must be constructed 198 according to the guidelines of the X.500 Directory. For the purposes of 199 conveying a distinguished name from an originator to a recipient, it 200 must be ASN.1 encoded and then printably encoded according to the base64 201 encoding defined by MIME. 203 ::= 204 ; a printably encoded, ASN.1 encoded 205 ; distinguished name 207 ** EXAMPLE DISTINGUISHED NAME ** 209 4.2. Identifiers 211 There are 6 identifiers specified by this document: email address, 212 arbitrary string, distinguished name, PGP key identifier, the public key 213 itself, and the issuer name and serial number pair from a certificate. 214 All of these have approximately the same structure as follows: 216 TYPE, KEYID, STRING 218 The TYPE field is a literal string, one for each of the possible 219 identifiers. 221 The KEYID field is used to distinguish between the multiple public keys 222 that may be associated with the name form in the STRING field. In 3 of 223 the identifiers its value is arbitrary, chosen by the owner of the key 224 pair, except that it must be distinct from all the other KEYIDs used by 225 the owner. Suggested values include a portion (low-order 16 or 32 bits) 226 or all of the actual public key used. In the other 3 identifiers the 227 value is still chosen by the owner of the public key and it must still 228 be unique, but its value is chosen from a more restricted alphabet. 230 The STRING field is the name form and has a different syntax according 231 to the value of the TYPE field. 233 The identifier used in each of the originator and recipient fields is 234 described by the following grammar. The definition of the key 235 identifier token is included here since it used by several of the 236 identifiers below. 238 ::= / / 240 ::= / / / 242 ::= 243 ; a printably encoded non-null sequence of octets 245 Each of the identifier name forms is described below. 247 4.2.1. Email Address 249 The email address identifier has the following syntax. 251 ::= "EN" "," "," CRLF 253 4.2.2. Arbitrary String 255 The arbitrary string identifier has the following syntax. 257 ::= "STR" "," "," CRLF 259 4.2.3. Distinguished Name 261 The distinguished name identifier has the following syntax. 263 ::= "DN" "," "," CRLF 265 The actual form and syntax of the distinguished name is outside the 266 scope of this specification. RFC1422 specifies one possible form based 267 on a particular choice of a certification hierarchy for certificates. 269 4.2.4. PGP Public Key 271 The PGP public key identifier has the following syntax. 273 ::= "PGP2" ",0x" "," CRLF 275 ::= ; a sequence from the following alphabet: {0-9, A-F} 276 ; which is either exactly six or eight characters long 278 4.2.5. Public Key 280 The public key identifier has the following syntax. This identifer, as 281 compared to the others, has the unique property that the STRING element 282 is optional and, when included, is not a string but rather one of four 283 of the other identifiers. 285 ::= "PK" "," [ "," ] CRLF 287 ::= 288 ; a printably encoded, ASN.1 encoded 289 ; subjectPublicKeyInfo 291 In normal usage, the STRING element is expected to be absent. When 292 present, it represents a mechanism by which an identifier (name form and 293 key identifier) can be associated with a public key. Recipients of a 294 public key identifier must take care to verify the accuracy of the 295 purported association. If not, it may be possible for a malicious 296 originator to assert an identifier that accords the originator 297 unauthorized privileges. See Section 7.2 for more details. 299 The object subjectPublicKeyInfo is imported from the X.500 Directory 300 from the certificate object. It is currently the best choice for a 301 general purpose public key encoding. 303 4.2.6. Issuer Name and Serial Number 305 The issuer name and serial number identifier has the following syntax. 307 ::= "IS" "," "," CRLF 309 ::= 1* 310 ; hex dump of the serial number of a certificate 312 The identifier is included for backward compatibility with 313 the ID-ASymmetric fields defined in [3]. The older fields are easily 314 converted to this new form by prefixing the old value with "IS," and 315 replacing the field name with an appropriate new ID field. 317 5. Applying PEM Security Services to MIME Body Parts 319 The next section describes the processing steps necessary to prepare a 320 MIME body part for the application of PEM security services. The 321 succeeding two sections describe the content of the multipart/signed and 322 multipart/encrypted body parts resulting from the application of PEM 323 security services to MIME body parts. 325 5.1. PEM Processing Steps 327 The definition of the multipart/signed and multipart/encrypted body 328 parts in [7] specifies three steps for creating both body parts. 330 (1) The body part is to be protected is created according to a local 331 convention. 333 (2) The body part is prepared for protection according to the protocol 334 parameter. 336 (3) The prepared body part is protected according to the protocol 337 parameter. 339 This specification makes no changes to step one in the sequence. For 340 step two, there is no preparation necessary for the encryption service. 341 For the digital signature service, the body part must be canonicalized 342 as described below. This specification makes no changes to step three 343 in the sequence. 345 Prior to the application of the digital signature service, the body part 346 must be in a canonical form. Transforming the body part to be signed 347 into a canonical form is a necessary and essential step in the digital 348 signature process. The canonical form must satisfy the property that it 349 is uniquely and unambiguously representable in both the originator and 350 recipient's local environment. This is required in order to ensure that 351 both the originator and recipient have the same data with which to 352 calculate the digital signature; the originator needs to be able to 353 include the digital signature value when transferring the body part, 354 while the recipient needs to be able to compare a re-computed value with 355 the received value. Further, the canonical form should satisfy the 356 property that it is representable on as many different host computers as 357 possible. By satisfying this property, signed data may be forwarded by 358 recipients to additional recipients, who will also be able to verify the 359 original signature. This service is called forwardable authentication. 361 The canonicalization transformation is a two step process. First, the 362 body part must be converted to canonical representation suitable for 363 transport between originators and recipients. Second, the body part 364 must have its line delimiters canonicalized prior to computing the 365 digital signature and prior to each verification of the digital 366 signature. 368 The canonical representation of all body parts is specified to be 7bit, 369 as defined by [2]. Since the headers of body parts are already required 370 to be representable in 7bit, this step requires that if the data to be 371 signed is not already 7bit it must be encoded with an appropriate MIME 372 content transfer encoding. Note, since the MIME standard explicitly 373 disallows nested content transfer encodings, i.e., the content types 374 multipart and message may not themselves be encoded, body parts enclosed 375 within, for example, a multipart content type, must be encoded in a 7bit 376 representation. Any valid MIME encoding may be selected. 378 The 7bit representation of the data must be transferred to the 379 recipient. As may be required by MIME, an appropriate Content- 380 Transfer-Encoding: header is included with the data. Upon receipt, a 381 MIME implementation would verify the signature of the data prior to 382 decoding the data and displaying it to the recipient. 384 Representing all complex content types as 7bit transforms them into 385 text-based content types. However, text-based content types present a 386 unique problem. In particular, the line delimiter used on a text-based 387 content type is specific to a local environment; different environments 388 use the single character carriage-return (), the single character 389 line-feed (), or the two character sequence "carriage-return line- 390 feed ()." 392 The application of the digital signature service requires that the same 393 line delimiter be used by both the originator and the recipient. This 394 document specifies that the two character sequence "" must be 395 used as the line delimiter. Thus, the canonicalization transformation 396 includes the transformation of the local line delimiter to the two 397 character sequence "". 399 The transformation to the canonical line delimiter is only required for 400 the purposes of computing the digital signature. Thus, originators must 401 apply the canonical line delimiter transformation before computing the 402 digital signature but must transfer the data without the canonical line 403 delimiter transformation. Similarly, recipients must apply the 404 canonical line delimiter transformation before computing the digital 405 signature. 407 NOTE: An originator can not transfer the content with the 408 canonical line delimiter transformation intact because the 409 transformation process is not idempotent. In particular, SMTP 410 servers may themselves convert the canonical line delimiter to a 411 local line delimiter, prior to the message being delivered to 412 the user. Thus, a recipient has no way of knowing if the 413 transformation is present or not. Thus, if the recipient 414 applies the transformation to a content in which it is already 415 present, the resulting content may have two line delimiters 416 present, which would cause the verification of the signature to 417 fail. 419 IMPLEMENTORS NOTE: Implementors should be aware that the 420 transformation to a canonical representation is a function that 421 is available even in a minimally compliant MIME user agent. 422 Further, the canonical line delimiter transformation required 423 here is distinct from the same transformation included in that 424 function. Specifically, the line delimiter transformation in 425 the former case is performed prior to the application of the 426 canonical representation while it is performed after the 427 application of the canonical representation in the latter case. 429 5.2. Use of multipart/signed Content Type 431 When this content type is used, the value of the required parameter 432 "protocol" is "pem" and the value of the required parameter "hashalg" is 433 one of the valid choices from [5], for example: 435 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; 436 boundary="Signed Message" 438 --Signed Message 439 Content-Type: text/plain 441 This is some example text. 443 --Signed Message 444 Content-Type: application/signature 446 447 --Signed Message-- 449 where the token is defined as follows. 451 ::= ( 1* ) 453 ::= "Version:" "5" CRLF 455 ::= 457 ::= "Originator-ID:" CRLF 459 The token is defined in Section 4.2. 461 The only valid value for a Content-Transfer-Encoding: header, if 462 included, is "7bit". 464 5.3. Use of multipart/encrypted Content Type 466 When this content type is used, the value of the required parameter 467 "protocol" is "pem", for example: 469 Content-Type: multipart/encrypted; protocol="pem"; 470 boundary="Encrypted Message" 472 --Encrypted Message 473 Content-Type: application/keys 475 477 --Encrypted Message 478 Content-Type: application/octet-stream 480 481 --Encrypted Message-- 483 where the token is defined as follows. 485 ::= 1* 487 ::= "Version:" "5" CRLF 489 ::= 491 ::= "Recipient-ID:" CRLF 493 ::= "Key-Info" ":" "," CRLF 495 The token is defined in Section 4.2. 497 6. Removing PEM Security Services from PEM Body Parts 499 This section describes the processing steps necessary to verify or 500 decrypt the PEM security services that have been applied to MIME body 501 parts. Outer layers of PEM security services must be processed prior to 502 processing inner layers of PEM security services. Processing includes a 503 user choosing to display a content without removing the PEM security 504 services. 506 The definition of the multipart/signed and multipart/encrypted body 507 parts in [7] specifies three steps for receiving both body parts. 509 (1) The protected body part and the control information body part are 510 prepared for processing. 512 (2) The prepared body parts are made available to the protection 513 removal process. 515 (3) The results of the protection removal process are made available to 516 the user and processing continues with the unprotected body part, 517 as returned by the protection removal process. 519 For step one, the preparation for digitally signed and encrypted body 520 parts is different, as described below. No changes are required to 521 steps two and three in the sequence. 523 For multipart/signed body parts, the control information is prepared by 524 removing any content transfer encodings that may be present. The 525 digitally signed body part is prepared by leaving the content transfer 526 encodings intact and canonicalizing the line delimiters according to 527 Step 2 of Section 5.1. 529 Multipart/encrypted body parts are prepared by removing the content 530 transfer encodings, if present, from both the control information and 531 the encrypted body part. 533 7. Definition of New Content Types 535 This document defines two new content types, the contents of which 536 comprise a replacement mechanism for [6]. The first content type is 537 application/key-request, which replaces the certification and CRL- 538 retrieval request messages. The second content type is 539 application/key-data, which replaces the certification reply message, 540 the crl-storage request message, and the crl-retrieval reply message. 541 There were no requirements for a crl-storage reply message and none are 542 specified in this document. This document includes a specification for 543 a public key and certificate request message, which were previously 544 undefined. 546 NOTE: RFC1424 has some descriptive text, especially for 547 certification messages, that should probably be included. 549 7.1. application/key-request Content Type Definition 551 (1) MIME type name: application 553 (2) MIME subtype name: key-request 554 (3) Required parameters: none 556 (4) Optional parameters: none 558 (5) Encoding considerations: quoted-printable is always sufficient 560 (6) Security Considerations: none 562 The content of this body part corresponds to the following production. 564 ::= 565 ( / / ) 566 ::= "Version:" "5" CRLF 567 ::= "Subject:" CRLF 568 ::= "Issuer:" CRLF 569 ::= "Certification:" CRLF 571 This content type is used to provide for some of the requests described 572 in [6]. The information in the body part is entirely independent of any 573 other body part. As such, the application/key-request content type is 574 an independent body part. 576 The certification request, certificate-retrieval request and crl- 577 retrieval request are provided for directly. If the content contains a 578 Certification: field it requests certification of the self-signed 579 certificate in the field value. If the content contains an Issuer: 580 field it requests the certificate revocation list chain beginning with 581 the issuer identified in the field value. If the content contains a 582 Subject: field it requests either the public key of the subject or the 583 certificate chain beginning with the subject identified in the field 584 value, or both. 586 The Subject: and Issuer: fields each contain a value of type , which 587 is defined in Section 4.2. 589 The crl-storage request is provided for by the application/key-data 590 content type described in the next section. 592 In each case, the response is transmitted in an application/key-data 593 content type. When returning public keys, certificate chains, and 594 certificate revocation list chains, if there exists more than one, 595 several application/key-data contents are to be returned in the reply 596 message, one for each. 598 7.2. application/key-data Content Type Definition 600 The principal objective of this content type is to convey cryptographic 601 keying material from an originator to a recipient. However, no explicit 602 provision is made for determining the authenticity or accuracy of the 603 data being conveyed. In particular, when a public key and the 604 identifier for its owner is conveyed, there is nothing to prevent an 605 originator or any interloper along the path from an originator to a 606 recipient from substituting alternate values for either the public key 607 or the identifier, thus setting up the recipient to potentially send 608 sensitive information that may be intercepted and disclosed 609 inappropriately. 611 It is incumbent upon a recipient to verify the authenticity and accuracy 612 of the data received prior to its use. The problem is addressed by the 613 use of certificates, since a certification hierarchy is a well-defined 614 mechanism that conveniently supports the automatic verification of the 615 data. Alternatively, the application/key-data body part could be 616 digitally signed by the originator. In this way, if a recipient 617 believes that correct originator's public key is available locally and 618 if the recipient believes the originator would convey accurate data, 619 then the key data received from the originator can be believed. 621 NOTE: Insofar as a certificate represents a mechanism by which 622 an issuer vouches for the binding between the name and public 623 key it embodies, the signing of an application/key-data body 624 part is a similar mechanism. 626 (1) MIME type name: application 628 (2) MIME subtype name: key-data 630 (3) Required parameters: none 632 (4) Optional parameters: none 634 (5) Encoding considerations: quoted-printable is always sufficient. 636 (6) Security Considerations: none 638 The content of this body part corresponds to the following production. 640 ::= 641 ( / / ) 642 ::= "Version:" "5" CRLF 643 ::= "Key:" "," CRLF 644 ::= *( [ ] ) 645 ::= 1*( [ ] ) 646 ::= "Certificate:" CRLF 647 ::= "CRL:" CRLF 649 This content type is used to transfer public keys, certificate chains, 650 or Certificate Revocation List (CRL) chains. The information in the 651 body part is entirely independent of any other body part. (Note that 652 the converse is not true: the validity of a protected body part cannot 653 be determined without the proper public keys, certificates, or current 654 CRL information.) As such, the application/key-data content type is an 655 independent body part. 657 The production contains exactly one public key. It is used to 658 bind a public key with its corresponding name form and key identifier. 659 It is recommended that when responders are returning this information 660 that the enclosing body part be digitally signed by the responder in 661 order to protect the information. 663 The production contains one certificate chain. A 664 certificate chain starts with a certificate and continues with the 665 certificates of subsequent issuers. Each issuer certificate included 666 must have issued the preceding certificate. For each issuer, a CRL may 667 be supplied. A CRL in the chain belongs to the immediately following 668 issuer. Therefore, it potentially contains the immediately preceding 669 certificate. 671 The production contains one certificate revocation list 672 chain. The CRLs in the chain begin with the requested CRL and continue 673 with the CRLs of subsequent issuers. The issuer of each CRL is presumed 674 to have issued a certificate for the issuer of the preceding CRL. For 675 each CRL, the issuer's certificate may be supplied. A certificate in 676 the chain must belong to the issuer of the immediately preceding CRL. 678 The relationship between a certificate and an immediately preceding CRL 679 is the same in both and . In a the 680 CRLs are optional. In a the certificates are optional. 682 8. Examples 684 NOTE: To be included upon completion of implementation. 686 9. Observations 688 The use of the pre-submission and post-delivery algorithms to combine 689 PEM and MIME capabilities exhibits several properties: 691 (1) It allows privacy-enhancement of an arbitrary content, not just the 692 body of an RFC822 message. 694 (2) For a multipart or message content, it allows the user to specify 695 different privacy enhancements to be applied to different 696 components of the structure of the content. 698 (3) It provides for messages containing several privacy enhanced 699 contents, thereby removing the requirement for PEM software to be 700 able to generate or interpret a single content which intermixes 701 both unenhanced and enhanced components. 703 The use of a MIME-capable user agent makes complex nesting of enhanced 704 message body parts much easier. For example, the user can separately 705 sign and encrypt a message. This motivates a complete separation of the 706 confidentiality security service from the digital signature security 707 service. That is, different key pairs could be used for the different 708 services and could be protected separately. This means an employee's 709 company could be given access to the (private) decryption key but not 710 the (private) signature key, thereby granting the company the ability to 711 decrypt messages addressed to the employee in emergencies without also 712 granting the company the ability to sign messages as the employee. 714 The use of two private keys requires the ability to maintain multiple 715 certificates for each user. 717 10. Summary of Changes to PEM Specification 719 This document updates the message encryption and signature procedures 720 defined by [3] and obsoletes the key certification and related services 721 defined by [6]. The changes are enumerated below. 723 (1) The PEM specification currently requires that encryption services 724 be applied only to message bodies that have been signed. By 725 providing for each of the services separately, they may be applied 726 recursively in any order according to the needs of the requesting 727 application. 729 (2) PEM implementations are currently restricted to processing only 730 text-based electronic mail messages. In fact, the message text is 731 required to be represented by the ASCII character set with 732 "" line delimiters. This restriction no longer applies. 734 (3) MIME includes transfer encoding operations to ensure the unmodified 735 transfer of body parts, which obviates these services in PEM. 737 (4) PEM specifies a Proc-Type: header field to identify the type of 738 processing that was performed on the message. This functionality 739 is subsumed by the MIME Content-Type: headers. The Proc-Type: 740 header also included a decimal number that was used to distinguish 741 among incompatible encapsulated header field interpretations which 742 may arise as changes are made to the PEM standard. This 743 functionality is replaced by the Version: header specified in this 744 document. 746 (5) PEM specifies a Content-Domain: header, the purpose of which is to 747 describe the type of the content which is represented within a PEM 748 message's encapsulated text. This functionality is subsumed by the 749 MIME Content-Type: headers. 751 (6) The PEM specifications include a document that defines new types of 752 PEM messages, specified by unique values used in the Proc-Type: 753 header, to be used to request certificate and certificate 754 revocation list information. This functionality is subsumed by two 755 new content types specified in this document. 757 (7) The header fields having to do with certificates (Originator- 758 Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated 759 for use only in the application/key-data and application/key- 760 request content types and are no longer allowed in the header 761 portion of a PEM signed or encrypted message. 763 (8) The grammar specified here explicitly separates the header fields 764 that may appear for the encryption and signature security services. 765 It is the intent of this document to specify a precise expression 766 of the allowed header fields; there is no intent to reduce the 767 functionality of combinations of encryption and signature security 768 from those of [3]. 770 (9) With the separation of the encryption and signature security 771 services, there is no need for a MIC-Info: field in the headers 772 associated with an encrypted message. 774 (10) In [3], when asymmetric key management is used, an Originator-ID 775 field is required in order to identify the private key used to sign 776 the MIC argument in the MIC-Info: field. Because no MIC-Info: 777 field is associated with the encryption security service under 778 asymmetric key managment, there is no requirement in that case to 779 include an Originator-ID field. 781 These changes represent a departure in mechanism, not in effect, from 782 those specified in [3] and [6]. The following technical changes to [3] 783 and [4] are also specified by this document. 785 (1) The grammar specified here explicitly excludes symmetric key 786 management. Currently, there are no generally available 787 implementations of symmetric key management nor are there any known 788 plans for implementing it. As a result, the IETF standards process 789 will require this feature to be dropped when the documents are 790 promoted to draft standard status from proposed standard status. 792 (2) This document requires all data that is to be digitally signed to 793 be represented in 7bit form. 795 (3) This document broadens the allowable name forms that users may use 796 to identify their public keys. Users may use arbitrary strings and 797 email addresses as their name. Further, users may distribute their 798 public key directly in lieu of using certificates. In support of 799 this change the Originator-ID-ASymmetric: and Recipient-ID- 800 ASymmetric: fields are deprecated in favor of Originator-ID: and 801 Recipient-ID: fields, respectively. 803 11. Collected Grammar 805 The following is a summary of the grammar presented in this document. 807 (1) Signature headers 808 ::= ( 1* ) 810 ::= "Version:" "5" CRLF 812 ::= 814 ::= "Originator-ID:" CRLF 816 (2) Encryption Headers 818 ::= 1* 820 ::= "Version:" "5" CRLF 822 ::= 824 ::= "Recipient-ID:" CRLF 826 ::= "Key-Info" ":" "," CRLF 828 (3) Identifier Name Forms 829 ::= / / 831 ::= / / / 833 ::= "EN" "," "," CRLF 835 ::= "STR" "," "," CRLF 837 ::= "DN" "," "," CRLF 839 ::= "PGP2" ",0x" "," CRLF 841 ::= "PK" "," [ "," ] CRLF 843 ::= "IS" "," "," CRLF 845 ::= 846 ; a printably encoded non-null sequence of octets 848 ::= / 849 ; an electronic mail address as defined by 850 ; these two tokens from RFC822 852 ::= ; a non-null sequence of us-ascii characters 854 ::= 855 ; a printably encoded, ASN.1 encoded 856 ; distinguished name 858 ::= ; a sequence from the following alphabet: {0-9, A-F} 859 ; which is either exactly six or eight characters long 861 ::= 862 ; a printably encoded, ASN.1 encoded 863 ; subjectPublicKeyInfo 865 ::= 1* 866 ; hex dump of the serial number of a certificate 868 (4) Request Headers (certificate, certification, etc.) 869 ::= 870 ( / / ) 871 ::= "Version:" "5" CRLF 872 ::= "Subject:" CRLF 873 ::= "Issuer:" CRLF 874 ::= "Certification:" CRLF 876 (5) Data Headers (certificate, certification revocation list) 878 ::= / 879 ::= *( [ ] ) 880 ::= 1*( [ ] ) 881 ::= "Certificate:" CRLF 882 ::= "CRL:" CRLF 883 ::= "Version:" "5" CRLF 885 12. Security Considerations 887 NOTE: to be done 889 13. Acknowledgements 891 David H. Crocker suggested the use of a multipart structure for MIME-PEM 892 interaction. 894 14. References 896 [1] David H. Crocker. Standard for the Format of ARPA Internet Text 897 Messages. RFC 822, University of Delaware, August 1982. 899 [2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet 900 Mail Extension) Part One: Mechanisms for Specifying and Describing 901 the Format of Internet Message Bodies. RFC 1521, Bellcore and 902 Innosoft, September 1993. Obsoletes RFC 1341. 904 [3] John Linn. Privacy Enhancement for Internet Electronic Mail: Part 905 I: Message Encryption and Authentication Procedures. RFC 1421, 906 February 1993. Obsoletes RFC 1113. 908 [4] Steve Kent. Privacy Enhancement for Internet Electronic Mail: Part 909 II: Certificate-Based Key Management. RFC 1422, BBN 910 Communications, February 1993. 912 [5] David M. Balenson. Privacy Enhancement for Internet Electronic 913 Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423, 914 Trusted Information Systems, February 1993. 916 [6] Burton S. Kaliski. Privacy Enhancement for Internet Electronic 917 Mail: Part IV: Key Certification and Related Services. RFC 1424, 918 RSA Laboratories, February 1993. 920 [7] James Galvin, Sandy Murphy, Steve Crocker, and Ned Freed. Security 921 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. 922 RFC XXXX, Trusted Information Systems and Innosoft, XXXX 1994. 924 15. Authors' Addresses 926 Steve Crocker 927 email: crocker@tis.com 929 James M. Galvin 930 email: galvin@tis.com 932 Sandra Murphy 933 email: murphy@tis.com 935 Trusted Information Systems 936 3060 Washington Road 937 Glenwood, MD 21738 938 Tel: +1 301 854 6889 939 FAX: +1 301 854 5363 941 Ned Freed 942 Innosoft International, Inc. 943 250 West First Street, Suite 240 944 Claremont, CA 91711 945 Tel: +1 909 624 7907 946 FAX: +1 909 621 5319 947 email: ned@innosoft.com 949 16. Appendix: Imported Grammar 951 The following productions are taken from [3]. The grammar presented in 952 [3] remains the authoritative source for these productions; they are 953 repeated here for the convenience of the reader. 955 ::= "DEK-Info" ":" [ "," ] CRLF 957 ::= "MIC-Info" ":" "," "," 958 CRLF 960 ::= 1* 961 ::= 4*4 962 ::= ALPHA / DIGIT / "+" / "/" / "=" 964 The following productions are taken from [5]. The grammar presented in 965 [5] remains the authoritative source for these productions; they are 966 repeated here for the convenience of the reader. 968 ::= "DES-CBC" 969 ::= "DES-EDE" / "DES-ECB" / "RSA" 970 ::= "RSA-MD2" / "RSA-MD5" 972 ::= 973 ::= 974 ::= 976 ::= 977 ::= 979 ::= 980 ::= 982 ::= 16*16 983 ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 984 ; no lower case 986 The following productions are taken from [1]. The grammar presented in 987 [1] remains the authorative source for these productions; they are 988 repeated here for the convenience of the reader. 990 ::= "@" ; global address 992 ::= *( "." ) ; uninterpreted 993 ; case-preserved 995 ::= *( "." ) 997 ::= / 999 ::= ; symbolic reference 1001 ::= "<" [ ] ">" 1003 ::= 1# ( "@" ) ":" ; path-relative 1005 ::= / 1007 ::= """ *( / ) """ 1009 ::= (any excepting """, " 1010 and including ) 1012 ::= " 1014 ::= 1*( [ CRLF ] ) ; semantics = SPACE 1015 ; CRLF => folding 1016 ::= SPACE / HTAB ; semantics = SPACE 1018 ::= 1*(any except , SPACE and s) 1020 ::= 1022 ::= 1024 ::= "(" / ")" / "<" / ">" / "@" ; Must be in quoted- 1025 / "," / ";" / ":" / " 1026 / "." / "[" / "]" ; within a word. 1028 Table of Contents 1030 1 Status of this Memo ............................................. 1 1031 2 Abstract ........................................................ 1 1032 3 Introduction .................................................... 2 1033 4 Name Forms and Identifiers ...................................... 3 1034 4.1 Name Forms .................................................... 4 1035 4.1.1 Email Addresses ............................................. 4 1036 4.1.2 Arbitrary Strings ........................................... 5 1037 4.1.3 Distinguished Names ......................................... 5 1038 4.2 Identifiers ................................................... 5 1039 4.2.1 Email Address ............................................... 6 1040 4.2.2 Arbitrary String ............................................ 6 1041 4.2.3 Distinguished Name .......................................... 7 1042 4.2.4 PGP Public Key .............................................. 7 1043 4.2.5 Public Key .................................................. 7 1044 4.2.6 Issuer Name and Serial Number ............................... 8 1045 5 Applying PEM Security Services to MIME Body Parts ............... 8 1046 5.1 PEM Processing Steps .......................................... 8 1047 5.2 Use of multipart/signed Content Type .......................... 10 1048 5.3 Use of multipart/encrypted Content Type ....................... 11 1049 6 Removing PEM Security Services from PEM Body Parts .............. 12 1050 7 Definition of New Content Types ................................. 13 1051 7.1 application/key-request Content Type Definition ............... 13 1052 7.2 application/key-data Content Type Definition .................. 15 1053 8 Examples ........................................................ 17 1054 9 Observations .................................................... 17 1055 10 Summary of Changes to PEM Specification ........................ 17 1056 11 Collected Grammar .............................................. 19 1057 12 Security Considerations ........................................ 22 1058 13 Acknowledgements ............................................... 22 1059 14 References ..................................................... 22 1060 15 Authors' Addresses ............................................. 23 1061 16 Appendix: Imported Grammar ..................................... 24