Subject: Re: PGP Message Exchange Formats Internet Draft
From: W Lewis <[email-masked]>
To: [email-masked]
Cc: jude shabry <[email-masked]>
Date: Thu, 31 Jul 1997 01:50:21 -0700 (PDT)

Some initial comments on the draft, mostly nits.

- The expanding integer formats used by new-style CTBs and by version-4
  signature subpacket fields should probably be given names and added to
  the catalog of types in section 3. The two formats are slightly
  different; what is the reasoning behind this?

- Section 2.4.1 does not fully describe the CRC used with ascii armor. 

- Section 7 does not mention the possibility of a subkey packet occurring
  in a transferable public key... I assume this is just an oversight.

- The draft does not describe how session keys and hash digests are
  encoded into MPIs for use in public-key algorithms. IMHO this is the
  most glaring omission.

Wim Lewis / [email-masked]

From: jude shabry <[email-masked]>
To: [email-masked], [email-masked]
Subject: PGP Message Exchange Formats Internet Draft
Reply-to: jude shabry <[email-masked]>
Date: Wed, 30 Jul 1997 17:02:34 -0700
Sender: [email-masked]

INTERNET-DRAFT						Gail Haspert
Security						PGP, Inc.
Expires in six months					Editor             
							July 30 1997

                   PGP Message Exchange Formats
                  <draft-ietf-pgp-formats00.txt>

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time.  It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

In order to release information about PGP 5.x prior to the Birds
of a Feather discussion at the 39th IETF Conference in Munich, we
wanted people to have the opportunity to review the current
specification of the published PGP source code. This document is
the cookbook for the source code. Completion of items marked TBD
will be done by end of October, 1997.

Abstract

PGP (Pretty Good Privacy) software uses a combination of public-key
and conventional encryption to provide strong security services
for e-mail, EDI, and data files.  These services include confidentiality,
authorization, authentication and digital signature. This document
specifies the message formats used in version 5.x, fully backward-
compatible with earlier PGP versions.

Since PGP first became available in 1991, it is now the worldwide
de facto standard for securing electronic communications. It has
achieve this success through international availability and the
unique distributed "Web-of-Trust" model to create the current PGP
Public Key Infrastructure for storing and obtaining
'PGP-formatted-certificates.'

PGP Formats - Open PGP BOF							Page 1


Table of Contents

1.    Introduction......................................3
2.    PGP Services......................................3
2.1   Digital signature.................................3
2.2   Confidentiality...................................4
2.3   Compression.......................................4
2.4   Radix-64 conversion...............................4
2.4.1 ASCII Armor Formats...............................5
3.    Data Element Formats..............................6
3.1   Scalar numbers....................................6
3.2   Multi-Precision Integers..........................6
3.3   Strings...........................................7
3.4   Time fields.......................................7
4.    Packets...........................................7
4.1   Overview..........................................7
4.2   Packet Headers....................................7
4.3   Packet Tags.......................................8
5.    Packet Types......................................9
5.1   Encrypted Session Key Packets.....................9
5.2   Conventional Encrypted Session-Key Packets........9
5.3   One-Pass Signature Packets........................9
5.4   Symmetrically Encrypted Data Packet..............10
5.5   Compressed Data Packet...........................10
5.6   Literal Data Packet..............................10
5.7   Obsolete Literal Packet..........................11
5.8   Key Material Packet..............................11
5.9   User-Name Packet.................................12
5.10  Signature Packets................................12
6.    Constants........................................13
6.1   Public Key Algorithms............................13
6.2   Symmetric Key Algorithms.........................13
6.3   Compression Algorithms...........................13
6.4   Hash Algorithms..................................13
7.    Transferable Public Keys.........................13
8.    PGP 5.0 Enhanced Key Formats.....................14
8.1   Key Structures...................................14
8.2   Public Key Certificate Packet Structure..........15
8.3   Signature Packet Structure.......................16
8.4   Diffie-Hellman/DSS Key IDs and Fingerprints......18
8.5   New Algorithm and Signature Classification Types.18
8.6   Interoperability.................................18
8.7   Future Formats...................................19

PGP Formats - Open PGP BOF							Page 2


1. Introduction

This document provides information on the message-exchange packet
formats used by PGP to provide encryption, decryption, and signing
functions. It builds on the foundation provided RFC 1991, PGP
Message Exchange Formats and RFC 2015, MIME Security with Pretty
Good Privacy (PGP). PGP and is the collective work of a number of
contributing authors. Those authors include, (alphabetical order):
Derek Atkins, Charles Breed, Jon Callas, Dave Del Torto, Marc
Dyksterhouse, Gail Haspert, Gene Hoffman, Raph Levine, Colin Plumb,
Will Price, William Stallings, Mark Weaver, and Philip R. Zimmermann.

A special thank you goes to Paul Hoffman for hosting and managing
the mail lists for PGP.PGP (Pretty Good Privacy) uses a combination
of public-key and conventional encryption to provide security
services for electronic mail messages, electronic data interchange
(EDI) and data files.  These services include confidentiality and
digital signature.  PGP is widely used throughout the global computer
community.  This document describes the format of "PGP files",
i.e., messages that have been encrypted and/or signed 1991. Subsequent
versions have been designed and implemented by a combination of
volunteers and PGP, Inc. in a collaborative effort under the design
guidance of Philip Zimmermann.  PGP and Pretty Good Privacy are
trademarks of Pretty Good Privacy, Inc.

2. PGP Services

PGP provides four services related to the format of messages and data files: 
      -digital signature
      -encryption 
      -compression
      -radix-64 conversion

2.1 Digital signature

   The digital signature uses a hash code or
   message digest algorithm, and a public-key encryption algorithm. The
   sequence is as follows:

     1. The sender creates a message
     2. The sending PGP generates a hash code of the message
     3. The sending PGP encrypts the hash code using the sender's                                                     
        private key.
     4. The encrypted hash code is prepended to the message
     5. The receiving PGP decrypts the hash code using the sender's    
        public key.
     6. The receiving PGP generates a new hash code for the received
        message and compares it to the decrypted hash code. If the two
        match, the message is accepted as authentic.
PGP Formats - Open PGP BOF							Page 3


