Adam Back <aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk> said:
BUT, if you choose to implement RSA and IDEA, then you MUST treat V3 keys
as implicit statement that IDEA is the only cipher supported.
I have to disagree, take the following example:
I have 2 users of my OpenPGP implementation who have upgraded from PGP x.x
and have migrated their V2/V3 RSA keys. Why should they be forced to use
IDEA/MD5 if they both chose not to?
You have two options here:
1) When promoting the V3 RSA key to V4+ (OpenPGP) RSA key increment
it's version number. Then you can list any ciphers you choose on
the capability list. Any v3 certs promoted with the public key (to
retain existing v3 WoT) would be defined as signatures over the v3
representation of the v4 key packet (ie with all v4 features
removed using some repeatable standard procedure) This procedure
could be called demoting the key from v4 down to v3 with loss of
various capability and v4 WoT information.
With this option you have the problem of the numerous methods of
key distribution: if there are v3 public keys on key servers, your
option then is to add the v4 promoted keys also -- it should be
able to co-exist because of the different keyID. However this
introduces the need for proactive key servers -- ones which return
different public keys depending on the version number of the key
requester -- something which could be done. It could for example
invoke the demotion algorithm on the v4 public key to derive the
subset which is a v3 public key
This still does not cope with keys distributed manually or on web
pages: pgp2.x will choke on the v4 keys.
2) Have a syntax for expressing the cipher suite and any other v4
features in a way which is transparent to a v3 implementation. This
could have been done, relatively easily: define the packets to be
encoded in the little used v3 comment packet. That allows you
then to send someone a V3 key which expresses algorithm
capabilities, without promoting it's version number, and the
existance of the comment packets is can contain the actual version
number (from an OpenPGP implementation's point of view).
Option 2) is not possible now because it is not backwards compatible
with pgp5.x. Option 1) should work I think.
I have to bring up my objections again about making preferences a
Must things are for compatibility. You can choose to over-ride them,
but then you are no longer compliant. You've got to publish the
algorithm capabilities in your public key otherwise people won't know
what you can cope with.
It should be up to the users of the product what algorithms they
wish to use (It is their communications after all). I don't have a
problem with saying that the default actions of the program should
follow the preferences but if the users are sophisticated enough to
choose different encryption/hash algorithms who am I to prevent
I think that this is fine but within the bounds of the capabilities of
both parties. Sending some eliptic curve variant / with a tiger hash,
and experimental non-transferable sig won't work if the other side
doesn't have the same extensions. There is a mechanism to express
I have coresponded with with other PGP 5.x users using all different
combinations of symetric/hash algorithm with both EL & RSA keys
depending on what mood takes me at the time.
Fine. But I presume you didn't send them combinations which were not
listed in their capability spec.
There is also the issue of what happens if the user upgrades/changes
his OpenPGP implementation or works with several different
implementations that have a variety of different capabilities?
Yes, this is really a problem. I would think your options are:
1) generate a new key (as you suggest);
2) promote the public key packet by adding a new capability self
signature packet superceding the old one; or replace the old
3) allow capability self sigs to be sent as part of messages
Options 1) only works for permanent upgrade (and not switching between
different versions), same problem for option 2).
Option 3) stands a chance of working, as you send a message to someone
their implementation updates their copy of your public key. You send
an update to the keyservers (using a key altered using method 2). You
can even move back to a previous less capable version.
In general though the whole topic is pretty messy and almost
intractible. I think the simplest compromise is to say that if you
want to change capabilities you do the following:
a) generate a new key (use the same secret components if you wish)
b) sign the new key with your old key
c) revoke the old key with `key retired use this key instead'
This means you can't use different versions with the same key, or that
if you do you must use algorithms in the common subset of capabilities
of all the implementations you are using with the same key. Building
more functionality seems to complicated. This may as you suggest
imply inability to receive messages from pgp2.x, and/or selection of
SHA1/3DES/Elgamal only. I don't see a practical alternative.