Subject: Re: Fix the secret key packet, not the S2K

From: [email-masked]
Date: Wed, 28 Mar 2001 15:49:04 -0800

Michael Young, <[email-masked]>, writes:
> Why is a new S2K mode preferable to a new key version?

I see two reasons:

First, the secret key packet as such doesn't have a version number.
The version number is borrowed from the public key packet that begins
the secret key packet.  In other words, the secret key packet is a public
key packet with extra data stored at the end.

So in order to change the secret key packet version, we need to bump the
public key packet version.  If we create a "V5" secret key then we need
to create a corresponding "V5" public key.  But since we aren't changing
the public key packet format, this is somewhat redundant, since V4 and
V5 public keys would be entirely identical.

Second, the purpose of the S2K specifier and associated information
(algorithm ID etc) is to describe how the secret data is protected.
Since we are making a change with regard to this protection, this is a
reasonable place to represent that change.

> The S2K is used in more than just the secret key packet.
> Adding another context-specific flag to the S2K seems
> wrong (unless you meant for this checksumming behavior
> to apply to other uses, which also seems wrong).

This is true, the S2K is also used for passphrase encrypted messages.

Another place we could represent the alternative format is the byte which
comes shortly before the S2K in the secret key packet.  This byte is
fixed at a value of 255 to flag that an S2K is in use.  We could perhaps
use some alternate value for this byte to flag that the private key is
using a different form of checksum protection.

> Do you think that existing implementations would just
> happen to ignore extra bits in the S2K specifier and
> extra checksum bytes at the end?  If so, I admire
> the trickery, but I don't think this is serious
> enough to warrant it in the spec -- as many folks have
> pointed out, local key storage can use any hackery
> an implementation likes anyway.

No, I think existing implementations will refuse to use the new keys
regardless of where we make the change.

> > The commercial version of PGP also uses some special S2K values, but
>
> Yes... the "raw" key used in key-splitting.
>
> Which brings me to another point: can we at least
> put placeholders in the spec for these existing PGP
> product features?  I know that some of these hidden
> features (ADKs, for instance) are unpopular, but an
> OpenPGP implementation may well run across them.
> I'd really like the spec to say how they appear (and
> even what they do), even if it does not endorse them,
> so that implementations can recognize them if they want.
> The spec does have a "placeholder" for the ADK
> subpacket.  Shouldn't it for the S2K extensions?
> Are there others we just haven't run across yet?

This is a good idea.  There are a few others I know of which are
undocumented, besides the two S2K identifiers.  These relate to X.509
certificate support.  There is a packet type used as CRL, and there
is a signature subpacket that holds an X.509 cert.  We should probably
add these to the revised draft as reserved identifiers.  GPG or other
implementations may also have some reserved values.

Hal

---

From: "Michael Young" <[email-masked]>
Date: Wed, 28 Mar 2001 19:47:07 -0500

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

>First, the secret key packet as such doesn't have a version number.

There is no deep reason that it couldn't.  Instead of forcing a
tight coupling between the two, give it its own version byte
(starting with 5).  The whole public key packet (or just its contents)
could follow, including its (independent) version number.

> Another place we could represent the alternative format is the byte
> which comes shortly before the S2K in the secret key packet.

A fine alternative... keeps the compatibility hacks together.  How
about 254?

---

From: Werner Koch <[email-masked]>
Date: Thu, 29 Mar 2001 09:32:08 +0200

> (starting with 5).  The whole public key packet (or just its contents)

The problem ist that this is not a local change but _may_ affect
other parts of an implementation.  For example, at a couple of
places we have to check whether this is a v[23] or v4 packet and if
at some place a version == 4 has accidently been used this would
lead to a lot of other bugs.  We are currently planning for
interoperability tests and such a change may delay those test even
further.  By not changing the the packet version number we can
implement that as a implementation specific change and don't have to
change the specs right now.

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code           et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

---

From: Werner Koch <[email-masked]>
Date: Thu, 29 Mar 2001 09:37:36 +0200

> using a different form of checksum protection.

That would be fine with me.  Although GnuPG already uses the S2K for
similiar purposes.

> implementations may also have some reserved values.

We already have a range for experimental/private extensions (except
for the S2K.  IMHO, an implementation should use these values as
long as that new feature is not in the standard or the WG has agreed
on some new values.  Of course, there should be a way to distinguish
between different usages of those experimental values.  For example,
GnuPG adds a string "GNU" to its private extensions to the S2K.

Ciao,

  Werner