2.2 Confidentiality

   PGP provides confidentiality by encrypting messages to be transmitted
   or data files to be stored locally using conventional encryption. In
   PGP, each conventional key is used only once. That is, a new key is
   generated as a random 128-bit number for each message. Since it is to
   be used only once, the session key is bound to the message and
   transmitted with it.  To protect the key, it is encrypted with the
   receiver's public key. The sequence is as follows:

     1. The sender creates a message.
     2. The sending PGP generates a random number to be used as a 
        session key for this message only.
     3. The sending PGP encrypts the message using the session key.
     4. The session key is encrypted using the recipient's public key 
        and is prepended to the encrypted message.
     5. The receiving PGP decrypts the session key using the recipient's
        private key.
     6. The receiving PGP decrypts the message using the session key.

   Both digital signature and confidentiality services may be applied to
   the same message. First, a signature is generated for the message and
   prepended to the message.  Then, the message plus signature is
   encrypted using a conventional session key. Finally, the session key
   is encrypted using public-key encryption and prepended to the
   encrypted block.

2.3 Compression

   As a default, PGP compresses the message after applying the signature
   but before encryption.

2.4 Radix-64 conversion

   When using PGP to sign clear text, or to encrypt and/or sign a 
   message a resulting encrypted block must either accompany or travel 
   in place of the message block. Thus, part or all of the resulting        
   block consists of a stream of arbitrary octets. Many electronic mail   
   systems only permit the use of blocks consisting of ASCII text. To  
   accommodate this restriction, PGP provides the service of converting    
   the raw 8-bit binary octet stream to a stream of printable ASCII   
   characters, called Radix-64 encoding or ASCII Armor.

   Similar to MIME encoding, the process of Radix-64 encoding an 8-bit   
   binary stream of data is as follows. Every three subsequent 8 bit   
   binary octets are mapped into four subsequent 6-bit ASCII characters.  
   Radix-64 encoding also appends a CRC to detect transmission errors.   
   This radix-64 conversion, is a wrapper around the binary PGP   
   messages, and is used to protect the binary messages during 
   transmission over non-binary channels, such as Internet Email.

   The following table defines the mapping.  The characters used are the
   upper- and lower-case letters, the digits 0 through 9, and the
   characters + and /.  The carriage-return and linefeed characters
   aren't used in the conversion, nor is the tab or any other character
   that might be altered by the mail system. The result is a text file
   that is "immune" to the modifications inflicted by mail systems.
PGP Formats - Open PGP BOF							Page 4


   To encode an arbitrary 3 octets, separate the bit stream logically    
   into four 6-bit groups, calculate the decimal value of the 6-bit 
   group, and replace it with the corresponding character from the table 
   below. Decoding is the exact opposite operation.

                     
                   6-bit Value Mapped to Character Encoding

   6-bit character   6-bit character   6-bit character   6-bit character
   value encoding  value  encoding    value   encoding    value encoding
   0        A        16        Q        32        g        48        w
   1        B        17        R        33        h        49        x
   2        C        18        S        34        i        50        y
   3        D        19        T        35        j        51        z
   4        E        20        U        36        k        52        0
   5        F        21        V        37        l        53        1
   6        G        22        W        38        m        54        2
   7        H        23        X        39        n        55        3
   8        I        24        Y        40        o        56        4
   9        J        25        Z        41        p        57        5
   1        K        26        a        42        q        58        6
   11       L        27        b        43        r        59        7
   12       M        28        c        44        s        60        8
   13       N        29        d        45        t        61        9
   14       O        30        e        46        u        62        +
   15       P        31        f        47        v        63        /
                                                         (pad)       =

	   Hex octet	        0x17	  0x3A      0xA3
Example:   Binary stream      00010111  00111010  10100011
	   Translate to 6bit  000101  110011  101010  100011
	   Decimal		 5      51      42      35
	   Final Character       F       z       q       j

   It is possible to use PGP to convert any arbitrary file to ASCII
   Armor.  When this is done, PGP tries to compress the data before it
   is converted to Radix-64.

2.4.1 ASCII Armor Formats

   When PGP encodes data into ASCII Armor, it puts specific headers
   around the data, so PGP can reconstruct the data at a future time.
   PGP tries to inform the user what kind of data is encoded in the
   ASCII armor through the use of the headers.

   ASCII Armor is created by concatenating the following data:

        - An Armor Headerline, appropriate for the type of data
        - Armor Headers
        - A blank line
        - The ASCII-Armored data
        - An Armor Checksum
        - The Armor Tail, which depends on the Armor Headerline.

PGP Formats - Open PGP BOF							Page 5


   An Armor Headerline is composed by taking the appropriate headerline
   text surrounded by five (5) dashes (-) on either side of the
   headerline text.  The headerline text is chosen based upon the type
   of data that is being encoded in Armor, and how it is being encoded.
   Headerline texts include the following strings:

    BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed files
    BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public keys 
    BEGIN PGP MESSAGE, PART X/Y -- used for multi-part messages, where
                                    the armor is split amongst Y files,
                                    and this is the Xth file out of Y.

   The Armor Headers are pairs of strings that can give the user or the
   receiving PGP message block some information about how to decode or   
   use the message.  The Armor Headers are a part of the armor, not a 
   part of the message, and hence should not be used to convey any    
   important information, since they can be changed in transport.

   The format of an Armor Header is that of a key-value pair.  PGP 
   should consider improperly formatted Armor Headers to be corruption 
   of the ASCII Armor.  Unknown keys should be reported to the user, but 
   PGP should continue to process the message. Currently defined Armor 
   Header Keys include "Version" and "Comment," which define the PGP 
   Version used to encode the message and a user-defined comment.

The Armor Checksum is a 24-bit CRC converted to four characters of 
radix-64 encoding, prepending an equal-sign (=) to the four character code.  
The CRC is computed by using the generator 0x864CFB and an initialization 
of 0xB704CE.  The accumulation is done on the data before it is converted 
to radix-64, rather than on the converted data.  For more information on 
CRC functions, the reader is asked to look at chapter 19 of the book 
"C Programmer's Guide to Serial Communications," by Joe Campbell.

   The Armor Tail is composed in the same manner as the Armor
   Headerline, except the string "BEGIN" is replaced by the string
   "END."

3. Data Element Formats
This section describes the data elements used by PGP.

3.1 Scalar numbers

Scalar numbers are unsigned, and are always stored in big-endian format. 
Thus, the value of a two-octet scalar is ((n[0] << 8) + n[1]). The value 
of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]).

3.2 Multi-Precision Integers

Multi-Precision Integers (also called MPIs) are unsigned integers used to 
hold large integers such as ones used in cryptographic calculations. 

An MPI consists of two pieces: a two-octet scalar that is the length of 
the MPI in bits followed by a string of octets that contain the actual integer. 
These octets form a big-endian number; a big-endian number can be made into an 
MPI by prefixing it with the appropriate length.

