doc/rfc1847.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          J. Galvin
   8 Request For Comments: 1847                                     S. Murphy
   9 Category: Standards Track                    Trusted Information Systems
  10                                                               S. Crocker
  11                                                          CyberCash, Inc.
  12                                                                 N. Freed
  13                                             Innosoft International, Inc.
  14                                                             October 1995
  15
  16
  17                      Security Multiparts for MIME:
  18                 Multipart/Signed and Multipart/Encrypted
  19
  20 Status of this Memo
  21
  22    This document specifies an Internet standards track protocol for the
  23    Internet community, and requests discussion and suggestions for
  24    improvements.  Please refer to the current edition of the "Internet
  25    Official Protocol Standards" (STD 1) for the standardization state
  26    and status of this protocol.  Distribution of this memo is unlimited.
  27
  28 Abstract
  29
  30    This document defines a framework within which security services may
  31    be applied to MIME body parts.  MIME, an acronym for "Multipurpose
  32    Internet Mail Extensions", defines the format of the contents of
  33    Internet mail messages and provides for multi-part textual and non-
  34    textual message bodies.  The new content types are subtypes of
  35    multipart: signed and encrypted.  Each will contain two body parts:
  36    one for the protected data and one for the control information
  37    necessary to remove the protection.  The type and contents of the
  38    control information body parts are determined by the value of the
  39    protocol parameter of the enclosing multipart/signed or
  40    multipart/encrypted content type, which is required to be present.
  41
  42 Table of Contents
  43
  44    1.  Introduction ..............................................    2
  45    2.  Definition of Security Subtypes of Multipart ..............    2
  46    2.1   Definition of Multipart/Signed ..........................    3
  47    2.2   Definition of Multipart/Encrypted .......................    6
  48    3.  Definition of Control Information Content Types ...........    9
  49    4.  Definition of Key Management Content Types ................    9
  50    5.  Security Considerations ...................................   10
  51    6.  Acknowledgements ..........................................   10
  52    7.  References ................................................   10
  53    8.  Authors' Addresses ........................................   11
  54
  55
  56
  57
  58 Galvin, et al               Standards Track                     [Page 1]
  59 \f
  60 RFC 1847                  Security Multiparts               October 1995
  61
  62
  63 1.  Introduction
  64
  65    An Internet electronic mail message consists of two parts: the
  66    headers and the body.  The headers form a collection of field/value
  67    pairs structured according to STD 11, RFC 822 [1], whilst the body,
  68    if structured, is defined according to MIME [2].  The basic MIME
  69    specification does not provide specific security protection.
  70
  71    This document defines a framework whereby security protection
  72    provided by other protocols may be used with MIME in a complementary
  73    fashion.  By itself, it does not specify security protection.  A MIME
  74    agent must include support for both the framework defined here and a
  75    mechanism to interact with a security protocol defined in a separate
  76    document.  The resulting combined service provides security for
  77    single-part and multi-part textual and non-textual messages.
  78
  79    The framework is provided by defining two new security subtypes of
  80    the MIME multipart content type: signed and encrypted.  In each of
  81    the security subtypes, there are exactly two related body parts: one
  82    for the protected data and one for the control information.  The type
  83    and contents of the control information body parts are determined by
  84    the value of the protocol parameter of the enclosing multipart/signed
  85    or multipart/encrypted content type, which is required to be present.
  86    By registering new values for the required protocol parameter, the
  87    framework is easily extended to accommodate a variety of protocols.
  88
  89    A MIME agent that includes support for this framework will be able to
  90    recognize a security multipart body part and to identify its
  91    protected data and control information body parts.  If the value of
  92    the protocol parameter is unrecognized the MIME agent will not be
  93    able to process the security multipart.  However, a MIME agent may
  94    continue to process any other body parts that may be present.
  95
  96 2.  Definition of Security Subtypes of Multipart
  97
  98    The multipart/signed content type specifies how to support
  99    authentication and integrity services via digital signature.  The
 100    control information is carried in the second of the two required body
 101    parts.
 102
 103    The multipart/encrypted content type specifies how to support
 104    confidentiality via encryption.  The control information is carried
 105    in the first of the two required body parts.
 106
 107    A three-step process is described for the origination and reception
 108    of the multipart/signed and multipart/encrypted contents.  The
 109    details of the processing performed during each step is left to be
 110    specified by the security protocol being used.
 111
 112
 113
 114 Galvin, et al               Standards Track                     [Page 2]
 115 \f
 116 RFC 1847                  Security Multiparts               October 1995
 117
 118
 119 2.1.  Definition of Multipart/Signed
 120
 121    (1)  MIME type name: multipart
 122
 123    (2)  MIME subtype name: signed
 124
 125    (3)  Required parameters: boundary, protocol, and micalg
 126
 127    (4)  Optional parameters: none
 128
 129    (5)  Security considerations: Must be treated as opaque while in
 130         transit
 131
 132    The multipart/signed content type contains exactly two body parts.
 133    The first body part is the body part over which the digital signature
 134    was created, including its MIME headers.  The second body part
 135    contains the control information necessary to verify the digital
 136    signature.  The first body part may contain any valid MIME content
 137    type, labeled accordingly.  The second body part is labeled according
 138    to the value of the protocol parameter.
 139
 140    The attribute token for the protocol parameter is "protocol", i.e.,
 141
 142     parameter := "protocol" "=" value
 143
 144    The value token is comprised of the type and sub-type tokens of the
 145    Content-Type: header of the second body part, i.e.,
 146
 147     value := <"> type "/" subtype <">
 148
 149    where the type and subtype tokens are defined by the MIME [2]
 150    specification.  The semantics of the protocol parameter are defined
 151    according to its value.
 152
 153    The attribute token for the micalg parameter is "micalg", i.e.,
 154
 155     parameter := "micalg" "=" value
 156
 157    The Message Integrity Check (MIC) is the name given to the quantity
 158    computed over the body part with a message digest or hash function,
 159    in support of the digital signature service.  Valid value tokens are
 160    defined by the specification for the value of the protocol parameter.
 161    The value may be a comma (",") separated list of tokens, indicating
 162    the use of multiple MIC algorithms.  As a result, the comma (",")
 163    character is explicitly excluded from the list of characters that may
 164    be included in a token used as a value of the micalg parameter.  If
 165    multiple MIC algorithms are specified, the purpose and use of the
 166    multiple algorithms is defined by the protocol.  If the MIC algorithm
 167
 168
 169
 170 Galvin, et al               Standards Track                     [Page 3]
 171 \f
 172 RFC 1847                  Security Multiparts               October 1995
 173
 174
 175    is also specified in the control information and the value there does
 176    not agree with the value in this parameter, it must be treated as an
 177    error.
 178
 179     NOTE: The presence of the micalg parameter on the
 180     multipart/signed content type header is explicitly intended to
 181     support one-pass processing.  MIME implementations may locate
 182     the second body part by inputting the first body part and
 183     computing the specified MIC values until the boundary
 184     identifying the second body part is found.
 185
 186    The entire contents of the multipart/signed container must be treated
 187    as opaque while it is in transit from an originator to a recipient.
 188    Intermediate message transfer agents must not alter the content of a
 189    multipart/signed in any way, including, but not limited to, changing
 190    the content transfer encoding of the body part or any of its
 191    encapsulated body parts.
 192
 193    The signature in a multipart/signed only applies to the material that
 194    is actually within the multipart/signed object.  In particular, it
 195    does not apply to any enclosing message material, nor does it apply
 196    to entities that are referenced (e.g. via a MIME message/external-
 197    body) by rather than included in the signed content.
 198
 199    When creating a multipart/signed body part, the following sequence of
 200    steps describes the processing necessary.  It must be emphasized that
 201    these steps are descriptive, not prescriptive, and in no way impose
 202    restrictions or requirements on implementations of this
 203    specification.
 204
 205    (1)  The content of the body part to be protected is prepared
 206         according to a local convention.  The content is then
 207         transformed into a MIME body part in canonical MIME format,
 208         including an appropriate set of MIME headers.
 209
 210         In addition, if the multipart/signed object is EVER to be
 211         transferred over the standard Internet SMTP infrastructure, the
 212         resulting MIME body is constrained to 7 bits -- that is, the use
 213         of material requiring either 8bit or binary
 214         content-transfer-encoding is NOT allowed.  Such 8bit or binary
 215         material MUST be encoded using either the quoted-printable or
 216         base64 encodings.
 217
 218         This requirement exists because it is not generally possible,
 219         given the current characteristics of Internet SMTP, for a
 220         message originator to guarantee that a message will travel only
 221         along paths capable of carrying 8bit or binary material.
 222
 223
 224
 225
 226 Galvin, et al               Standards Track                     [Page 4]
 227 \f
 228 RFC 1847                  Security Multiparts               October 1995
 229
 230
 231         SMTP clients normally have the option of either converting the
 232         message to eliminate the use of 8bit or binary encoding or
 233         returning a nondelivery notification to the originator.
 234         However, conversion is not viable in the case of signed objects
 235         since conversion would necessarily invalidate the signature.
 236         This leaves a nondelivery notification as the only available
 237         option, which is not acceptable.
 238
 239    (2)  The body part (headers and content) to be digitally signed is
 240         prepared for signature according to the value of the protocol
 241         parameter.  The MIME headers of the signed body part are
 242         included in the signature to protect the integrity of the MIME
 243         labeling of the data that is signed.
 244
 245    (3)  The prepared body part is made available to the signature creation
 246         process according to a local convention.  The signature creation
 247         process must make available to a MIME implementation two data
 248         streams: the control information necessary to verify the
 249         signature, which the MIME implementation will place in the second
 250         body part and label according to the value of the protocol
 251         parameter, and the digitally signed body part, which the MIME
 252         implementation will use as the first body part.
 253
 254    When receiving a multipart/signed body part, the following sequence
 255    of steps describes the processing necessary to verify the signature
 256    or signatures.  It must be emphasized that these steps are
 257    descriptive, not prescriptive, and in no way impose restrictions or
 258    requirements on implementations of this specification.
 259
 260    (1)  The first body part and the control information in the second body
 261         part must be prepared for the signature verification process
 262         according to the value of the protocol parameter.
 263
 264    (2)  The prepared body parts must be made available to the signature
 265         verification process according to a local convention.  The
 266         signature verification process must make available to the MIME
 267         implementation the result of the signature verification and the
 268         body part that was digitally signed.
 269
 270             NOTE: The result of the signature verification is likely to
 271             include a testament of the success or failure of the
 272             verification.  Also, in the usual case, the body part
 273             returned after signature verification will be the same as
 274             the body part that was received.  We do not insist that
 275             this be the case to allow for protocols that may modify the
 276             body part during the signature processing.
 277
 278
 279
 280
 281
 282 Galvin, et al               Standards Track                     [Page 5]
 283 \f
 284 RFC 1847                  Security Multiparts               October 1995
 285
 286
 287    (3)  The result of the signature verification process is made available
 288         to the user and the MIME implementation continues processing with
 289         the verified body part, i.e., the body part returned by the
 290         signature verification process.
 291
 292    The following example is an illustration of a multipart/signed body
 293    part.  It is necessarily incomplete since the control information is
 294    defined by the security protocol, which must be specified in a
 295    separate document.
 296
 297     Content-Type: multipart/signed; protocol="TYPE/STYPE";
 298             micalg="MICALG"; boundary="Signed Boundary"
 299
 300     --Signed Boundary
 301     Content-Type: text/plain; charset="us-ascii"
 302
 303     This is some text to be signed although it could be
 304     any type of data, labeled accordingly, of course.
 305
 306     --Signed Boundary
 307     Content-Type: TYPE/STYPE
 308
 309     CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
 310
 311     --Signed Boundary--
 312
 313 2.2.  Definition of Multipart/Encrypted
 314
 315    (1)  MIME type name: multipart
 316
 317    (2)  MIME subtype name: encrypted
 318
 319    (3)  Required parameters: boundary, protocol
 320
 321    (4)  Optional parameters: none
 322
 323    (5)  Security considerations: none
 324
 325    The multipart/encrypted content type contains exactly two body parts.
 326    The first body part contains the control information necessary to
 327    decrypt the data in the second body part and is labeled according to
 328    the value of the protocol parameter.  The second body part contains
 329    the data which was encrypted and is always labeled
 330    application/octet-stream.
 331
 332    The attribute token for the protocol parameter is "protocol", i.e.,
 333
 334     parameter := "protocol" "=" value
 335
 336
 337
 338 Galvin, et al               Standards Track                     [Page 6]
 339 \f
 340 RFC 1847                  Security Multiparts               October 1995
 341
 342
 343    The value token is comprised of the type and sub-type tokens of the
 344    Content-Type: header of the first body part, i.e.,
 345
 346     value := <"> type "/" subtype <">
 347
 348    where the type and subtype tokens are defined by the MIME [2]
 349    specification.  The semantics of the protocol parameter are defined
 350    according to its value.
 351
 352    When creating a multipart/encrypted body part, the following sequence
 353    of steps describes the processing necessary.  It must be emphasized
 354    that these steps are descriptive, not prescriptive, and in no way
 355    impose restrictions or requirements on implementations of this
 356    specification.
 357
 358    (1)  The contents of the body part to be protected is prepared according
 359         to a local convention.  The contents are then transformed into a
 360         MIME body part in canonical MIME format, including an appropriate
 361         set of MIME headers.
 362
 363    (2)  The body part (headers and content) to be encrypted is prepared for
 364         encryption according to the value of the protocol parameter.  The
 365         MIME headers of the encrypted body part are included in the
 366         encryption to protect from disclosure the MIME labeling of the
 367         data that is encrypted.
 368
 369    (3)  The prepared body part is made available to the encryption process
 370         according to a local convention.  The encryption process must make
 371         available to a MIME implementation two data streams: the control
 372         information necessary to decrypt the body part, which the MIME
 373         implementation will place in the first body part and label
 374         according to the value of the protocol parameter, and the
 375         encrypted body part, which the MIME implementation will place in
 376         the second body part and label application/octet-stream.  Thus,
 377         when used in a multipart/encrypted, the application/octet-stream
 378         data is comprised of a nested MIME body part.
 379
 380    When receiving a multipart/encrypted body part, the following
 381    sequence of steps describes the processing necessary to decrypt the
 382    enclosed data.  It must be emphasized that these steps are
 383    descriptive, not prescriptive, and in no way impose restrictions or
 384    requirements on implementations of this specification.
 385
 386    (1)  The second body part and the control information in the first body
 387         part must be prepared for the decryption process according to the
 388         value of the protocol parameter.
 389
 390
 391
 392
 393
 394 Galvin, et al               Standards Track                     [Page 7]
 395 \f
 396 RFC 1847                  Security Multiparts               October 1995
 397
 398
 399    (2)  The prepared body parts must be made available to the decryption
 400         process according to a local convention.  The decryption process
 401         must make available to the MIME implementation the result of the
 402         decryption and the decrypted form of the encrypted body part.
 403
 404             NOTE: The result of the decryption process is likely to
 405             include a testament of the success or failure of the
 406             decryption.  Failure may be due to an inability to locate
 407             the proper decryption key or the proper recipient field,
 408             etc.  Implementors should note that the data, if any, of a
 409             failed decryption process is pretty much guaranteed to be
 410             garbage.
 411
 412    (3)  The result of the decryption process is made available to the user
 413         and the MIME implementation continues processing with the decrypted
 414         body part, i.e., the body part returned by the decryption process.
 415
 416             NOTE: A MIME implementation will not be able to display the
 417             received form of the second body part because the
 418             application of encryption will transform the body part.
 419             This transformation will not be described in the MIME
 420             headers (Content-Type: and Content-Transfer-Encoding:) but,
 421             rather, will be described in the content of the first body
 422             part.  Therefore, an implementation should wait until the
 423             encryption has been removed before attempting to display
 424             the content.
 425
 426    The following example is an illustration of a multipart/encrypted
 427    body part.  It is necessarily incomplete since the control
 428    information is defined by the security protocol, which must be
 429    specified in a separate document.
 430
 431     Content-Type: multipart/encrypted; protocol="TYPE/STYPE";
 432             boundary="Encrypted Boundary"
 433
 434     --Encrypted Boundary
 435     Content-Type: TYPE/STYPE
 436
 437     CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
 438
 439     --Encrypted Boundary
 440     Content-Type: application/octet-stream
 441
 442         Content-Type: text/plain; charset="us-ascii"
 443
 444
 445
 446
 447
 448
 449
 450 Galvin, et al               Standards Track                     [Page 8]
 451 \f
 452 RFC 1847                  Security Multiparts               October 1995
 453
 454
 455         All of this indented text, including the indented headers,
 456         would be unreadable since it would have been encrypted by
 457         the protocol "TYPE/STYPE".  Also, this encrypted data could
 458         be any type of data, labeled accordingly, of course.
 459
 460     --Encrypted Boundary--
 461
 462 3.  Definition of Control Information Content Types
 463
 464    This document defines a framework within which security services may
 465    be applied to MIME body parts.  A minimal MIME implementation will be
 466    able to recognize multipart/signed and multipart/encrypted body parts
 467    and be able to identify the protected data and control information
 468    body parts within them.
 469
 470    Complete support for security services requires the MIME agent to
 471    recognize the value of the protocol parameter and to continue
 472    processing based on its value.  The value of the protocol parameter
 473    is the same value used to label the content type of the control
 474    information.
 475
 476    The value of the protocol parameter and the resulting processing
 477    required must be specified in the document defining the security
 478    protocol used.  That document must also precisely specify the
 479    contents of the control information body part.
 480
 481 4.  Definition of Key Management Content Types
 482
 483    This specification recognizes that the complete specification of a
 484    MIME-based security protocol must include a mechanism for
 485    distributing the cryptographic material used in support of the
 486    security services.  For example, a digital signature service
 487    implemented with asymmetric cryptography requires that a signer's
 488    public key be available to the signee.
 489
 490    One possible mechanism for distributing cryptographic material is to
 491    define two additional body parts: one for the purpose of requesting
 492    cryptographic information and one for the purpose of returning the
 493    cryptographic information requested.  The specification of a security
 494    protocol may include a definition of two such body parts or it may
 495    specify an alternate mechanism for the distribution of cryptographic
 496    material.
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Galvin, et al               Standards Track                     [Page 9]
 507 \f
 508 RFC 1847                  Security Multiparts               October 1995
 509
 510
 511 5.  Security Considerations
 512
 513    This specification describes an enhancement to MIME to support signed
 514    and encrypted body parts.  In that context this entire document is
 515    about security.
 516
 517 6.  Acknowledgements
 518
 519    David H. Crocker suggested the use of a multipart structure for the
 520    MIME and PEM interaction.
 521
 522 7.  References
 523
 524    [1] Crocker, D., "Standard for the Format of ARPA Internet Text
 525        Messages", STD 11, RFC 822, University of Delaware, August 1982.
 526
 527    [2] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
 528        Extension) Part One: Mechanisms for Specifying and Describing the
 529        Format of Internet Message Bodies", RFC 1521, Bellcore and
 530        Innosoft, September 1993.
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Galvin, et al               Standards Track                    [Page 10]
 563 \f
 564 RFC 1847                  Security Multiparts               October 1995
 565
 566
 567 8.  Authors' Addresses
 568
 569    Jim Galvin
 570    Trusted Information Systems
 571    3060 Washington Road
 572    Glenwood, MD  21738
 573
 574    Phone: +1 301 854 6889
 575    Fax: +1 301 854 5363
 576    EMail:  galvin@tis.com
 577
 578
 579    Sandy Murphy
 580    Trusted Information Systems
 581    3060 Washington Road
 582    Glenwood, MD  21738
 583
 584    Phone: +1 301 854 6889
 585    Fax: +1 301 854 5363
 586    EMail:  sandy@tis.com
 587
 588
 589    Steve Crocker
 590    CyberCash, Inc.
 591    2086 Hunters Crest Way
 592    Vienna, VA 22181
 593
 594    Phone::    +1 703 620 1222
 595    Fax:    +1 703 391 2651
 596    EMail:  crocker@cybercash.com
 597
 598
 599    Ned Freed
 600    Innosoft International, Inc.
 601    1050 East Garvey Avenue South
 602    West Covina, CA 91790
 603
 604    Phone: +1 818 919 3600
 605    Fax: +1 818 919 3614
 606    EMail:  ned@innosoft.com
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Galvin, et al               Standards Track                    [Page 11]
 619 \f