From f672b68d7d43e4e8bd57b72a1bf9788dd52e728b Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Wed, 13 Aug 2008 15:57:31 -0400
Subject: [PATCH] documenting our trouble with (and possible approaches to)
 handling passphrase-locked secret keys.

---
 .../handle-passphrase-locked-secret-keys.mdwn | 83 +++++++++++++++++++
 1 file changed, 83 insertions(+)
 create mode 100644 website/bugs/handle-passphrase-locked-secret-keys.mdwn

diff --git a/website/bugs/handle-passphrase-locked-secret-keys.mdwn b/website/bugs/handle-passphrase-locked-secret-keys.mdwn
new file mode 100644
index 0000000..a61b5ba
--- /dev/null
+++ b/website/bugs/handle-passphrase-locked-secret-keys.mdwn
@@ -0,0 +1,83 @@
+[[meta title="MonkeySphere needs to be able to cleanly export passphrase-locked secret keys from the GPG keyring"]]
+
+At the moment, the only tool we have to export passphrase-locked
+secret keys from the GPG keyring is `gpg` itself (and `gpg2`, which
+has roughly the same behavior).
+
+As a result, we have the `seckey2sshagent` hack, which is unfriendly
+and awkward to use.
+
+Ideally, `openpgp2ssh` would be able to convert passphrase-locked
+secret keys into clean subkeys.  However, i've tried to do this via
+GnuTLS, and that library is not ready for this.
+
+OpenCDK, which is the component of GnuTLS which reads OpenPGP-style
+keys, cannot cope with encrypted secret key material.  I have had
+[some
+success](http://lists.gnu.org/archive/html/gnutls-devel/2008-06/msg00092.html)
+in getting GnuTLS's OpenCDK to accept the existence of encrypted
+secret key packets, [i learned that OpenCDK as included in GnuTLS is
+incapable of dealing with the encrypted packets
+themselves](http://lists.gnu.org/archive/html/gnutls-devel/2008-07/msg00012.html).
+
+
+Some possible resolutions:
+
+---------
+
+If we can assume that the passphrase-encrypted key we want to use is
+actually a subkey, and if we could fix GnuTLS to ignore the use of the
+"gnu-dummy S2K" produced by `gpg --export-secret-subkeys` for the
+primary key, then something like the following script should actually
+work for reasonable values of `$KEYID`:
+
+	TMPDIR=$(mktemp -d)
+	uname 077
+	mkfifo "$TMPDIR/passphrase"
+	kname="MonkeySphere Key $KEYID"
+	mkfifo "$TMPDIR/$kname"
+	ssh-agent "Please enter the passphrase for MonkeySphere key $KEYID" >"$TMPDIR/passphrase" &
+	gpg  --passphrase-fd 3 3<"$TMPDIR/passphrase" --export-options export-reset-subkey-passwd,export-minimal,no-export-attributes --export-secret-subkeys "$KEYID"\! | openpgp2ssh "$KEYID" > "$TMPDIR/$kname"
+	(cd "$TMPDIR" && ssh-add -c "$kname")
+	rm -rf "$TMPDIR"	
+
+---------
+
+Ben Laurie and Rachel Willmer's
+[OpenPGPSDK](http://openpgp.nominet.org.uk) is a candidate: this is a
+C-based library that intends to implement RFC 4880 functionality.
+
+We could potentially re-write `openpgp2ssh` using this library, and it
+*should* be able to handle everything we need from the OpenPGP side
+(though it might need to be re-linked to OpenSSL to handle PEM-encoded
+exports.
+
+Concerns:
+
+* OpenPGPSDK is not in debian yet, and doesn't currently (2008-08-13)
+  build with gcc 4.2 or 4.3.
+
+* OpenPGPSDK uses the apache license and appears to link to OpenSSL,
+  which has a GPL-incompatible license.  I think this would mean that
+  `openpgp2ssh` could not remain GPL (though the rest of the
+  monkeysphere could).
+
+---------
+
+We could try to use perl.  The last time i checked, the pure-perl
+OpenPGP implementations all depended on Math::PARI, which [is not in
+debian](http://bugs.debian.org/440527).  The most likely candidate is
+[Crypt::OpenPGP](http://search.cpan.org/~btrott/Crypt-OpenPGP),
+despite [some
+bugginess](http://cpanratings.perl.org/dist/Crypt-OpenPGP).  
+
+Concerns:
+
+* the aforementioned buggy reviews
+
+* there's a lot of dependency chasing to get anything like this
+  available in debian.
+
+---------
+
+Other alternatives?
-- 
2.26.2