PGP Formats - Open PGP BOF							Page 6

Examples:

(all numbers are in hexadecimal)

The string of octets [00 01 01] forms an MPI that has a value of 1. The string 
[00 09 01 ff] forms an MPI with the value of 511.

Additional rules:

The size of an MPI is ((MPI.length + 7) / 8) + 2.

The length field of an MPI describes the length starting from its most 
significant non-zero bit. Thus, the MPI [00 02 01] is not formed correctly.
It should be [00 01 01].

3.3 Strings

A string consists of a one-octet length and then N octets of string data.

3.4 Time fields

A time field is a four-octet number containing the number of seconds 
elapsed since midnight, 1 January 1970 GMT.

4. Packets

This section describes the packets used by PGP.

4.1 Overview

A packet is a chunk of data that has a tag specifying its meaning. A PGP
message, keyring, certificate, and so forth consists of a number of packets. 
Some of those packets may contain other PGP packets (for example, a 
compressed data packet, when uncompressed, contains PGP packets).

Each packet consists of a packet header, followed by the packet body.
The packet header is of variable length.

4.2 Packet Headers

The first octet of the packet header is called the "Cipher Type Byte."
It determines the format of the header. Its high-order bit (0x80) must be set. 
If the next bit (0x40) is set, it is a new format packet. 
If it is clear, then it is an old format packet. New format packets can only be 
decoded by PGP V5.0 or later. Thus, software that needs to be compatible 
with earlier versions of PGP must only use old format packets.

In an old format packet, the packet tag resides in the middle four bits
((ctb & 0x3c) >> 2). The two low order bits (ctb & 0x3) denote the number 
of octets following the CTB that hold the length of the packet body. 
The meaning of the length-type is:

PGP Formats - Open PGP BOF						      Page 7


0 - The packet has a one-octet length. The header is 2 octets long.
1 - The packet has a two-octet length. The header is 3 octets long.
2 - The packet has a four-octet length. The header is 5 octets long.
3 - The packet is of indeterminate length. The header is 1 byte long, 
and the application must determine how long the packet is. If the packet 
is in a file, this means that the packet extends until the end of the file. 
In general, an application should not use indeterminate length packets.

In a new format packet, the low-order six bits (cth & 0x3f) form the packet tag. 
The length of the packet is found in the next one or two octets, thus:

If the next octet is 191 or less, then that is the length of the packet
body. If that octet is between 192 and 223, then the length of the packet 
body is held in the two octets following the CTB with the following formula:

   bodyLen = ((p[1] - 192) * 256) + p[2] + 192;

Note that this yields a maximum packet body length of 8383 octets for this type of 
packet.

If the second octet is 224 or greater (note that 224 is E0 in hexadecimal, or 
11100000 in binary), then the low-order five bits form the length of the 
packet body with the formula:

   bodyLen = 1 << (p[1] & 0x1f);

In English, the packet body length is a power of two. Its maximum length 
is 2**31 octets long. Note that there is no way to form a new-format packet 
that is longer than 8383 octets and not a power of two in length.

Please note that in all of these explanations, the total length of the
packet is the length of the header plus the length of the body.

4.3 Packet Tags

The packet tag denotes what type of packet the body holds. Note that old
format packets can only have tags less than 16, whereas new format packets 
can have tags as great as 63. The defined tags are:

0  -- Reserved. A packet must not have a tag with this value.
1  -- Encrypted Session Key Packet
2  -- Signature Packet
3  -- Conventionally Encrypted Session Key Packet
4  -- One-Pass Signature Packet
5  -- Secret Key Packet
6  -- Public Key Packet
7  -- Secret Subkey Packet
8  -- Compressed Data Packet
9  -- Symmetrically Encrypted Data Packet
10 -- Obsolete Literal Packet
11 -- Literal Data Packet
12 -- Trust Packet
13 -- Name Packet

PGP Formats - Open PGP BOF							Page 8


14 -- Subkey Packet
15 -- Reserved
16 -- Comment Packet

5.0 Packet Types

This section describes some of the more interesting packet types.

5.1 Encrypted Session Key Packets

The encrypted session key packet (tag 1) describes how a message is
encrypted. One or more of these packets precede a Symmetrically 
Encrypted Data Packet, for each PGP key the message is encrypted to. 
The recipient of the message finds a session key that is encrypted 
to their public key, decrypts the session key, and then uses the 
session key to decrypt the message.

The body of this packet consists of:

	- A one-octet number giving the version number of the packet type,
        either 2 or 3. All modern versions of PGP generate type 3   
        packets.
- An eight-octet number that gives the ID of the public key that 
  the session key is encrypted to.
	- A one-octet number giving the public-key algorithm used.
- A string of octets that is the encrypted session key. This 
  string takes up the remainder of the packet, but is not     
  explicitly counted.

5.2 Conventional Encrypted Session-Key Packets

This packet (tag 3) describes a session key that has been encrypted to a
secondary symmetric cipher. This allows a message to be encrypted to a
number of public keys, and also to one or more pass phrases. This packet 
type is new, and is not generated by PGP 2.x or PGP 5.0.

The body of this packet consists of:
	- A one-octet version number. The current version is 4.
	- A one-octet number describing the symmetric algorithm used.
	- A "string-to-key" object. This is described below. It is 2, 10,   
        or 11 octets long.
	- The encrypted session key itself, which is decrypted with the
        string-to-key object.

The string-to-key object has this format:

<To be written in a future draft.>

5.3 One-Pass Signature Packets

This packet (tag 4) is also a new packet type, but may be generated by PGP 
5.0 or later. This in an in-line packet that tells the processing software 
how to compute a signature so that it does not have to read the entire 
message before starting.

PGP Formats - Open PGP BOF							Page 9


The body of this packet consists of:
	- A one-octet version number. The current version is 3.
	- A one-octet signature type. Signature types are described later 
        in this document.
	- A one-octet number describing the hash algorithm used.
	- A one-octet number describing the public key algorithm used.
	- An eight-octet number holding the key ID of the signing key.
	- A one-octet number holding a flag showing if the signature is
        nested. 

5.4 Symmetrically Encrypted Data Packet

This packet (tag 9) contains encrypted data. When it has been decrypted, 
it will typically contain other packets (often literal data packets or 
compressed data packets).

The body of this packet consists of:
	- Eight octets of initialization data. This is arbitrarily chosen
        material that starts the encryption engine. This serves a     
        similar purpose to an initialization vector in a cipher-block-    
        chaining engine. It helps to reduce the chance of information 
        leaks caused by known-plaintext attacks.
