-----BEGIN PGP SIGNED MESSAGE-----
Hal seems to endorse to Werner's suggestion:
We introcude a new S2K mode and encrypt this:
Why is a new S2K mode preferable to a new key version?
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).
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.
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?
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQEVAwUBOsJj/2NDnIII+QUHAQHU2QgAl36/7/SQ++dtBv1am8pEECYoAF3v7r8+
YOXSImQ9fODIx/hSipgtIrbzz4Ky1rkHPhlLwy43XhOT2msStghXKDgzjYzu2CJn
nvyCAkVLrT8QpfOr8cT7gvM4UlkgB5+TmPOJ4Uuz0wtfuz2BLvdBXDEBT9EbeCeE
QQuclQ/nJe99Dme1SThnKWRchmF3JkHLOxfS5PHwf0wYXihaL0ziZmQezMvGUQVL
zxfWKVlVzCGWwCG7bWtvpr7n6+Ye5ZoCEOCM8Qa642K0EMJ477E7CrSeZbvyMcps
4Vwb20ONtah80/Afko85vjSIzpXgGKQsKQIUihiR8vnSp4BB8ZxaZw==
=eplI
-----END PGP SIGNATURE-----