Re: generating revocation certs non-interactively
On Tue, 5 May 2015 01:14, l...@greenhost.nl said: > keypair we would also like to generate a revocation certificate. Keys > are passwordless, so at first I thought that it should be straight forward. Note that GnuPG 2.1 generates revocation certificates by default. > for the revocation certificate. So I'm a little stuck. The --gen-revoke > option prompts the user for 4 questions for a passwordless key, 5 if the > key has a password and I couldn't get around this. The idea is that you should be able to tell the reason for the revocation. This is not very often used and thus I consider the command line interface sufficent. You may automate this but you need to employ a state mahine to answer all the questions. This is how the GUI tools work. I don't think that adding a --quick-gen-revoke command is very useful here. It would be only done for 2.1 anyway and that version has the pre-made revocations. > I have also tried pexpect to 'mock' user input to bypass interaction, no > success there. You need to use this command gpg --command-fd 0 --status-fd 2 --gen-revoke 0x12345678 and act upon the GET_* status lines. --8<---cut here---start->8--- [GNUPG:] GET_BOOL gen_revoke.okay y [GNUPG:] GOT_IT Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel (Probably you want to select 1 here) [GNUPG:] GET_LINE ask_revocation_reason.code 3 [GNUPG:] GOT_IT Enter an optional description; end it with an empty line: [GNUPG:] GET_LINE ask_revocation_reason.text foo [GNUPG:] GOT_IT [GNUPG:] GET_LINE ask_revocation_reason.text [GNUPG:] GOT_IT Reason for revocation: Key is no longer used foo [GNUPG:] GET_BOOL ask_revocation_reason.okay y [GNUPG:] GOT_IT ASCII armored output forced. --8<---cut here---end--->8--- End the "ask_revocation_reason.text" prompts with an empty line. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --with-sig-check silently ignored when used with --import and --recv-keys
On Mon, 4 May 2015 17:58, diaf...@gmail.com said: > Gotcha. Would it be possible to throw an error when --with-sig-check > is included with --import or --recv-keys? When silently ignored, it is > very easy for a user to assume that the signature checks passed. No. The purporse of the --with-* options is to allow putting them into your gpg.conf. If you want to check the signatures you use the --check-sigs command. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: generating revocation certs non-interactively
luis wrote: > To: gnupg-users > Subject: generating revocation certs non-interactively > ECHO Y\n0\n\nY\n|GPG --command-fd 0 --gen-revoke 0xDEADBEEF ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Incorrect general key info, for key on Yubikey NEO
On 05/04/2015 03:05 PM, te...@elde.net wrote: > Hi list, > > I've got what seems to be a not too uncommon setup, with a primary key used > only > for certifying, then separate signature, encryption and authentication keys as > subkeys. I wanted to make new ones, and have the subkeys on a Yubikey NEO. > > All was going perfectly fine, I revoked the old subkeys, generated new ones, > and > everything seemed well. After I moved the key to another machine though, I > noticed that the "General key info" is somehow bound to the signature subkey, > not to my primary key. > > I'm not sure, but I'm wondering if what I did wrong could have been that I > ran a > gpg --card-edit and fetch, while the machine was offline, so it wasn't able to > pull down the key from the set URL. I'm wondering if this can be the source > of > the incorrect binding. > > On the old (offline, airgapped etc) machine where I generated the key, the > subkeys seem to be properly set up on the master key, but with the general key > info being incorrect, I can't get the second (online, day-to-day work-laptop) > machine to properly recognise and bind the subkeys to the master key. > > Exporting/importing the public keys from the offline machine doesn't seem to > change anything either. > > Output from gpg --card-status is as follows: > > -- > Application ID ...: D276000[...] > Version ..: 2.0 > Manufacturer .: Yubico > Serial number : 0350[...] > Name of cardholder: Terje Elde > Language prefs ...: [not set] > Sex ..: unspecified > URL of public key : http://elde.net/keys/pgp/terje.asc > Login data ...: tld > Signature PIN : forced > Key attributes ...: 2048R 2048R 2048R > Max. PIN lengths .: 127 127 127 > PIN retry counter : 3 3 3 > Signature counter : 1 > Signature key : F76C 2924 AA47 2F40 9B8D 3BCD 53C9 00F2 CD95 0E4F > created : 2015-05-04 18:02:05 > Encryption key: D87C 6986 5C34 C778 A0CF 4208 4B31 3528 CA68 9462 > created : 2015-05-04 17:04:17 > Authentication key: D5CC 5261 CA84 CFAC 0BBC EB22 EEF9 5F70 1D85 0949 > created : 2015-05-04 18:03:08 > General key info..: pub 2048R/0x53C900F2CD950E4F 2015-05-04 Terje Elde > > -- > > > As you can see, the key mentioned in general key info: > 0x53C900F2CD950E4F > matches the signature-key, ending in: > 53C900F2CD950E4F > > The key as a whole looks like this: > -- >> gpg --list-key 0xAE05171EA277084B > pub 3072R/0xAE05171EA277084B 2015-04-22 [expires: 2016-10-13] > Key fingerprint = 04F1 2CA5 E18B DE4F CF19 0A69 AE05 171E A277 084B > uid [ultimate] Terje Elde > uid [ultimate] Terje Elde > sub 2048R/0x4B313528CA689462 2015-05-04 [expires: 2016-10-25] > sub 2048R/0x53C900F2CD950E4F 2015-05-04 [expires: 2016-10-25] > sub 2048R/0xEEF95F701D850949 2015-05-04 [expires: 2016-10-25] > -- > > It's even aware of the subkeys being detached: > -- >> gpg -K > /Users/tld/.gnupg/secring.gpg > - > sec# 3072R/0xAE05171EA277084B 2015-04-22 [expires: 2016-10-13] > Key fingerprint = 04F1 2CA5 E18B DE4F CF19 0A69 AE05 171E A277 084B > uidTerje Elde > uidTerje Elde > ssb> 2048R/0xFC5D2BB7C48EB15C 2015-04-22 > ssb> 2048R/0xE7A7BAFE92B298A2 2015-04-22 > ssb> 2048R/0xDE0525B2E9641E2B 2015-04-22 > -- > > Not possible to use the thing though: > -- >> gpg --clearsign f.txt > gpg: no default secret key: Unusable secret key > gpg: f.txt: clearsign failed: Unusable secret key > -- > > I am able to confirm that I can actually use the keys, as using them with SSH > seems to work fine. > > My guest guess would be that GnuPG isn't connecting the dots. > > For completeness, let me quickly mention that previous (now revoked) subkeys > were also on smartcard, Yubikey NEO-n to be exact. > > > Would love a suggestion or a pointer, I'm a bit eager to release the > revocation > of the old subkeys. > > Terje > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users This made me notice that my --card-status does the same thing, it shows my signing subkey at "General key info" (although I thought at some point it used to show the master...). That said, everything works fine and my card is usable (v2.1.3). So maybe it's a red herring. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: generating revocation certs non-interactively
On 05/05/15 09:41, Werner Koch wrote:
> Note that GnuPG 2.1 generates revocation certificates by default.
Great! Good to know!
> The idea is that you should be able to tell the reason for the
> revocation.
Yes of course, this makes perfect sense. There is however the fact that
good practice guides now a days often advice to generate a preemptive
revocation certificate at the time of creation of the key. So at that
moment the reason is well... not really relevant. So it's great that 2.1
does this on keypair generation.
> You need to use this command
>
> gpg --command-fd 0 --status-fd 2 --gen-revoke 0x12345678
>
> and act upon the GET_* status lines.
Great, thanks!
This hack seems to have worked though (in python), but your suggestion
seems more robust:
import pexpect
cmd = "gpg --homedir {0} --gen-revoke {1}".format(KEYRING_DIR,
'0xDEADD00D')
px = pexpect.spawn(cmd, timeout=5)
px.expect("(y/N)")
px.sendline("y")
px.expect("Your decision?")
px.sendline('0')
px.expect("> ")
px.sendline("\n")
px.sendline("\n")
px.expect("Is this okay?")
px.sendline("y")
px.expect(pexpect.EOF)
bidx = px.before.index('-BEGIN PGP PUBLIC KEY BLOCK-')
eidx = px.before.index('-END PGP PUBLIC KEY BLOCK-')
eidx += len('-END PGP PUBLIC KEY BLOCK-')
print px.before[bidx:eidx]
Salud,
Luis.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Incorrect general key info, for key on Yubikey NEO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > This made me notice that my --card-status does the same thing, it > shows my signing subkey at "General key info" (although I thought > at some point it used to show the master...). That said, everything > works fine and my card is usable (v2.1.3). So maybe it's a red > herring. Hi, I just checked this and get the same results with an FSFE Smartcard: Signing Subkey is mentioned under General Key Info.. DK -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJVSSxWAAoJEA7irlPqaBCOtXkP/jQaW/1EsHiPCb/WH0A+Wdly yOrzvzDr2QNQJrC4nv9P077cjMViiNJfr2QwTDNh8/uX1eDgR7h9FjM/TTABksB0 yRUWkUHtPuSpromZUceEsFQ7BnGnP8Foqfm7UPYFGTbwPXQFnWSLPDQ87rBi/Ugd 7WO1HeGx4Vr5geEIlRwcc6Or2n0aIlU6ksKiXcFzHTCtSbbKtElGVqFkNQWY2Diy itmvU66bf6udqL6g++Zh++k7o+UDsdgW5jTCMphe5kqeG17NlFTxICOPvoPV+G89 Pvlvhk3SsTdAHtrxPRprq3RYSjYYSaFWuFitB6vVNiI9apLTpThnI2FG0STGtd/k sdVQZ18cbLkpqFKWHxytTvb+k0H7Wqdhrys4/IYqE9ox2NyPNv2UU5qNsaEzu20T ZMOUzmYjcZRGORmq3h/rjc00UFy55F3g+EPOVRSkYz4ebzGewxz1u1vbj6Subq/T OiSEeMUAj8AvDav5aZ2lZE7Wd8d0wQX+rI+5mi+BKdwFh8IoV8Q1SdEoBCD1V2+u JoORSj7KGmU/vuDnS9ORJJ9mzwcWY/Jnx+FtU41lxJFRysieOSczTCy0HUlGMIgL ch/CzRgIBdpUguWm7TTac5dpU6ZZ2AkAV39Z3j2KDecFGgx40EqjH+/SUwX/dRu6 k2F0B1fjB6wuV4+39gyo =2iTb -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generating GnuPG S/MINE key pair
*SOLVED*
On Tue, Apr 28, 2015 at 11:12 AM, Dan Bryant wrote:
> OK... I'm apparently suffering from a bad gpgsm setup. According to
> the 2011 post
> (https://lists.gnupg.org/pipermail/gnupg-devel/2011-March/025989.html)
> the following command, should just work:
>gpgsm --gen-key | gpgsm --import
>
> Not for me... I get
> gpgsm: problem looking for existing certificate: Invalid argument
> gpgsm: error storing certificate
>
I found the problem. I had a corrupt install. I was
trying to work around problems in the 2.1.3 installer, and went about
it poorly. I copied pinentry from gpg4win 2.2.4 (bad idea).
The better way to do it was as follows:
1) Download gnupg-w32-2.1.1_20141216.exe
2) Install {1} to %ProgramFiles(x86)%\GNU\GnuPG
3) Copy files out of {2} into %UserProfile%\GnuPG.Combined
4) Uninstall {1}
6) Stop any processes running from {2}
7) Remove directory {2}
8) Download gnupg-w32-2.1.3_20150413.exe
9) Install {8} to %ProgramFiles(x86)%\GNU\GnuPG
10) Copy files out of {9} into %UserProfile%\GnuPG.Combined
11) Stop any processes running from {9}
12) Copy %UserProfile%\GnuPG.Combined to %UserProfile%\GnuPG as Admin
13) Remove %UserProfile%\GnuPG.Combined
This will get GPA.exe and PinEntry.exe working (I hope) on a 2.1.3 baseline.
You may be able to simply install 2.1.1 then install 2.1.3 over it, I
leave others to speculate on that. This worked for me.
The GPGSM self-sign cert now imports without error.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
