home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-pgp-pgpformat-01.txt < prev    next >
Text File  |  1995-10-20  |  45KB  |  968 lines
  1. Network Working Group                                          D. Atkins
  2. INTERNET_DRAFT                                                       MIT
  3. Category: Informational                                     W. Stallings
  4.                                                     Comp-Comm Consulting
  5.                                                            P. Zimmermann
  6.                                             Boulder Software Engineering
  7.                                                                July 1995
  8.  
  9.  
  10.                      PGP Message Exchange Formats
  11.  
  12. Status of this memo
  13.  
  14.    This document is  an  Internet-Draft.   Internet-Drafts  are  working
  15.    documents  of  the Internet Engineering Task Force (IETF), its areas,
  16.    and its working groups.  Note that other groups may  also  distribute
  17.    working documents as Internet-Drafts.
  18.  
  19.    Internet-Drafts are draft documents valid for a maximum of six months
  20.    and  may be updated, replaced, or obsoleted by other documents at any
  21.    time.  It is inappropriate  to  use  Internet-  Drafts  as  reference
  22.    material or to cite them other than as ``work in progress.''
  23.  
  24.    To learn the current status of any Internet-Draft, please  check  the
  25.    ``1id-abstracts.txt''  listing  contained  in  the  Internet-  Drafts
  26.    Shadow Directories on ds.internic.net (US East Coast),  nic.nordu.net
  27.    (Europe),  ftp.isi.edu  (US  West  Coast),  or munnari.oz.au (Pacific
  28.    Rim).
  29.  
  30.    Distribution of this memo is unlimited.  Please send comments to  the
  31.    <pgp-bugs@mit.edu> mailing list.
  32.  
  33. Table of Contents
  34.  
  35.    1.    Introduction............................................2
  36.    2.    PGP Services............................................3
  37.    2.1   Digital signature.......................................3
  38.    2.2   Confidentiality.........................................3
  39.    2.3   Compression.............................................4
  40.    2.4   Radix-64 conversion.....................................4
  41.    2.4.1 ASCII Armor Formats.....................................5
  42.    3.    Data Element Formats....................................6
  43.    3.1   Byte strings............................................6
  44.    3.2   Whole number fields.....................................7
  45.    3.3   Multiprecision fields...................................7
  46.    3.4   String fields...........................................8
  47.    3.5   Time fields.............................................8
  48.    4.    Common Fields...........................................8
  49.    4.1   Packet structure fields.................................8
  50.    4.2   Number ID fields.......................................10
  51.    4.3   Version fields.........................................10
  52.    5.    Packets................................................10
  53.    5.1   Overview...............................................10
  54.    5.2   General Packet Structure...............................11
  55.    5.2.1 Message component......................................11
  56.    5.2.2 Signature component....................................11
  57.    5.2.3 Session key component..................................11
  58.    6.    PGP Packet Types.......................................12
  59.    6.1   Literal data packets...................................12
  60.    6.2   Signature packets......................................13
  61.    6.2.1 Message-digest-related fields..........................14
  62.    6.2.2 Public-key-related fields..............................15
  63.    6.2.3 RSA signatures.........................................16
  64.    6.2.4 Miscellaneous fields...................................16
  65.    6.3   Compressed data packets................................16
  66.    6.4   Conventional-key-encrypted data packets................17
  67.    6.4.1 Conventional-encryption type byte......................18
  68.    6.5   Public-key-encrypted packets...........................18
  69.    6.5.1 RSA-encrypted data encryption key (DEK)................19
  70.    6.6   Public-key Packets.....................................19
  71.    6.7   User ID packets........................................19
  72.    7.    Transferable Public Keys...............................20
  73.    8.    Acknowledgments........................................20
  74.    9.    Security Considerations................................20
  75.    10.   Authors' Addresses.....................................21
  76.  
  77. 1. Introduction
  78.  
  79.    PGP (Pretty  Good   Privacy) uses a  combination    of public-key and
  80.    conventional encryption to  provide security services for  electronic
  81.    mail messages and data files.  These services include confidentiality
  82.    and digital  signature.   PGP is widely  used  throughout  the global
  83.    computer  community.    This document describes  the   format of "PGP
  84.    files", i.e., messages  that have been  encrypted and/or signed  with
  85.    PGP.
  86.  
  87.    PGP was created by  Philip Zimmermann and  first released, in Version
  88.    1.0, in 1991. Subsequent versions have  been designed and implemented
  89.    by an all-volunteer collaborative effort under the design guidance of
  90.    Philip Zimmermann.  PGP  and  Pretty Good Privacy are   trademarks of
  91.    Philip Zimmermann.
  92.  
  93.    This document describes  versions 2.x of PGP.  Specifically, versions
  94.    2.6 and  2.7 conform to this specification.   Version 2.3 conforms to
  95.    this specification with minor differences.
  96.  
  97.    A new  release of PGP, known as  PGP 3.0, is  anticipated in 1995. To
  98.    the maximum extent possible, this version will be upwardly compatible
  99.    with version 2.x. At a minimum, PGP 3.0 will be able to read messages
  100.    and signatures produced by version 2.x.
  101.  
  102. 2. PGP Services
  103.  
  104.    PGP provides four services related to the format of messages and data
  105.    files: digital signature,  confidentiality, compression, and radix-64
  106.    conversion.
  107.  
  108. 2.1 Digital signature
  109.  
  110.    The digital signature  service involves the  use of  a hash code,  or
  111.    message digest, algorithm, and a public-key encryption algorithm. The
  112.    sequence is as follows:
  113.  
  114.      -the sender creates a message
  115.      -the sending PGP generates a hash code of the message
  116.      -the sending PGP encrypts the hash code using the sender's private
  117.       key
  118.      -the encrypted hash code is prepended to the message
  119.      -the receiving PGP decrypts the hash code using the sender's public
  120.       key
  121.      -the receiving PGP generates a new hash code for the received
  122.       message and compares it to the decrypted hash code. If the two
  123.       match, the message is accepted as authentic
  124.  
  125.    Although signatures  normally are  found  attached to the  message or
  126.    file that they sign, this is not always the case: detached signatures
  127.    are supported. A  detached signature  may  be stored  and transmitted
  128.    separately from the   message it signs.   This is  useful  in several
  129.    contexts. A user may wish to maintain a separate signature log of all
  130.    messages  sent or received.  A detached   signature of an  executable
  131.    program  can  detect  subsequent  virus  infection. Finally, detached
  132.    signatures can be used when more than one party must sign a document,
  133.    such as a legal contract.  Each person's signature is independent and
  134.    therefore is applied   only to  the document. Otherwise,   signatures
  135.    would have  to  be nested, with   the second signer  signing both the
  136.    document and the first signature, and so on.
  137.  
  138. 2.2 Confidentiality
  139.  
  140.    PGP provides confidentiality by encrypting messages to be transmitted
  141.    or data files to be stored  locally using conventional encryption. In
  142.    PGP, each conventional key  is used only once. That  is, a new key is
  143.    generated as a random 128-bit number for each message. Since it is to
  144.    be used  only once,  the session key    is bound to the  message  and
  145.    transmitted with it.   To protect the key, it  is encrypted  with the
  146.    receiver's public key. The sequence is as follows:
  147.  
  148.      -the sender creates a message
  149.      -the sending PGP generates a random number to be used as a session
  150.       key for this message only
  151.      -the sending PGP encrypts the message using the session key
  152.      -the session key is encrypted using the recipient's public key and
  153.       prepended to the encrypted message
  154.      -the receiving PGP decrypts the session key using the recipient's
  155.       private key
  156.      -the receiving PGP decrypts the message using the session key
  157.  
  158.    Both digital signature and confidentiality services may be applied to
  159.    the same message. First, a signature is generated for the message and
  160.    prepended to   the message.  Then,   the message  plus   signature is
  161.    encrypted using a conventional  session key. Finally, the session key
  162.    is encrypted using  public-key    encryption and prepended   to   the
  163.    encrypted block.
  164.  
  165. 2.3 Compression
  166.  
  167.    As a default, PGP compresses the message after applying the signature
  168.    but before encryption.
  169.  
  170. 2.4 Radix-64 conversion
  171.  
  172.    When PGP is used, usually   part of the   block to be transmitted  is
  173.    encrypted. If  only the signature  service is used,  then the message
  174.    digest  is  encrypted (with  the   sender's   private key). If    the
  175.    confidentiality service   is  used, the   message plus  signature (if
  176.    present) are encrypted (with a one-time conventional key). Thus, part
  177.    or all of the resulting block consists of a stream of arbitrary 8-bit
  178.    bytes.  However, many electronic mail  systems only permit the use of
  179.    blocks consisting of ASCII text. To accommodate this restriction, PGP
  180.    provides the  service of converting the  raw 8-bit binary stream to a
  181.    stream of printable ASCII characters, called ASCII Armor.
  182.  
  183.    The scheme  used for this purpose  is radix-64 conversion. Each group
  184.    of three bytes of binary data is mapped into 4 ASCII characters. This
  185.    format   also  appends a  CRC  to detect  transmission  errors.  This
  186.    radix-64 conversion, also called Ascii Armor, is a wrapper around the
  187.    binary PGP  messages,  and is  used to  protect  the  binary messages
  188.    during transmission over non-binary channels, such as Internet Email.
  189.  
  190.    The following table defines the mapping.  The characters used are the
  191.    upper-  and lower-case  letters,  the  digits  0 through  9,  and the
  192.    characters + and  /.   The carriage-return and  linefeed   characters
  193.    aren't used in the conversion, nor is  the tab or any other character
  194.    that might be altered by the  mail system. The  result is a text file
  195.    that is "immune" to the modifications inflicted by mail systems.
  196.  
  197.    6-bit character   6-bit character   6-bit character   6-bit character
  198.    value encoding  value  encoding    value   encoding    value encoding
  199.    0        A        16        Q        32        g        48        w
  200.    1        B        17        R        33        h        49        x
  201.    2        C        18        S        34        i        50        y
  202.    3        D        19        T        35        j        51        z
  203.    4        E        20        U        36        k        52        0
  204.    5        F        21        V        37        l        53        1
  205.    6        G        22        W        38        m        54        2
  206.    7        H        23        X        39        n        55        3
  207.    8        I        24        Y        40        o        56        4
  208.    9        J        25        Z        41        p        57        5
  209.    1        K        26        a        42        q        58        6
  210.    11       L        27        b        43        r        59        7
  211.    12       M        28        c        44        s        60        8
  212.    13       N        29        d        45        t        61        9
  213.    14       O        30        e        46        u        62        +
  214.    15       P        31        f        47        v        63        /
  215.                                                          (pad)       =
  216.  
  217.    It is possible   to use PGP to  convert  any arbitrary file to  ASCII
  218.    Armor.  When this  is done, PGP tries to  compress the data before it
  219.    is converted to Radix-64.
  220.  
  221. 2.4.1 ASCII Armor Formats
  222.  
  223.    When  PGP  encodes data into  ASCII Armor,  it  puts specific headers
  224.    around the data, so PGP  can reconstruct the data  at a future  time.
  225.    PGP tries  to inform the user  what kind  of  data is  encoded in the
  226.    ASCII armor through the use of the headers.
  227.  
  228.    ASCII Armor is created by concatenating the following data:
  229.  
  230.         - An Armor Headerline, appropriate for the type of data
  231.         - Armor Headers
  232.         - A blank line
  233.         - The ASCII-Armored data
  234.         - An Armor Checksum
  235.         - The Armor Tail (which depends on the Armor Headerline).
  236.  
  237.    An Armor Headerline is composed  by taking the appropriate headerline
  238.    text  surrounded by  five  (5)  dashes  (-)  on  either side of   the
  239.    headerline text.  The headerline text  is chosen based upon the  type
  240.    of data that is being encoded in Armor, and how  it is being encoded.
  241.    Headerline texts include the following strings:
  242.  
  243.     BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed files
  244.     BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public keys
  245.     BEGIN PGP MESSAGE, PART X/Y -- used for multi-part messages, where
  246.                                     the armor is split amongst Y files,
  247.                                     and this is the Xth file out of Y.
  248.  
  249.    The Armor Headers are pairs of strings that  can give the user or the
  250.    receiving PGP program some information about how to decode or use the
  251.    message.   The Armor Headers are  a part of  the armor, not a part of
  252.    the  message, and hence  should not be  used to  convey any important
  253.    information, since they can be changed in transport.
  254.  
  255.    The format  of  an Armor  Header is that   of a key-value  pair,  the
  256.    encoding  of  RFC-822  headers.     PGP should  consider   improperly
  257.    formatted Armor Headers to be corruption of the ASCII Armor.  Unknown
  258.    Keys should be   reported to the  user,  but so  long as the  RFC-822
  259.    formatting is correct, PGP   should continue to process the  message.
  260.    Currently defined Armor  Header Keys include "Version" and "Comment",
  261.    which  define   the PGP  Version used  to  encode the   message and a
  262.    user-defined comment.
  263.  
  264.    The Armor Checksum   is a  24-bit CRC   converted  to four  bytes  of
  265.    radix-64 encoding, prepending an   equal-sign  (=) to the   four-byte
  266.    code.  The CRC is  computed  by using the  generator 0x864CFB  and an
  267.    initialization of 0xB704CE.    The accumulation is  done on  the data
  268.    before it is   converted to radix-64, rather   than on the  converted
  269.    data.  For more information on CRC functions,  the reader is asked to
  270.    look  at  chapter 19  of  the book  "C  Programmer's  Guide to Serial
  271.    Communications," by Joe Campbell.
  272.  
  273.    The   Armor   Tail is  composed  in  the   same  manner as  the Armor
  274.    Headerline,   except the  string "BEGIN"  is  replaced  by the string
  275.    "END".
  276.  
  277. 3. Data Element Formats
  278.  
  279. 3.1 Byte strings
  280.  
  281.    The objects considered  in this document are  all "byte strings."   A
  282.    byte string is a finite sequence of bytes.  The concatenation of byte
  283.    string X of length M with byte string Y of  length N is a byte string
  284.    Z of length M + N; the first  M bytes of Z are  the bytes of X in the
  285.    same order, and the remaining N bytes of Z are the bytes  of Y in the
  286.    same order.
  287.  
  288.    Literal byte strings  are written from left  to right,  with pairs of
  289.    hex nibbles  separated by spaces,  enclosed  by angle  brackets:  for
  290.    instance, <05  ff 07> is a byte  string of length  3 whose bytes have
  291.    numeric  values  5, 255,  and  7 in that  order.  All numbers in this
  292.    document outside angle brackets are written in decimal.
  293.  
  294.    The byte string of length 0 is called "empty" and written <>.
  295.  
  296. 3.2 Whole number fields
  297.  
  298.    Purpose.  A whole number field can represent any nonnegative integer,
  299.    in a format where the field length is known in advance.
  300.  
  301.    Definition.  A whole  number field is  any byte string.  It is stored
  302.    in radix-256 MSB-first format.  This means  that a whole number field
  303.    of length N with bytes b_0 b_1 ...  b_{N-2} b_{N-1} in that order has
  304.    value
  305.  
  306.       b_0 * 256^{N-1} + b_1 * 256^{N-2} + ... + b_{N-2} * 256 + b_{N-1}.
  307.  
  308.    Examples.   The byte  string <00  0D  64 11 00 00>   is a valid whole
  309.    number field with value 57513410560.  The byte string <FF> is a valid
  310.    whole number field with value   255.  The byte  string  <00 00> is  a
  311.    valid whole number field with value 0.  The empty byte string <> is a
  312.    valid whole number field with value 0.
  313.  
  314. 3.3 Multiprecision fields
  315.  
  316.    Purpose.   A  multiprecision   field can  represent  any  nonnegative
  317.    integer which is not too large.   The field length  need not be known
  318.    in advance.  Multiprecision fields  are designed to waste very little
  319.    space: a small integer uses a short field.
  320.  
  321.    Definition.  A  multiprecision  field  is  the  concatenation of  two
  322.    fields:
  323.  
  324.       (a) a whole number field of length 2, with value B;
  325.       (b) a whole number field, with value V.
  326.  
  327.    Field (b) is of length [(B+7)/8], i.e., the greatest integer which is
  328.    no larger than   (B+7)/8.  The value  of the  multiprecision field is
  329.    defined to be V.  V  must be between 2^{B-1} and  2^B - 1  inclusive.
  330.    In other words B must be exactly the number of significant bits in V.
  331.  
  332.    Some   implementations   may limit the  possible    range of  B.  The
  333.    implementor  must  document  which values  of B   are   allowed by an
  334.    implementation.
  335.  
  336.    Examples.  The byte string <00  00> is a valid multiprecision integer
  337.    with value 0.  The  byte string <00  03 05> is a valid multiprecision
  338.    field with value 5.  The byte  strings <00 03 85>  and <00 00 00> are
  339.    not valid multiprecision fields.  The former is invalild because <85>
  340.    has  8 significant bits,  not  3; the latter   is invalid because the
  341.    second field has too many bytes of data given  the value of the first
  342.    field.  The byte string <00 09 01 ff> is a valid multiprecision field
  343.    with value 511.  The byte string <01 00 80 00 00 00 00 00 00 00 00 00
  344.    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07> is
  345.    a valid multiprecision field with value 2^255 + 7.
  346.  
  347. 3.4  String fields
  348.  
  349.    Purpose.  A  string field represents  any sequence of bytes of length
  350.    between 0 and 255   inclusive.   The length  need   not be  known  in
  351.    advance.  By convention,  the content of a  string field  is normally
  352.    interpreted as ASCII codes when it is displayed.
  353.  
  354.    Definition.  A string field is the concatenation of the following:
  355.  
  356.      (a) a whole number field of length 1, with value L;
  357.      (b) a byte string of length L.
  358.  
  359.    The content of the string field is defined to be field (b).
  360.  
  361.    Examples: <05  48 45 4c 4c 4f>  is a valid  string field  which would
  362.    normally be  displayed as the string  HELLO.  <00> is a  valid string
  363.    field which would normally be displayed as the empty string.  <01 00>
  364.    is a valid string field.
  365.  
  366. 3.5  Time fields
  367.  
  368.    Purpose.  A time field represents the number of seconds elapsed since
  369.    1970   Jan   1 00:00:00   GMT.  It  is   compatible  with   the usual
  370.    representation of times under UNIX.
  371.  
  372.    Definition.  A time field  is a whole  number field of length 4, with
  373.    value  V.  The time represented  by the time  field is the one-second
  374.    interval beginning V seconds after 1970 Jan 1 00:00:00 GMT.
  375.  
  376. 4. Common Fields
  377.  
  378.    This section defines fields found in more than one packet format.
  379.  
  380. 4.1  Packet structure fields
  381.  
  382.    Purpose.  The packet structure  field distinguishes between different
  383.    types of packets, and indicates the length of packets.
  384.  
  385.    Definition.  A packet structure  field is a  byte string of length 1,
  386.    2, 3, or 5.  Its first byte is the cipher type  byte (CTB), with bits
  387.    labeled  76543210,  7 the most    significant  bit and  0  the  least
  388.    significant bit.   As   indicated  below the  length   of  the packet
  389.    structure field is determined by the CTB.
  390.  
  391.    CTB bits 76 have values listed in the following table:
  392.  
  393.       10 - normal CTB
  394.       11 - reserved for future experimental work
  395.       all others - reserved
  396.  
  397.    CTB  bits 5432, the "packet  type  bits", have  values  listed in the
  398.    following table:
  399.  
  400.       0001 - public-key-encrypted packet
  401.       0010 - signature packet
  402.       0101 - secret-key certificate packet
  403.       0110 - public-key certificate packet
  404.       1000 - compressed data packet
  405.       1001 - conventional-key-encrypted packet
  406.       1011 - literal data packet
  407.       1100 - keyring trust packet
  408.       1101 - user id packet
  409.       1110 - comment packet     (*)
  410.       all others - reserved
  411.  
  412.    CTB bits  10, the "packet-length length  bits", have values listed in
  413.    the following table:
  414.  
  415.       00 - 1-byte packet-length field
  416.       01 - 2-byte packet-length field
  417.       10 - 4-byte packet-length field
  418.       11 - no packet length supplied, unknown packet length
  419.  
  420.    As indicated  in this table,  depending  on the packet-length  length
  421.    bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field
  422.    are a "packet-length   field".  The packet-length   field is a  whole
  423.    number field.  The value of the packet-length field  is defined to be
  424.    the value of the whole number field.
  425.  
  426.    A   value of 11   is  currently  used   in  one place: on  compressed
  427.    data. That is,  a compressed data block currently  looks like <A3  01
  428.    . .  .>, where   <A3>, binary  10 1000   11, is an  indefinite-length
  429.    packet. The proper interpretation is "until the  end of the enclosing
  430.    structure", although it  should  never  appear outermost (where   the
  431.    enclosing structure is a file).
  432.  
  433.    Options marked with an   asterisk (*) are  not implemented   yet; PGP
  434.    2.6.2 will never output this packet type.
  435.  
  436. 4.2  Number ID fields
  437.  
  438.    Purpose.  The ID of a whole number is  its 64 least significant bits.
  439.    The ID is a convenient way  to distinguish between large numbers such
  440.    as keys, without having to transmit the number itself. Thus, a number
  441.    that may be hundreds or thousands of decimal  digits in length can be
  442.    identified with a 64-bit identifier. Two keys may have the same ID by
  443.    chance or by  malice; although  the  probability that two large  keys
  444.    chosen at random would have the same ID is extremely small.
  445.  
  446.    Definition.  A number ID  field is a whole  number field of length 8.
  447.    The value of  the number ID field  is defined to be  the value of the
  448.    whole number field.
  449.  
  450. 4.3  Version fields
  451.  
  452.    Many packet  types include a version number  as the first byte of the
  453.    body.  The format   and meaning of   the body depend on  the  version
  454.    number.   More versions of packets,  with new version numbers, may be
  455.    defined in the  future.   An implementation  need  not  support every
  456.    version of each packet type.  However,  the implementor must document
  457.    which versions   of   each  packet  type   are supported     by   the
  458.    implementation.
  459.  
  460.    A version  number of  2 or 3   is currently allowed  for each  packet
  461.    format.  New versions will probably be  numbered sequentially up from
  462.    3.  For   backwards compatibility,  implementations will   usually be
  463.    expected to  support  version  N of  a  packet  whenever they support
  464.    version N+1.  Version 255 may be used for experimental purposes.
  465.  
  466. 5. Packets
  467.  
  468. 5.1 Overview
  469.  
  470.    A packet  is a  digital envelope with  data inside.   A PGP file,  by
  471.    definition, is the concatenation of one or more packets. In addition,
  472.    one  or    more of the  packets   in  a file   may  be   subject to a
  473.    transformation using encryption, compression, or radix-64 conversion.
  474.  
  475.    A packet is the concatenation of the following:
  476.  
  477.       (a) a packet structure field;
  478.       (b) a byte string of some length N.
  479.  
  480.    Byte string (b) is called the "body" of the packet.  The value of the
  481.    packet-length field inside the  packet structure field (a) must equal
  482.    N, the length of the body.
  483.  
  484.    Other characteristics of the packet are determined by the type of the
  485.    packet.  See the  definitions of particular  packet types for further
  486.    details.  The CTB packet-type bits inside the packet structure always
  487.    indicate the packet type.
  488.  
  489.    Note that packets may  be nested: one digital  envelope may be placed
  490.    inside another.   For  example,  a conventional-key-encrypted  packet
  491.    contains a disguised packet, which in turn might be a compressed data
  492.    packet.
  493.  
  494. 5.2  General packet structure
  495.  
  496.    A pgp file  consists  of  three components:  a  message  component, a
  497.    signature (optional), and a session key component (optional).
  498.  
  499. 5.2.1 Message component
  500.  
  501.    The  message   component includes  the  actual  data  to be stored or
  502.    transmitted  as well as a   header that includes control  information
  503.    generated by PGP. The message component consists  of a single literal
  504.    data packet.
  505.  
  506. 5.2.2 Signature component
  507.  
  508.    The  signature component is the  signature of  the message component,
  509.    formed using a hash code of the message component  and the public key
  510.    of the sending  PGP entity.  The  signature component consists  of  a
  511.    single signature packet.
  512.  
  513.    If the   default option  of compression  is   chosen, then the  block
  514.    consisting of the  literal data  packet  and the signature  packet is
  515.    compressed to form a compressed data packet.
  516.  
  517. 5.2.3 Session key component
  518.  
  519.    The session key component includes the encrypted  session key and the
  520.    identifier of the recipients public key used by the sender to encrypt
  521.    the  session key.  The  session key  component  consists  of a single
  522.    public-key-encrypted packet for each recipient of the message.
  523.  
  524.    If compression has been used, then conventional encryption is applied
  525.    to the  compressed data  packet  formed from  the compression  of the
  526.    signature packet and the literal data packet. Otherwise, conventional
  527.    encryption is applied to the block consisting of the signature packet
  528.    and the  literal  data packet.  In   either case,  the  cyphertext is
  529.    referred to as a conventional-key-encrypted data packet.
  530.  
  531. 6.  PGP Packet Types
  532.  
  533.    PGP includes the following types of packets:
  534.  
  535.        -literal data packet
  536.        -signature packet
  537.        -compressed data packet
  538.        -conventional-key-encrypted data packet
  539.        -public-key-encrypted packet
  540.        -public-key packet
  541.        -User ID packet
  542.  
  543. 6.1 Literal data packets
  544.  
  545.    Purpose.  A literal data packet is the lowest  level of contents of a
  546.    digital envelope.   The  data  inside a  literal  data packet  is not
  547.    subject to any further interpretation by PGP.
  548.  
  549.    Definition.  A    literal data packet  is   the concatenation  of the
  550.    following fields:
  551.  
  552.       (a) a packet structure field;
  553.       (b) a byte, giving a mode;
  554.       (c) a string field, giving a filename;
  555.       (d) a time field;
  556.       (e) a byte string of literal data.
  557.  
  558.    Fields (b), (c), and (d) suggest how the data should  be written to a
  559.    file. Byte (b) is either  ASCII b <62>, for binary,  or ASCII t <74>,
  560.    for text. Byte (b) may also  take on the value  ASCII 1, indicating a
  561.    machine-local conversion. It is not defined how PGP will convert this
  562.    across platforms.
  563.  
  564.    Field (c) suggests a filename. Field (d) should be  the time at which
  565.    the file was last modified, or the time at  which the data packet was
  566.    created, or 0.
  567.  
  568.    Note that  only  field  (e) of a  literal  data  packet is fed   to a
  569.    message-digest  function   for  the formation  of    a signature. The
  570.    exclusion of the  other fields ensures  that detached signatures  are
  571.    exactly the same   as attached signatures  prefixed to   the message.
  572.    Detached signatures  are calculated on  a separate file that has none
  573.    of the literal data packet header fields.
  574.  
  575. 6.2 Signature packet
  576.  
  577.    Purpose.  Signatures  are attached to data, in  such a way  that only
  578.    one  entity,  called the "writer,"   can  create the signature.   The
  579.    writer  must first create a  "public key"  K  and distribute it.  The
  580.    writer keeps  certain  private  data related   to  K.  Only   someone
  581.    cooperating  with  the writer can sign  data  using K, enveloping the
  582.    data  in  a signature  packet  (also known as a private-key-encrypted
  583.    packet).  Anyone   can look through the   glass  in the  envelope and
  584.    verify that the signature was  attached to the data  using K.  If the
  585.    data is altered in any way then the verification will fail.
  586.  
  587.    Signatures have different meanings.   For example, a signature  might
  588.    mean "I wrote  this  document," or  "I received   this document."   A
  589.    signature packet    includes a "classification"  which  expresses its
  590.    meaning.
  591.  
  592.    Definition.  A signature packet, version 2 or 3, is the concatenation
  593.    of the following fields:
  594.  
  595.       (a) packet structure field (2, 3, or 5 bytes);
  596.       (b) version number = 2 or 3 (1 byte);
  597.       (c) length of following material included in MD calculation
  598.           (1 byte, always the value 5);
  599.       (d1) signature classification (1 byte);
  600.       (d2) signature time stamp (4 bytes);
  601.       (e) key ID for key used for singing (8 bytes);
  602.       (f) public-key-cryptosystem (PKC) type (1 byte);
  603.       (g) message digest algorithm type (1 byte);
  604.       (h) first two bytes of the MD output, used as a checksum
  605.           (2 bytes);
  606.       (i) a byte string of encrypted data holding the RSA-signed digest.
  607.  
  608.    The message digest is taken of the bytes of the file, followed by the
  609.    bytes of field  (d). It was originally intended  that  the length (c)
  610.    could vary, but now  it seems that it will  alwaye remain  a constant
  611.    value of 5, and that is the only value that will  be accepted.  Thus,
  612.    only the fields (d1) and (d2) will be hashed into the signature along
  613.    with the main message.
  614.  
  615. 6.2.1 Message-digest-related fields
  616.  
  617.    The message digest algorithm is specified  by the message digest (MD)
  618.    number of field (g). The following MD numbers are currently defined:
  619.  
  620.       1 - MD5 (output length 16)
  621.       255 - experimental
  622.  
  623.    More MD numbers may be defined in the future.  An implementation need
  624.    not  support every MD number.  The   implementor must document the MD
  625.    numbers understood by an implementation.
  626.  
  627.    A  message digest algorithm reads a   byte string of  any length, and
  628.    writes a byte string of some fixed  length, as indicated in the table
  629.    above.
  630.  
  631.    The input to  the message digest algorithm   is the concatenation  of
  632.    some "primary input" and some "appended input."
  633.  
  634.    The appended input is specified by field (c), which gives a number of
  635.    bytes to  be taken from the following  fields: (d1), (d2), and so on.
  636.    The current   implementation uses the value 5   for  this number, for
  637.    fields (d1)  and (d2).  Any field not  included in the appended input
  638.    is not "signed" by field (i).
  639.  
  640.    The primary input is determined by  the signature classification byte
  641.    (d1).   Byte  (d1) is  one of the  following hex  numbers, with these
  642.    meanings:
  643.  
  644.       <00> - document signature, binary image ("I wrote this document")
  645.       <01> - document signature, canonical text ("I wrote this document")
  646.       <10> - public key packet and user ID packet, generic certification
  647.            ("I think this key was created by this user, but I won't say
  648.            how sure I am")
  649.       <11> - public key packet and user ID packet, persona certification
  650.            ("This key was created by someone who has told me that he is
  651.            this user") (#)
  652.       <12> - public key packet and user ID packet, casual certification
  653.            ("This key was created by someone who I believe, after casual
  654.            verification, to be this user")  (#)
  655.       <13> - public key packet and user ID packet, positive certification
  656.            ("This key was created by someone who I believe, after
  657.            heavy-duty identification such as picture ID, to be this
  658.            user")  (#)
  659.       <20> - public key packet, key compromise ("This is my key, and I
  660.            have revoked it")
  661.       <30> - public key packet and user ID packet, revocation ("I retract
  662.            all my previous statements that this key is related to this
  663.            user")  (*)
  664.       <40> - time stamping ("I saw this document") (*)
  665.  
  666.    More classification numbers  may be defined in  the future to  handle
  667.    other meanings of signatures, but only the  above numbers may be used
  668.    with version  2 or version  3 of  a signature  packet.   It should be
  669.    noted that PGP 2.6.2  has not implemented the  packets marked with an
  670.    asterisk (*), and the packets marked with a  hash  (#) are not output
  671.    by PGP 2.6.2.
  672.  
  673.    Signature packets are used in two  different contexts. One (signature
  674.    type <00>   or <01>) is  of text  (either  the contents of  a literal
  675.    packet or a separate file), while types <10> through <1F> appear only
  676.    in key files, after the keys and user  IDs that they sign.  Type <20>
  677.    appears in  key files, after  the keys that it   signs, and type <30>
  678.    also appears after a key/userid combination. Type <40> is intended to
  679.    be a signature of a signature, as a notary seal on a signed document.
  680.  
  681.    The output of  the message digest algorithm is  a message digest,  or
  682.    hash code. Field i contains the cyphertext produced by encrypting the
  683.    message digest with  the signer's private key.  Field h contains  the
  684.    first two bytes  of the unencrypted  message digest. This enables the
  685.    recipient to determine if the correct public key  was used to decrypt
  686.    the message  digest  for authentication, by comparing  this plaintext
  687.    copy of the first two byes with the first  two bytes of the decrypted
  688.    digest. These two bytes  also serve as a  16-bit frame check sequence
  689.    for the message.
  690.  
  691. 6.2.2 Public-key-related fields
  692.  
  693.    The  message  digest is signed by  encrypting  it using  the writer's
  694.    private key. Field (e) is the ID of the corresponding public key.
  695.  
  696.    The  public-key-encryption algorithm  is specified by  the public-key
  697.    cryptosystem (PKC) number of field (f). The following PKC numbers are
  698.    currently defined:
  699.  
  700.       1 - RSA
  701.       255 - experimental
  702.  
  703.    More PKC numbers  may be defined   in the future.   An implementation
  704.    need not support every PKC number.  The implementor must document the
  705.    PKC numbers understood by an implementation.
  706.  
  707.    A PKC number identifies both   a public-key encryption method and   a
  708.    signature method.  Both of these methods are fully defined as part of
  709.    the definition of the PKC number.  Some cryptosystems are usable only
  710.    for encryption, or only  for signatures; if  any such PKC numbers are
  711.    defined in the future, they will be marked appropriately.
  712.  
  713. 6.2.3 RSA signatures
  714.  
  715.    An RSA-signed byte string is a multiprecision field that is formed by
  716.    taking the message  digest and filling in an  ASN structure, and then
  717.    encrypting the whole byte string in the RSA key of the signer.
  718.  
  719.    PGP versions 2.3 and later encode the MD into a PKCS-format signature
  720.    string, which has the following format:
  721.  
  722.           MSB               .   .   .                    LSB
  723.           0   1   <FF>(n bytes)   0   ASN(18 bytes)   MD(16 bytes)
  724.  
  725.    See RFC1423 for an explanation of the meaning  of the ASN string.  It
  726.    is the following 18 byte long hex value:
  727.  
  728.           <30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 10>
  729.  
  730.    Enough bytes of  <FF> padding are added  to  make the length of  this
  731.    whole string equal to the number of bytes in the modulus.
  732.  
  733. 6.2.4 Miscellaneous fields
  734.  
  735.    The timestamp   field (d2) is  analogous to  the  date box next  to a
  736.    signature  box on a  form.  It  represents a time  which is typically
  737.    close to the moment that the signature packet  was created.  However,
  738.    this is not a requirement.  Users may choose to date their signatures
  739.    as they wish, just as they do now in handwritten signatures.
  740.  
  741.    If an application  requires the  creation  of trusted  timestamps  on
  742.    signatures, a  detached  signature   certificate with  an   untrusted
  743.    timestamp may  be submitted to a  trusted timestamp notary service to
  744.    sign the  signature packet with  another signature packet, creating a
  745.    signature of a signature.   The notary's signature's  timestamp could
  746.    be used as the trusted "legal" time of the original signature.
  747.  
  748. 6.3 Compressed data packets
  749.  
  750.    Purpose.  A   compressed  data packet  is an  envelope   which safely
  751.    squeezes its contents into a small space.
  752.  
  753.    Definition.  A compressed  data  packet is  the concatenation of  the
  754.    following fields:
  755.  
  756.       (a) a packet structure field;
  757.       (b) a byte, giving a compression type;
  758.       (c) a byte string of compressed data.
  759.  
  760.    Byte  string  (c) is a  packet  which  may be decompressed  using the
  761.    algorithm  identified in  byte (b).   Typically,  the  data  that are
  762.    compressed consist of  a literal  data  packet or  a signature packet
  763.    concatenated to a literal data packet.
  764.  
  765.    A  compression type  selects  a  compression  algorithm  for use   in
  766.    compressed  data  packets.   The   following compression  numbers are
  767.    currently defined.
  768.  
  769.       1 - ZIP
  770.       255 - experimental
  771.  
  772.    More  compression    numbers may   be defined  in    the  future.  An
  773.    implementation need not support every   MD number.  The   implementor
  774.    must  document   the     compression   numbers  understood   by    an
  775.    implementation.
  776.  
  777. 6.4 Conventional-key-encrypted data packets
  778.  
  779.    Purpose.  A    conventional-key-encrypted data packet   is  formed by
  780.    encrypting a block  of data with  a conventional encryption algorithm
  781.    using a one-time session key. Typically, the block to be encrypted is
  782.    a compressed data packet.
  783.  
  784.    Definition.    A   conventional-key-encrypted data  packet    is  the
  785.    concatenation of the following fields:
  786.  
  787.       (a) a packet structure field;
  788.       (b) a byte string of encrypted data.
  789.  
  790.    The plaintext or compressed plaintext that is encrypted to form field
  791.    (b) is   first prepended with  64 bits  of random  data  plus 16 "key
  792.    check"  bits.  The  random prefix  serves  to  start off  the  cipher
  793.    feedback  chaining process   with  64 bits of   random material; this
  794.    serves    the same function as an    initialization vector (IV) for a
  795.    cipher-block-chaining encryption   scheme.  The key  check  prefix is
  796.    equal to the last 16 bits of the random  prefix. During decryption, a
  797.    comparison is made to see  if the 7th  and 8th byte of the  decrypted
  798.    material match the 9th  and 10th bytes.  If so, then the conventional
  799.    session key used for decryption is assumed to be correct.
  800.  
  801. 6.4.1 Conventional-encryption type byte
  802.  
  803.    Purpose.  The conventional-encryption type byte  is used to determine
  804.    what conventional encryption algorithm is in use.  The algorithm type
  805.    byte will also  define how long the  conventional encryption key  is,
  806.    based upon the algorithm in use.
  807.  
  808.    Definition.  A conventional-encryption   type byte is a   single byte
  809.    which  defines   the algorithm  in  use.   It   is possible that  the
  810.    algorithm in use may  require further definition, such as key-length.
  811.    It  is up to the implementor  to document the supported key-length in
  812.    such a situation.
  813.  
  814.       1 - IDEA (16-byte key)
  815.       255 - experimental
  816.  
  817. 6.5 Public-key-encrypted packets
  818.  
  819.    Purpose.  The public-key-encrypted  packet   is the format   for  the
  820.    session key component of a message. The  purpose of this packet is to
  821.    convey the one-time  session key used to  encrypt the message  to the
  822.    recipient in a secure manner. This  is done by encrypting the session
  823.    key with the  recipient's public key, so that  only the recipient can
  824.    recover the session key.
  825.  
  826.    Definition.   A public-key-encrypted packet, version   2 or 3, is the
  827.    concatenation of the following fields:
  828.  
  829.       (a) a packet structure field;
  830.       (b) a byte, giving the version number, 2 or 3;
  831.       (c) a number ID field, giving the ID of a key;
  832.       (d) a byte, giving a PKC number;
  833.       (e) a byte string of encrypted data (DEK).
  834.  
  835.    Byte  string (e) represents  the value of  the session key, encrypted
  836.    using the reader's public key K, under the cryptosystem identified in
  837.    byte (d).
  838.  
  839.    The value of field (c) is the ID of K.
  840.  
  841.    Note that the packet does not actually  identify K: two keys may have
  842.    the  same ID, by chance or  by malice.  Normally   it will be obvious
  843.    from the context which   key K was used  to  create the packet.   But
  844.    sometimes it is not obvious.  In this case field  (c) is useful.  If,
  845.    for example,  a  reader has   created  several keys,  and receives  a
  846.    message, then he should attempt to  decrypt the message only with the
  847.    key whose ID matches the value of field  (c).  If he has accidentally
  848.    generated two keys with the same ID,  then he must attempt to decrypt
  849.    the message with both keys, but this case is highly unlikely to occur
  850.    by chance.
  851.  
  852. 6.5.1 RSA-encrypted data encryption key (DEK)
  853.  
  854.    The Data Encryption Key (DEK) is  a multiprecision field which stores
  855.    an RSA encrypted byte string.  The byte string  is a PKCS encoding of
  856.    the secret key used the encrypt the message,  with random padding for
  857.    each Public-Key encrypted packet.
  858.  
  859.    PGP version  2.3 and later   encode the DEK   into an  MPI using  the
  860.    following format:
  861.  
  862.      MSB                       .   .   .                       LSB
  863.       0   2   RND(n bytes)   0  ALG(1 byte)  DEK(k bytes)  CSUM(2 bytes)
  864.  
  865.    ALG refers to the algorithm byte for the secret key algorithm used to
  866.    encrypt the data packet.  The DEK is  the actual Data Encryption Key,
  867.    and  its size is dependent upon  the encryption  algorithm defined by
  868.    ALG.  For the IDEA encryption  algorithm, type byte 1,  the DEK is 16
  869.    bytes long.  CSUM is a 16-bit checksum of  the DEK, used to determine
  870.    that  the correct Private  key was used  to decrypt this packet.  The
  871.    checksum is computed by the 16-bit sum of the  bytes in the DEK.  RND
  872.    is random padding to  expand  the byte to  fill  the size of  the RSA
  873.    Public Key that is used to encrypt the whole byte.
  874.  
  875. 6.6 Public Key Packet
  876.  
  877.    Purpose.  A public key packet defines an RSA public key.
  878.  
  879.    Definition.     A public  key  packet  is   the concatenation of  the
  880.    following fields:
  881.  
  882.       (a) packet structure field (2 or 3 bytes);
  883.       (b) version number = 2 or 3 (1 byte);;
  884.       (c) time stamp of key creation (4 bytes);
  885.       (d) validity period in days (0 means forever) (2 bytes);
  886.       (e) public-key-cryptosystem (PKC) type (1 byte);
  887.       (f) MPI of RSA public modulus n;
  888.       (g) MPI of RSA public encryption exponent e.
  889.  
  890.     The validity period is always set to 0.
  891.  
  892. 6.7 User ID Packet
  893.  
  894.    Purpose.  A user ID packet identifies a user and is associated with a
  895.    public or private key.
  896.  
  897.    Definition.  A  user ID packet is the  concatenation of the following
  898.    fields:
  899.  
  900.       (a) packet structure field (2 bytes);
  901.       (b) User ID string.
  902.  
  903.    The  User ID string may be  any string of printable ASCII characters.
  904.    However, since the purpose of this packet is  to uniquely identify an
  905.    individual, the  usual practice is for  the User ID string to consist
  906.    of the user's name followed by  an e-mail address  for that user, the
  907.    latter enclosed in angle brackets.
  908.  
  909. 7. Transferable Public Keys
  910.  
  911.    Public keys may transferred between PGP users. The essential elements
  912.    of a transferable public key are
  913.  
  914.       (a) One public key packet;
  915.       (b) One or more user ID packets;
  916.       (c) Zero or more signature packets
  917.  
  918.    The public key  packet occurs first.  Each of  the following user  ID
  919.    packets provides the identity  of the owner  of this public  key.  If
  920.    there are multiple  user   ID packets, this corresponds  to  multiple
  921.    means of identifying the same unique  individual user; for example, a
  922.    user may enjoy the use of more than one e-mail address, and construct
  923.    a user  ID packet for each one.   Immediately following each  user ID
  924.    packet,  there are zero or  more   signature packets. Each  signature
  925.    packet is calculated on the immediately  preceding user ID packet and
  926.    the initial public key packet.   The signature serves to certify  the
  927.    corresponding public  key and  user   ID.  In effect,  the signer  is
  928.    testifying to  his or her belief that  this public key belongs to the
  929.    user identified by this user ID.
  930.  
  931. 8. Acknowledgments
  932.  
  933.    Philip Zimmermann is  the creator of  PGP 1.0, which is the precursor
  934.    of PGP   2.x.   Major parts  of  later   versions of PGP    have been
  935.    implemented  by  an  international collaborative effort   involving a
  936.    large  number  of contributors, under the   design guidance of Philip
  937.    Zimmermann.
  938.  
  939. 9. Security Considerations
  940.  
  941.     Security issues are discussed throughout this memo.
  942.  
  943. 10. Authors' Addresses
  944.  
  945.    Derek Atkins
  946.    12 Rindge Ave. #1R
  947.    Cambridge, MA
  948.    Phone: +1 617 868-4469
  949.    EMail: warlord@MIT.EDU
  950.  
  951.    William Stallings
  952.    Comp-Comm Consulting
  953.    P. O. Box 2405
  954.    Brewster, MA 02631
  955.    EMail: stallings@ACM.org
  956.  
  957.    Philip Zimmermann
  958.    Boulder Software Engineering
  959.    3021 Eleventh Street
  960.    Boulder, Colorado 80304  USA
  961.    Phone: +1-303-541-0140
  962.    EMail: prz@acm.org
  963.  
  964.  
  965.  
  966.  
  967.  
  968.