home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2015.txt < prev    next >
Text File  |  1996-10-10  |  14KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          M. Elkins
  8. Request for Comments: 2015                     The Aerospace Corporation
  9. Category: Standards Track                                   October 1996
  10.  
  11.  
  12.               MIME Security with Pretty Good Privacy (PGP)
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document describes how Pretty Good Privacy (PGP) can be used to
  25.    provide privacy and authentication using the Multipurpose Internet
  26.    Mail Extensions (MIME) security content types described in RFC1847.
  27.  
  28. 1.  Introduction
  29.  
  30.    Previous work on integrating PGP with MIME (including the since
  31.    withdrawn application/pgp content type) has suffered from a number of
  32.    problems, the most significant of which is the inability to recover
  33.    signed message bodies without parsing data structures specific to
  34.    PGP.  This work makes use of the elegant solution proposed in
  35.    RFC1847, which defines security multipart formats for MIME. The
  36.    security multiparts clearly separate the signed message body from the
  37.    signature, and have a number of other desirable properties. This
  38.    document is styled after RFC 1848, which defines MIME Object Security
  39.    Services (MOSS) for providing security and authentication.
  40.  
  41.    This document defines three new content types for implementing
  42.    security and privacy with PGP: application/pgp-encrypted,
  43.    application/pgp-signature and application/pgp-keys.
  44.  
  45. 1.1  Compliance
  46.  
  47.    In order for an implementation to be compliant with this
  48.    specification, is it absolutely necessary for it to obey all items
  49.    labeled as MUST or REQUIRED.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Elkins                      Standards Track                     [Page 1]
  59.  
  60. RFC 2015                 MIME Security with PGP             October 1996
  61.  
  62.  
  63. 2.  PGP data formats
  64.  
  65.    PGP can generate either ASCII armor (described in [3]) or 8-bit
  66.    binary output when encrypting data, generating a digital signature,
  67.    or extracting public key data.  The ASCII armor output is the
  68.    REQUIRED method for data transfer.  This allows those users who do
  69.    not have the means to interpret the formats described in this
  70.    document to be able extract and use the PGP information in the
  71.    message.
  72.  
  73.    When the amount of data to be transmitted requires that it be sent in
  74.    many parts, the MIME message/partial mechanism should be used rather
  75.    than the multipart ASCII armor PGP format.
  76.  
  77. 3.  Content-Transfer-Encoding restrictions
  78.  
  79.    Multipart/signed and multipart/encrypted are to be treated by agents
  80.    as opaque, meaning that the data is not to be altered in any way [1].
  81.    However, many existing mail gateways will detect if the next hop does
  82.    not support MIME or 8-bit data and perform conversion to either
  83.    Quoted-Printable or Base64.  This presents serious problems for
  84.    multipart/signed, in particular, where the signature is invalidated
  85.    when such an operation occurs.  For this reason all data signed
  86.    according to this protocol MUST be constrained to 7 bits (8- bit data
  87.    should be encoded using either Quoted-Printable or Base64).  Note
  88.    that this also includes the case where a signed object is also
  89.    encrypted (see section 6).  This restriction will increase the
  90.    likelihood that the signature will be valid upon receipt.
  91.  
  92.    Data that is ONLY to be encrypted is allowed to contain 8-bit
  93.    characters and therefore need not be converted to a 7-bit format.
  94.  
  95.      Implementor's note: It cannot be stressed enough that applications
  96.      using this standard should follow MIME's suggestion that you "be
  97.      conservative in what you generate, and liberal in what you accept."
  98.      In this particular case it means it would be wise for an
  99.      implementation to accept messages with any content-transfer-
  100.      encoding, but restrict generation to the 7-bit format required by
  101.      this memo.  This will allow future compatibility in the event the
  102.      Internet SMTP framework becomes 8-bit friendly.
  103.  
  104. 4.  PGP encrypted data
  105.  
  106.    Before encryption with PGP, the data should be written in MIME
  107.    canonical format (body and headers).
  108.  
  109.    PGP encrypted data is denoted by the "multipart/encrypted" content
  110.    type, described in [1], and MUST have a "protocol" parameter value of
  111.  
  112.  
  113.  
  114. Elkins                      Standards Track                     [Page 2]
  115.  
  116. RFC 2015                 MIME Security with PGP             October 1996
  117.  
  118.  
  119.    "application/pgp-encrypted".  Note that the value of the parameter
  120.    MUST be enclosed in quotes.
  121.  
  122.    The multipart/encrypted MUST consist of exactly two parts.  The first
  123.    MIME body part must have a content type of "application/pgp-
  124.    encrypted".  This body contains the control information.  A message
  125.    complying with this standard MUST contain a "Version: 1" field in
  126.    this body.  Since the PGP packet format contains all other
  127.    information necessary for decrypting, no other information is
  128.    required here.
  129.  
  130.    The second MIME body part MUST contain the actual encrypted data.  It
  131.    must be labeled with a content type of "application/octet- stream".
  132.  
  133.    Example message:
  134.  
  135.      From: Michael Elkins <elkins@aero.org>
  136.      To: Michael Elkins <elkins@aero.org>
  137.      Mime-Version: 1.0
  138.      Content-Type: multipart/encrypted; boundary=foo;
  139.         protocol="application/pgp-encrypted"
  140.  
  141.      --foo
  142.      Content-Type: application/pgp-encrypted
  143.  
  144.      Version: 1
  145.  
  146.      --foo
  147.      Content-Type: application/octet-stream
  148.  
  149.      -----BEGIN PGP MESSAGE-----
  150.      Version: 2.6.2
  151.  
  152.      hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
  153.      eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
  154.      g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
  155.      AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
  156.      1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
  157.      =zzaA
  158.      -----END PGP MESSAGE-----
  159.  
  160.      --foo--
  161.  
  162. 5.  PGP signed data
  163.  
  164.    PGP signed messages are denoted by the "multipart/signed" content
  165.    type, described in [1], with a "protocol" parameter which MUST have a
  166.    value of "application/pgp-signature" (MUST be quoted).  The "micalg"
  167.  
  168.  
  169.  
  170. Elkins                      Standards Track                     [Page 3]
  171.  
  172. RFC 2015                 MIME Security with PGP             October 1996
  173.  
  174.  
  175.    parameter MUST have a value of "pgp-<hash-symbol>", where <hash-
  176.    symbol> identifies the message integrity check (MIC) used to generate
  177.    the signature.  The currently defined values for <hash-symbol> are
  178.    "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm.
  179.  
  180.    The multipart/signed body MUST consist of exactly two parts.  The
  181.    first part contains the signed data in MIME canonical format,
  182.    including a set of appropriate content headers describing the data.
  183.  
  184.    The second body MUST contain the PGP digital signature.  It MUST be
  185.    labeled with a content type of "application/pgp-signature".
  186.  
  187.    When the PGP digital signature is generated:
  188.  
  189.    (1)  The data to be signed must first be converted to its
  190.         type/subtype specific canonical form.  For text/plain, this
  191.         means conversion to an appropriate character set and conversion
  192.         of line endings to the canonical <CR><LF> sequence.
  193.  
  194.    (2)  An appropriate Content-Transfer-Encoding is then applied. Each
  195.         line of the encoded data MUST end with the canonical <CR><LF>
  196.         sequence.
  197.  
  198.    (3)  MIME content headers are then added to the body, each ending
  199.         with the canonical <CR><LF> sequence.
  200.  
  201.    (4)  As described in [1], the digital signature MUST be calculated
  202.         over both the data to be signed and its set of content headers.
  203.  
  204.    (5)  The signature MUST be generated detached from the signed data
  205.         so that the process does not alter the signed data in any way.
  206.  
  207.    Example message:
  208.  
  209.      From: Michael Elkins <elkins@aero.org>
  210.      To: Michael Elkins <elkins@aero.org>
  211.      Mime-Version: 1.0
  212.      Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
  213.      protocol="application/pgp-signature"
  214.  
  215.      --bar
  216.      & Content-Type: text/plain; charset=iso-8859-1
  217.      & Content-Transfer-Encoding: quoted-printable
  218.      &
  219.      & =A1Hola!
  220.      &
  221.      & Did you know that talking to yourself is a sign of senility?
  222.      &
  223.  
  224.  
  225.  
  226. Elkins                      Standards Track                     [Page 4]
  227.  
  228. RFC 2015                 MIME Security with PGP             October 1996
  229.  
  230.  
  231.      & It's generally a good idea to encode lines that begin with
  232.      & From=20because some mail transport agents will insert a greater-
  233.      & than (>) sign, thus invalidating the signature.
  234.      &
  235.      & Also, in some cases it might be desirable to encode any   =20
  236.      &railing whitespace that occurs on lines in order to ensure  =20
  237.      & that the message signature is not invalidated when passing =20
  238.      & a gateway that modifies such whitespace (like BITNET). =20
  239.      &
  240.      & me
  241.  
  242.      --bar
  243.      Content-Type: application/pgp-signature
  244.  
  245.     -----BEGIN PGP MESSAGE-----
  246.    Version: 2.6.2
  247.  
  248.    iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
  249.    jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
  250.    uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
  251.    HOxEa44b+EI=
  252.    =ndaj
  253.    -----END PGP MESSAGE-----
  254.  
  255.    --bar--
  256.  
  257.    The "&"s in the previous example indicate the portion of the data
  258.    over which the signature was calculated.
  259.  
  260.    Though not required, it is generally a good idea to use Quoted-
  261.    Printable encoding in the first step (writing out the data to be
  262.    signed in MIME canonical format) if any of the lines in the data
  263.    begin with "From ", and encode the "F".  This will avoid an MTA
  264.    inserting a ">" in front of the line, thus invalidating the
  265.    signature!
  266.  
  267.    Upon receipt of a signed message, an application MUST:
  268.  
  269.    (1)  Convert line endings to the canonical <CR><LF> sequence before
  270.         the signature can be verified.  This is necessary since the
  271.         local MTA may have converted to a local end of line convention.
  272.  
  273.    (2)  Pass both the signed data and its associated content headers
  274.         along with the PGP signature to the signature verification
  275.         service.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Elkins                      Standards Track                     [Page 5]
  283.  
  284. RFC 2015                 MIME Security with PGP             October 1996
  285.  
  286.  
  287. 6.  Encrypted and Signed Data
  288.  
  289.    Sometimes it is desirable to both digitally sign and then encrypt a
  290.    message to be sent.  This protocol allows for two methods of
  291.    accomplishing this task.
  292.  
  293. 6.1  RFC1847 Encapsulation
  294.  
  295.    [1], it is stated that the data should first be signed as a
  296.    multipart/signature body, and then encrypted to form the final
  297.    multipart/encrypted body, i.e.,
  298.  
  299.     Content-Type: multipart/encrypted;
  300.        protocol="application/pgp-encrypted"; boundary=foo
  301.  
  302.     --foo
  303.     Content-Type: application/pgp-encrypted
  304.  
  305.     Version: 1
  306.  
  307.     --foo
  308.     Content-Type: application/octet-stream
  309.  
  310.     -----BEGIN PGP MESSAGE-----
  311.     & Content-Type: multipart/signed; micalg=pgp-md5
  312.     &     protocol="application/pgp-signature"; boundary=bar
  313.     &
  314.     & --bar
  315.     & Content-Type: text/plain; charset=us-ascii
  316.     &
  317.     & This message was first signed, and then encrypted.
  318.     &
  319.     & --bar
  320.     & Content-Type: application/pgp-signature
  321.     &
  322.     & -----BEGIN PGP MESSAGE-----
  323.     & Version: 2.6.2
  324.     &
  325.     & iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
  326.     & jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
  327.     & uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
  328.     & HOxEa44b+EI=
  329.     & =ndaj
  330.     & -----END PGP MESSAGE-----
  331.     &
  332.     & --bar--
  333.     -----END PGP MESSAGE-----
  334.  
  335.  
  336.  
  337.  
  338. Elkins                      Standards Track                     [Page 6]
  339.  
  340. RFC 2015                 MIME Security with PGP             October 1996
  341.  
  342.  
  343.     --foo--
  344.  
  345.     (The text preceded by '&' indicates that it is really
  346.     encrypted, but presented as text for clarity.)
  347.  
  348. 6.2  Combined method
  349.  
  350.    Versions 2.x of PGP also allow data to be signed and encrypted in one
  351.    operation.  This method is an acceptable shortcut, and has the
  352.    benefit of less overhead.  The resulting data should be formed as a
  353.    "multipart/encrypted" object as described above.
  354.  
  355.    Messages which are encrypted and signed in this combined fashion are
  356.    REQUIRED to follow the same canonicalization rules as for
  357.    multipart/signed objects.
  358.  
  359.    It is explicitly allowed for an agent to decrypt a combined message
  360.    and rewrite it as a multipart/signed object using the signature data
  361.    embedded in the encrypted version.
  362.  
  363. 7.  Distribution of PGP public keys
  364.  
  365.    Content-Type: application/pgp-keys
  366.    Required parameters: none
  367.    Optional parameters: none
  368.  
  369.    This is the content type which should be used for relaying public key
  370.    blocks.
  371.  
  372. 8.  Notes
  373.  
  374.    PGP and Pretty Good Privacy are trademarks of Philip Zimmermann.
  375.  
  376. 9.  Security Considerations
  377.  
  378.    Use of this protocol has the same security considerations as PGP, and
  379.    is not known to either increase or decrease the security of messages
  380.    using it; see [3] for more information.
  381.  
  382. 10.  Author's Address
  383.  
  384.         Michael Elkins
  385.         P.O. Box 92957 - M1/102
  386.         Los Angeles, CA 90009-2957
  387.  
  388.         Phone: +1 310 336 8040
  389.         Fax: +1 310 336 4402
  390.  
  391.  
  392.  
  393.  
  394. Elkins                      Standards Track                     [Page 7]
  395.  
  396. RFC 2015                 MIME Security with PGP             October 1996
  397.  
  398.  
  399. References
  400.  
  401.    [1]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security
  402.         Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
  403.         RFC 1847, October 1995.
  404.  
  405.    [2]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "MIME Object
  406.         Security Services", RFC 1848, October 1995.
  407.  
  408.    [3]  Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
  409.         Exchange Formats", RFC 1991, August 1996.
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Elkins                      Standards Track                     [Page 8]
  451.  
  452.