- Two octets of data that are used to check the decryption    
        process. The seventh and eighth octets of decrypted data must  
        match these two octets.
	- The remainder of the packet is encrypted data.

5.5 Compressed Data Packet

This packet (tag 8) contains compressed data. Typically, this packet is
found as the contents of an encrypted packet, and contains literal data
packets.

The body of this packet consists of:
	- One octet that gives the algorithm used to compress the packet.
	- The remainder of the packet is compressed data.

5.6 Literal Data Packet

A literal data packet (tag 11) contains the body of a message, data 
that is not to be further interpreted.

The body of this packet consists of:
- A one-octet field that describes how the data is formatted. If    
  it is a 'b' (0x62), then the literal packet contains binary    
  data. If it is 't' (0x74), then it contains text data, and thus  
  may need line ends converted to local form, or other text-mode  
  changes (similar to FTP's text mode). RFC 1991 also defines a 
  'local' mode for machine-local conversions, but does not define 
  it. Curiously, it specifies that the character for it is '1'  
  (numeral one) (which this author thinks might be a typo for 'l'  
  (lower-case ell), and does not give its hexadecimal equivalent.
	- A counted string giving a file name.
- A four-octet number that indicates the modification date of the 
  file, or the creation time of the packet, or a zero that 
  indicates the present time.
	- The remainder of the packet is literal data.

PGP Formats - Open PGP BOF						   Page 10


5.7 Obsolete Literal Packet

An experimental version of PGP used this packet (tag 10) as the literal
packet, but no released version of PGP generated literal packets with this 
tag. With PGP 5.x, this packet has been re-assigned and is reserved for 
use as a marker packet. PGP 5.x makes a packet and puts it at the start of 
a message that mixes RSA and DSS keys, so that PGP 2.x will recognize it 
as a legal PGP message, but one that it is not equipped to decode. You 
may use these packets for similar purposes, and should ignore any you find.

The packet that PGP 5.x uses contains three octets of data, holding the
string "PGP."

5.8 Key Material Packet

A key material packet contains all the information about a public or
private key. There are four variants of this packet type, and two major
versions. Consequently, this section is complex.

A public-key packet (tag 6) starts a series of packets that forms a PGP
certificate (or PGP key, as it is commonly known). A subkey packet (tag 14) 
has exactly the same format, but denotes a subkey. If it had the same tag, 
then it would be impossible to tell a subkey from the start of another certificate.

A secret-key packet (tag 5) contains all the information that is found 
in a public key packet, including the public key material, but also 
includes the secret key material after all the public-key fields. 
As you would expect, a secret subkey packet (tag 7) is the secret-key 
analog of the secret key packet, and has exactly the same format.

There are two versions of key-material packets. Version 3 packets
are PGP 2.6 packets. Version 2 packets are identical in format to
Version 3 packets, but are generated by PGP 2.5 or before. This
document hereafter ignores them. PGP 5.0 introduces version 4
packets, with new fields and semantics.

PGP 5.x uses version 3 packets for RSA keys, and version 4 packets
for DSS/DH keys. Note that there is no reason that there cannot be
a V4 RSA key (except that it is not compatible with previous versions
of PGP), nor a reason that there cannot be a V3 DSS key.

A version 3 packet contains:
	- A one-octet version number.
	- A four-octet number denoting the time that the key was created.
	- A two-octet number denoting the time in days that this key is                  
        valid. If this number is zero, then it does not expire.
	- A one-octet number denoting the public key algorithm of this key
- A series of multi-precision integers comprising the key      
  material.
An RSA key has two MPIs: the RSA public modulus (n), followed by the 
public exponent (e).

A Diffie-Hellman key has three MPIs: the prime (p), the generator (g), 
and the public key (k).

A DSS key has four MPIs: the prime (p), the group order (o),
 the generator(g), and the public key (k).
PGP Formats - Open PGP BOF						Page 11


The fingerprint of the key is formed by hashing the body (but not the
two-octet length) of the MPIs that form the key material with MD5.

The eight-octet key ID of the key is formed by taking the low 64 bits 
of the public modulus of an RSA key.

Note that no released version of PGP has created a V3 key with any 
other public key algorithm other than RSA. PGP 5 still generates 
its RSA keys in V3 format to ensure interoperability with V2.x.

Since the release of PGP 2.6, there have been a number of improvements
desired in the key format. For example, making the key id be a function 
of the public modulus makes it easy for a person to purposely create a 
key that has the same key id as some existing key. Similarly, 
MD5 is no longer the preferred hash algorithm, and not hashing the 
length of an MPI with its body increases the chances of a fingerprint 
collision.

The version four packet format is similar to the V3 format except for the 
following changes:
	- There is no validity period field.
	- The fingerprint is constructed by taking the SHA-1 hash of                                
        <To be written in later draft>.
	- The key ID is the low 64 bits of the fingerprint.
        <Placeholder for Secret key extensions in a later draft.>

5.9 User-Name Packet

A user-name packet is a counted string with a one-octet length. By
convention, it is an RFC 822 mail name, but there are no restrictions on its content.

5.10 Signature Packets

A signature packet describes a binding between some public key and some
data. The most common signatures are a signature of a file or a block of text, 
and a signature that is a certification of a user name. There are a number of 
meanings of a signature, which are specified in a signature-type octet in 
any given signature. These meanings are:
	- 0x00: Signature of a binary document. Typically, this means the
        signer owns it, created it, or certifies that it has not been     
        modified.
	- 0x01: Signature of a canonical text document. Typically, this
        means the signer owns it, created it, or certifies that it has    
        not been modified.
	- 0x10: The generic certification of a user name and public-key
        packet. The issuer of this certification does not make any      
        particular assertion as to how well the certifier has checked 
        that the owner of the key is in fact the person described by  
        the user name. Note that all PGP "key signatures" are this type   
        of certification.
- 0x11: This is a persona certification of a user name and 
        public-key packet. It means that the issuer of this     
        certification has not done any verification of the claim that   
        the owner of this key is the user name specified. Note that no     
        released version of PGP has generated this type of 
        certification.
PGP Formats - Open PGP BOF						Page 12


- 0x12: This is the casual certification of a user name and 
  public-key packet. It means that the issuer of this   
  certification has done some casual verification of the claim of 
  identity. Note that no version of PGP has generated this type   
  of certification, nor is there any definition of what 
  constitutes a casual certification.
- 0x13: This is the positive certification of a user name and 
  public-key packet. It means that the issuer of this   
  certification has done substantial verification of the claim of    
  identity. Note that no version of PGP has generated this type  
  of certification, nor is there any definition of what 
  constitutes a positive certification. Please also note that the 
  vagueness of these certification systems is not a flaw, but a 
  feature of the system. Because PGP places final authority for 
  validity upon the receiver of a certification, it may be that 
  one authority's casual certification might be more rigorous 
  than some other authority's positive certification.

	  SigSubkeyCert	= 0x18,
	  SigKRev		= 0x20,
	  SigSubkeyRev	= 0x28,
	  SigKSRev		= 0x30,
	  SigTimeStamp	= 0x40

6. Constants

This section describes the constants used in PGP Version 5.x.

6.1 Public Key Algorithms

1	-	RSA
16	-	Diffie-Helman, El Gamal variant
17	-	DSS (Digital Signature Algorithm)

6.2 Symmetric Key Algorithms

0	-	Plaintext
1	-	IDEA
2	-	Triple-DES (DES-EDE, 168 bit key)
3	-	CAST5 (128 bit key)

6.3 Compression Algorithms

0	-	Uncompressed
1	-	ZIP

6.4 Hash Algorithms

1	-	MD5
2	-	SHA-1
?	-	RIPE-MD/160

7. Transferable Public Keys

   Public keys may transferred between PGP users. The essential elements
   of a transferable public key are:

PGP Formats - Open PGP BOF					     	Page 13 


      (a) One public-key packet
      (b) One or more user-ID packets
      (c) Zero or more signature packets

   The public-key packet occurs first.  Each of the following user ID
   packets provides the identity of the owner of this public key.  If
   there are multiple user-ID packets, this corresponds to multiple
   means of identifying the same unique individual user; for example, a
   user may enjoy the use of more than one e-mail address, and construct
   a user-ID packet for each one.  Immediately following each user-ID
   packet, there are zero or more signature packets. Each signature
   packet is calculated on the immediately preceding user-ID packet and
   the initial public key packet.  The signature serves to certify the
   corresponding public key and user ID.  In effect, the signer is
   testifying to his or her belief that this public key belongs to the
   user identified by this user ID.

8. PGP 5.0 Enhanced Key Formats

With PGP 5.0, a more flexible PGP key format was introduced.  The 
new key format allows for two new features.  One is the ability 
to support a key that has one public key to do authentication and 
a second to do encryption.  The other new feature is the ability 
to easily expand the signature packets.

Currently, both authentication and encryption are done using the
RSA public key cryptosystem.  The RSA algorithm uses a single
public/private key pair to perform both operations.  The existing
PGP key format only supports algorithms that digitally sign and
encrypt with a single key.  The enhanced key format supports
algorithms that can use a different key pair for each operation.

The first example of this new flexibility is PGP 5.0's support of 
keys that use NIST's Digital Signature Standard (DSS) for digital 
signatures and the ElGamal variation of Diffie-Hellman for 
encryption and decryption.  PGP 5.0 continues to support both the 
RSA algorithm and the existing PGP key format when used with RSA.

The new signature packet (version 4) includes subpackets to easily
add new attributes to a signature.  Further, two types of
subpackets exist; a group of subpackets that is included in the
hash used by the signature and a group that is not.  The subpackets
can be either attributes of the signature packet, or they can be an
assertion by the signer about the key being signed.

Currently, this new format is only generated for signatures on
Diffie-Hellman/DSS keys.  This prevents any backward compatibility 
problems since all RSA keys still use version 3 signatures and all 
software that supports Diffie-Hellman/DSS also supports the new 
signature packets.

8.1 Key Structures

The format of an existing PGP key using RSA is as follows.  Entries
in square brackets are optional and ellipses indicate repetition.

PGP Formats - Open PGP BOF						Page 14


    RSA Public Key
       [Revocation Self Signature]
        UserID [Signature ...]
       [UserID [Signature ...] ...]

Each signature certifies the RSA public key and the preceding UserID.
The RSA public key can have many UserIDs and each UserID can have
many signatures.

The format of the new PGP key type that requires two public keys is
very similar except that the second key is added to the end as a
'subkey' of the primary key.

    Primary-Key
       [Revocation Self Signature]
        UserID [Signature ...]
       [UserID [Signature ...] ...]
       [Subkey Primary-Key-Signature]

The subkey always has a single signature after it that is issued
using the primary key to tie the two keys together.  The new format
can use either the new signature packets or the existing signature
packets.

In a Diffie-Hellman/DSS key, the DSS public key is the primary key, the
Diffie-Hellman public key is the subkey, and either version 3 or 4 of 
the signature packet can be used.

8.2 Public Key Certificate Packet Structure 

To accommodate the addition of the subkey construction, a new
version of the public-key-certificate packet was created.  Packets
with a version of '3' are still created for PGP keys that use RSA
public keys.  For specifics on version 3 packets, see RFC 1991.
The terms and formatting used here are consistent with that RFC.

A Cipher Type Byte (CTB) with bits 5-2 of 0110 indicates a primary
public-key-certificate packet.  This can be either an existing RSA
key with a packet version of 3 or a DSS key with a version of 4.

A new packet type is now defined for the subkey.  The CTB of the
subkey packet has bits 5-2 of 1110.  Notice that this used to
indicate a comment packet.  These packet-type bits were selected
because no previous version of PGP ever emitted comment packets but
they did properly ignore them.  This provides some backwards
compatibility with existing PGP implementations.

Below are the complete definitions for the primary and subkey public
key packets.  Support for RSA and Diffie-Hellman/DSS keys is described.

RSA Public Key Certificate Packet ("old format")

    a) packet structure field with CTB bits 5-2 = 0110 (2 or 3 bytes);
    b) version number = 3 (1 byte);
    c) time stamp of key creation (4 bytes);
    d) validity period in days (0 means forever) (2 bytes);
