Adam Back wrote:
In ESMTP/SMTP there are extension mechanisms. Clients/Servers can use
this mechanism where the other party has it also. This is a very
powerful and simple to add feature. I think we need such an extension
mechanism in OpenPGP.
Exactly what I've been thinking of over the last few days, although from
a different angle. I agree with Paul Hoffman (IMC) that OpenPGP MUSTs
should be absolutely as simple as possible, to allow other
standards/programs to incorporate it with minimal effort. We have
already abandoned MUST backwards-capability with PGP 2.6 (RSA and IDEA
can't be MUSTs) so we could have some paring down of MUSTs to a minimum.
PGP backward compatibility could then be just an option for
implementations.
At a first glance, ALL that would seem to be needed in a minimal
implementation would be (using the first draft at the IMC):
PGP provides four services related to the format of messages
and data files:
-digital signature
-encryption
-compression
-radix-64 conversion
Only the first two are MUSTs. The second two are specified in RFCs
elsewhere, {c/sh}ould be optional, and could even be largely absent from
the document - just refer to Zip and MIME RFCs.
I've also been looking at PGP/MIME. It REQUIRES Armour use, which was
appropriate for backward compatibility but is now not as important.
ietf-open-pgp is chartered to replace RFC1991 AND RFC2015 (PGP/MIME) so
we could define a version 2 of PGP/MIME which simply encodes binary
OpenPGP
data like all other MIME data.
"Implementations MAY understand Armour (see RFC 1991/corrected) for
backward compatibility. They SHOULD use PGP/MIME2 for transport of
OpenPGP messages using mail."
This allows all other mention of armour to be excised.
The current packet types are as follows:
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
14 -- Subkey Packet
15 -- Reserved
16 -- Comment Packet
Packet headers contain a length, so it is simple for us to specify that
packets that are not understood by an implementation should simply be
ignored. All vital packets which an implementation MUST understand will
be specified in openPGP. At first glance, these would be 1, 2, 5, 6, 9
and 11
(and maybe 3).
Keyring management programs would also need to understand 12 and 13. As
Peter Gutmann suggested, this need not be part of the base
specification. Applications may wish to use a public key without needing
to
know anything about a userID/email address for it. Public keys should
also
be securely obtainable from Secure DNS (when it finally rolls out)
without an absolute need for signatures.
Someone like the IANA could then act as a registry for other, optional
packet types. Something Raif Naffah wrote on another list recently:
Assuming you already have the classes to
handle each specific PGP packet, it's easy to process a public or secret
keyring or even a PGP message as a structured sequence of packets. In the
mentioned cases, the structure is well defined by current implementations
of PGP and by proposed standards.
The tool/bean I'm thinking of would allow the user to define and process
other types of PGP packet sequence(s). Ultimately it can also allow users
to define their own packets. With such a tool, communities can agree and
use their own PGP-based 'structures.' An additional layer of code or data
may allow the encoding of the structure and its elements totally
dissociating the data (the packets contents) from their structure (sequence
of a public keyring, secret keyring, etc...).
Finally, the only MUST symmetric encryption algorithm would be 3DES; the
only MUST asymmetric encryption algorithm Elgamal; the only MUST
signature algorithm DSA.
This would allow a very minimal implementation indeed of OpenPGP. All
other features would be MAYs.
Ian :D