more on read_s2k() for GnuTLS 2.4.1 (including "GNU dummy S2K")

[Daniel Kahn Gillmor]

After reading Nikos' assessment of the state of OpenCDK in handling
enciphered subpackets, i've backed off from my original goal of
actually decrypting secret keys.  I'd like GnuTLS to be able to do
that at some point, but i don't understand OpenCDK's filter model well
enough yet to actually implement the cipher needed to decrypt locked
secret keys.

However, there is a reason to prefer to be able to identify and parse
locked secret keys, even if we can't unlock them yet.  In particular,
RFC4880 allows for some secret subkeys (or the primary key) in a
keyset to be unlocked while others are locked.

For example, you might want to provide a TLS service with the
Authentication subkey for the host's key, but not provide it with the
unlocked primary key itself.  Presented with a keyset like this
(locked primary key, unlocked subkey), and asked to use the subkey,
GnuTLS will currently fail to operate despite having access to all the
information needed.

My earlier read_s2k implementation [0] would have allowed GnuTLS to
handle this case properly.

gpg itself is capable of generating such a keyset, using the flag:

 --export-secret-subkeys

But it "locks" the primary key by removing the secret MPIs entirely
for the primary key packet, using an experimental S2K identifier
(101), which GPG classifies as "gnu-dummy".

gpg(1) says of --export-secret-subkeys:

   the command has the special property to render the secret part of
   the primary key useless; this is a GNU extension to OpenPGP and
   other implementations can not be expected to successfully import
   such a key.

However, it isn't difficult to actually import such a key (and to
ensure that such a packet conforms to the flavor emitted by GPG).  The
attached patch is an update to my earlier read_s2k implementation and
is capable of interpreting the gnu-dummy S2K extension.  As a GNU
project, this seems like a worthwhile step to me.

Is there any objection to including this GNU extension in the event
that a 2.4.2 release is made?

I'd be happy to implement the same thing for the 2.5.x branch as well,
if there are no objections.

As always, i welcome feedback!

    --dkg
‐

[0] http://lists.gnu.org/archive/html/gnutls-devel/2008-06/msg00092.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 19_functional_s2k_with_GNU_dummy.diff
Type: text/x-diff
Size: 3930 bytes
Desc: functional s2k against GnuTLS 2.4.1 (including interpretation of gnu-dummy S2K extension)
URL: </pipermail/attachments/20080813/7115845e/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080813/7115845e/attachment.pgp>