PGP Formats - Open PGP BOF							Page 15


    e) algorithm (1 byte):
          1 = RSA,
    f) Algorithm specific fields.

    Algorithm Specific Fields for RSA keys:
    f.1) multiprecision integer (MPI) of RSA public modulus n;
    f.2) MPI of RSA public encryption exponent e.

New Public Key Certificate Packet

    a) packet structure field with (2 or 3 bytes):
         Bits 5-2 of CTB = 0110 means primary key packet,
         Bits 5-2 of CTB = 1110 means subkey packet;
    b) version number = 4 (1 byte);
    c) time stamp of key creation (4 bytes);
    e) algorithm (1 byte):
          1 = RSA (not presently generated),
         16 = Diffie-Hellman,
         17 = DSS;
    f) Algorithm specific fields.

    Algorithm Specific Fields for DSS keys:
    f.1) MPI of DSS prime p;
    f.2) MPI of DSS group order q (q is a prime divisor of p-1);
    f.3) MPI of DSS group generator g;
    f.4) MPI of DSS public key value y (= g**x where x is secret).

    Algorithm Specific Fields for Diffie-Hellman keys:
    f.1) MPI of Diffie-Hellman prime p;
    f.2) MPI of Diffie-Hellman group generator g;
    f.3) MPI of Diffie-Hellman public key value y (= g**x where x 
	     is secret).

8.3 Signature Packet Structure

Version 4 of the signature packet adds the concept of hashed and
non-hashed subpackets.  Since this version is not recognized by
previous versions of PGP, it is currently only being generated in
conjunction with version 4 public-key-certificate packets (i.e.,
Diffie-Hellman/DSS PGP keys).

NOTE: The order and contents of the data that is hashed in a 
version 4 signature packet needs further detail.

Here is the specification of a version 4 signature packet:

    a) packet structure field with CTB with bits 5-2 = 0010
         (2 or 3 bytes);
    b) version number = 4 (1 byte);
    c) signature classification (hashed) (1 byte);
    d) public key algorithm (hashed) (1 byte):
          1 = RSA (not presently generated),
         16 = Diffie-Hellman,
         17 = DSS;
PGP Formats - Open PGP BOF							Page 16


    e) hash algorithm (hashed) (1 byte):
          1 = MD5,
          2 = SHA;
    f) length of hashed subpacket data (hashed) (2 bytes);
    g) hashed subpacket data (hashed) (f bytes):
          - signature creation time,
          - key expiration time,
          - preferred symmetric encryption algorithms;
    h) length of non-hashed subpacket data (2 bytes);
    i) non-hashed subpacket data (h bytes):
          - signer key ID;
    j) first 2 bytes of message digest (16 bit checksum);
    k) MPI of public key signature
    l) MPI #2 of public key signature (for DSS signatures only)

Fields g) and i) consist of signature subpackets.  Below is the
specification of signature subpackets.  The list of subpackets may grow
in the future.  Unrecognized packets should be skipped unless marked as
critical.

    a) subpacket length (1 or 2 bytes):
         Length includes the type byte but not this length,
         1st byte <  192, then length is one byte,
         1st byte >= 192, then length is 2 bytes and equal to
            (1st byte & 0x3F) * 256 + (2nd byte) + 192;
    b) subpacket type (1 byte):
         If bit 7 is set, subpacket understanding is critical,
          2 = signature creation time,
          9 = key expiration time,
         11 = preferred symmetric algorithms,
         16 = key ID of signer,
    c) subpacket specific data (b bytes);

Several types of subpackets are currently defined.  Some subpackets
apply to the signature itself and some are attributes of the key.

    Signature creation time (4 byte time field) (Hashed)
        The time the signature was made.  Always included with new
        signatures.

    Key ID of signer (8 byte key ID) (Non-hashed)
        The PGP key ID of the person signing the key.

    Key expiration time (4 byte time field) (Hashed)
        The validity period of the key.  This is the number of seconds
        after the key creation time that the key expires.  If this is
        not present or has a value of zero, the key never expires.
        This is found on a self-signature.

    Preferred symmetric algorithms (array of 1 byte) (Hashed)
        Symmetric algorithm numbers that indicate which algorithms
        the key holder prefers to use.  This is an ordered list of
        bytes with the most preferred listed first.  It should be
        assumed that only algorithms listed are supported by the
        recipient's software.  Algorithm numbers are provided below.
        If this subpacket is not included, IDEA is assumed.  This is
        found on a self-signature.
PGP Formats - Open PGP BOF							Page 17


8.4  Diffie-Hellman/DSS Key IDs and Fingerprints

A Diffie-Hellman/DSS fingerprint is the 160-bit SHA-1 hash of a few 
header bytes followed by the entire public key packet starting with 
the version field.  The key ID is either the low order 32 bits or 
64 bits of the fingerprint.  Here are the fields of the hash 
material:

    a.1) 0x99 (1 byte)
    a.2) high order length byte of (b)-(f) (1 byte)
    a.3) low order length byte of (b)-(f) (1 byte)
    b) version number = 4 (1 byte);
    c) time stamp of key creation (4 bytes);
    e) algorithm (1 byte):
         17 = DSS;
    f) Algorithm specific fields.

    Algorithm Specific Fields for DSS keys:
    f.1) MPI of DSS prime p;
    f.2) MPI of DSS group order q (q is a prime divisor of p-1);
    f.3) MPI of DSS group generator g;
    f.4) MPI of DSS public key value y (= g**x where x is secret).

8.5 New Algorithm and Signature Classification Types 

Several new algorithm types were added to support Diffie-Hellman/DSS 
keys.  Below are the new public-key-encryption algorithm numbers:

     Diffie-Hellman     16
     DSS                17

DSS uses a different message digest algorithm, the Secure Hash
Algorithm (SHA-1).  This is the only message-digest-algorithm number
added:

     SHA-1               2
 
Below are the preferred symmetric algorithm numbers:

     IDEA                1 (not new)
     Triple DES          2
     CAST5               3

A single new signature classification was added for the signature 
packet that ties the subkey to the primary key.

     Subkey Signature   24

8.6 Interoperability 

Starting with PGP 5.0, PGP's products support this new format and 
the sending and receiving of mail protected using either RSA or 
Diffie-Hellman/DSS keys.  A keyring can contain both types of
keys and you can send a piece of mail to people with either key type.

PGP Formats - Open PGP BOF							Page 18


Users of previous versions of PGP cannot accept keys that use 
Diffie-Hellman/DSS.  PGP is releasing patches for most versions that
provide some support for Diffie-Hellman/DSS keys.  The patches allow 
prior versions to interoperate better with Diffie-Hellman/DSS keys.  
The patched versions still do not support generating Diffie-Hellman/DSS 
keys or usingthem to send or receive encrypted mail.

8.7 Future Formats 

Additional information on PGP formats is being provided to the public in
order for others to build compatible or complimentary systems that
support PGP.  

PGP Formats - Open PGP BOF							Page 19

From: Tay Beng Kuan Steven <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: digest mode
Date: Fri, 25 Jul 1997 22:16:40 +0800
Sender: [email-masked]

