From dkg at fifthhorseman.net Sun Sep 1 13:51:44 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 01 Sep 2019 07:51:44 -0400 Subject: first-party attestations of third-party certifications (1pa3pc) in gnupg Message-ID: <874l1w8ca7.fsf@fifthhorseman.net> It would be great if GnuPG could manage first-party attestations of third-party certifications (1pa3pc) as documented in https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20. Attached is a proposal for how the UI/API of GnuPG might enable this. i've also recorded this as https://dev.gnupg.org/T4694/, in the hopes that we can get something like this working. The baseline attestation functionality was fairly straightforward to implement in PGPy, and i'd be happy to collaborate on this if we can get the functionality into some version of GnuPG. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg-attestations.md Type: text/markdown Size: 5371 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jeroen at berkeley.edu Sun Sep 1 17:25:55 2019 From: jeroen at berkeley.edu (Jeroen Ooms) Date: Sun, 1 Sep 2019 17:25:55 +0200 Subject: gpgme_check_version () reports: 1.13.1-unknown Message-ID: In the new version of gpgme that has landed in Debian testing earlier this week: gpgme_check_version (NULL) now returns: "1.13.1-unknown". This breaks the build of bindings that assume the version string is numeric. Where does the "unknown" part originate? Is this intended? From gniibe at fsij.org Mon Sep 2 01:58:48 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 02 Sep 2019 08:58:48 +0900 Subject: Poldi (no-)change Message-ID: <87blw3muvb.fsf@iwagami.gniibe.org> Hello, I maintain Poldi in Debian, as a package maintainer, because it would be useful in some situation. In private mail, I was asked about Poldi in the context of this bug (of libkscreenlocker5): https://bugs.debian.org/934185 Since it is better to discuss in public, I bring it here. In the past, similar bug is reported with SDDM. It was reported to gnupg-devel with a proposed patch for Poldi: https://lists.gnupg.org/pipermail/gnupg-devel/2018-November/thread.html#34063 But, the proposed patch (which removes conversation upcall from Poldi) doesn't work well for other valid use case (of lightdm). So, it was not applied. In my opinion, it is wrong to change Poldi to work around for this kind of bug. This time, I investigated the cause in detail (in my environment). For mine (I use Debian), and the relevant code is: The executable kcheckpass: https://sources.debian.org/src/kscreenlocker/5.14.5-1/kcheckpass/ and The greeter (for GUI): https://sources.debian.org/src/kscreenlocker/5.14.5-1/greeter/ The kcheckpass does it correctly (handling "conv"ersation between PAM module). IIUC, it is the greeter which is need to be fixed. The password is only set once at tryUnlock function at first, and the function which handles conversation between PAM module repeatedly returns this same password by handleVerify function (forever), without asking to a user at all. This implementation only works when a PAM module does no upcall. Te elaborate... The greeter only implements PAM support partially which only works well in a specific situation; It only works when the first pass goes well. It doesn't work well when PAM module asks the second pass (or more) with conversation feature. Here is a figure to explain interaction. ========================== A user of a PAM module A PAM module (greeter+kcheckpass) (libpam-poldi) (1) Simplest case: only with the first pass -->With a PIN from human user Ask authenticate --> <-- PAM_SUCCESS Good, it works. (2) General case(s): multiple passes Ask authenticate --> again: <-- Up call by PAM_CONV for new PIN with a message of error (PIN too short) <-- should ask human user again --> new PIN it answers back with new PIN --> go again if a PAM module asks PAM_CONV again Or, finally it comes with: <-- PAM_SUCCESS or <-- PAM_AUTH_ERR ========================== The greeter never implements the case of (2) correctly: https://sources.debian.org/src/kscreenlocker/5.14.5-1/greeter/authenticator.cpp/#L245 Here, it returns back with same string by GSendStr, without asking new PIN to human. -- From wk at gnupg.org Fri Sep 6 16:51:16 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Sep 2019 16:51:16 +0200 Subject: [PATCH] g10: support --quiet for --send-key In-Reply-To: <20190409174816.18330-1-robbat2@gentoo.org> (Robin H. Johnson's message of "Tue, 9 Apr 2019 10:48:16 -0700") References: <20190409174816.18330-1-robbat2@gentoo.org> Message-ID: <87d0gdo4uz.fsf@wheatstone.g10code.de> On Tue, 9 Apr 2019 10:48, robbat2 at gentoo.org said: > The --recv-key command supports --quiet, but --send-key does not. > Add support for it for parity and better scripting. Done for master and 2.2 Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Fri Sep 6 17:28:44 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Sep 2019 17:28:44 +0200 Subject: [PATCH GnuPG v2] gpg: expand GPG groups when resolving a key In-Reply-To: <15508587.oujxkZr0W8@tauon.chronox.de> (Stephan Mueller's message of "Tue, 19 Feb 2019 08:14:41 +0100") References: <15508587.oujxkZr0W8@tauon.chronox.de> Message-ID: <878sr1o34j.fsf@wheatstone.g10code.de> Hi! It took quite long but finally it landed in master. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jiri.kerestes at trustica.cz Tue Sep 10 16:33:39 2019 From: jiri.kerestes at trustica.cz (Jiri Kerestes) Date: Tue, 10 Sep 2019 16:33:39 +0200 Subject: Generating card keys via gpg-connect-agent Message-ID: <3141935f-0e9f-c5d1-cd01-555db157b433@trustica.cz> Hello, I'm trying to automate generating keys on a smart card using gpg-connect-agent. However, there is no documentation at all on using "SCD GENKEY" command. [1] Running this command generates the key, but the key is not added to the keyring. $ gpg-connect-agent 'SCD GENKEY --force 1' /bye S KEY-CREATED-AT 1568124470 S KEY-DATA q 4023152B5972F631E7CB641A636C060DE8DA6E2233D4B7D81AAAB4FBE0B44612EB S KEY-DATA curve 092B06010401DA470F01 S KEY-FPR 4AC38BF258507FBF1B1E26066291278FDDA260D1 OK Log inspection shows that 'gpg --card-edit' does not pass user-supplied information (e.g. name, email, key expiration date) to gpg-agent, so it must use some other mechanism. Is it even possible to generate keys on smart card using just gpg-agent? [1]: https://gnupg.org/documentation/manuals/gnupg/Scdaemon-GENKEY.html Best regards, Jiri From wk at gnupg.org Tue Sep 10 18:23:37 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Sep 2019 18:23:37 +0200 Subject: Generating card keys via gpg-connect-agent In-Reply-To: <3141935f-0e9f-c5d1-cd01-555db157b433@trustica.cz> (Jiri Kerestes's message of "Tue, 10 Sep 2019 16:33:39 +0200") References: <3141935f-0e9f-c5d1-cd01-555db157b433@trustica.cz> Message-ID: <8736h4m86u.fsf@wheatstone.g10code.de> On Tue, 10 Sep 2019 16:33, jiri.kerestes at trustica.cz said: > I'm trying to automate generating keys on a smart card using > gpg-connect-agent. However, there is no documentation at all on using > "SCD GENKEY" command. [1] as with all IPC commands you can use help. In this case: # GENKEY [--force] [--timestamp=] # # Generate a key on-card identified by , which is application # specific. Return values are also application specific. For OpenPGP # cards 3 status lines are returned: # # S KEY-FPR # S KEY-CREATED-AT # S KEY-DATA [-|p|n] # # 'p' and 'n' are the names of the RSA parameters; '-' is used to # indicate that HEXDATA is the first chunk of a parameter given # by the next KEY-DATA. Only used by GnuPG version < 2.1. # # --force is required to overwrite an already existing key. The # KEY-CREATED-AT is required for further processing because it is # part of the hashed key material for the fingerprint. # # If --timestamp is given an OpenPGP key will be created using this # value. The value needs to be in ISO Format; e.g. # "--timestamp=20030316T120000" and after 1970-01-01 00:00:00. # # The public part of the key can also later be retrieved using the # READKEY command. > Running this command generates the key, but the key is not added to the > keyring. You asked gpg-agent/scdaemon to create a key. This is an internal (also stable) command which is used by gpg to create key. > Log inspection shows that 'gpg --card-edit' does not pass user-supplied > information (e.g. name, email, key expiration date) to gpg-agent, so it > must use some other mechanism. You can use gpg --command-fd FD1 --status-fd FD2 --edit-key to do that. It is a bit complicated because you need to write a FSM to answer the prompts from gpg. Kleopatra and GPA use this method. > Is it even possible to generate keys on smart card using just gpg-agent? Yes, but you need to create a corresponding OpenPGP key then latter. You use the 'keygrip' method for this. If this is for a new project, I'd suggest that you look at gnupg's master branch in the repo which features the new tool gpg-card which has all kind of support to script stuff for cards. The plan is to release GnuPG 2.3 (i.e. master) by the end of the year. Shalom-Salam, Werner ps. List of commands implemented in gpg-card: --8<---------------cut here---------------start------------->8--- quit quit this menu help show this help list list all available data name change card holder's name url change URL to retrieve key fetch fetch the key specified in the card URL login change the login name lang change the language preferences salutation change card holder's salutation cafpr change a CA fingerprint forcesig toggle the signature force PIN flag generate generate new keys passwd menu to change or unblock the PIN verify verify the PIN and list all data unblock unblock the PIN using a Reset Code authenticate authenticate to the card reset send a reset to the card daemon factory-reset destroy all keys and data kdf-setup setup KDF for PIN authentication key-attr change the key attribute uif change the User Interaction Flag privatedo change a private data object readcert read a certificate from a data object writecert store a certificate to a data object writekey store a private key to a data object yubikey Yubikey management commands --8<---------------cut here---------------end--------------->8--- The man page (not up-to-date despite the recent date): --8<---------------cut here---------------start------------->8--- GPG-CARD(1) GNU Privacy Guard 2.2 GPG-CARD(1) NAME gpg-card - Administrate Smart Cards SYNOPSIS gpg-card [options] gpg-card [options] command { -- command } DESCRIPTION The gpg-card is used to administrate smart cards and USB tokens. It provides a superset of fea- tures from gpg --card-edit an can be considered a frontend to scdaemon which is a daemon started by gpg-agent to handle smart cards. If gpg-card is invoked without commands an interactive mode is used. If gpg-card is invoked with one or more commands the same commands as available in the interactive mode are run from the command line. These commands need to be delimited with a double-dash. If a double-dash or a shell specific character is required as part of a command the entire command needs to be put in quotes. If one of those commands returns an error the remaining commands are mot any- more run unless the command was prefixed with a single dash. A list of commands is available by using the command help and a detailed description of each com- mand is printed by using help COMMAND. See the NOTES sections for instructions pertaining to specific cards or card applications. OPTIONS gpg-card understands these options: --with-colons This option has currently no effect. --status-fd n Write special status strings to the file descriptor n. This program returns only the status messages SUCCESS or FAILURE which are helpful when the caller uses a double fork approach and can't easily get the return code of the process. --verbose Enable extra informational output. --quiet Disable almost all informational output. --version Print version of the program and exit. --help Display a brief help page and exit. --no-autostart Do not start the gpg-agent if it has not yet been started and its service is required. This option is mostly useful on machines where the connection to gpg-agent has been redirected to another machines. --agent-program file Specify the agent program to be started if none is running. The default value is determined by running gpgconf with the option --list-dirs. --gpg-program file Specify a non-default gpg binary to be used by certain commands. --gpgsm-program file Specify a non-default gpgsm binary to be used by certain commands. NOTES (OPENPGP) The support for OpenPGP cards in gpg-card is not yet complete. For missing features, please continue to use gpg --card-edit. NOTES (PIV) GnuPG has support for PIV cards (``Personal Identity Verification'' as specified by NIST Special Publication 800-73-4). This section describes how to initialize (personalize) a fresh Yubikey token featuring the PIV application (requires Yubikey-5). We assume that the credentials have not yet been changed and thus are: Authentication key This is a 24 byte key described by the hex string 010203040506070801020304050607080102030405060708. PIV Application PIN This is the string 123456. PIN Unblocking Key This is the string 12345678. See the example section on how to change these defaults. For production use it is important to use secure values for them. Note that the Authentication Key is not queried via the usual Pinentry dialog but needs to be entered manually or read from a file. The use of a dedicated machine to personalize tokens is strongly suggested. To see what is on the card, the command list can be given. We will use the interactive mode in the following (the string gpg/card> is the prompt). An example output for a fresh card is: gpg/card> list Reader ...........: 1050:0407:X:0 Card type ........: yubikey Card firmware ....: 5.1.2 Serial number ....: D2760001240102010006090746250000 Application type .: OpenPGP Version ..........: 2.1 [...] It can be seen by the ``Application type'' line that GnuPG selected the OpenPGP application of the Yubikey. This is because GnuPG assigns the highest priority to the OpenPGP application. To use the PIV application of the Yubikey several methods can be used: With a Yubikey 5 or later the OpenPGP application on the Yubikey can be disabled: gpg/card> yubikey disable all opgp gpg/card> yubikey list Application USB NFC ----------------------- OTP yes yes U2F yes yes OPGP no no PIV yes no OATH yes yes FIDO2 yes yes gpg/card> reset The reset is required so that the GnuPG system rereads the card. Note that disabled applications keep all their data and can at any time be re-enabled (use 'help yubikey'). Another option, which works for all Yubikey versions, is to disable the support for OpenPGP cards in scdaemon. This is done by adding the line disable-application openpgp to '~/.gnupg/scdaemon.conf' and by restarting scdaemon, either by killing the process or by using 'gpgconf --kill scdaemon'. Finally the default order in which card applications are tried by scdaemon can be changed. For example to prefer PIV over OpenPGP it is sufficient to add application-priority piv to '~/.gnupg/scdaemon.conf' and to restart scdaemon. This has an effect only on tokens which sup- port both, PIV and OpenPGP, but does not hamper the use of OpenPGP only tokens. With one of these methods employed the list command of gpg-card shows this: gpg/card> list Reader ...........: 1050:0407:X:0 Card type ........: yubikey Card firmware ....: 5.1.2 Serial number ....: FF020001008A77C1 Application type .: PIV Version ..........: 1.0 Displayed s/n ....: yk-9074625 PIN usage policy .: app-pin PIN retry counter : - 3 - PIV authentication: [none] keyref .....: PIV.9A Card authenticat. : [none] keyref .....: PIV.9E Digital signature : [none] keyref .....: PIV.9C Key management ...: [none] keyref .....: PIV.9D In case several tokens are plugged into the computer, gpg-card will show only one. To show another token the number of the token (0, 1, 2, ...) can be given as an argument to the list command. The command 'list --cards' prints a list of all inserted tokens. Note that the ``Displayed s/n'' is printed on the token and also shown in Pinentry prompts asking for the PIN. The four standard key slots are always shown, if other key slots are initialized they are shown as well. The PIV authentication key (internal reference PIV.9A) is used to authenticate the card and the card holder. The use of the associated private key is protected by the Applica- tion PIN which needs to be provided once and the key can the be used until the card is reset or removed from the reader or USB port. GnuPG uses this key with its Secure Shell support. The Card authentication key (PIV.9E) is also known as the CAK and used to support physical access applica- tions. The private key is not protected by a PIN and can thus immediately be used. The Digital signature key (PIV.9C) is used to digitally sign documents. The use of the associated private key is protected by the Application PIN which needs to be provided for each signing operation. The Key management key (PIV.9D) is used for encryption. The use of the associated private key is protected by the Application PIN which needs to be provided only once so that decryption operations can then be done until the card is reset or removed from the reader or USB port. We now generate three of the four keys. Note that GnuPG does currently not use the the Card authentication key; however, that key is mandatory by the PIV standard and thus we create it too. Key generation requires that we authenticate to the card. This can be done either on the command line (which would reveal the key): gpg/card> auth 010203040506070801020304050607080102030405060708 or by reading the key from a file. That file needs to consist of one LF terminated line with the hex encoded key (as above): gpg/card> auth < myauth.key As usual 'help auth' gives help for this command. An error message is printed if a non-matching key is used. The authentication is valid until a reset of the card or until the card is removed from the reader or the USB port. Note that that in non-interactive mode the '<' needs to be quoted so that the shell does not interpret it as a its own redirection symbol. Here are the actual commands to generate the keys: gpg/card> generate --algo=nistp384 PIV.9A PIV card no. yk-9074625 detected gpg/card> generate --algo=nistp256 PIV.9E PIV card no. yk-9074625 detected gpg/card> generate --algo=rsa2048 PIV.9C PIV card no. yk-9074625 detected If a key has already been created for one of the slots an error will be printed; to create a new key anyway the option '--force' can be used. Note that only the private and public keys have been created but no certificates are stored in the key slots. In fact, GnuPG uses its own non-standard method to store just the public key in place of the the certificate. Other application will not be able to make use these keys until gpgsm or another tool has been used to create and store the respective certificates. Let us see what the list command now shows: gpg/card> list Reader ...........: 1050:0407:X:0 Card type ........: yubikey Card firmware ....: 5.1.2 Serial number ....: FF020001008A77C1 Application type .: PIV Version ..........: 1.0 Displayed s/n ....: yk-9074625 PIN usage policy .: app-pin PIN retry counter : - 3 - PIV authentication: 213D1825FDE0F8240CB4E4229F01AF90AC658C2E keyref .....: PIV.9A (auth) algorithm ..: nistp384 Card authenticat. : 7A53E6CFFE7220A0E646B4632EE29E5A7104499C keyref .....: PIV.9E (auth) algorithm ..: nistp256 Digital signature : 32A6C6FAFCB8421878608AAB452D5470DD3223ED keyref .....: PIV.9C (sign,cert) algorithm ..: rsa2048 Key management ...: [none] keyref .....: PIV.9D The primary information for each key is the keygrip, a 40 byte hex-string identifying the key. This keygrip is a unique identifier for the specific parameters of a key. It is used by gpg-agent and other parts of GnuPG to associate a private key to its protocol specific certificate format (X.509, OpenPGP, or SecureShell). Below the keygrip the key reference along with the key usage capabilities are show. Finally the algorithm is printed in the format used by {gpg}. At that point no other information is shown because for these new keys gpg won't be able to find matching certificates. Although we could have created the Key management key also with the generate command, we will cre- ate that key off-card so that a backup exists. To accomplish this a key needs to be created with either gpg or gpgsm or imported in one of these tools. In our example we create a self-signed X.509 certificate (exit the gpg-card tool, first): $ gpgsm --gen-key -o encr.crt (1) RSA (2) Existing key (3) Existing key from card Your selection? 1 What keysize do you want? (3072) 2048 Requested keysize is 2048 bits Possible actions for a RSA key: (1) sign, encrypt (2) sign (3) encrypt Your selection? 3 Enter the X.509 subject name: CN=Encryption key for yk-9074625,O=example,C=DE Enter email addresses (end with an empty line): > otto at example.net > Enter DNS names (optional; end with an empty line): > Enter URIs (optional; end with an empty line): > Create self-signed certificate? (y/N) y These parameters are used: Key-Type: RSA Key-Length: 2048 Key-Usage: encrypt Serial: random Name-DN: CN=Encryption key for yk-9074625,O=example,C=DE Name-Email: otto at example.net Proceed with creation? (y/N) Now creating self-signed certificate. This may take a while ... gpgsm: about to sign the certificate for key: &34798AAFE0A7565088101CC4AE31C5C8C74461CB gpgsm: certificate created Ready. $ gpgsm --import encr.crt gpgsm: certificate imported gpgsm: total number processed: 1 gpgsm: imported: 1 Note the last step which imported the created certificate. If you you instead created a certifi- cate signing request (CSR) instead of a self-signed certificate and sent this off to a CA you would do the same import step with the certificate received from the CA. Take note of the keygrip (pre- fixed with an ampersand) as shown during the certificate creation or listed it again using 'gpgsm --with-keygrip -k otto at example.net'. Now to move the key and certificate to the card start gpg- card again and enter: gpg/card> writekey PIV.9D 34798AAFE0A7565088101CC4AE31C5C8C74461CB gpg/card> writecert PIV.9D < encr.crt If you entered a passphrase to protect the private key, you will be asked for it via the Pinentry prompt. On success the key and the certificate has been written to the card and a list command shows: [...] Key management ...: 34798AAFE0A7565088101CC4AE31C5C8C74461CB keyref .....: PIV.9D (encr) algorithm ..: rsa2048 used for ...: X.509 user id ..: CN=Encryption key for yk-9074625,O=example,C=DE user id ..: In case the same key (identified by the keygrip) has been used for several certificates you will see several ``used for'' parts. With this the encryption key is now fully functional and can be used to decrypt messages encrypted to this certificate. Take care: the original key is still stored on-disk and should be moved to a backup medium. This can simply be done by copying the file '34798AAFE0A7565088101CC4AE31C5C8C74461CB.key' from the directory '~/.gnupg/private-keys-v1.d/' to the backup medium and deleting the file at its original place. The final example is to create a self-signed certificate for digital signatures. Leave gpg-card using quit or by pressing Control-D and use gpgsm: $ gpgsm --learn $ gpgsm --gen-key -o sign.crt Please select what kind of key you want: (1) RSA (2) Existing key (3) Existing key from card Your selection? 3 Serial number of the card: FF020001008A77C1 Available keys: (1) 213D1825FDE0F8240CB4E4229F01AF90AC658C2E PIV.9A nistp384 (2) 7A53E6CFFE7220A0E646B4632EE29E5A7104499C PIV.9E nistp256 (3) 32A6C6FAFCB8421878608AAB452D5470DD3223ED PIV.9C rsa2048 (4) 34798AAFE0A7565088101CC4AE31C5C8C74461CB PIV.9D rsa2048 Your selection? 3 Possible actions for a RSA key: (1) sign, encrypt (2) sign (3) encrypt Your selection? 2 Enter the X.509 subject name: CN=Signing key for yk-9074625,O=example,C=DE Enter email addresses (end with an empty line): > otto at example.net > Enter DNS names (optional; end with an empty line): > Enter URIs (optional; end with an empty line): > Create self-signed certificate? (y/N) These parameters are used: Key-Type: card:PIV.9C Key-Length: 1024 Key-Usage: sign Serial: random Name-DN: CN=Signing key for yk-9074625,O=example,C=DE Name-Email: otto at example.net Proceed with creation? (y/N) y Now creating self-signed certificate. This may take a while ... gpgsm: about to sign the certificate for key: &32A6C6FAFCB8421878608AAB452D5470DD3223ED gpgsm: certificate created Ready. $ gpgsm --import sign.crt gpgsm: certificate imported gpgsm: total number processed: 1 gpgsm: imported: 1 The use of 'gpgsm --learn' is currently necessary so that gpg-agent knows what keys are available on the card. The need for this command will eventually be removed. The remaining commands are similar to the creation of an on-disk key. However, here we select the 'Digital signature' key. During the creation process you will be asked for the Application PIN of the card. The final step is to write the certificate to the card using gpg-card: gpg/card> writecert PIV.9C < sign.crt By running list again we will see the fully initialized card: Reader ...........: 1050:0407:X:0 Card type ........: yubikey Card firmware ....: 5.1.2 Serial number ....: FF020001008A77C1 Application type .: PIV Version ..........: 1.0 Displayed s/n ....: yk-9074625 PIN usage policy .: app-pin PIN retry counter : - [verified] - PIV authentication: 213D1825FDE0F8240CB4E4229F01AF90AC658C2E keyref .....: PIV.9A (auth) algorithm ..: nistp384 Card authenticat. : 7A53E6CFFE7220A0E646B4632EE29E5A7104499C keyref .....: PIV.9E (auth) algorithm ..: nistp256 Digital signature : 32A6C6FAFCB8421878608AAB452D5470DD3223ED keyref .....: PIV.9C (sign,cert) algorithm ..: rsa2048 used for ...: X.509 user id ..: CN=Signing key for yk-9074625,O=example,C=DE user id ..: Key management ...: 34798AAFE0A7565088101CC4AE31C5C8C74461CB keyref .....: PIV.9D (encr) algorithm ..: rsa2048 used for ...: X.509 user id ..: CN=Encryption key for yk-9074625,O=example,C=DE user id ..: It is now possible to sign and to encrypt with this card using gpgsm and to use the 'PIV authenti- cation' key with ssh: $ ssh-add -l 384 SHA256:0qnJ0Y0ehWxKcx2frLfEljf6GCdlO55OZed5HqGHsaU cardno:yk-9074625 (ECDSA) As usual use ssh-add with the uppercase '-L' to list the public ssh key. To use the certificates with Thunderbird or Mozilla, please consult the Scute manual for details. If you want to use the same PIV keys also for OpenPGP (for example on a Yubikey to avoid switching between OpenPGP and PIV), this is also possible: $ gpgsm --learn $ gpg --full-gen-key Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (14) Existing key from card Your selection? 14 Serial number of the card: FF020001008A77C1 Available keys: (1) 213D1825FDE0F8240CB4E4229F01AF90AC658C2E PIV.9A nistp384 (auth) (2) 7A53E6CFFE7220A0E646B4632EE29E5A7104499C PIV.9E nistp256 (auth) (3) 32A6C6FAFCB8421878608AAB452D5470DD3223ED PIV.9C rsa2048 (cert,sign) (4) 34798AAFE0A7565088101CC4AE31C5C8C74461CB PIV.9D rsa2048 (encr) Your selection? 3 Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: Email address: otto at example.net Comment: You selected this USER-ID: "otto at example.net" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o gpg: key C3AFA9ED971BB365 marked as ultimately trusted gpg: revocation certificate stored as '[...]D971BB365.rev' public and secret key created and signed. Note that this key cannot be used for encryption. You may want to use the command "--edit-key" to generate a subkey for this purpose. pub rsa2048 2019-04-04 [SC] 7F899AE2FB73159DD68A1B20C3AFA9ED971BB365 uid otto at example.net Note that you will be asked two times to enter the PIN of your PIV card. If you run gpg in --expert mode you will also ge given the option to change the usage flags of the key. The next typescript shows how to add the encryption subkey: $ gpg --edit-key 7F899AE2FB73159DD68A1B20C3AFA9ED971BB365 Secret key is available. sec rsa2048/C3AFA9ED971BB365 created: 2019-04-04 expires: never usage: SC card-no: FF020001008A77C1 trust: ultimate validity: ultimate [ultimate] (1). otto at example.net gpg> addkey Secret parts of primary key are stored on-card. Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (14) Existing key from card Your selection? 14 Serial number of the card: FF020001008A77C1 Available keys: (1) 213D1825FDE0F8240CB4E4229F01AF90AC658C2E PIV.9A nistp384 (auth) (2) 7A53E6CFFE7220A0E646B4632EE29E5A7104499C PIV.9E nistp256 (auth) (3) 32A6C6FAFCB8421878608AAB452D5470DD3223ED PIV.9C rsa2048 (cert,sign) (4) 34798AAFE0A7565088101CC4AE31C5C8C74461CB PIV.9D rsa2048 (encr) Your selection? 4 Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y Really create? (y/N) y sec rsa2048/C3AFA9ED971BB365 created: 2019-04-04 expires: never usage: SC card-no: FF020001008A77C1 trust: ultimate validity: ultimate ssb rsa2048/7067860A98FCE6E1 created: 2019-04-04 expires: never usage: E card-no: FF020001008A77C1 [ultimate] (1). otto at example.net gpg> save Now you can use your PIV card also with gpg. SEE ALSO scdaemon(1) GnuPG 2.3.0-beta911 2019-08-30 GPG-CARD(1) --8<---------------cut here---------------end--------------->8--- -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Sep 10 20:30:24 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Sep 2019 20:30:24 +0200 Subject: Generating card keys via gpg-connect-agent In-Reply-To: <8736h4m86u.fsf@wheatstone.g10code.de> (Werner Koch via Gnupg-devel's message of "Tue, 10 Sep 2019 18:23:37 +0200") References: <3141935f-0e9f-c5d1-cd01-555db157b433@trustica.cz> <8736h4m86u.fsf@wheatstone.g10code.de> Message-ID: <87mufcuhq7.fsf@wheatstone.g10code.de> On Tue, 10 Sep 2019 18:23, gnupg-devel at gnupg.org said: > as with all IPC commands you can use help. In this case: Forgot to paste the first line $ gpg-connect-agent > scd help genkey # GENKEY [--force] [--timestamp=] "SCD" is a commnd which diverts to the scdameon while keeping the pinentry functionality. Note that gpg-agent has its own genkey command: "help genkey" would show that one. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jason.franklin at quoininc.com Tue Sep 10 21:38:33 2019 From: jason.franklin at quoininc.com (Franklin, Jason) Date: Tue, 10 Sep 2019 15:38:33 -0400 Subject: Poldi (no-)change In-Reply-To: <87blw3muvb.fsf@iwagami.gniibe.org> References: <87blw3muvb.fsf@iwagami.gniibe.org> Message-ID: On 9/1/19 7:58 PM, NIIBE Yutaka wrote: > In private mail, I was asked about Poldi in the context of this bug (of > libkscreenlocker5): > > https://bugs.debian.org/934185 > > Since it is better to discuss in public, I bring it here. > > In the past, similar bug is reported with SDDM. It was reported to > gnupg-devel with a proposed patch for Poldi: > > https://lists.gnupg.org/pipermail/gnupg-devel/2018-November/thread.html#34063 The bug reports above are pretty important to me. I have written and submitted a patch that fixes the KScreenLocker greeter, and I have submitted it to the upstream developers of that project. See the link below: https://phabricator.kde.org/D23849 Any help reviewing/testing this change would be very much welcome! -- Jason Franklin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From jiri.kerestes at trustica.cz Wed Sep 11 09:50:23 2019 From: jiri.kerestes at trustica.cz (Jiri Kerestes) Date: Wed, 11 Sep 2019 09:50:23 +0200 Subject: Generating card keys via gpg-connect-agent In-Reply-To: <8736h4m86u.fsf@wheatstone.g10code.de> References: <3141935f-0e9f-c5d1-cd01-555db157b433@trustica.cz> <8736h4m86u.fsf@wheatstone.g10code.de> Message-ID: Thanks, gpg-card looks exactly like the thing I'm looking for. Best regards, Jiri On 10. 09. 19 18:23, Werner Koch wrote: > On Tue, 10 Sep 2019 16:33, jiri.kerestes at trustica.cz said: > >> I'm trying to automate generating keys on a smart card using >> gpg-connect-agent. However, there is no documentation at all on using >> "SCD GENKEY" command. [1] > > as with all IPC commands you can use help. In this case: > > # GENKEY [--force] [--timestamp=] > # > # Generate a key on-card identified by , which is application > # specific. Return values are also application specific. For OpenPGP > # cards 3 status lines are returned: > # > # S KEY-FPR > # S KEY-CREATED-AT > # S KEY-DATA [-|p|n] > # > # 'p' and 'n' are the names of the RSA parameters; '-' is used to > # indicate that HEXDATA is the first chunk of a parameter given > # by the next KEY-DATA. Only used by GnuPG version < 2.1. > # > # --force is required to overwrite an already existing key. The > # KEY-CREATED-AT is required for further processing because it is > # part of the hashed key material for the fingerprint. > # > # If --timestamp is given an OpenPGP key will be created using this > # value. The value needs to be in ISO Format; e.g. > # "--timestamp=20030316T120000" and after 1970-01-01 00:00:00. > # > # The public part of the key can also later be retrieved using the > # READKEY command. > >> Running this command generates the key, but the key is not added to the >> keyring. > > You asked gpg-agent/scdaemon to create a key. This is an internal (also > stable) command which is used by gpg to create key. > >> Log inspection shows that 'gpg --card-edit' does not pass user-supplied >> information (e.g. name, email, key expiration date) to gpg-agent, so it >> must use some other mechanism. > > You can use > > gpg --command-fd FD1 --status-fd FD2 --edit-key > > to do that. It is a bit complicated because you need to write a FSM to > answer the prompts from gpg. Kleopatra and GPA use this method. > >> Is it even possible to generate keys on smart card using just gpg-agent? > > Yes, but you need to create a corresponding OpenPGP key then latter. > You use the 'keygrip' method for this. > > If this is for a new project, I'd suggest that you look at gnupg's > master branch in the repo which features the new tool gpg-card which has > all kind of support to script stuff for cards. The plan is to release > GnuPG 2.3 (i.e. master) by the end of the year. > > > > Shalom-Salam, > > Werner > > > > ps. > List of commands implemented in gpg-card: > --8<---------------cut here---------------start------------->8--- > quit quit this menu > help show this help > list list all available data > name change card holder's name > url change URL to retrieve key > fetch fetch the key specified in the card URL > login change the login name > lang change the language preferences > salutation change card holder's salutation > cafpr change a CA fingerprint > forcesig toggle the signature force PIN flag > generate generate new keys > passwd menu to change or unblock the PIN > verify verify the PIN and list all data > unblock unblock the PIN using a Reset Code > authenticate authenticate to the card > reset send a reset to the card daemon > factory-reset destroy all keys and data > kdf-setup setup KDF for PIN authentication > key-attr change the key attribute > uif change the User Interaction Flag > privatedo change a private data object > readcert read a certificate from a data object > writecert store a certificate to a data object > writekey store a private key to a data object > yubikey Yubikey management commands > --8<---------------cut here---------------end--------------->8--- > > > The man page (not up-to-date despite the recent date): > > --8<---------------cut here---------------start------------->8--- > GPG-CARD(1) GNU Privacy Guard 2.2 GPG-CARD(1) > > > > NAME > gpg-card - Administrate Smart Cards > > SYNOPSIS > gpg-card [options] > gpg-card [options] command { -- command } > > > DESCRIPTION > > The gpg-card is used to administrate smart cards and USB tokens. > It provides a superset of fea- tures from gpg --card-edit an can > be considered a frontend to scdaemon which is a daemon started by > gpg-agent to handle smart cards. > > If gpg-card is invoked without commands an interactive mode is > used. > > If gpg-card is invoked with one or more commands the same > commands as available in the interactive mode are run from the > command line. These commands need to be delimited with a > double-dash. If a double-dash or a shell specific character is > required as part of a command the entire command needs to be put > in quotes. If one of those commands returns an error the > remaining commands are mot any- more run unless the command was > prefixed with a single dash. > > A list of commands is available by using the command help and a > detailed description of each com- mand is printed by using help > COMMAND. > > See the NOTES sections for instructions pertaining to specific > cards or card applications. > > > OPTIONS > gpg-card understands these options: > > > > --with-colons > This option has currently no effect. > > > --status-fd n > > Write special status strings to the file descriptor n. > This program returns only the status messages SUCCESS or > FAILURE which are helpful when the caller uses a double > fork approach and can't easily get the return code of the > process. > > > --verbose > Enable extra informational output. > > > --quiet > Disable almost all informational output. > > > --version > Print version of the program and exit. > > > --help Display a brief help page and exit. > > > --no-autostart > > Do not start the gpg-agent if it has not yet been started > and its service is required. This option is mostly useful > on machines where the connection to gpg-agent has been > redirected to another machines. > > > --agent-program file > > Specify the agent program to be started if none is > running. The default value is determined by running > gpgconf with the option --list-dirs. > > > --gpg-program file > Specify a non-default gpg binary to be used by certain commands. > > > --gpgsm-program file > Specify a non-default gpgsm binary to be used by certain commands. > > > NOTES (OPENPGP) > > The support for OpenPGP cards in gpg-card is not yet complete. > For missing features, please continue to use gpg --card-edit. > > > NOTES (PIV) > > GnuPG has support for PIV cards (``Personal Identity > Verification'' as specified by NIST Special Publication > 800-73-4). This section describes how to initialize > (personalize) a fresh Yubikey token featuring the PIV application > (requires Yubikey-5). We assume that the credentials have not > yet been changed and thus are: > > Authentication key > This is a 24 byte key described by the hex string > 010203040506070801020304050607080102030405060708. > > PIV Application PIN > This is the string 123456. > > PIN Unblocking Key > This is the string 12345678. > > See the example section on how to change these defaults. For > production use it is important to use secure values for them. > Note that the Authentication Key is not queried via the usual > Pinentry dialog but needs to be entered manually or read from a > file. The use of a dedicated machine to personalize tokens is > strongly suggested. > > To see what is on the card, the command list can be given. We > will use the interactive mode in the following (the string > gpg/card> is the prompt). An example output for a fresh card is: > > gpg/card> list > Reader ...........: 1050:0407:X:0 > Card type ........: yubikey > Card firmware ....: 5.1.2 > Serial number ....: D2760001240102010006090746250000 > Application type .: OpenPGP > Version ..........: 2.1 > [...] > > It can be seen by the ``Application type'' line that GnuPG > selected the OpenPGP application of the Yubikey. This is because > GnuPG assigns the highest priority to the OpenPGP application. > To use the PIV application of the Yubikey several methods can be > used: > > With a Yubikey 5 or later the OpenPGP application on the Yubikey > can be disabled: > > gpg/card> yubikey disable all opgp > gpg/card> yubikey list > Application USB NFC > ----------------------- > OTP yes yes > U2F yes yes > OPGP no no > PIV yes no > OATH yes yes > FIDO2 yes yes > gpg/card> reset > > The reset is required so that the GnuPG system rereads the card. > Note that disabled applications keep all their data and can at > any time be re-enabled (use 'help yubikey'). > > Another option, which works for all Yubikey versions, is to > disable the support for OpenPGP cards in scdaemon. This is done > by adding the line > > disable-application openpgp > > to '~/.gnupg/scdaemon.conf' and by restarting scdaemon, either by > killing the process or by using 'gpgconf --kill scdaemon'. > Finally the default order in which card applications are tried by > scdaemon can be changed. For example to prefer PIV over OpenPGP > it is sufficient to add > > application-priority piv > > to '~/.gnupg/scdaemon.conf' and to restart scdaemon. This has an > effect only on tokens which sup- port both, PIV and OpenPGP, but > does not hamper the use of OpenPGP only tokens. > > With one of these methods employed the list command of gpg-card > shows this: > > gpg/card> list > Reader ...........: 1050:0407:X:0 > Card type ........: yubikey > Card firmware ....: 5.1.2 > Serial number ....: FF020001008A77C1 > Application type .: PIV > Version ..........: 1.0 > Displayed s/n ....: yk-9074625 > PIN usage policy .: app-pin > PIN retry counter : - 3 - > PIV authentication: [none] > keyref .....: PIV.9A > Card authenticat. : [none] > keyref .....: PIV.9E > Digital signature : [none] > keyref .....: PIV.9C > Key management ...: [none] > keyref .....: PIV.9D > > In case several tokens are plugged into the computer, gpg-card > will show only one. To show another token the number of the > token (0, 1, 2, ...) can be given as an argument to the list > command. The command 'list --cards' prints a list of all > inserted tokens. > > Note that the ``Displayed s/n'' is printed on the token and also > shown in Pinentry prompts asking for the PIN. The four standard > key slots are always shown, if other key slots are initialized > they are shown as well. The PIV authentication key (internal > reference PIV.9A) is used to authenticate the card and the card > holder. The use of the associated private key is protected by > the Applica- tion PIN which needs to be provided once and the key > can the be used until the card is reset or removed from the > reader or USB port. GnuPG uses this key with its Secure Shell > support. The Card authentication key (PIV.9E) is also known as > the CAK and used to support physical access applica- tions. The > private key is not protected by a PIN and can thus immediately be > used. The Digital signature key (PIV.9C) is used to digitally > sign documents. The use of the associated private key is > protected by the Application PIN which needs to be provided for > each signing operation. The Key management key (PIV.9D) is used > for encryption. The use of the associated private key is > protected by the Application PIN which needs to be provided only > once so that decryption operations can then be done until the > card is reset or removed from the reader or USB port. > > We now generate three of the four keys. Note that GnuPG does > currently not use the the Card authentication key; however, that > key is mandatory by the PIV standard and thus we create it too. > Key generation requires that we authenticate to the card. This > can be done either on the command line (which would reveal the > key): > > gpg/card> auth 010203040506070801020304050607080102030405060708 > > or by reading the key from a file. That file needs to consist of > one LF terminated line with the hex encoded key (as above): > > gpg/card> auth < myauth.key > > As usual 'help auth' gives help for this command. An error > message is printed if a non-matching key is used. The > authentication is valid until a reset of the card or until the > card is removed from the reader or the USB port. Note that that > in non-interactive mode the '<' needs to be quoted so that the > shell does not interpret it as a its own redirection symbol. > > > Here are the actual commands to generate the keys: > > gpg/card> generate --algo=nistp384 PIV.9A > PIV card no. yk-9074625 detected > gpg/card> generate --algo=nistp256 PIV.9E > PIV card no. yk-9074625 detected > gpg/card> generate --algo=rsa2048 PIV.9C > PIV card no. yk-9074625 detected > > If a key has already been created for one of the slots an error > will be printed; to create a new key anyway the option '--force' > can be used. Note that only the private and public keys have > been created but no certificates are stored in the key slots. In > fact, GnuPG uses its own non-standard method to store just the > public key in place of the the certificate. Other application > will not be able to make use these keys until gpgsm or another > tool has been used to create and store the respective > certificates. Let us see what the list command now shows: > > gpg/card> list > Reader ...........: 1050:0407:X:0 > Card type ........: yubikey > Card firmware ....: 5.1.2 > Serial number ....: FF020001008A77C1 > Application type .: PIV > Version ..........: 1.0 > Displayed s/n ....: yk-9074625 > PIN usage policy .: app-pin > PIN retry counter : - 3 - > PIV authentication: 213D1825FDE0F8240CB4E4229F01AF90AC658C2E > keyref .....: PIV.9A (auth) > algorithm ..: nistp384 > Card authenticat. : 7A53E6CFFE7220A0E646B4632EE29E5A7104499C > keyref .....: PIV.9E (auth) > algorithm ..: nistp256 > Digital signature : 32A6C6FAFCB8421878608AAB452D5470DD3223ED > keyref .....: PIV.9C (sign,cert) > algorithm ..: rsa2048 > Key management ...: [none] > keyref .....: PIV.9D > > The primary information for each key is the keygrip, a 40 byte > hex-string identifying the key. This keygrip is a unique > identifier for the specific parameters of a key. It is used by > gpg-agent and other parts of GnuPG to associate a private key to > its protocol specific certificate format (X.509, OpenPGP, or > SecureShell). Below the keygrip the key reference along with the > key usage capabilities are show. Finally the algorithm is > printed in the format used by {gpg}. At that point no other > information is shown because for these new keys gpg won't be able > to find matching certificates. > > Although we could have created the Key management key also with > the generate command, we will cre- ate that key off-card so that > a backup exists. To accomplish this a key needs to be created > with either gpg or gpgsm or imported in one of these tools. In > our example we create a self-signed X.509 certificate (exit the > gpg-card tool, first): > > $ gpgsm --gen-key -o encr.crt > (1) RSA > (2) Existing key > (3) Existing key from card > Your selection? 1 > What keysize do you want? (3072) 2048 > Requested keysize is 2048 bits > Possible actions for a RSA key: > (1) sign, encrypt > (2) sign > (3) encrypt > Your selection? 3 > Enter the X.509 subject name: CN=Encryption key for yk-9074625,O=example,C=DE > Enter email addresses (end with an empty line): > > otto at example.net > > > Enter DNS names (optional; end with an empty line): > > > Enter URIs (optional; end with an empty line): > > > Create self-signed certificate? (y/N) y > These parameters are used: > Key-Type: RSA > Key-Length: 2048 > Key-Usage: encrypt > Serial: random > Name-DN: CN=Encryption key for yk-9074625,O=example,C=DE > Name-Email: otto at example.net > > Proceed with creation? (y/N) > Now creating self-signed certificate. This may take a while ... > gpgsm: about to sign the certificate for key: &34798AAFE0A7565088101CC4AE31C5C8C74461CB > gpgsm: certificate created > Ready. > $ gpgsm --import encr.crt > gpgsm: certificate imported > gpgsm: total number processed: 1 > gpgsm: imported: 1 > > Note the last step which imported the created certificate. If > you you instead created a certifi- cate signing request (CSR) > instead of a self-signed certificate and sent this off to a CA > you would do the same import step with the certificate received > from the CA. Take note of the keygrip (pre- fixed with an > ampersand) as shown during the certificate creation or listed it > again using 'gpgsm --with-keygrip -k otto at example.net'. Now to > move the key and certificate to the card start gpg- card again > and enter: > > gpg/card> writekey PIV.9D 34798AAFE0A7565088101CC4AE31C5C8C74461CB > gpg/card> writecert PIV.9D < encr.crt > > If you entered a passphrase to protect the private key, you will > be asked for it via the Pinentry prompt. On success the key and > the certificate has been written to the card and a list command > shows: > > [...] > Key management ...: 34798AAFE0A7565088101CC4AE31C5C8C74461CB > keyref .....: PIV.9D (encr) > algorithm ..: rsa2048 > used for ...: X.509 > user id ..: CN=Encryption key for yk-9074625,O=example,C=DE > user id ..: > > In case the same key (identified by the keygrip) has been used > for several certificates you will see several ``used for'' parts. > With this the encryption key is now fully functional and can be > used to decrypt messages encrypted to this certificate. Take > care: the original key is still stored on-disk and should be > moved to a backup medium. This can simply be done by copying the > file '34798AAFE0A7565088101CC4AE31C5C8C74461CB.key' from the > directory '~/.gnupg/private-keys-v1.d/' to the backup medium and > deleting the file at its original place. > > The final example is to create a self-signed certificate for > digital signatures. Leave gpg-card using quit or by pressing > Control-D and use gpgsm: > > $ gpgsm --learn > $ gpgsm --gen-key -o sign.crt > Please select what kind of key you want: > (1) RSA > (2) Existing key > (3) Existing key from card > Your selection? 3 > Serial number of the card: FF020001008A77C1 > Available keys: > (1) 213D1825FDE0F8240CB4E4229F01AF90AC658C2E PIV.9A nistp384 > (2) 7A53E6CFFE7220A0E646B4632EE29E5A7104499C PIV.9E nistp256 > (3) 32A6C6FAFCB8421878608AAB452D5470DD3223ED PIV.9C rsa2048 > (4) 34798AAFE0A7565088101CC4AE31C5C8C74461CB PIV.9D rsa2048 > Your selection? 3 > Possible actions for a RSA key: > (1) sign, encrypt > (2) sign > (3) encrypt > Your selection? 2 > Enter the X.509 subject name: CN=Signing key for yk-9074625,O=example,C=DE > Enter email addresses (end with an empty line): > > otto at example.net > > > Enter DNS names (optional; end with an empty line): > > > Enter URIs (optional; end with an empty line): > > > Create self-signed certificate? (y/N) > These parameters are used: > Key-Type: card:PIV.9C > Key-Length: 1024 > Key-Usage: sign > Serial: random > Name-DN: CN=Signing key for yk-9074625,O=example,C=DE > Name-Email: otto at example.net > > Proceed with creation? (y/N) y > Now creating self-signed certificate. This may take a while ... > gpgsm: about to sign the certificate for key: &32A6C6FAFCB8421878608AAB452D5470DD3223ED > gpgsm: certificate created > Ready. > $ gpgsm --import sign.crt > gpgsm: certificate imported > gpgsm: total number processed: 1 > gpgsm: imported: 1 > > The use of 'gpgsm --learn' is currently necessary so that > gpg-agent knows what keys are available on the card. The need > for this command will eventually be removed. The remaining > commands are similar to the creation of an on-disk key. However, > here we select the 'Digital signature' key. During the creation > process you will be asked for the Application PIN of the card. > The final step is to write the certificate to the card using > gpg-card: > > gpg/card> writecert PIV.9C < sign.crt > > By running list again we will see the fully initialized card: > > Reader ...........: 1050:0407:X:0 > Card type ........: yubikey > Card firmware ....: 5.1.2 > Serial number ....: FF020001008A77C1 > Application type .: PIV > Version ..........: 1.0 > Displayed s/n ....: yk-9074625 > PIN usage policy .: app-pin > PIN retry counter : - [verified] - > PIV authentication: 213D1825FDE0F8240CB4E4229F01AF90AC658C2E > keyref .....: PIV.9A (auth) > algorithm ..: nistp384 > Card authenticat. : 7A53E6CFFE7220A0E646B4632EE29E5A7104499C > keyref .....: PIV.9E (auth) > algorithm ..: nistp256 > Digital signature : 32A6C6FAFCB8421878608AAB452D5470DD3223ED > keyref .....: PIV.9C (sign,cert) > algorithm ..: rsa2048 > used for ...: X.509 > user id ..: CN=Signing key for yk-9074625,O=example,C=DE > user id ..: > Key management ...: 34798AAFE0A7565088101CC4AE31C5C8C74461CB > keyref .....: PIV.9D (encr) > algorithm ..: rsa2048 > used for ...: X.509 > user id ..: CN=Encryption key for yk-9074625,O=example,C=DE > user id ..: > > It is now possible to sign and to encrypt with this card using > gpgsm and to use the 'PIV authenti- cation' key with ssh: > > $ ssh-add -l > 384 SHA256:0qnJ0Y0ehWxKcx2frLfEljf6GCdlO55OZed5HqGHsaU cardno:yk-9074625 (ECDSA) > > As usual use ssh-add with the uppercase '-L' to list the public > ssh key. To use the certificates with Thunderbird or Mozilla, > please consult the Scute manual for details. > > If you want to use the same PIV keys also for OpenPGP (for > example on a Yubikey to avoid switching between OpenPGP and PIV), > this is also possible: > > $ gpgsm --learn > $ gpg --full-gen-key > Please select what kind of key you want: > (1) RSA and RSA (default) > (2) DSA and Elgamal > (3) DSA (sign only) > (4) RSA (sign only) > (14) Existing key from card > Your selection? 14 > Serial number of the card: FF020001008A77C1 > Available keys: > (1) 213D1825FDE0F8240CB4E4229F01AF90AC658C2E PIV.9A nistp384 (auth) > (2) 7A53E6CFFE7220A0E646B4632EE29E5A7104499C PIV.9E nistp256 (auth) > (3) 32A6C6FAFCB8421878608AAB452D5470DD3223ED PIV.9C rsa2048 (cert,sign) > (4) 34798AAFE0A7565088101CC4AE31C5C8C74461CB PIV.9D rsa2048 (encr) > Your selection? 3 > Please specify how long the key should be valid. > 0 = key does not expire > = key expires in n days > w = key expires in n weeks > m = key expires in n months > y = key expires in n years > Key is valid for? (0) > Key does not expire at all > Is this correct? (y/N) y > > GnuPG needs to construct a user ID to identify your key. > > Real name: > Email address: otto at example.net > Comment: > You selected this USER-ID: > "otto at example.net" > > Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o > gpg: key C3AFA9ED971BB365 marked as ultimately trusted > gpg: revocation certificate stored as '[...]D971BB365.rev' > public and secret key created and signed. > > Note that this key cannot be used for encryption. You may want to use > the command "--edit-key" to generate a subkey for this purpose. > pub rsa2048 2019-04-04 [SC] > 7F899AE2FB73159DD68A1B20C3AFA9ED971BB365 > uid otto at example.net > > Note that you will be asked two times to enter the PIN of your > PIV card. If you run gpg in --expert mode you will also ge given > the option to change the usage flags of the key. The next > typescript shows how to add the encryption subkey: > > $ gpg --edit-key 7F899AE2FB73159DD68A1B20C3AFA9ED971BB365 > Secret key is available. > > sec rsa2048/C3AFA9ED971BB365 > created: 2019-04-04 expires: never usage: SC > card-no: FF020001008A77C1 > trust: ultimate validity: ultimate > [ultimate] (1). otto at example.net > gpg> addkey > Secret parts of primary key are stored on-card. > Please select what kind of key you want: > (3) DSA (sign only) > (4) RSA (sign only) > (5) Elgamal (encrypt only) > (6) RSA (encrypt only) > (14) Existing key from card > Your selection? 14 > Serial number of the card: FF020001008A77C1 > Available keys: > (1) 213D1825FDE0F8240CB4E4229F01AF90AC658C2E PIV.9A nistp384 (auth) > (2) 7A53E6CFFE7220A0E646B4632EE29E5A7104499C PIV.9E nistp256 (auth) > (3) 32A6C6FAFCB8421878608AAB452D5470DD3223ED PIV.9C rsa2048 (cert,sign) > (4) 34798AAFE0A7565088101CC4AE31C5C8C74461CB PIV.9D rsa2048 (encr) > Your selection? 4 > Please specify how long the key should be valid. > 0 = key does not expire > = key expires in n days > w = key expires in n weeks > m = key expires in n months > y = key expires in n years > Key is valid for? (0) > Key does not expire at all > Is this correct? (y/N) y > Really create? (y/N) y > > sec rsa2048/C3AFA9ED971BB365 > created: 2019-04-04 expires: never usage: SC > card-no: FF020001008A77C1 > trust: ultimate validity: ultimate > ssb rsa2048/7067860A98FCE6E1 > created: 2019-04-04 expires: never usage: E > card-no: FF020001008A77C1 > [ultimate] (1). otto at example.net > > gpg> save > > Now you can use your PIV card also with gpg. > > > > SEE ALSO > scdaemon(1) > > > > GnuPG 2.3.0-beta911 2019-08-30 GPG-CARD(1) > --8<---------------cut here---------------end--------------->8--- > > From wk at gnupg.org Wed Sep 11 16:11:01 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Sep 2019 16:11:01 +0200 Subject: Generating card keys via gpg-connect-agent In-Reply-To: (Jiri Kerestes's message of "Wed, 11 Sep 2019 09:50:23 +0200") References: <3141935f-0e9f-c5d1-cd01-555db157b433@trustica.cz> <8736h4m86u.fsf@wheatstone.g10code.de> Message-ID: <87a7bavs7e.fsf@wheatstone.g10code.de> On Wed, 11 Sep 2019 09:50, jiri.kerestes at trustica.cz said: > Thanks, gpg-card looks exactly like the thing I'm looking for. Let me know if you have any problems or wishes. As I mentioned it is still under development. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Wed Sep 11 16:36:32 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 11 Sep 2019 15:36:32 +0100 Subject: Scute 1.6.0 released Message-ID: <20190911143632.v4leyeyyzkzmnuhh@aurora.local.incenp.org> Hi, The GnuPG Project is pleased to announce the availability of Scute 1.6.0. Scute is a PKCS#11 module built around the GnuPG Agent and the GnuPG Smart Card Daemon. It allows you to use an OpenPGP or a PIV smart card for TLS client authentication and S/MIME mail and document signing. Noteworthy changes in version 1.6.0 (2019-09-10) =================================== * PIV cards are now supported in addition to OpenPGP cards. * Key selection is delegated to GpgSM, resulting in faster operations. * The license has been changed to the GNU Lesser General Public License, version 2.1 or later. * Scute now requires at a minimum the current stable version of GnuPG (2.2.0); advanced PIV card support needs the current GnuPG development version. Release-info: https://dev.gnupg.org/T4697 Download ======== Source code is hosted at the GnuPG FTP server and its mirror as listed as . On the primary server the source tarball and its signature are: ftp://ftp.gnupg.org/gcrypt/scute/scute-1.6.0.tar.bz2 ftp://ftp.gnupg.org/gcrypt/scute/scute-1.6.0.tar.bz2.sig The same files are also available via HTTP: https://gnupg.org/ftp/gcrypt/scute/scute-1.6.0.tar.bz2 https://gnupg.org/ftp/gcrypt/scute/scute-1.6.0.tar.bz2.sig Signing key =========== The tarball is signed by the maintainer's key: rsa4096 2014-03-14 Key fingerprint = 4FA2 0823 62FE 73AD 03B8 8830 A8DC 7067 E25F BABB Damien Goutte-Gattat That key is available via a WKD lookup: $ gpg --locate-key dgouttegattat at incenp.org Copying ======= Scute is copyright by g10 Code GmbH and licensed under the GNU Lesser General Public License version 2.1 or later (LGPLv2.1+). The full text of the license is included in the COPYING.LESSER file of the source distribution. Note that this is a change compared to previous releases of Scute, which were licensed under the GNU General Public License version 2 or later with an additional exception. Support ======= The Scute manual is included in the source distribution and is also available online at . For community support, you may ask on the gnupg-users mailing list . If you need commercial support, check out . Maintenance and development of Scute and of GnuPG as a whole is mostly financed by donations. Please consider donating via . Happy hacking! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dgouttegattat at incenp.org Wed Sep 11 16:36:32 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 11 Sep 2019 15:36:32 +0100 Subject: [Announce] Scute 1.6.0 released Message-ID: <20190911143632.v4leyeyyzkzmnuhh@aurora.local.incenp.org> Hi, The GnuPG Project is pleased to announce the availability of Scute 1.6.0. Scute is a PKCS#11 module built around the GnuPG Agent and the GnuPG Smart Card Daemon. It allows you to use an OpenPGP or a PIV smart card for TLS client authentication and S/MIME mail and document signing. Noteworthy changes in version 1.6.0 (2019-09-10) =================================== * PIV cards are now supported in addition to OpenPGP cards. * Key selection is delegated to GpgSM, resulting in faster operations. * The license has been changed to the GNU Lesser General Public License, version 2.1 or later. * Scute now requires at a minimum the current stable version of GnuPG (2.2.0); advanced PIV card support needs the current GnuPG development version. Release-info: https://dev.gnupg.org/T4697 Download ======== Source code is hosted at the GnuPG FTP server and its mirror as listed as . On the primary server the source tarball and its signature are: ftp://ftp.gnupg.org/gcrypt/scute/scute-1.6.0.tar.bz2 ftp://ftp.gnupg.org/gcrypt/scute/scute-1.6.0.tar.bz2.sig The same files are also available via HTTP: https://gnupg.org/ftp/gcrypt/scute/scute-1.6.0.tar.bz2 https://gnupg.org/ftp/gcrypt/scute/scute-1.6.0.tar.bz2.sig Signing key =========== The tarball is signed by the maintainer's key: rsa4096 2014-03-14 Key fingerprint = 4FA2 0823 62FE 73AD 03B8 8830 A8DC 7067 E25F BABB Damien Goutte-Gattat That key is available via a WKD lookup: $ gpg --locate-key dgouttegattat at incenp.org Copying ======= Scute is copyright by g10 Code GmbH and licensed under the GNU Lesser General Public License version 2.1 or later (LGPLv2.1+). The full text of the license is included in the COPYING.LESSER file of the source distribution. Note that this is a change compared to previous releases of Scute, which were licensed under the GNU General Public License version 2 or later with an additional exception. Support ======= The Scute manual is included in the source distribution and is also available online at . For community support, you may ask on the gnupg-users mailing list . If you need commercial support, check out . Maintenance and development of Scute and of GnuPG as a whole is mostly financed by donations. Please consider donating via . Happy hacking! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From jowerstc at gmail.com Thu Sep 12 20:18:25 2019 From: jowerstc at gmail.com (Tyler Jowers) Date: Thu, 12 Sep 2019 14:18:25 -0400 Subject: Generating ECC shared-secret Message-ID: Good Thursday, I'm stuck figuring out how an ECC shared-secret should be generated with Libgcrypt. So far as I'm aware, the goal, after generating a public key with a random number, is to replace the generator point G with the other party's public key and use the local private key again to generate the shared secret. So I get the other party's q-point, then I (by some mechanism) convert the q-point to an mpi-point? I tried gcry_sexp_build(.. "(genkey (ecc (curve "NIST P-192") (g %S) (d %M)))", gcry_sexp_cdr(gcry_sexp_find_token(other_party_keydata, "q", 1)), u8_ptr_localprivatekey_as_mpi); And a few variations of that, and I don't get any error, but I get a duplicate public-key returned that matches verbatim the private-key. I need to know how the API wants me to generate a shared secret. If the way I was doing it is the right direction, how do I properly convert the q-point into a valid g-point? Regards, Tyler Jowers From manowar at altlinux.org Thu Sep 12 22:24:30 2019 From: manowar at altlinux.org (Paul Wolneykien) Date: Thu, 12 Sep 2019 23:24:30 +0300 Subject: Generating ECC shared-secret In-Reply-To: References: Message-ID: <8d1bd420-be0a-d885-6018-79cc06f7131e@altlinux.org> 12.09.2019 21:18, Tyler Jowers via Gnupg-devel ?????: > Good Thursday, > > I'm stuck figuring out how an ECC shared-secret should be generated > with Libgcrypt. > > So far as I'm aware, the goal, after generating a public key with a > random number, is to replace the generator point G with the other > party's public key and use the local private key again to generate the > shared secret. > > So I get the other party's q-point, then I (by some mechanism) convert > the q-point to an mpi-point? I tried gcry_sexp_build(.. "(genkey (ecc > (curve "NIST P-192") (g %S) (d %M)))", > gcry_sexp_cdr(gcry_sexp_find_token(other_party_keydata, "q", 1)), > u8_ptr_localprivatekey_as_mpi); And a few variations of that, and I > don't get any error, but I get a duplicate public-key returned that > matches verbatim the private-key. > > I need to know how the API wants me to generate a shared secret. If > the way I was doing it is the right direction, how do I properly > convert the q-point into a valid g-point? Hi! cipher/ecc.c: ecc_encrypt_raw() do all that for you. The other part is in GnuPG: g10/pkglue.c: pk_encrypt(). It works as follows: you generate an ephemeral private key ? a scalar, ? and after ecc_encrypt_raw() you get a) the shared point; b) the ephemeral public key (that corresponds to the ephemeral private key you've passed to ecc_encrypt_raw()). The way you get your shared secret ? a scalar, suitable for symmetric encryption ? from shared point depends on the key agreement algorithm. One example is the ECDH, implemented in g10/ecdh.c. Another one is GOST VKO I'm working on. In general, you should to reduce, i.e. to hash the shared point data some way. From dgouttegattat at incenp.org Sun Sep 15 14:18:39 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 15 Sep 2019 13:18:39 +0100 Subject: [PATCH gnupg-doc] web: Import Scute documentation. Message-ID: <20190915121839.31290-1-dgouttegattat@incenp.org> Hi GnuPG folks, The patch below is the first step to move Scute's documentation from scute.org to gnupg.org. The next step will be to make sure the manual (stored in Scute's git repo under doc/manual and hosted at http://scute.org/scute.html/) is available at http://gnupg.org/documentation/manuals/. The patch below takes care of adding a link to the correct destination, but the manual files will also need to be placed under the /var/www/shared/manuals directory on the web server. Cheers, - Damien -- >8 -- Subject: [PATCH gnupg-doc] web: Import scute documentation. Fill the Scute page with a condensed version of what is currently on Scute's own website. Also list the Scute manual along with the other manuals in web/documentation/manuals. --- web/documentation/manuals.org | 1 + web/software/scute/index.org | 56 +++++++++++++++++++++++++++++++++++++++---- 2 files changed, 53 insertions(+), 4 deletions(-) diff --git a/web/documentation/manuals.org b/web/documentation/manuals.org index d72ff1a..ff314e4 100644 --- a/web/documentation/manuals.org +++ b/web/documentation/manuals.org @@ -12,3 +12,4 @@ - Libksba manual :: [[file:manuals/ksba/][HTML]], [[file:manuals/ksba.pdf][PDF]]. - Libassuan manual :: [[file:manuals/assuan/][HTML]], [[file:manuals/assuan.pdf][PDF]]. - GPGME manual :: [[file:manuals/gpgme/][HTML]], [[file:manuals/gpgme.pdf][PDF]]. + - Scute manual :: [[file:manuals/scute/][HTML]], [[file:manuals/scute.pdf][PDF]]. diff --git a/web/software/scute/index.org b/web/software/scute/index.org index 613814f..9ca0ab3 100644 --- a/web/software/scute/index.org +++ b/web/software/scute/index.org @@ -4,10 +4,58 @@ * Scute - /Scute/ is a PKCS#11 provider on top of GnuPG. + /Scute/ is a [[https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11][PKCS#11] + provider on top of GnuPG. It adds support for the [[https://www.g10code.com/p-card.html][OpenPGP + smartcard]] and PIV cards to the [[https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS] + [Mozilla Network Security Services]] (NSS). - Please [[https://www.scute.org][www.scute.org]] for details until we have moved the - docs to this page. + This allows you to use your OpenPGP or PIV card as a security device in [[https://www.mozilla.org/] + [Firefox]] and other software that makes use of the NSS library. - See [[../../download/index.org::#scute][download]] section to download the latest tarball. The current + Currently, supported usages are HTTPS client authentication, S/MIME email signing, and document + signing with [[https://www.libreoffice.org/][LibreOffice]]. + + See the [[../../download/index.org::#scute][download]] section to download the latest tarball. + The user manual is available [[file:../../documentation/manuals/scute/][here]]. The current version is {{{scute_ver}}}. + +** Installation + + Scute requires the following packages to compile: + + - [[file:../libgpg-error/][libgpg-error]] >= 1.24 + - [[file:../libassuan/][libassuan]] >= 2.5.0 + + Scute also requires the following packages to run: + + - Firefox, Thunderbird or any other supported application using PKCS#11 + - [[file:../][GnuPG]] >= 2.2.0 + - [[file:../pinentry/][Pinentry]] + + Canonical installation instructions can be found in the file INSTALL in the top-level directory + of the source packages. + +** Development + + The source of Scute is managed using the GIT distributed revision control system. The repository + can be retrieved with the following command: + + : git clone git://git.gnupg.org/scute.git + + Please send an e-mail to the [[http://lists.gnupg.org/mailman/listinfo/gnupg-devel][GnuPG + development mailing list]] if you are interested in participating in Scute development. Bugs + reports should be submitted to our [[https://bugs.gnupg.org/][bug tracking system]] or sent via + e-mail to the GnuPG development mailing list. + + A web interface to the [[http://git.gnupg.org/cgi-bin/gitweb.cgi?p=scute.git][Scute source + repository]] is available on-line, and contains up-to-date as well as archived versions of + all files included in the Scute source package, including the most recent development changes. + +** Contact + + Scute is developed and maintained by [[https://www.g10code.com/][g10 Code GmbH]]. You can support + its development by [[https://www.g10code.com/support.html][getting support contracts]] for custom + development, security consulting and training. + + The members of our community can be reached via e-mail on the + [[http://www.gnupg.org/documentation/mailing-lists.html][GnuPG mailing lists]]. -- 2.14.5 From jason.franklin at quoininc.com Tue Sep 17 15:52:20 2019 From: jason.franklin at quoininc.com (Franklin, Jason) Date: Tue, 17 Sep 2019 09:52:20 -0400 Subject: Seeking advice on debugging Poldi Message-ID: Greetings, In the past few weeks, I've been working through some issues related to the boundary between the Debian libpam-poldi package and the KDE screen locker (the Debian libkscreenlocker5 package). During this time, I have had some difficulty with debugging, in particular, libpam-poldi. My workflow has been as follows: 1. build libpam-poldi with debugging flags using export DEB_CFLAGS_MAINT_APPEND = -Og -ggdb -g3 export DEB_LDFLAGS_MAINT_APPEND = -Og -ggdb -g3 in the debian/rules file. 2. install the package with dpkg -i ....deb 3. lock the screen, switch to a virtual console and open the code in Vim 4. I then use the debugging plugin to set a deferred/pending breakpoint on one of the Poldi functions (e.g., query_user()) 5. Switch back to the screen locker and try to unlock the desktop 6. Switch back to virtual console and step through the code This works pretty well for the screen locker, but the debugger doesn't perform as expected. Much of the code is still optimized out, even though the debugging flags set above appear in the output of "debuild -us -uc". Is my workflow reasonable? For those who work on Poldi, how do you go about stepping through the code? -- Jason Franklin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From bigon at bigon.be Wed Sep 18 17:28:45 2019 From: bigon at bigon.be (Laurent Bigonville) Date: Wed, 18 Sep 2019 17:28:45 +0200 Subject: Multiple readers with scdaemon In-Reply-To: References: <87mux9r8l2.fsf@iwagami.gniibe.org> Message-ID: Hello, I'm coming back to this question after almost a year, but this is still an issue for me as without pcscd support, I cannot use other smartcard if scdaemon is running. On 9/05/18 13:49, Laurent Bigonville wrote: > Le 09/05/18 ? 02:11, NIIBE Yutaka a ?crit?: >> Laurent Bigonville wrote: >>> Are there any plans to support multiples readers? >> When you can disable PC/SC, multiple readers are supported by the >> internal CCID driver of scdaemon (through libusb, directly). > > In that case I cannot use other smartcards if scdaemon is still > running, this is quite annoying. > >> Currently, I don't have a specific plan to support multiple readers with >> PC/SC.? There are different PC/SC implementations, I mean, the one of >> Windows, the one of macOS, and pcsc-lite+libccid.? In this situation, it >> is a bit harder for me to introduce new feature to scdaemon with PC/SC. >> I could test with pcsc-lite, but major users of scdaemon with PC/SC are >> on Windows or macOS. >> >> And it seems for me that PC/SC is not actively developed on Windows and >> macOS.? If it is the case, I'd like to put my energy to the internal >> CCID driver. >> >> BTW, I'm curious if the internal CCID driver can be used on Windows and >> macOS. > Isn't pcsc-lite used on MacOSX the same as the one on GNU/Linux? > If I can trust this page(https://github.com/OpenSC/OpenSC/wiki/PCSC-and-pcsc-lite), it says that: "PC/SC is the de facto cross-platform API for accessing smart card readers. It is published by PC/SC Workgroup but the ?reference implementation? is Windows. Linux and Mac OS X use the open source pcsc-lite package." So this is far from being dead, and the API itself (not the pcsc-lite implementation) is working on all platforms including MS/Windows From peter at digitalbrains.com Wed Sep 18 20:25:50 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 18 Sep 2019 20:25:50 +0200 Subject: Multiple readers with scdaemon In-Reply-To: References: <87mux9r8l2.fsf@iwagami.gniibe.org> Message-ID: On 18/09/2019 17:28, Laurent Bigonville via Gnupg-devel wrote: > If I can trust this > page(https://github.com/OpenSC/OpenSC/wiki/PCSC-and-pcsc-lite), it says > that: > > [...snip...] > So this is far from being dead Erm, that page hasn't been edited since 2012 and the link to pcsc-lite is dead... just saying. The Alioth server has been taken down over a year ago, if I'm not mistaken, so it's not a recently dead link. I don't see why you say it indicates aliveness. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Thu Sep 19 01:49:49 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 19 Sep 2019 08:49:49 +0900 Subject: Multiple readers with scdaemon In-Reply-To: References: <87mux9r8l2.fsf@iwagami.gniibe.org> Message-ID: <877e659nc2.fsf@iwagami.gniibe.org> Hello, Laurent Bigonville wrote: > I'm coming back to this question after almost a year, but this is still > an issue for me as without pcscd support, I cannot use other smartcard > if scdaemon is running. It is not ignored. Sorry, it has been in low priority state. Well, the multiple readers support with PC/SC is tracked here: https://dev.gnupg.org/T4620 The feature is now in the master branch (this week). I tested the feature in my environment of Windows under qemu VM, too. It works for this environment of mine. So far, it is only lightly tested. I think that there are some complicated use cases like: using two readers for OpenPGP cards, and another for different card for different application. Those cases are not tested at all. Your testing will be appreciated. Still, in my opinion, I prefer access to USB device directly by libusb (not through PC/SC service), when it is possible. In the development of the support of multiple readers with PC/SC, I tried to use the API of SCardGetStatusChange and SCardCancel within a single context, so that scdaemon don't need to poll periodically. I realized that the API is not good enough (there are fundamental race conditions). So, for this time, I don't pursue to remove scdaemon's periodical check with SCardGetStatus. I know that this is not a perfect situation and some users of laptop complain about possible more use of energy. -- From uri at mit.edu Thu Sep 19 02:13:00 2019 From: uri at mit.edu (Uri Blumenthal) Date: Thu, 19 Sep 2019 00:13:00 +0000 Subject: Multiple readers with scdaemon In-Reply-To: <877e659nc2.fsf@iwagami.gniibe.org> References: <87mux9r8l2.fsf@iwagami.gniibe.org> <877e659nc2.fsf@iwagami.gniibe.org> Message-ID: Another problem is that GnuPG insists on opening the card in an exclusive mode - which is unacceptable for cards/tokens with multiple applets (OpenPGP and PIV is what I've got), as different apps require use of both applets, sometimes running in parallel - like a browser session that uses PIV to authenticate to the server, an email session that may use both PIV and OpenPGP applets to deal with S/MIME and PGP/MIME emails, and occasional SSH operations during that time. Sent from my test iPhone > On Sep 18, 2019, at 19:51, NIIBE Yutaka wrote: > > Hello, > > Laurent Bigonville wrote: >> I'm coming back to this question after almost a year, but this is still >> an issue for me as without pcscd support, I cannot use other smartcard >> if scdaemon is running. > > It is not ignored. Sorry, it has been in low priority state. > > Well, the multiple readers support with PC/SC is tracked here: > > https://dev.gnupg.org/T4620 > > The feature is now in the master branch (this week). I tested the > feature in my environment of Windows under qemu VM, too. It works for > this environment of mine. > > So far, it is only lightly tested. I think that there are some > complicated use cases like: using two readers for OpenPGP cards, and > another for different card for different application. Those cases are > not tested at all. Your testing will be appreciated. > > > Still, in my opinion, I prefer access to USB device directly by libusb > (not through PC/SC service), when it is possible. > > In the development of the support of multiple readers with PC/SC, I > tried to use the API of SCardGetStatusChange and SCardCancel within a > single context, so that scdaemon don't need to poll periodically. I > realized that the API is not good enough (there are fundamental race > conditions). So, for this time, I don't pursue to remove scdaemon's > periodical check with SCardGetStatus. I know that this is not a perfect > situation and some users of laptop complain about possible more use of > energy. > -- > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2894 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 19 10:06:45 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Sep 2019 10:06:45 +0200 Subject: Yubikey and PIV support in 2.3 (was: Multiple readers with scdaemon) In-Reply-To: (Uri Blumenthal's message of "Thu, 19 Sep 2019 00:13:00 +0000") References: <87mux9r8l2.fsf@iwagami.gniibe.org> <877e659nc2.fsf@iwagami.gniibe.org> Message-ID: <871rwck8ve.fsf_-_@wheatstone.g10code.de> On Thu, 19 Sep 2019 00:13, uri at mit.edu said: > Another problem is that GnuPG insists on opening the card in an > exclusive mode - which is unacceptable for cards/tokens with multiple > applets (OpenPGP and PIV is what I've got), as different apps require Actually this is a another reason to have exclusive access. It allows us to switch between the PIV and OpenPGP apps on a Yubikey as needed. > use of both applets, sometimes running in parallel - like a browser > session that uses PIV to authenticate to the server, an email session > that may use both PIV and OpenPGP applets to deal with S/MIME and > PGP/MIME emails, and occasional SSH operations during that time. That is exactly the use case we have implemented. Needs more testing with several cards but a single Yubikey works well enough known in 2.3. To make testing easier we have Debian packages of gnupg master (to be 2.3) and scute (our pkcs11 provider) available: deb [arch=amd64] https://ftp.g10code.com/apt buster gnupg-beta deb [arch=amd64] https://ftp.g10code.com/apt stretch gnupg-beta deb [arch=amd64] https://ftp.g10code.com/apt cosmic gnupg-beta The version currently available do not yet include gniibe's latest changes. I was able to use gpg for signing and encrypting with a card while also accessing PIV key protected pages with Firefox. Earlier this year I also did tests with Thunderbird which also worked. Yubikey 5 and 4 are supported. You may want to have a look at the new gpg-card tool and its man page. Also gpg --full-gen-key and gpgsm --gen-key now show a list of keys available on the current smartcard and allow to use them for the generation of OpenPGP/X.509 certificates. --quick-gen-key has also been enhanced to act upon the special algo parameter "card" with the generation of a standard OpenPGP key based on the standard signing and decryption key of the card (for OpenPGP, Netkey, and PIV cards). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg at eckner.net Thu Sep 19 10:29:48 2019 From: gnupg at eckner.net (Erich Eckner) Date: Thu, 19 Sep 2019 10:29:48 +0200 (CEST) Subject: WKD on http2 server Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, we had trouble with our wkd on archlinux32.org. gpg only said "gpg: error retrieving 'buildmaster at archlinux32.org' via WKD: General error". No (failed or successul) accesses were logged server side during a tried `gpg --locate-key ...`. We switched off http2 (removed "http2" parameter from nginx' "listen" directive) and key location via wkd workes. I now wonder, whether: 1. This is known. 2. This is documented. 3. It is intended to change this. ("this" = "key retrieval via wkd does not work with (some?) http2 servers") Also, it would be nice to give a somewhat more detailed error message, like "cannot connect to https://$domain". regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl2DPH0ACgkQCu7JB1Xa e1oRzRAAuOpD8nLHhY1pOpr7TfTwk4zq7tfsd419dYe2JKnwucRr09RT1JrN9z7v 8EGJ4Bd9frzYKP3/5lZeSSVU3zEbtEYaFrsjiJgAKBo+8jDih8sZaGxpfJcQmz4+ 1RHGvNZikN0fXbRZoBp/GaDz4orBXnbuH81GWJKzmEvAGdQA0YCMpSKh4xP38Tpz mYikTs3BZdjo/WfpQlAeJSOvQIjC4cjTECw3UgTOUS7Qi71vhIoGRCS0LeeylAo3 Vq2UComLwFsRYVa7z72UbEjudmDW1Mb/L5XS3uvX/ZRrnp3iCarjiOVqCNjG8I34 BhyWWOfSA+Z02Ot5wpwU2f8N6j4OaHLosd+n80FC30I2ABdi3y6COuf+lkTiK1XH SuHutfq5Pdheai9ZKBsoAGteS1sP7Dd7QvmEAQ5OVDaT6m/F5ZgnI3CTfQIcsInd ALtrGPNte1znWDuvcKAsq+ctAlwrOAbQrS9k1dluQ3glN3y1uiOZ+MjtDE78W/ZZ n6+q05bmF6V6mkprp0F+6YTHZTbeqYO+/MoZiEGUEtAX6UXbHODNd9CiPc2LeN11 MOPpWhZAe0HnvON0GO67ETDJS4U/HKp99Vbo0X3ljmwVgXSXDLj5nBoKjUAJrnVv VoOj39wZOrJQyAx7rFl33hvpjf1GN9u47QPomLETeVRC1wFwvXU= =pNNT -----END PGP SIGNATURE----- From wk at gnupg.org Thu Sep 19 11:58:45 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Sep 2019 11:58:45 +0200 Subject: WKD on http2 server In-Reply-To: (Erich Eckner via Gnupg-devel's message of "Thu, 19 Sep 2019 10:29:48 +0200 (CEST)") References: Message-ID: <87lfukip4a.fsf@wheatstone.g10code.de> On Thu, 19 Sep 2019 10:29, gnupg-devel at gnupg.org said: > ("this" = "key retrieval via wkd does not work with (some?) http2 > servers") Google HTTP does not work. > Also, it would be nice to give a somewhat more detailed error message, > like "cannot connect to https://$domain". dirmngr should print such a message but given it is a daemon you will only see them in the logs. We can of course add code to move common errors up to gpg. Would you mind to open a ticket at dev.gnupg.org? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From uri at mit.edu Thu Sep 19 12:51:54 2019 From: uri at mit.edu (Uri Blumenthal) Date: Thu, 19 Sep 2019 10:51:54 +0000 Subject: Yubikey and PIV support in 2.3 (was: Multiple readers with scdaemon) In-Reply-To: <871rwck8ve.fsf_-_@wheatstone.g10code.de> References: <87mux9r8l2.fsf@iwagami.gniibe.org> <877e659nc2.fsf@iwagami.gniibe.org> <871rwck8ve.fsf_-_@wheatstone.g10code.de> Message-ID: <1CC36679-DA55-4FE1-91D8-C1449712E8FF@mit.edu> Werner, That is interesting. But my platform is Mac, and among the apps I need working are MS Outlook and Apple Mail (and Safari). At least the Apple apps use CTK to access smart cards. I'm pretty sure that even if everything else GnuPG-related works OK the way you described, that GnuPG exclusive access would block out the native apps that do not (cannot) use scute. Currently in using OpenSC for PKCS#11 access (Firefox, Adobe Acrobat, everything OpenSSL-based), and OpenSC.tokend or native pivtoken for those apps that don't speak PKCS#11 - which on Mac means either CDSA or CTK (tokend addresses CDSA apps such as MS Office, and pivtoken - the new CTK ones). Frankly, I don't see how it would work on Mac, if GnuPG would lock the token for its own use only. Which is why I keep saying that this lock should be a configurable parameter - maybe on by default, but with the ability to turn it off. Also, OpenSC deals with multiple applets by testing whether the required applet is active, and re-asserting/selecting it if needed. Thanks! Sent from my test iPhone > On Sep 19, 2019, at 04:10, Werner Koch wrote: > > On Thu, 19 Sep 2019 00:13, uri at mit.edu said: >> Another problem is that GnuPG insists on opening the card in an >> exclusive mode - which is unacceptable for cards/tokens with multiple >> applets (OpenPGP and PIV is what I've got), as different apps require > > Actually this is a another reason to have exclusive access. It allows > us to switch between the PIV and OpenPGP apps on a Yubikey as needed. > >> use of both applets, sometimes running in parallel - like a browser >> session that uses PIV to authenticate to the server, an email session >> that may use both PIV and OpenPGP applets to deal with S/MIME and >> PGP/MIME emails, and occasional SSH operations during that time. > > That is exactly the use case we have implemented. Needs more testing > with several cards but a single Yubikey works well enough known in 2.3. > > To make testing easier we have Debian packages of gnupg master (to be > 2.3) and scute (our pkcs11 provider) available: > > deb [arch=amd64] https://ftp.g10code.com/apt buster gnupg-beta > deb [arch=amd64] https://ftp.g10code.com/apt stretch gnupg-beta > deb [arch=amd64] https://ftp.g10code.com/apt cosmic gnupg-beta > > The version currently available do not yet include gniibe's latest > changes. I was able to use gpg for signing and encrypting with a card > while also accessing PIV key protected pages with Firefox. Earlier this > year I also did tests with Thunderbird which also worked. Yubikey 5 and > 4 are supported. You may want to have a look at the new gpg-card tool > and its man page. Also gpg --full-gen-key and gpgsm --gen-key now show > a list of keys available on the current smartcard and allow to use them > for the generation of OpenPGP/X.509 certificates. --quick-gen-key has > also been enhanced to act upon the special algo parameter "card" with > the generation of a standard OpenPGP key based on the standard signing > and decryption key of the card (for OpenPGP, Netkey, and PIV cards). > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2894 bytes Desc: not available URL: From jason.franklin at quoininc.com Thu Sep 19 15:18:29 2019 From: jason.franklin at quoininc.com (Franklin, Jason) Date: Thu, 19 Sep 2019 09:18:29 -0400 Subject: Reporting bug fix for kscreenlocker to work with libpam-poldi Message-ID: <7528280f-3bf5-d2e5-6594-623ba6f187b7@quoininc.com> To those interested, I just wanted to report that I authored a patch for the KDE screen locker project so that it would work better with libpam-poldi. The issue was that entering a PIN that was under 6 characters at the screen locker would lock up the system when PAM authentication was being done by poldi. This is now fixed. See a link to the patch below: https://phabricator.kde.org/D23849 This problem was previously discussed in the following threads: https://lists.gnupg.org/pipermail/gnupg-devel/2019-September/034443.html https://lists.gnupg.org/pipermail/gnupg-devel/2018-November/034063.html For those who use Plasma on Debian, I have requested that the maintainers there cherry pick this patch to fix the screen locker in buster. -- Jason Franklin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From gnupg-devel at spodhuis.org Fri Sep 20 01:02:56 2019 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Thu, 19 Sep 2019 19:02:56 -0400 Subject: WKD on http2 server In-Reply-To: References: Message-ID: <20190919230256.GA55026@osmium.pennocktech.home.arpa> On 2019-09-19 at 10:29 +0200, Erich Eckner via Gnupg-devel wrote: > We switched off http2 (removed "http2" parameter from nginx' "listen" > directive) and key location via wkd workes. I have nginx 1.16.1 (OpenSSL 1.1.1d) running on FreeBSD using `http2` in the listen directives for `openpgpkey.spodhuis.org` and GnuPG (2.2.17) works with it. gpg -v --auto-key-locate clear,nodefault,wkd --locate-key phil.pennock@${ThatDomain} Loosely, if a client doesn't speak HTTP/2 then it won't try to negotiate it and so won't be affected by it. What _might_ happen is a client built with a library which can speak HTTP/2 and the client making something like case-sensitive header name assumptions. But if there are bad interactions then it's not as simple as "GnuPG is not compatible with nginx servers which enable HTTP/2 support". Since that works for me. -Phil From jason.franklin at quoininc.com Fri Sep 20 18:39:35 2019 From: jason.franklin at quoininc.com (Franklin, Jason) Date: Fri, 20 Sep 2019 12:39:35 -0400 Subject: Should Poldi lock the smart card when the screen locks? Message-ID: Greetings, I'm continuing my work on the integration of Poldi and the KDE screen locker. Currently, when the user locks the screen and leaves their smart card inserted, the smart card remains unlocked. Thus, the screen can be locked and the user (or someone else!) can simply press to unlock the desktop. My question is simple: What component should be modified to make sure the smart card is locked when the screen is locked, thus requiring the user to enter the GPG card passphrase to unlock the card and then the desktop? This would make the locker behave as expected. -- Jason Franklin From gniibe at fsij.org Mon Sep 23 07:58:51 2019 From: gniibe at fsij.org (Niibe Yutaka) Date: Mon, 23 Sep 2019 14:58:51 +0900 Subject: Should Poldi lock the smart card when the screen locks? In-Reply-To: References: Message-ID: <87h853d04k.fsf@jumper.gniibe.org> Hello, Franklin, Jason wrote: > I'm continuing my work on the integration of Poldi and the KDE screen > locker. Well, It's not clear for me what kind of scenario you expect. Could you please elaborate? I'm writing some of my ideas in this message. With current implementations (Poldi, gpg-agent+scdaemon) in mind, there are three usages of OpenPGP card in possible scenario(s). (1) Login authentication to user by Poldi with OpenPGP card (2) In user session, use OpenPGP card by gpg-agent+scdaemon, for gpg and/or SSH, possibly Scute. (3) (possible) authentication to user by Poldi for screen locker, to unlock screen I think that those three can work well, when/if there are three independent OpenPGP cards for each purpose. If you share a single OpenPGP card among three purposes, you need to write a couple of hook scripts, I suppose. Sharing between (1) and (2), I think that there would be no/less problem. It depends on how you invoke gpg-agent+scdaemon. You need to make sure that scdaemon is no longer active after logout. In a configuration of automatic socket activation of gpg-agent by systemd, I'm afraid scdaemon remains some seconds after logout. Sharing between (2) and (3) is problematic. I think you need to write a hook script for screen locker, to make sure scdaemon will be killed before screen is locked and Poldi can invoke new scdaemon for authentication. I'd say, sharing a single OpenPGP card for those multiple purposes is not that simple. It's compilicated, because for (3), Poldi runs by user privilege and it runs by system privilege for (1). * * * And... I think that a typical use case of such a user authentication with Smartcard is something like: * A smartcard is used for login authentication * When it is removed from card reader, either the user session is suspended by screen locker, or the user gets log out. * In case of suspended session, when user insert the card again, that user will be asked PIN for the authentication using the card. Then, user session resumes. In this use case, there should be some program watching the card reader to detect card removal. To achieve this kind of Smartcard use, I think that Poldi is not good enough, because it simply handles basic authentication by OpenPGP card. Perhaps, it's good to investigate how other smartcards are used to support this scenario, by other software. I have a quick look at: http://opensc.github.io/pam_pkcs11/doc/pam_pkcs11.html It seems that the use case above is supported by the PAM-PKCS#11 module. -- From alex at nitrokey.com Tue Sep 24 09:21:58 2019 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Tue, 24 Sep 2019 09:21:58 +0200 Subject: Should Poldi lock the smart card when the screen locks? In-Reply-To: References: Message-ID: <1db93f8e-d865-fa43-67d0-7f14b1fffaaf@nitrokey.com> Hey, I found it odd too. I have two thoughts on that. * The reason for using a smartcard to unlock a computer is to have a second factor. Locking the screen but leaving the card inside the computer is therefore like disabling the second factor. One could argue that you shouldn't do that anyway. Unplugging the card disables the described problem. * On the other hand, the situation now is like disabling both factors, so this is quite bad, especially because people tend to just forget stuff... What I was thinking about is a function in the OpenPGP Card standard since version 3.1. It is possible to use the VERIFY command to reset the access status to 'not verified' (see 7.2.2 of the current standard). [1] This may does the trick. Of course, this solution would be limited to OpenPGP Cards only. @Niibe Gnuk does only support OpenPGP Card 2.1 (besides ECC keys) yet, right? Kind regards Alex [1] https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.3.1.pdf On 20.09.19 18:39, Franklin, Jason wrote: > Greetings, > > I'm continuing my work on the integration of Poldi and the KDE screen > locker. > > Currently, when the user locks the screen and leaves their smart card > inserted, the smart card remains unlocked. Thus, the screen can be > locked and the user (or someone else!) can simply press to > unlock the desktop. > > My question is simple: What component should be modified to make sure > the smart card is locked when the screen is locked, thus requiring the > user to enter the GPG card passphrase to unlock the card and then the > desktop? > > This would make the locker behave as expected. > From wk at gnupg.org Tue Sep 24 15:02:00 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Sep 2019 15:02:00 +0200 Subject: Should Poldi lock the smart card when the screen locks? In-Reply-To: (Jason Franklin's message of "Fri, 20 Sep 2019 12:39:35 -0400") References: Message-ID: <87lfudzw3b.fsf@wheatstone.g10code.de> On Fri, 20 Sep 2019 12:39, jason.franklin at quoininc.com said: > My question is simple: What component should be modified to make sure > the smart card is locked when the screen is locked, thus requiring the What you need to do is a gpgconf --kill scdaemon or if you want to send the command directly you send scd killscd to the gpg-agent. This way the scdaemon is terminated and the card powered down. The next time a card is requested the gpg-agent will restart scdameon and in turn it will ask for the PIN. It would be nicer if we could have scdaemon running as a system daemon but that is not easy to implement because we need take card of users who have permissions to use the card reader but are not allowed to start or re-configure a system daemon. However, we assume that a smartcard is used only on single-user-at-a-time box and thus a system daemon does not give a real advantage. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jason.franklin at quoininc.com Tue Sep 24 17:23:31 2019 From: jason.franklin at quoininc.com (Franklin, Jason) Date: Tue, 24 Sep 2019 11:23:31 -0400 Subject: Should Poldi lock the smart card when the screen locks? In-Reply-To: <1db93f8e-d865-fa43-67d0-7f14b1fffaaf@nitrokey.com> References: <1db93f8e-d865-fa43-67d0-7f14b1fffaaf@nitrokey.com> Message-ID: <06a47dc2-a6d7-e154-1549-f172252f8feb@quoininc.com> On 9/24/19 3:21 AM, Alexander Paetzelt | Nitrokey via Gnupg-devel wrote: > Hey, > > I found it odd too. I have two thoughts on that. > > * The reason for using a smartcard to unlock a computer is to have a > second factor. Locking the screen but leaving the card inside the > computer is therefore like disabling the second factor. One could argue > that you shouldn't do that anyway. Unplugging the card disables the > described problem. Negligent users do this kind of thing all the time. I would argue that it is common enough that safeguards should be in place to minimize the likelihood of system compromise when it inevitably happens. The current behavior is that putting the machine in a locked state (locking the screen) only requires one factor to unlock the machine (the card). This is not two-factor authentication, at least in the case of the screen locker. > * On the other hand, the situation now is like disabling both factors, > so this is quite bad, especially because people tend to just forget stuff... Precisely my point! I am currently working with colleagues to provision Debian machines with 2FA using the GPG smart card. It has become pretty obvious that most of the less technical users of this configuration will habitually forget to remove their smart cards when locking the screen. > What I was thinking about is a function in the OpenPGP Card standard > since version 3.1. It is possible to use the VERIFY command to reset the > access status to 'not verified' (see 7.2.2 of the current standard). [1] > This may does the trick. Of course, this solution would be limited to > OpenPGP Cards only. This sounds like a great idea. I would love to explore this further. I am very curious to see what Niibe thinks about this. -- Jason Franklin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From alex at nitrokey.com Wed Sep 25 14:13:04 2019 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Wed, 25 Sep 2019 14:13:04 +0200 Subject: Should Poldi lock the smart card when the screen locks? In-Reply-To: <06a47dc2-a6d7-e154-1549-f172252f8feb@quoininc.com> References: <1db93f8e-d865-fa43-67d0-7f14b1fffaaf@nitrokey.com> <06a47dc2-a6d7-e154-1549-f172252f8feb@quoininc.com> Message-ID: On 24.09.19 17:23, Franklin, Jason wrote: > >> What I was thinking about is a function in the OpenPGP Card standard >> since version 3.1. It is possible to use the VERIFY command to reset the >> access status to 'not verified' (see 7.2.2 of the current standard). [1] >> This may does the trick. Of course, this solution would be limited to >> OpenPGP Cards only. > > This sounds like a great idea. I would love to explore this further. > > I am very curious to see what Niibe thinks about this. > > My message was a bit misleading, I am afraid. I mixed up some things in my head... The proposed "maybe-solution" would only work with newer cards following the OpenPGP Card standard (v3.1). I am not sure if you would like to use this for a general purpose screen locker. Thus, I guess the solution that Werner proposed is much better (killing scdaemon when locking the screen), especially because I think it is working for all cards that make use of poldi. So this would be a more general approach. Did you already think about that solution? Kind regards Alex From jason.franklin at quoininc.com Wed Sep 25 15:56:53 2019 From: jason.franklin at quoininc.com (Franklin, Jason) Date: Wed, 25 Sep 2019 09:56:53 -0400 Subject: Should Poldi lock the smart card when the screen locks? In-Reply-To: References: <1db93f8e-d865-fa43-67d0-7f14b1fffaaf@nitrokey.com> <06a47dc2-a6d7-e154-1549-f172252f8feb@quoininc.com> Message-ID: On 9/25/19 8:13 AM, Alexander Paetzelt | Nitrokey via Gnupg-devel wrote: > My message was a bit misleading, I am afraid. I mixed up some things in > my head... > > The proposed "maybe-solution" would only work with newer cards following > the OpenPGP Card standard (v3.1). I am not sure if you would like to use > this for a general purpose screen locker. Thus, I guess the solution > that Werner proposed is much better (killing scdaemon when locking the > screen), especially because I think it is working for all cards that > make use of poldi. So this would be a more general approach. Did you > already think about that solution? That is currently the method my colleague uses to solve the problem. I had hoped that a more general solution could be deployed that would work across desktop environments. Perhaps this is not feasible. -- Jason Franklin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Sep 26 09:51:38 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Sep 2019 09:51:38 +0200 Subject: Should Poldi lock the smart card when the screen locks? In-Reply-To: (Jason Franklin's message of "Wed, 25 Sep 2019 09:56:53 -0400") References: <1db93f8e-d865-fa43-67d0-7f14b1fffaaf@nitrokey.com> <06a47dc2-a6d7-e154-1549-f172252f8feb@quoininc.com> Message-ID: <87zhirwl4l.fsf@wheatstone.g10code.de> On Wed, 25 Sep 2019 09:56, jason.franklin at quoininc.com said: > That is currently the method my colleague uses to solve the problem. I > had hoped that a more general solution could be deployed that would work > across desktop environments. The proposed method works on all envirinments, including Windows. What did I miss? What we could implement in addition is an option to reset the card after some time of inactivity. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From marcelf at selfnet.de Sun Sep 29 18:16:21 2019 From: marcelf at selfnet.de (Marcel Fest) Date: Sun, 29 Sep 2019 18:16:21 +0200 Subject: WKD support? (hkp4py beta support for vks (Hagrid keyserver)) Message-ID: Hey GnuPG developers, I have integrated the Hagrid KeyServer Support (vks://) to my Library. The problem is that the library currently drops support for python under 3.5 because my code is written with type annotations. Is it necessary to support python 2.7 or older python 3.x revisions. As you can see on https://pythonclock.org/ python 2.7 eol will be in 3 months. Is it worth to support it. I am also looking into supporting WKD. But i need some more time to integrate that. Code is available here under MIT. https://github.com/Selfnet/hkp4py VKS is currently not merged into master feature/gpg-vks holds the code for it. Best Regards Marcel Fest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Sep 30 09:41:42 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Sep 2019 09:41:42 +0200 Subject: WKD on http2 server In-Reply-To: <20190919230256.GA55026@osmium.pennocktech.home.arpa> (Phil Pennock via Gnupg-devel's message of "Thu, 19 Sep 2019 19:02:56 -0400") References: <20190919230256.GA55026@osmium.pennocktech.home.arpa> Message-ID: <877e5qut6x.fsf@wheatstone.g10code.de> Hi! On Thu, 19 Sep 2019 19:02, Phil Pennock via gnupg-devel at gnupg.org said: > But if there are bad interactions then it's not as simple as "GnuPG is > not compatible with nginx servers which enable HTTP/2 support". Since > that works for me. We meanwhile solved the problem (https://dev.gnupg.org/T4708); it is due to a misconfiguration of the server. Here is my comment from the ticket: It does not work either. Your problem is the use of a wildcard DNS for archlinux32.org: $ host foosomething.archlinux32.org foosomething.archlinux32.org is an alias for archlinux32.org. Now dirmngr does an initial DNS lookup for openpgpkey.archlinux32.org and the wildcard DNS entry hits. dirmngr knows that the modern subdomain lookup is possible and uses this. Because you don't have that domain in your cert it fails. The solution to this is given in the latest WKD draft: Sites which do not use the advanced method but employ wildcard DNS for their sub-domains MUST make sure that the ~openpgpkey~ sub-domain is not subject to the wildcarding. This can be done by inserting an empty TXT RR for this sub-domain. Now, why we have different results with HTTP/2 and without is not clear to me. It could be a DNS caching issue but it might also be that you are not running 2.2.17 but an older version of dirmngr. We changed the way of looking up the openpgpkey sub-domain only in 2.2.17 to get better error messages. Given that the OP was indeed using 2.2.17 the problem is very likely that of a DNS caching issue. I have changed the ticket to a documentaion issue. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Sep 30 23:54:46 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 30 Sep 2019 17:54:46 -0400 Subject: GPGME documentation for gpgme_op_decrypt_ext return codes unclear Message-ID: <87wodpxxeh.fsf@fifthhorseman.net> Hi GnuPG folks-- the GPGME documentation for gpgme_op_decrypt_ext() says: The function returns the error codes as described for ?gpgme_op_decrypt? respective ?gpgme_op_encrypt?. It is unclear to me what "respective ?gpgme_op_encrypt?" means here. Can someone help me understand it? I'd be happy to update the docs to make them clearer if i understood what they were trying to say. Or, is this trailing clause extra and it could just be dropped? Dropping it makes the explanation simpler, for sure. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Sep 30 22:42:06 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 30 Sep 2019 16:42:06 -0400 Subject: gpgsm: decrypting session key failed: Invalid session key In-Reply-To: <87o91hqzvp.fsf@iwagami.gniibe.org> References: <20190718165820.456e2c70@md1za8fc.ad001.siemens.net> <87o91hqzvp.fsf@iwagami.gniibe.org> Message-ID: <8736gdzfc1.fsf@fifthhorseman.net> On Fri 2019-07-26 11:43:38 +0900, NIIBE Yutaka wrote: > Henning Schild via Gnupg-devel wrote: >> An increasing amount of x509 encrypted email i receive can not be >> decrypted with gpgsm anymore. > > Is there any change of cipher used? > >> Details: (from latest git build) >> $ /foo/gnupg/sm/gpgsm --debug-level guru --decrypt smime_bad.p7m >> ... >> gpgsm: DBG: chan_5 -> PKDECRYPT >> gpgsm: DBG: chan_5 <- S INQUIRE_MAXLEN 4096 >> gpgsm: DBG: chan_5 <- INQUIRE CIPHERTEXT >> gpgsm: DBG: chan_5 -> [ 44 20 28 37 3a 65 6e 63 2d 76 61 6c 28 33 3a 72 ...(273 byte(s) skipped) ] >> gpgsm: DBG: chan_5 -> END >> Vim: Reading from stdin... >> gpgsm: DBG: chan_5 <- S PADDING 0 >> gpgsm: DBG: chan_5 <- [ 44 20 28 35 3a 76 61 6c 75 65 33 32 3a e5 ff cd ...(31 byte(s) skipped) ] >> gpgsm: DBG: chan_5 <- OK >> gpgsm: DBG: pkcs1 encoded session key: e5ffcd51107897682fc0d805173d85ce7088fddabda33ac74da73b0813c04593 >> gpgsm: decrypting session key failed: Invalid session key >> gpgsm: message decryption failed: Invalid session key > > The encoded session key is 32-byte, which looks like a key of AES-256. > > My guess is, this is the point where we need a fix: > > diff --git a/sm/decrypt.c b/sm/decrypt.c > index ec9800840..af509fea1 100644 > --- a/sm/decrypt.c > +++ b/sm/decrypt.c > @@ -75,7 +75,7 @@ prepare_decryption (ctrl_t ctrl, const char *hexkeygrip, const char *desc, > log_printhex (seskey, seskeylen, "pkcs1 encoded session key:"); > > n=0; > - if (seskeylen == 24 || seskeylen == 16) > + if (seskeylen == 32 || seskeylen == 24 || seskeylen == 16) > { > /* Smells like a 3-DES or AES-128 key. This might happen > * because a SC has already done the unpacking. A better It looks like this change was adopted in GnuPG master as ef2424144a070c9199e40424ec8d9b5a9919aa72. Should this be backported to the 2.2 stable branch? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: