ietf-openpgp
[Top] [All Lists]

Re: implementing backwards compatibility (Re: Some suggestions)

1998-04-28 15:45:57
On Tue, 28 Apr 1998, Adam Back wrote:

An implementor is able within the OpenPGP spec I think to write an
openPGP implementation which is largely backwards compatible with
pgp-2.6.x.

Actually there are enough enumerated points to allow it to be completely
compatible.

Then, in addition you need to interpret a pgp-2.6.x formatted public
key as an implicit encoding of the fact that the sending application
can only cope with pgp-2.6.x packets, and only cope with algorithms
IDEA, MD5, and RSA.

I think this should work.

It would, but you might want to update your RSA key to v4 (though that
would bring in the keyid problem) to say that you can do all of the new
stuff.

It gets tricky when your application is creating clear signed
signatures -- you don't know who the message is targetted at -- so to
follow the backwards compatibility reasoning to it's logical
conclusion this implies that all clear signed messages (or at least
those where you don't know who will later wish to verify them) should
only use MD5, and RSA.

Just doing multiple signatures is an issue.

<why not MD5...>

It would have been possible I think to hide an Elgamal/DSA key in a
pgp2.6.x format packet (for example in a comment field); using this
method we could have had full backwards compatibility.  (A similar
trick is used in the move from SSLv2 to SSLv3.)  (Similar kinds of
packet upgrades would have allowed backwards compatiblity for
signatures and encrypted information for multiple recipients with some
recipients being openPGP new algorithms over pgp-2.6.x).

There is nothing within the V3 packet format precluding DSA keys.  They
can be output with 3 as the version, and the creation time and valid days
fields:

BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPrivacy 0.9

mQDkAzVGWtkAABECANS2E1sRohE7kN1IGj5IAbVQg/J+7SdaCWPzVOetXNhaFk2I
fHvOa4aD6HcEl7mHNhhMe4VmuUeiITBnHCI9wA0AoPfThufPh/EhPUr3NiMY3Okd
/OTNAf9cIrf46iJpum3IX4yor9d8d0FGX5fCZF3ajFMTAXOYc4pl427l32gvp5Bl
4KRO+kJ59Qb4YZ7vdlJp48uMoJPuAgCllOUKrDQG7gha0FKMPaslUtpycKZc9oWP
AZ9rfu2Kan8mUxbR21gw6VUr2RtG+JmN6oRU3OmprlgYpRDePOlysAGHtAhWM0RI
L0RTQbABA7kAzwM1RlrZAAAQAwD15Itoz82i/Q3Fkim7gGvloo0Q0Pu8r2VWZRa5
K0GinDuPnI/e6WfX2ABD7lYgIr1fmNrcheI7VfaLyHqsGLuXwN5uy+HJXNA05WLH
MxyV52FefHCOWrunDgT91Q2f+AMAAwUC/2SvnNUE2HwsmGRuvNnNM093ClduEiMY
YHvEcEeS3dumoMEdM7jv/GQ5TSfGTPLjUxsQglHwkzJxPbHZiHSVxoXxFBBvh6tT
sBLGEDIrjJhYc1sopJNw7QDL5CJOimCgirABhw==
=jl4k
END PGP PUBLIC KEY BLOCK-----

As a comment to Hal and Jon, I think that the PGP implementation could
use some improvement in the area of auto-detecting pgp-2.6.x and
reacting accordingly -- I receive messages from people using pgp-5.x
with RSA implemented, and the message is RSA and IDEA encrypted but
has (I think) DSA signatures contained even though the user also has
an RSA key.  (Either that or is inserting a pgp5.x only packet which
otherwise throws pgp-2.6.x).

The problem is that there are problems with 2.6.x and that is why it is
being dumped in favor of OpenPGP.  My V3 handling does "the right thing"
most places, so a 2.6.1998 is possible, but why bother?  If you are going
to move at all, OpenPGP is not that much of a jump.  If you can't move,
then there is no reason to do partial stuff

--- reply to tzeruch - at - ceddec - dot - com ---


<Prev in Thread] Current Thread [Next in Thread>