Hi all,

	How do I receive in digest mode.
--------
Tay Beng Kuan Steven  [ ICQ: 1423100 ]
Url : Http://web.singnet.com.sg/~taylc/
Email : [email-masked]  /  [email-masked]
PGP Key-ID 4036268D Send message to me with subject "send pgp" for key
Key fingerprint = 65 6F 50 EB 09 7B C7 83  96 7C F9 82 5F E5 5F F6

Date: Wed, 23 Jul 1997 15:24:13 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: Subject line
Sender: [email-masked]

Steve,

Encryption of SUBJECT LINES: can be useful, this was discussed on the PGP/MIME mail list. To the best of my knowledge, there was no definitive conclusion. I'll keep track of these requests. MUA should allow user's to sort mail and view subject lines without requiring decryption, or automating the process. User's should be smart enough not to make subject_lines too descriptive, however, any subject adds to traffic analysis.

cb

At 02:27 PM 7/23/97 -0700, Steve Schear wrote:
>It is obvious that descriptive email Subject lines can offer a potential
>security leak, aiding traffic analysis and eavesdropping.  Therefore
>cautious crypto emailers either leave this line blank, use a
>non-descriptive header line, etc.
>
>Might it be possible to add a feature to the PGP cyphertext body so email
>plug-ins could save the Subject line in the cyphertext, blank the email
>field during transit and restore its value after decryption at the
>receiptient end?
>
>--Steve
>
>
>
>

From: "William H. Geiger III" <[email-masked]>
Reply-to: "William H. Geiger III" <[email-masked]>
Date: Wed, 23 Jul 97 16:53:56 -0400
To: Steve Schear <[email-masked]>
Cc: [email-masked]
Subject: Re: Subject line
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <v03102801affc26f9a959@[10.0.2.15]>, on 07/23/97 
   at 04:27 PM, Steve Schear <[email-masked]> said:

>It is obvious that descriptive email Subject lines can offer a potential
>security leak, aiding traffic analysis and eavesdropping.  Therefore
>cautious crypto emailers either leave this line blank, use a
>non-descriptive header line, etc.

>Might it be possible to add a feature to the PGP cyphertext body so email
>plug-ins could save the Subject line in the cyphertext, blank the email
>field during transit and restore its value after decryption at the
>receiptient end?

This can be doen quite easily by the client software as follows:

Create message
sign message
encrypt message with final recipiant's public key
Create new message where old message is a multipart/encrypted attachment.

[New Header multipart/mixed]

  [message/rfc822]

    [application/pgp-encrypted]
    [application/octet-stream]

The only information in the header of the new message is that which is
need to deliver the message. After this new message has been created one
does the proper encryption wrapping for the remailer chain.

IMHO this all should be handled on the client end and really shouldn't
involve PGP at all.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Wed, 23 Jul 1997 14:31:04 -0700
To: Wolfgang Ley <[email-masked]>, [email-masked]
From: Steve Schear <[email-masked]>
Subject: Re: Key search
Sender: [email-masked]

Wolfgang Ley <[email-masked]>, wrote:
>I don't know why this should be useful. In real life this won't help
>you because if you trust A's key and want to find a path to D then
>the only way would be "A has signed D". In all other case you have
>to trust the keys on the path (in your example B and C) to act as an
>introducer.

Phil mentioned, at the June 14th Cypherpunks meeting, that an upcoming
version of PGP will support introducers.

--Steve

Date: Wed, 23 Jul 1997 14:27:25 -0700
To: [email-masked]
From: Steve Schear <[email-masked]>
Subject: Subject line
Sender: [email-masked]

It is obvious that descriptive email Subject lines can offer a potential
security leak, aiding traffic analysis and eavesdropping.  Therefore
cautious crypto emailers either leave this line blank, use a
non-descriptive header line, etc.

Might it be possible to add a feature to the PGP cyphertext body so email
plug-ins could save the Subject line in the cyphertext, blank the email
field during transit and restore its value after decryption at the
receiptient end?

--Steve

Date: Wed, 23 Jul 1997 16:35:28 -0400
To: Charles Breed <[email-masked]>
From: Ben Cox <[email-masked]>
Subject: Re: Key search
Cc: [email-masked]
Sender: [email-masked]

--PGPplugin/Eudora-5.0-42029812327-1342444942
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Charles Breed <[email-masked]> writes:
>You might want to check out 	http://akpublic.research.att.com/~reiter/PathServer/
>written by Mike Reiter and Stuart Stubblebine

Thanks; this looks very similar to what I have.

>This list will be used for discussing new features and functionality to be
>in the next, open, standards-track pgp spec, hopefully from the IETF
>working group called open-pgp.

...and, to quote the charter:

>- enhanced methods for public pgp key / certificate exchange 
>  (search, retrieval, revocation)
    ^^^^^^^^^^^^^^^^^

Wolfgang Ley <[email-masked]> writes:
>I don't know why this should be useful. In real life this won't help
[...]
>So the real life situation is most probably more like "get the key from
>D, add it to your keyring to check if you can verify with your existing
>keys/trust definitions". If you can't then have lost because the helper
>keys B and C are most probably from people you've never met in person
>before and therefor can't judge on their key management to use them
>as an introducer. On the other hand (if you're able to make that judge-
>ment) then you've met already and the other key is already inside your
>keyring to be sure that your trust judgement is really valid for that
>person and not just for a key with the name of person you met before.

I beg to differ.  Suppose I do the search for D given that I trust A
and it gives me A->B->C->D, and persons B and C turn out to be, for
example, Jeff Schiller and Phil Zimmermann.  Now, I might never have
met them before, and I might not have their keys on my keyring (ignore
for the moment that those keys are on the keyring shipped with PGP),
but I know them by reputation.  If I can believe person A that the
holder of key B really _is_ Jeff Schiller, then I should be able to
believe Jeff Schiller that the holder of key C really _is_ Phil
Zimmermann, and thus I should be able to believe that person D is
who Phil says he is.

I think the path finder idea is quite useful.  It may be that the
results I get from doing the path search don't necessarily work to
directly establish the link to D (i.e., D shouldn't automatically
become completely valid immediately with no further interaction by
me), but I may be able to retrieve some useful keys that I can then
go and manipulate by hand (i.e., adjust the trust levels).

>I think most "path finder" ideas do have several drawbacks
>+ The only work on key signatures not on the trust levels

Again, I think the path finder can be a good first step, working
on the signatures and giving me the raw materials to manipulate
the trust levels by hand based on knowledge that cannot be
represented in the PGP keyring itself.

