Re: Commands supported by extra socket
On Thu 1 Aug, 2019, 9:20 PM Werner Koch, wrote: > On Fri, 26 Jul 2019 15:57, gnupg-users@gnupg.org said: > > > Where can I find information on what commands are supported by > > S.gpg-agent and S.gpg-agent.extra socket? I am looking for some > > information which clearly differentiates these two sockets. > > Here is an overview on the allowed commands for the S.gpg-agent.extra > and S.gpg-agent.browser. Only the commands required for perform a > signature creation or a decryption are possible via these sockets. It is > for example not possible to list all known keys or to create a key. > > | Command | Allowed | Comment | > |---+-+-| > | GETEVENTCOUNTER | no | | > | ISTRUSTED | yes | | > | HAVEKEY | yes | | > | KEYINFO | no | | > | SIGKEY| yes | | > | SETKEY| yes | | > | SETKEYDESC| yes | | > | SETHASH | yes | | > | PKSIGN| yes | | > | PKDECRYPT | yes | | > | GENKEY| no | | > | READKEY | no | | > | GET_PASSPHRASE| no | | > | PRESET_PASSPHRASE | no | | > | CLEAR_PASSPHRASE | no | | > | GET_CONFIRMATION | no | | > | LISTTRUSTED | no | | > | MARKTRUSTED | no | | > | LEARN | no | | > | PASSWD| no | | > | SCD | no | | > | KEYWRAP_KEY | no | | > | IMPORT_KEY| no | | > | EXPORT_KEY| no | | > | DELETE_KEY| no | | > | GET_SECRET| no | | > | PUT_SECRET| no | | > | GETVAL| no | | > | PUTVAL| no | | > | UPDATESTARTUPTTY | no | | > | KILLAGENT | no | | > | RELOADAGENT | no | | > | KEYTOCARD | no | | > | GETINFO | no | see 1 | > | OPTION| no | see 2 | > |---+-+-| > > 1) except for the sub-commands: >"version", "cmd_has_option", "s2k_count", "restricted". > 2) except for the option: >"agent-awareness" > > > Thank you Werner!! Best, Vijai Kumar K > > 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: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information
Playfair via Gnupg-users: > On 8/1/19 7:37 AM, Werner Koch via Gnupg-users wrote: >> On Mon, 29 Jul 2019 09:43, gnupg-users@gnupg.org said: >>> it that way", i think. Perhaps Werner can provide more background on >>> why GnuPG is generally resistant to holding OpenPGP certificates that >>> have no User ID at all in its local keyring. >> >> The user ID is important because the accompanying self-signature conveys >> important information about the keyblock. For example expiration date >> and preferences. It is true that this can also be conveyed with >> direct-key-signatures (a self-signature directly on a key which was >> mainly introduced for dedicated revocations). However, this is a not so >> well tested feature of gpg and my educated guess is that many other >> OpenPGP implementations do not handle direct-key signatures in a way >> compatible to pgp or gpg - if at all. Thus by relying on them we would >> sail into uncharted waters. >> >>> Doing such a merge would be super helpful, particularly for receiving >>> things like subkey updates and revocation information from >> >> I agree that we can add a code path to import a primary key plus >> revocation certificate but without user-ids. PGP however, does not >> support this and is the reason why we extended the revocation >> certifciate with a minmal primary key. >> >> Update of subkeys is a different issue and I see no solid use case for >> allowing that without user-id (cf. expiration date of the primary key). > > Couldn't this issue be dealt with by the key server instead of by > OpenPGP implementations? GnuPG can create and import keys having > non-email-address user IDs. A string of more than 4 characters is > acceptable. Anything remotely resembling an email address, e.g. > x...@y.xyz, is okay. > > If keys.openpgp.org won't publish a user ID other than a verified email > address, is its only recourse to remove the user ID? Could it instead > substitute the hex key ID, fingerprint or a dummy string like "User ID > not verified"? If it can't, is there any benefit in publishing a > mutilated key people can't use? Just reject it. > > Chuck > > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Why upload a key to a keyserver with no email address? What's the point of doing that? You cant send an encrypted email to it - unless your given the email first -will it work to encrypt to a publlic key with no email? I got 180 public keys - some are very weird (I should delete them) some keys are for signing some sub keys are for encrypting and some sub keys decryption - why not make a key that does it all with a oad of sub keys? Keyservers should have strict rules on public keys - all to have a valid email a validation email sent back - then confirmed and that public key is then available. No identity available - simple - reject the key. Users of gpg that want to create weird and wonderful keys need to keep them on their own laptop or desktop - keyservers should be able to purge off these keys then keyservers would be back to what was intended. David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information
On Thu, 1 Aug 2019 09:27, gnupg-users@gnupg.org said: > We're already in uncharted waters with the inevitable abuse of SKS, we > need to figure out how to stabilize the ecosystem. Most businesses do not use public keyservers at all but use their internal PKI. > If the PGP implementation of OpenPGP has bugs or doesn't behave well in > the context of a minimized/stripped certificate, let's ask them to fix > those bugs. The bugs in how that implementation interprets data are Good luck. PGP is in maintenance mode and there won't be any updates. We even had layer-8 problems back in the times when Hal was still alive/unfrozen to get new OpenPGP features into PGP. In particular companies will hesitate to update their once purchased PGP. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information
On 8/1/19 7:37 AM, Werner Koch via Gnupg-users wrote: > On Mon, 29 Jul 2019 09:43, gnupg-users@gnupg.org said: >> it that way", i think. Perhaps Werner can provide more background on >> why GnuPG is generally resistant to holding OpenPGP certificates that >> have no User ID at all in its local keyring. > > The user ID is important because the accompanying self-signature conveys > important information about the keyblock. For example expiration date > and preferences. It is true that this can also be conveyed with > direct-key-signatures (a self-signature directly on a key which was > mainly introduced for dedicated revocations). However, this is a not so > well tested feature of gpg and my educated guess is that many other > OpenPGP implementations do not handle direct-key signatures in a way > compatible to pgp or gpg - if at all. Thus by relying on them we would > sail into uncharted waters. > >> Doing such a merge would be super helpful, particularly for receiving >> things like subkey updates and revocation information from > > I agree that we can add a code path to import a primary key plus > revocation certificate but without user-ids. PGP however, does not > support this and is the reason why we extended the revocation > certifciate with a minmal primary key. > > Update of subkeys is a different issue and I see no solid use case for > allowing that without user-id (cf. expiration date of the primary key). Couldn't this issue be dealt with by the key server instead of by OpenPGP implementations? GnuPG can create and import keys having non-email-address user IDs. A string of more than 4 characters is acceptable. Anything remotely resembling an email address, e.g. x...@y.xyz, is okay. If keys.openpgp.org won't publish a user ID other than a verified email address, is its only recourse to remove the user ID? Could it instead substitute the hex key ID, fingerprint or a dummy string like "User ID not verified"? If it can't, is there any benefit in publishing a mutilated key people can't use? Just reject it. Chuck signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
skipped packet 12
Hello, Do you have any ideas why am getting multiple lines of: gpg: skipped packet of type 12 in keybox Thanks David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information
Daniel Kahn Gillmor via Gnupg-users [2019-08-01T09:27:45-04] wrote: > Here's one use case (i've got others if you want): > > * You have my OpenPGP certificate (with userid with e-mail address), >but it is not published in full publicly because i do not want people >to be able to find anything related to my e-mail address online. > > * It has an encryption-capable subkey "X" that expires in 1 year, which >i use to be able to have deletable messages. I will destroy the >secret component when X expires. > > * As the year draws to a close, i create a new subkey "Y" and i attach >it to my OpenPGP certificate, and i push the updated certificate to >an abuse-resistant keystore (like keys.openpgp.org), again declining >to allow it to publish my e-mail address. > > * After the expiration of "X", you want to send me an encrypted mail >(as is your habit when mailing me). You follow best practices and >refresh your keyring (fetching certificate updates by primary key >fingerprint) from a public, abuse-resistant keystore. Does your >OpenPGP implementation learn about "Y" when it pulls in the update? >It should. To me this sounds very relevant use case and adds one more feature to the general OpenPGP system. I hope future implementations support exporting and importing (merging) also partial key block data. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tliko...@iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Commands supported by extra socket
On Fri, 26 Jul 2019 15:57, gnupg-users@gnupg.org said: > Where can I find information on what commands are supported by > S.gpg-agent and S.gpg-agent.extra socket? I am looking for some > information which clearly differentiates these two sockets. Here is an overview on the allowed commands for the S.gpg-agent.extra and S.gpg-agent.browser. Only the commands required for perform a signature creation or a decryption are possible via these sockets. It is for example not possible to list all known keys or to create a key. | Command | Allowed | Comment | |---+-+-| | GETEVENTCOUNTER | no | | | ISTRUSTED | yes | | | HAVEKEY | yes | | | KEYINFO | no | | | SIGKEY| yes | | | SETKEY| yes | | | SETKEYDESC| yes | | | SETHASH | yes | | | PKSIGN| yes | | | PKDECRYPT | yes | | | GENKEY| no | | | READKEY | no | | | GET_PASSPHRASE| no | | | PRESET_PASSPHRASE | no | | | CLEAR_PASSPHRASE | no | | | GET_CONFIRMATION | no | | | LISTTRUSTED | no | | | MARKTRUSTED | no | | | LEARN | no | | | PASSWD| no | | | SCD | no | | | KEYWRAP_KEY | no | | | IMPORT_KEY| no | | | EXPORT_KEY| no | | | DELETE_KEY| no | | | GET_SECRET| no | | | PUT_SECRET| no | | | GETVAL| no | | | PUTVAL| no | | | UPDATESTARTUPTTY | no | | | KILLAGENT | no | | | RELOADAGENT | no | | | KEYTOCARD | no | | | GETINFO | no | see 1 | | OPTION| no | see 2 | |---+-+-| 1) except for the sub-commands: "version", "cmd_has_option", "s2k_count", "restricted". 2) except for the option: "agent-awareness" Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --lsign --add-me or the invisible WoT
Friedhelm Waitzmann wrote: > Stefan Claas: > > >I lsign Bob's key so third parties do not know (normally) that I did > >this. But how could my friend Alice trust Bob's key she has without > >my non-exportable lsign sig? > > >What I tried to propose is an additional parameter, like --add-me > >which would write a 'blob' to a second file.db where I can export > >then Bob's blob (non-compatible to SKS etc.) with my --lsign sig, > >and give it to my friend Alice. > > I think, this can be done with GnuPG as it is: [snip] Thank you very much Friedhelm! Best regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information
On Thu 2019-08-01 13:37:26 +0200, Werner Koch wrote: > The user ID is important because the accompanying self-signature conveys > important information about the keyblock. For example expiration date > and preferences. It is true that this can also be conveyed with > direct-key-signatures (a self-signature directly on a key which was > mainly introduced for dedicated revocations). However, this is a not so > well tested feature of gpg and my educated guess is that many other > OpenPGP implementations do not handle direct-key signatures in a way > compatible to pgp or gpg - if at all. Thus by relying on them we would > sail into uncharted waters. We're already in uncharted waters with the inevitable abuse of SKS, we need to figure out how to stabilize the ecosystem. >> Doing such a merge would be super helpful, particularly for receiving >> things like subkey updates and revocation information from > > I agree that we can add a code path to import a primary key plus > revocation certificate but without user-ids. PGP however, does not > support this and is the reason why we extended the revocation > certifciate with a minmal primary key. If the PGP implementation of OpenPGP has bugs or doesn't behave well in the context of a minimized/stripped certificate, let's ask them to fix those bugs. The bugs in how that implementation interprets data are irrelevant to data that > Update of subkeys is a different issue and I see no solid use case for > allowing that without user-id (cf. expiration date of the primary key). Here's one use case (i've got others if you want): * You have my OpenPGP certificate (with userid with e-mail address), but it is not published in full publicly because i do not want people to be able to find anything related to my e-mail address online. * It has an encryption-capable subkey "X" that expires in 1 year, which i use to be able to have deletable messages. I will destroy the secret component when X expires. * As the year draws to a close, i create a new subkey "Y" and i attach it to my OpenPGP certificate, and i push the updated certificate to an abuse-resistant keystore (like keys.openpgp.org), again declining to allow it to publish my e-mail address. * After the expiration of "X", you want to send me an encrypted mail (as is your habit when mailing me). You follow best practices and refresh your keyring (fetching certificate updates by primary key fingerprint) from a public, abuse-resistant keystore. Does your OpenPGP implementation learn about "Y" when it pulls in the update? It should. If it does not, you will end up sending me cleartext e-mail, pointlessly, because your local client had the opportunity to know (for certain -- with cryptographically-verifiable evidence!) that a non-expired encryption-capable subkey was available, associated with the given primary key. Regards, --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information
On Mon, 29 Jul 2019 09:43, gnupg-users@gnupg.org said: > it that way", i think. Perhaps Werner can provide more background on > why GnuPG is generally resistant to holding OpenPGP certificates that > have no User ID at all in its local keyring. The user ID is important because the accompanying self-signature conveys important information about the keyblock. For example expiration date and preferences. It is true that this can also be conveyed with direct-key-signatures (a self-signature directly on a key which was mainly introduced for dedicated revocations). However, this is a not so well tested feature of gpg and my educated guess is that many other OpenPGP implementations do not handle direct-key signatures in a way compatible to pgp or gpg - if at all. Thus by relying on them we would sail into uncharted waters. > Doing such a merge would be super helpful, particularly for receiving > things like subkey updates and revocation information from I agree that we can add a code path to import a primary key plus revocation certificate but without user-ids. PGP however, does not support this and is the reason why we extended the revocation certifciate with a minmal primary key. Update of subkeys is a different issue and I see no solid use case for allowing that without user-id (cf. expiration date of the primary key). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --lsign --add-me or the invisible WoT
Stefan Claas:
>I lsign Bob's key so third parties do not know (normally) that I did
>this. But how could my friend Alice trust Bob's key she has without
>my non-exportable lsign sig?
>What I tried to propose is an additional parameter, like --add-me
>which would write a 'blob' to a second file.db where I can export
>then Bob's blob (non-compatible to SKS etc.) with my --lsign sig,
>and give it to my friend Alice.
I think, this can be done with GnuPG as it is:
In the following GnuPG invocations $TEMP_KEYRING stands for a
temporary key ring:
(1) export Bob's key from your default key ring, minimize it, and
import it into the temporary one.
$ gpg --export-options=export-minimal \
--export =user_id_of_Bob | \
gpg --no-default-keyring --keyring=$TEMP_KEYRING --import
Now you have Bob's public key minimized in the temporary key
ring.
(2) lsign a user id of Bob:
$ gpg --no-default-keyring --keyring=$TEMP_KEYRING \
--lsign =user_id_of_Bob
(3) export this version of Bob's public key into a public key
block Bob.pubkey, that you can give to Alice:
$ gpg --no-default-keyring --keyring=$TEMP_KEYRING \
--export-options=export-local-sigs \
--output Bob.pubkey \
--export
(4) import your local signature into your default key ring:
$ gpg --import-options=import-local-sigs --import Bob.pubkey
>Later If Alice knows Bob better
>or personally knows him she can --lsign --add-me Bob's key ('blob')
>too and give it to her friend Mary.
Alice would do the same: Import Bob's keyblock Bob.pubkey
into a temporary key ring using
--import-options=import-local-sigs, lsign it there, export it
using --export-options=export-local-sigs into
Bob.pubkey, give Bob.pubkey to Mary and import
Bob.pubkey using --import-options=import-local-sigs in
her default key ring.
Regards
Friedhelm
binkQZjTBxcza.bin
Description: PGP Key 0xD0B55F3592C00CED.
signature.asc
Description: Digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Enigmail
Andrew Gallagher: > On 31/07/2019 13:36, David wrote: >> Enigmail always defaults to the first set of keys one created > > Enigmail will default to the first set of keys in your keyring that > matches the selection criteria. Do you have more than one ID on each > key? Do you have more than one key for each ID? This could be causing > some confusion. > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Andrew, I have one key pair associated with one email address Those keys do not have other ids attached to them. Each key pair is only for a single (not multiple) email account. Regards David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