>+ The programs I've seen are working on key->key->...->key paths and not
>  on the needed key->key->...->key/userid paths (a signature is always
>  valid for a key/userid combination, bot for the key only)

Yes; I suppose it would be fairly easy to modify my code to take
a key ID and a userid as input, and only return paths that lead to
the correct userid.  (Right now it returns paths that lead to any
userid on the specified key.)

Cheers,

__
Ben Cox
[email-masked]

--PGPplugin/Eudora-5.0-42029812327-1342444942
Content-Type: application/pgp-signature

--PGPplugin/Eudora-5.0-42029812327-1342444942--

From: Wolfgang Ley <[email-masked]>
Subject: Re: Key search
To: [email-masked] (Ben Cox)
Date: Wed, 23 Jul 1997 21:50:41 +0200 (MET DST)
Cc: [email-masked]
Organization: DFN-CERT (Computer Emergency Response Team, Germany)
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Ben Cox wrote:
>
> (Is this list "open for business" yet?)
>
> Hello all,
>
> I am interested in a key search mechanism by which I can ask a
> key server for a chain of keys which leads between a desired key
> and a key that I trust.
>
> For example, if I trust A's key, and I am interested in finding
> a chain by which I can trust D, I can ask the key server for the
> chain and it will return B and C (where A has signed B's key, B
> has signed C's key, and C has signed D's).
>
> I actually have code that will do this for a PGP 2.6 key ring,
> and am willing to contribute it to whomever is interested in it.
>
> Basically it builds a directed graph whose vertices are the keys
> and whose edges point from a key to all keys that have signed it.
> It then does a breadth-first search of the graph, starting at the
> requested key, stopping when it finds one of the keys listed as
> "trusted".  When it finds a trusted key, it returns all the keys
> on the path from the starting vertex to the ending vertex.
>
> Is anyone interested in seeing this code?

Hi,

I don't know why this should be useful. In real life this won't help
you because if you trust A's key and want to find a path to D then
the only way would be "A has signed D". In all other case you have
to trust the keys on the path (in your example B and C) to act as an
introducer.

So the real life situation is most probably more like "get the key from
D, add it to your keyring to check if you can verify with your existing
keys/trust definitions". If you can't then have lost because the helper
keys B and C are most probably from people you've never met in person
before and therefor can't judge on their key management to use them
as an introducer. On the other hand (if you're able to make that judge-
ment) then you've met already and the other key is already inside your
keyring to be sure that your trust judgement is really valid for that
person and not just for a key with the name of person you met before.

I think most "path finder" ideas do have several drawbacks
+ The only work on key signatures not on the trust levels
+ The programs I've seen are working on key->key->...->key paths and not
  on the needed key->key->...->key/userid paths (a signature is always
  valid for a key/userid combination, bot for the key only)

By the way: a nice PathServer is available from AT&T - see
  http://www.research.att.com/~reiter/PathServer/

Bye,
  Wolfgang Ley (DFN-CERT)
- --
Wolfgang Ley, DFN-CERT, Vogt-Koelln-Str. 30, 22527 Hamburg,    Germany
Email: [email-masked]   Phone: +49 40 5494-2262 Fax: +49 40 5494-2241
PGP-Key available via finger [email-masked] any key-server or via
WWW from http://www.cert.dfn.de/~ley/               ...have a nice day

Date: Wed, 23 Jul 1997 12:42:14 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: Key search
Sender: [email-masked]

Hello Ben,

You might want to check out 	http://akpublic.research.att.com/~reiter/PathServer/
written by Mike Reiter and Stuart Stubblebine

This list will be used for discussing new features and functionality to be in the next, open, standards-track pgp spec, hopefully from the IETF working group called open-pgp.

At 03:18 PM 7/23/97 -0400, you wrote:
>(Is this list "open for business" yet?)
>
>Hello all,
>
>I am interested in a key search mechanism by which I can ask a
>key server for a chain of keys which leads between a desired key
>and a key that I trust.
>
>For example, if I trust A's key, and I am interested in finding
>a chain by which I can trust D, I can ask the key server for the
>chain and it will return B and C (where A has signed B's key, B
>has signed C's key, and C has signed D's).
>
>I actually have code that will do this for a PGP 2.6 key ring,
>and am willing to contribute it to whomever is interested in it.
>
>Basically it builds a directed graph whose vertices are the keys
>and whose edges point from a key to all keys that have signed it.
>It then does a breadth-first search of the graph, starting at the
>requested key, stopping when it finds one of the keys listed as
>"trusted".  When it finds a trusted key, it returns all the keys
>on the path from the starting vertex to the ending vertex.
>
>Is anyone interested in seeing this code?
>
>
>__
>Ben Cox
>[email-masked]
>
>
>
>

Date: Wed, 23 Jul 1997 15:18:03 -0400
To: [email-masked]
From: Ben Cox <[email-masked]>
Subject: Key search
Sender: [email-masked]

(Is this list "open for business" yet?)

Hello all,

I am interested in a key search mechanism by which I can ask a
key server for a chain of keys which leads between a desired key
and a key that I trust.

For example, if I trust A's key, and I am interested in finding
a chain by which I can trust D, I can ask the key server for the
chain and it will return B and C (where A has signed B's key, B
has signed C's key, and C has signed D's).

I actually have code that will do this for a PGP 2.6 key ring,
and am willing to contribute it to whomever is interested in it.

Basically it builds a directed graph whose vertices are the keys
and whose edges point from a key to all keys that have signed it.
It then does a breadth-first search of the graph, starting at the
requested key, stopping when it finds one of the keys listed as
"trusted".  When it finds a trusted key, it returns all the keys
on the path from the starting vertex to the ending vertex.

Is anyone interested in seeing this code?

__
Ben Cox
[email-masked]

Date: Tue, 22 Jul 1997 09:39:24 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: IETF "Open-PGP" Birds of a Feather
Sender: [email-masked]

IETF Munich, "Open-PGP" Birds of a Feather Meeting Notice
---------------------------------------------------------
	http://www.imc.org/ietf-open-pgp/

This is to confirm one session for OPEN-PGP BOF as follows:

    Tuesday, August 12 at 0900-1115 (opposite charset ipvbi, idr, 
                                     rsvp, ssh 2000, calsch)

Marcia
**********************************************************************
Marcia Beaulieu <[email-masked]>
IETF Meeting Coordinator
Voice: 703-620-8990 ext. 210
Fax: 703-758-5913