From simon at josefsson.org Mon Jan 1 14:28:34 2018 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 01 Jan 2018 14:28:34 +0100 Subject: "best" ed25519/curve25519 setup? Message-ID: <87a7xxso71.fsf@latte.josefsson.org> Hi. I want to use ed25519/curve25519, but right now I have an offline master RSA key with three subkeys. Does it work well to add new subkeys for Ed25519/Curve25519? What is the user experience in various applications? I'm thinking MUAs, SSH, git, gpg itself, and also more exotic approaches like K9Mail. The alternative for me of course is to create a brand new key, with an offline Ed25519 master key, plus some subkeys. Has anyone done this, and can share their experience? Naturally, I want the subkeys to be on hardware (smartcard). Is it possible to have multiple OpenPGP cards for the same master key, but for different subkeys? Does GNUK handle combined RSA+25519 keys? /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From guilhem at fripost.org Mon Jan 1 19:33:31 2018 From: guilhem at fripost.org (Guilhem Moulin) Date: Mon, 1 Jan 2018 19:33:31 +0100 Subject: "best" ed25519/curve25519 setup? In-Reply-To: <87a7xxso71.fsf@latte.josefsson.org> References: <87a7xxso71.fsf@latte.josefsson.org> Message-ID: <20180101183331.GA7187@localhost.localdomain> Hi Simon, On Mon, 01 Jan 2018 at 14:28:34 +0100, Simon Josefsson wrote: > I want to use ed25519/curve25519, but right now I have an offline > master RSA key with three subkeys. Does it work well to add new > subkeys for Ed25519/Curve25519? What is the user experience in > various applications? I'm thinking MUAs, SSH, git, gpg itself, and > also more exotic approaches like K9Mail. AFAICT multiple Ed25519/Curve25519 subkeys work fine, with the following caveats: * You'll want to sign with both your Ed25519 and non-ECC (sub-)keys, otherwise non-ECC capable OpenPGP implementations won't be able to verify your data signatures. You can do this by adding local-user $FINGERPRINT! for each (sub)key to sign with (note the trailing exclamation mark to specify the subkey). * You'll want to create your Curve25519 encryption subkey *after* the non-ECC one, as `gpg --encrypt --recipient $KEYID` only uses the most recent valid encryption-capable subkey, I think. So if you have an older non-ECC encryption subkey, older gpg(1) will encrypt to it while ?2.1 will use the Curve25519 encryption subkey. * You can use multiple authentication subkeys with gpg-agent's SSH agent emulation, but `gpg --export-ssh-key $KEYID` currently only exports the most recent authentication (sub)key, so you'll need to generate the relevant authorized_keys(5) for OpenSSH as follows: gpg --with-colons --list-key $FINGERPRINT \ | sed -nr 's/^[ps]ub:[^deir:]*(:[^:]*){2}:([0-9a-fA-F]+)(:[^:]*){7}a.*/\2/p' \ | xargs -I{} gpg --export-ssh-key {}\! (note the trailing exclamation mark to specify the subkey). Recent OpenSSH's PubkeyAcceptedKeyTypes default value contain ?ssh-ed25519, ssh-rsa? in that order so the Ed25519 (sub)key will be tried first. Older OpenSSH ? that don't support Ed25519 ? will fallback to the RSA (sub)key. > The alternative for me of course is to create a brand new key, with an > offline Ed25519 master key, plus some subkeys. Has anyone done this, > and can share their experience? IMHO it's too early to use an Ed25519 master key in production, because there are still a lot of legacy systems out there and that will make the whole key unusable for encryption and verification. It's fine to start bring such key to KSPs to improve its reputation and have a less painful key rollover later, though :-) Cheers, -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From hallomaarten at yahoo.com Tue Jan 2 14:43:25 2018 From: hallomaarten at yahoo.com (Maarten Nieber) Date: Tue, 2 Jan 2018 13:43:25 +0000 (UTC) Subject: trouble listing keys in my private-keys-v1.d directory References: <182245186.8000863.1514900605660.ref@mail.yahoo.com> Message-ID: <182245186.8000863.1514900605660@mail.yahoo.com> Hi, until today I was using gpg only for pass (the linux password manager). Today, I played around with gpg and now I have 2 problems: 1. I'm unable to list the key that is used for pass To list the keys, I use: gpg --list-keys. Some new keys that I added today are there, but my previous key that I used for pass is not there.Fortunately, I am able to use this key, so it exists! The gpg password dialog (that pops up when I invoke pass) tells me that it's an openpgp key with ID 89F615FB. When I run kbxutil --stats ~/.gnupg/pubring.kbx, it tells me that indeed there is 1 openpgp key: Total number of blobs:? ? ? ? 2? ? ? ? ? ? ? ?header:? ? ? ? 1? ? ? ? ? ? ? ? empty:? ? ? ? 0? ? ? ? ? ? ? openpgp:? ? ? ? 1? ? ? ? ? ? ? ? ?x509:? ? ? ? 0? ? ? ? ? non flagged:? ? ? ? 1? ? ? ?secret flagged:? ? ? ? 0? ? ephemeral flagged:? ? ? ? 0 Looking at the file modification dates, I suspect that my previous key is stored in?private-keys-v1.d, but this key is for some reasonnot showing up when I run gpg --list-keys ~/.gnupg $ ls -altotal 168drwx------? 4 maarten maarten? 4096 Jan? 2 14:11 .drwx------ 68 maarten maarten 20480 Jan? 1 17:59 ..-rw-------? 1 maarten maarten? 2649 Mar? 5? 2017 dirmngr.conf-rw-------? 1 maarten maarten? 5191 Mar? 5? 2017 gpg.conf-rw-------? 1 maarten maarten? ? ?0 Mar? 6? 2017 .gpg-v21-migrateddrwx------? 2 maarten maarten? 4096 Mar? 5? 2017 openpgp-revocs.ddrwx------? 2 maarten maarten? 4096 Mar? 5? 2017 private-keys-v1.d-rw-------? 1 maarten maarten? 3607 Jan? 2 14:11 pubring.gpg-rw-------? 1 maarten maarten? 3607 Jan? 2 14:11 pubring.gpg~-rw-r--r--? 1 maarten maarten? 1362 Mar? 5? 2017 pubring.kbx-rw-------? 1 maarten maarten? ? 32 Mar? 5? 2017 pubring.kbx~-rw-------? 1 maarten maarten? ?600 Jan? 2 14:11 random_seed-rw-r--r--? 1 maarten maarten? ?540 Jan? 1 23:02 revoke.carnism.asc-rw-------? 1 maarten maarten? 5199 Jan? 2 14:11 secring.gpgsrwx------? 1 maarten maarten? ? ?0 Jan? 2 11:02 S.gpg-agent-rw-------? 1 maarten maarten? 1440 Jan? 2 14:11 trustdb.gpg 2. pass is complaining when I try to add a new password: gpg: 89F615FB: There is no assurance this key belongs to the named usergpg: [stdin]: encryption failed: Unusable public key My hypothesis is that somehow, by creating a few extra keys today, my previous openpgp key is not visible anymore. Can somebody explain why that might be the case, and help me to repair this? Thanks in advance,Maarten -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Tue Jan 2 17:04:14 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 2 Jan 2018 16:04:14 +0000 Subject: trouble listing keys in my private-keys-v1.d directory In-Reply-To: <182245186.8000863.1514900605660@mail.yahoo.com> References: <182245186.8000863.1514900605660.ref@mail.yahoo.com> <182245186.8000863.1514900605660@mail.yahoo.com> Message-ID: <93d3ed47-28c6-170d-08ba-33f3b2dc33f4@incenp.org> Hi, On 01/02/2018 01:43 PM, Maarten Nieber via Gnupg-users wrote: > My hypothesis is that somehow, by creating a few extra keys today, my previous openpgp key is not visible anymore. Can somebody explain why that might be the case, and help me to repair this? My first guess would be that pass was using gpg2, while you started using gpg which on your system is probably gpg 1.4. The location of both the public and private keys has changed in the history of GnuPG (basically: public keys were stored in pubring.gpg in GnuPG <= 2.0, and in pubring.kbx from GnuPG 2.1, while private keys were stored in secring.gpg in GnuPG 1.x, and in private-keys-v1.d from GnuPG 2.0+). If gpg is gpg 1.x on your system, this could explain why you don't see your pass private key when you call gpg --list-keys. Can you check precisely which version(s) of GnuPG are available on your system? $ gpg --version $ gpg2 --version As for pass complaining about the "unusable public key", that could be the result of the trustdb having been updated by gpg 1.4 (which did not know that the private key for 89F615FB was available, and therefore has marked the corresponding public key as untrusted instead of having ultimate trust). If that's the case, the best option would probably be to stop using the old gpg 1.4 and use only gpg2. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Jan 2 20:26:12 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 02 Jan 2018 14:26:12 -0500 Subject: Ascii-armor in paper - question In-Reply-To: <77f866a4-7bf2-e1c3-eab5-7120a2e406fd@gmail.com> References: <77f866a4-7bf2-e1c3-eab5-7120a2e406fd@gmail.com> Message-ID: <87shbof4ff.fsf@fifthhorseman.net> Hi Egon-- sorry for the delay in responding to you here. On Mon 2017-12-25 14:49:02 +0100, Egon wrote: > I have an encrypted GPG Ascii-armored document which I want to print it > to paper in short form (if it is possible). > Does ascii-armor format redundant or redundancy it true only for GPG > keys? OpenPGP ASCII-armor does not provide any additional redundancy -- the "CRC" check at the end of ASCII armor will help you determine if there was an accidental transcription mistake, but it is *not* capable of helping you recover from such an error. ASCII-armor is at its core just base64 encoding. If you have a binary document that you want to print to be able to reconstruct byte-for-byte, you could just as well use the "base64" program to convert it to a printable sequence. You don't mention whether your document is OpenPGP-encrypted or OpenPGP-signed. I'm assuming in this discussion that the only thing OpenPGP-related for this document is the ASCII-armoring, since that's what you mention above, but if there are other OpenPGP characteristics you care about, you should probably mention them. > What can I do to print it in "shorter form"? (if available, convert it > to some standardized format which produce shorter text). converting a large document to a smaller document is best done with compression (e.g. gzip or xz). You can do this compression before converting to OpenPGP format, or you can do it as part of the OpenPGP conversion. I recommend doing the compression independently of OpenPGP conversion. > I want to find a method which help me to reconstruct the printed > ascii-armor file from paper more easily (if possible). > > Paperkey - I think - working only with GPG keys. paperkey is specifically designed for OpenPGP keys, correct. It will not help you produce a more minimal form of the ascii-armored document that is not an OpenPGP key. I think what you're looking for is twofold: * error correction * easy re-digitization You might find that QR codes attempt to tackle both of these problems. Take a look at https://blog.liw.fi/posts/qr-backup/ for a discussion of that approach, with some pointers. hope this helps, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From lewisurn at gmail.com Wed Jan 3 08:02:08 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Tue, 2 Jan 2018 23:02:08 -0800 Subject: Modernizing Web-of-trust for Organizations Message-ID: I saw some interests in this mailing list about PGP's certification and web-of-trust. I've been working on a system for enterprise customers that dramatically changes how PGP key signing and verification work and would like to discuss it here to see if someone is interested in it. 1. Goals of the system a. An organization does not depend on third-party certificate authorities. b. Its employees and business partners do not manually manage their own keys and trust relationship, and the administrator centrally manages all certificates and trustworthiness for the organization. c. Business units can flexibly define trust boundaries. For example, the security department can have some black hats as business partners but these black hats should be not be trusted by other employees of the organization. d. Providing end-to-end security with public key ciphers. An end user's private key should not be exposed to anyone, namely, only the end user has access to his or her private key to ensure valid signature and decryption. e. Support auditing of encrypted messages. 2. Current system design After building a prototype based on PGP, I'd like to share the parts that are closely related to, or dramatically different from, PGP. a. The new "autonomous certificate authority" trust model. In this model, an enterprise has a root key (RK) and a certifying key (CK). The RK is used to certify the CK, and the CK is used to certify keys of employees and business partners. Keys that are ultimately certified by the same RK are "potentially" considered trusted to each other. The RK represents the only certificate authority of the organization. The RK can be stored offline, and the CK is online for normal certification operations for security reasons. If the CK is compromised, then the RK can be used to revoke it and certify a new CK. b. Certificate verification. An organization has two types of users: employees and business partners. Accordingly, the system distinguishes two type of certificates: employee certificate and partner certificate. For a communication pair (the receiver and the sender), two keys are considered in the same trust realm if they are ultimately certified by the same RK (through the CK chain) and one of the certificate types is the employee certificate. Keys in the same realm are automatically considered as trusted to each other. When keys of business partners are certified by the CK, the above two design principles place the employees and business partners in the same trust realm and therefore trust each other, but not between two business partners because two business partners are not in the same trust realm. c. Trust groups. The employees and the administrator share security responsibility of business partner's certificates. Employees know business processes and understand which email addresses are business partners, and the administrator does not have this knowledge. Therefore, an employee invites an email address as a business partner by using an automated process that certifies the partner's key. The administrator can monitor which employee invites which email address as a business partner. When the employee invites a business partner, the former can specify or name a trust group for the latter and optionally add other partners and employees into the group. When the partner's key is certified by the CK, the group information is hashed in the certificate. In addition, other group members' certificates are updated to include the group information automatically. Now the certificate verification process has an additional constraint besides belonging to the same trust realm: the two certificates must share a common group in order to be considered trusted. However, this constraint is not applied if the two certificates are both employee certificates. This ensures that two employees always trust each other, but a business partner can only enter a trust group, not the realm, that is defined by the group owner which is an employee. This gives an organization the ability to define trust boundaries according to its own business needs. d. Auditing key. An organization also has an auditing key (AK) besides the RK and CK. When a user certified by the organization sends an encrypted email, the client plugin automatically encrypts the message with the AK besides receiver's key. As a result, goals 1.d and 1.e can be both achieved at the same time with help of other system design. The administrator only needs to use the AK private key at the auditing appliance to conduct business auditing or message scans. 3. System components. Since this has less relationship with PGP, I just mention that the entire system includes four major components: an organization key management system which runs the CK, the server which manages all user keys and certificates securely, a web user interface for the administrator, and a client plugin that performs encryption and certificate verification. The client plugin is a traditional PGP client with the above enhancement. I've implemented a chrome extension to demo a simple end-user interface in Gmail, whose snapshots are available at http://www.secregen.com. 4. It's worth of mentioning that I've used PGP's notation to hold the certificate type and trust group information. There is much left unsaid about the system, especially the management of user keys and certificates which are critical to zero-configuration on end-user side, but I would like to say this post is just my first-try to see if there is enough interest to this new trust model and its application for enterprise environments. Please feel free to ask questions or make comments if you're interested in learning more about or discussing the system. -- Thanks, Lou -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Jan 3 20:21:07 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 03 Jan 2018 14:21:07 -0500 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: Message-ID: <87y3led9zw.fsf@fifthhorseman.net> Hi Lou-- On Tue 2018-01-02 23:02:08 -0800, Lou Wynn wrote: > b. Its employees and business partners do not manually manage their own > keys and trust relationship, and the administrator centrally manages all > certificates and trustworthiness for the organization. backing up a bit here -- what kind of "trustworthiness" are you talking about in your proposal? your description includes several uses of the word "trust", but no clear explanation of what that trust entails. saying that keys are "trusted" doesn't mean much on its own. What is a "trusted" key allowed to do that an "untrusted" key is not allowed to do? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From lewisurn at gmail.com Wed Jan 3 22:04:38 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Wed, 3 Jan 2018 13:04:38 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <87y3led9zw.fsf@fifthhorseman.net> References: <87y3led9zw.fsf@fifthhorseman.net> Message-ID: <62eedf27-e45f-92df-cae5-5d882eb2c2ff@gmail.com> On 01/03/2018 11:21 AM, Daniel Kahn Gillmor wrote: > Hi Lou-- > > On Tue 2018-01-02 23:02:08 -0800, Lou Wynn wrote: >> b. Its employees and business partners do not manually manage their own >> keys and trust relationship, and the administrator centrally manages all >> certificates and trustworthiness for the organization. > backing up a bit here -- what kind of "trustworthiness" are you talking > about in your proposal? your description includes several uses of the > word "trust", but no clear explanation of what that trust entails. > > saying that keys are "trusted" doesn't mean much on its own. What is a > "trusted" key allowed to do that an "untrusted" key is not allowed to > do? > > --dkg Yes, "trusted" keys do not mean much without contexts. There are few contexts to see what trustworthiness means. 1. From certificate verification point of view, a trusted key means that the certificate is verified to be in the same trust realm or in the same trust group with the receiver. 2. From the user interface point of view, a trusted key is reflected by marking the sender's signature is verified, and an untrusted key is marked by the warning that the signature cannot be verified. An automated or manual process can be applied to delete or quarantine messages whose signature verification fails. The screenshots on the web link show this intuitive UI. Of course, the final decision about what to do with such messages is up to the receiver. The warning of signature verification makes the receiver aware of the sender status, which is either certified to be in the same trust realm/group or not being certified as such. Thanks, Lou From lewisurn at gmail.com Wed Jan 3 22:46:16 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Wed, 3 Jan 2018 13:46:16 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <62eedf27-e45f-92df-cae5-5d882eb2c2ff@gmail.com> References: <87y3led9zw.fsf@fifthhorseman.net> <62eedf27-e45f-92df-cae5-5d882eb2c2ff@gmail.com> Message-ID: I just realized that I overloaded the meaning of signature verification. Here, signature verification, both in my previous discussion and in the receiver's UI, also includes the certificate verification described in 2.b, in addition to traditional signature verification. Thanks, Lou On 01/03/2018 01:04 PM, Lou Wynn wrote: > Yes, "trusted" keys do not mean much without contexts. There are few > contexts to see what trustworthiness means. > > 1. From certificate verification point of view, a trusted key means that > the certificate is verified to be in the same trust realm or in the same > trust group with the receiver. > > 2. From the user interface point of view, a trusted key is reflected by > marking the sender's signature is verified, and an untrusted key is > marked by the warning that the signature cannot be verified. An > automated or manual process can be applied to delete or quarantine > messages whose signature verification fails. The screenshots on the web > link show this intuitive UI. Of course, the final decision about what to > do with such messages is up to the receiver. The warning of signature > verification makes the receiver aware of the sender status, which is > either certified to be in the same trust realm/group or not being > certified as such. > > Thanks, > Lou > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bagel.alderman at protonmail.com Wed Jan 3 23:42:19 2018 From: bagel.alderman at protonmail.com (Bagel Alderman) Date: Wed, 03 Jan 2018 17:42:19 -0500 Subject: Obtaining Key Stubs From Smartcard Message-ID: I've been trying to learn to use GnuPG and have hit a spot of trouble. My goal is to set up an off-line master key with a sub-key each for signing, encryption and authentication, and to keep the sub-keys on a smart card (Yubikey) for convenient use. To prepare for the inevitable moment I destroy/lose my Yubikey, I want to keep a copy of my sub-keys on my backup Yubikey as well. So far I have been able to manage this by using keytocard, deleting the local stubs, and importing the sub-keys from a backup. Using this method, the most recent Yubikey to have keys moved to it is listed as the key which contains the sub-keys. My concern is this: If I do lose my Yubikey, I wont be able to use my backup Yubikey without first deleting current stubs, importing my backup sub-keys, and keytocard-ing them to the backup Yubikey, since my machine thinks the stubs only exist on the lost/destroyed smart card. I've heard several say that the workaround is to use gpg --card-status to create key stubs from the currently inserted smart card, but so far I haven't had any luck getting that to work, neither on my Ubuntu machine or my Windows 7 box. Can anyone tell me why gpg --card-status isn't creating key stubs (even after the original stubs are deleted)? It displays card information, but that seems to be all it does. Ubuntu 16.04 using GnuPG v2.1.11 installed/updated with apt Windows 7 using GnuPG v2.2.3 via gpg4win -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Thu Jan 4 01:40:59 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Thu, 4 Jan 2018 00:40:59 +0000 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: Message-ID: <12300523.20180104004058@my_localhost_LG> Hi On Wednesday 3 January 2018 at 7:02:08 AM, in , Lou Wynn wrote:- > 1. Goals of the system > a. An organization does not depend on third-party certificate > authorities. It is already the case that an organisation does not need to depend on third-party CAs to certify its staff's OpenPGP keys. For example, my ISP [0] says "All staff keys are signed using the company signing key. This is very much like a traditional company seal. Only the director has access to this key and it is only used for signing other keys. If/when a member of staff leaves a revocation is issued of that signature and loaded on to keyservers." > b. Its employees and business partners do not manually manage their > own keys and trust relationship, and the administrator centrally > manages all certificates and trustworthiness for the organization. Are you talking about something like a shared keyring? Or just managing trust relationships by issuing key certifications and revocations? > c. Business units can flexibly define trust boundaries. For example, > the security department can have some black hats as business > partners but these black hats should be not be trusted by other > employees of the organization. Would the business unit achieve this by using their own certifying key in addition to the enterprise-wide certifying key? > d. Providing end-to-end security with public key ciphers. An end > user's private key should not be exposed to anyone, namely, only the > end user has access to his or her private key to ensure valid > signature and decryption. So each user would still generate their own key pair. > When keys of business partners are certified by the CK, the above > two design principles place the employees and business partners in > the same trust realm and therefore trust each other, but not between > two business partners because two business partners are not in the > same trust realm. Isn't it up to the two business partners to decide whether or not to trust each others' keys? Whether or not the business partners choose to consider the presence of the certification from the company's RK/CKs when making their respective decisions, isn't it ultimately not really any of the company's business? [0] -- Best regards MFPA Zorba the Greek - before he zorbas you -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 1252 bytes Desc: not available URL: From lewisurn at gmail.com Thu Jan 4 02:34:30 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Wed, 3 Jan 2018 17:34:30 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <12300523.20180104004058@my_localhost_LG> References: <12300523.20180104004058@my_localhost_LG> Message-ID: Hi MFPA, On 01/03/2018 04:40 PM, MFPA wrote: > Hi > >> a. An organization does not depend on third-party certificate >> authorities. > It is already the case that an organisation does not need to depend on > third-party CAs to certify its staff's OpenPGP keys. > > For example, my ISP [0] says "All staff keys are signed using the > company signing key. This is very much like a traditional company > seal. Only the director has access to this key and it is only used for > signing other keys. If/when a member of staff leaves a revocation is > issued of that signature and loaded on to keyservers." >> b. Its employees and business partners do not manually manage their >> own keys and trust relationship, and the administrator centrally >> manages all certificates and trustworthiness for the organization. > Are you talking about something like a shared keyring? Or just > managing trust relationships by issuing key certifications and > revocations? The short answer is for both. End users do not need to manage their keys, both private and public; nor do they need to trust the company key as described in your reference "It is up to you if you wish to trust the company key to sign others, but we recommend you trust it to sign any @aa.net.uk or @aaisp.net.uk email addresses on keys". Your first comment above mentioned no 3rd-party CA is needed for PGP users, but the reference still requires users to manage their trust. In my opinion, PGP has an unnecessarily complicated trust management recommendation: the web of trust, when used in an enterprise environment. My goal is to simplify user-side trust management work to zero, and the result is the concept of trust realm and trust group. They are explicitly validated by certificate verification which is carried out together with the signature verification when a message is received. The management of users' private key is a little more complicated. I use two levels of protection. One level is at the organization. An organization actually has a fourth key, which I call the guard key, to encrypt the password of user's private key. This guard key is also managed by the key management system. In addition, a user can choose another her own password to encrypt the key password too. >> c. Business units can flexibly define trust boundaries. For example, > Would the business unit achieve this by using their own certifying > key in addition to the enterprise-wide certifying key? No, there is no business unit level certifying key. An enterprise only has one root key, which is the ultimate certificate authority for its own employees and business partners. >> d. Providing end-to-end security with public key ciphers. An end >> user's private key should not be exposed to anyone, namely, only the >> end user has access to his or her private key to ensure valid >> signature and decryption. > So each user would still generate their own key pair. That is correct technically. A goal here is to make this process as transparent to users. As I mentioned above, the only operation for a user to do with key management is choosing a user own password to protect the private key. >> When keys of business partners are certified by the CK, the above >> two design principles place the employees and business partners in >> the same trust realm and therefore trust each other, but not between >> two business partners because two business partners are not in the >> same trust realm. > Isn't it up to the two business partners to decide whether or not to > trust each others' keys? Totally agree, I've designed the trust realm and the group to establish trustworthiness between employees and their immediate business partners, not among partners. > Whether or not the business partners choose > to consider the presence of the certification from the company's > RK/CKs when making their respective decisions, isn't it ultimately not > really any of the company's business? > > > [0] > Thanks, Lou From lewisurn at gmail.com Thu Jan 4 02:46:55 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Wed, 3 Jan 2018 17:46:55 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> Message-ID: <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> On 01/03/2018 05:34 PM, Lou Wynn wrote: >> Are you talking about something like a shared keyring? Or just?managing trust relationships by issuing key certifications and >> revocations? > The short answer is for both. End users do not need to manage their When I said for "both," I might have misunderstood what you meant by a shared keyring? Can you explain it a little bit? My system doesn't share anything that is related to user private keys, except for that encrypted private keys are saved in a database. An analogy is placing two people's encrypted PGP secret keyring on a file server, and decryption is still done at the client side. I'm not sure if this is what you meant by a shared keyring. Thanks, Lou From 2017-r3sgs86x8e-lists-groups at riseup.net Thu Jan 4 03:37:23 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Thu, 4 Jan 2018 02:37:23 +0000 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> Message-ID: <1288953570.20180104023723@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 4 January 2018 at 1:46:55 AM, in , Lou Wynn wrote:- > When I said for "both," I might have misunderstood what you meant by > a shared keyring? Can you explain it a little bit? PGP and GnuPG traditionally store private keys in a secret keyring and public keys in a public keyring. Each user's secret keyring has just their own secret keys. Each user's public keyring contains their own public keys, plus other people's public keys for encrypting messages or checking signatures. Multiple users' OpenPGP installations could theoretically all be configured to point to the same shared keyring files instead of each user having their own local keyring files (or all their local keyring files could be kept in sync with a central copy). > My system doesn't > share anything that is related to user private keys, except for that > encrypted private keys are saved in a database. If the user's OpenPGP software accesses that database each time it needs to use the private key, the database is providing the same function as the old secret keyring. > An analogy is > placing two people's encrypted PGP secret keyring on a file server, > and decryption is still done at the client side. I'm not sure if > this is what you meant by a shared keyring. If my keyring and your keyring happened to be stored on the same server but they were separate and there was no sharing or syncing between them, it would not be a shared keyring. - -- Best regards MFPA Is it bad luck to be superstitious? -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWk2TLV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +scSAP4vmeuwK8YCAyYjs4Psorv96r7m3oxgzLu7sJKF96yXTQEAgAjsz8M6S03n 8sLlKoRB8wlcCmjzECrzjtTytkNsfwSJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWk2TP18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/5DkD/9BrPANt1BW46XokjuD/kcjuJxQ F24osueo+o/Cu/+oRnXVExm8dj1zSmr5FH5WUPxejCHORzVxEZjeKAQaLOUoxNjr hpWvJckeYi7O/+Iv7Mcvj5T88qawtebB/R8RseXak68ZIag6eFG9aMa6qIV75Jvq 60AFLEmZwOOtAoUxfwaIAgLqUc2ER2IYtdiUQX31xsNUrG60nIrWHl77mu7x31L3 FJm1t8wCI6WCKWHCygThkxFburohGIHhsC8z2MEfaN0/e/zy/ZNccC4pfhMOcAWR 1ArFEkRkluMVlkFPItPuwmSDINR3UltTyi77CQ0hYpceleJ47p2n+auYNnSS6Q+D pIh1q4nMlVCG0TgUI98lKn4JcklHfiu7HGJhFgik+tvC+2TJ+U1NZtVWqZCsr+cA YePtEyB8Pe82iu7SL3RF5AjtCJa4aS9DQjZixKwxe6WaOfVrcgd+Ne2z6nYX9vto uSRmir5f5yVhP849AyZ5q31OLPJ8GsvyLF4hyBe1Of6SxhVnlggSZJaJg3/Z31Zr /2J0U85bk8KyKtWbGn+t1KgrDt1N/u5ExuEkE3PU/5phip3gEHFymB8qqOrBCUAQ cMcp9W5hI0LAGwGJJ8vKAieoIEQvyIG6d70i/Q1C6+ktNzJSlOfvIUJMFDnXdhAM 4x3CgH8LC0MuJEMRfQ== =Ol4C -----END PGP SIGNATURE----- From lewisurn at gmail.com Thu Jan 4 05:42:07 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Wed, 3 Jan 2018 20:42:07 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <1288953570.20180104023723@my_localhost_LG> References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> Message-ID: On 01/03/2018 06:37 PM, MFPA wrote: > Hi > > > On Thursday 4 January 2018 at 1:46:55 AM, in > , Lou Wynn wrote:- > > If the user's OpenPGP software accesses that database each time it > needs to use the private key, the database is providing the same > function as the old secret keyring. > > If my keyring and your keyring happened to be stored on the same > server but they were separate and there was no sharing or syncing > between them, it would not be a shared keyring. This is what happens in my system, so it is not a shared keyring. My system uses a customized PGP client, which acts like a special web client. It has a client key and uses it to log into the server, which is similar to SSH key authentication, to retrieve the private key after authentication. It does not save the private key locally on storage devices after decrypting it; it only keeps the private key in memory until session times out, when it cleans the private key from memory. But it caches public keys locally though. In this sense, you could say that the client has local public key rings and a remote private key ring if you like to compare it with GnuPG implementation. Thanks, Lou From lewisurn at gmail.com Thu Jan 4 06:10:34 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Wed, 3 Jan 2018 21:10:34 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> Message-ID: On 01/03/2018 04:40 PM, MFPA wrote: >> It is already the case that an organisation does not need to depend on >> third-party CAs to certify its staff's OpenPGP keys. >> It's true for OpenPGP because OpenPGP is a distributed system, there is no single CA, or it doesn't have the concept of CA at all. My original implicit reference is PKI based S/MIME. The autonomous certificate authority model is different from both PKI and web of trust. As I explained in one of my previous posts that this model clearly defines what trustworthiness is. The short version is: A trusted key or trustworthiness means that the sender's certificate is verified to be in the same trust realm or in the same trust group with the receiver, besides traditional signature verification. In this model, end users are freed from managing trust relationship completely because the trustworthiness can be checked mechanically and it makes sense to organizational usages. Thanks, Lou From andrewg at andrewg.com Thu Jan 4 09:25:27 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 4 Jan 2018 08:25:27 +0000 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> Message-ID: > On 4 Jan 2018, at 04:42, Lou Wynn wrote: > > It has a client key and uses it to log into the server, which is > similar to SSH key authentication, to retrieve the private key after > authentication. This bit confuses me. If you already store a private key locally, why use it to download a second private key? If you?re using a key escrow system then surely you just need to upload the private key once and keep a local copy? A From peter at digitalbrains.com Thu Jan 4 11:27:18 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 4 Jan 2018 11:27:18 +0100 Subject: Obtaining Key Stubs From Smartcard In-Reply-To: References: Message-ID: <37d31b07-42da-c0cc-d8bc-737a390e02e5@digitalbrains.com> On 03/01/18 23:42, Bagel Alderman via Gnupg-users wrote: > Can anyone tell me why gpg --card-status isn't creating key stubs (even > after? the original stubs are deleted)? Could you post commands entered and their result? We can't tell what goes wrong just by this description. It has always worked fine for me. By the way, a quicker method than > using keytocard, deleting the local stubs, and importing the sub-keys from a backup is using keytocard and then not saving the changes. That way, the key is both on the card and on disk. 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 kristian.fiskerstrand at sumptuouscapital.com Thu Jan 4 12:02:35 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 4 Jan 2018 12:02:35 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> Message-ID: On 01/04/2018 02:34 AM, Lou Wynn wrote: > No, there is no business unit level certifying key. An enterprise only > has one root key, which is the ultimate certificate authority for its > own employees and business partners. I normally recommend separating those, as the value for external parties that might want to trust this CA for certifying employees but not other third parties. As for access to private key material, I normally recommend that the end user never has access to any secret key material, but only access to using subkeys (never the primary) using smartcard tokens. Wrt your other discussion of ssh based scheme, an alternative for escrow is actually using gnupg 2.1's gpg-agent through SSH socket forwarding so key material never is available locally, a system could theoretically be set up in a restricted setup so user doesn't actually get access to the key material (but it would require some setup to ensure they don't have it, so smartcard is generally easier) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Carpe noctem Seize the night -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Thu Jan 4 15:10:42 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Thu, 4 Jan 2018 14:10:42 +0000 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> Message-ID: <31807605.20180104141042@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thursday 4 January 2018 at 1:34:30 AM, in , Lou Wynn wrote:- > Your first comment above mentioned no 3rd-party CA is needed for PGP > users, but the reference still requires users to manage their trust. > In my opinion, PGP has an unnecessarily complicated trust management > recommendation: the web of trust, when used in an enterprise > environment. It is up to the enterprise how simple or complicated they choose to make it. Their internal web of trust could be a simple hierarchy. > My goal is to simplify user-side trust management work > to zero, and the result is the concept of trust realm and trust > group. How complicated is user-side trust management within an enterprise environment? If their internal web of trust is a simple hierarchy, each user's software automatically trusts all other employees. For business partners, the enterprise's certification key would have to be able to sign the business partner's key as a trusted introducer but only for staff at their own domain. Perhaps the use of Web Key Directory [0] is already a simple enough solution. The organisation's particular threat model may not require the keys of business partners' staff to be signed at all as long as each contact consistently uses the same key. In that case, Trust On First Use (TOFU) [1] may be sufficient. [0] [1] - -- Best regards MFPA Never trust a dog with orange eyebrows -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWk415F8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +p3PAQCwGkiAzOTumDV1rSPtSSLI+Ox155txEAiB/KPhNdUiNgEAhJsh8iXOJEB7 4x/9Mr74vObJlmhY8xp4F/G6y1klUA2JApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWk415F8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/+/jEACSWurMNn2RRQdT+mGkhS/VxIeb noHv3IgBgWUmMN0REwD+wxgH3qg1NIUA3dgNM22pBv/D3CIRyKQ0uWGle6HsdwHP YGDKWdqrhVbVj37nvGEYiXiEE/Eg6SZWUo7ukzqcnAexQSgb/NBVs/fvX8hwYV4M 7Rmg73vtq2zpVFI8aHwEUVBov+NMLugDDdsPJhBHHnzwcY3PHXo/SKgNo2DVe9EA fzxh68KyFKhpkOc5Pd9u7XtzaX9E0HBf1Bik9l9UQxq6hnOsewlHs6qFRoJRiKsh 7cWczb/01VsyqfXZSH4eWfxoy1TuRnQjX2hIH/9JVf7A1pJZxE0LLIgDs/NGRIRr SiLN/TFGrzun9ty7XhPQYjBMbIL3oPGUNEPsTisk0z2qq8HIMCeUT5JmM8fu1B3H F1asqR3lJVJOWrElkAxuX4ocB7slL9psyJMVWUb8/Fs2nnlOgmMD/KV2gDGVwmPY VXCJN8t2D8QZf3eUGODy7/jHMpAkz3f2vZw5E/y0vZVcGVoX2QAhMWWKZlg0FsR3 Y4Mi9fIlZGv/zEE/C6icV8g3+1eCKVtNRZW533O/NS9j6Y90gZBRN4qabJELVFNp IPCPCzRMYbJkPXSnhcF2NfFraXMe7/CVITijdo2R8XmyYud8wuL6RDXwqZz2p8pt YlQ32ar6pqY7tZhplQ== =iXSr -----END PGP SIGNATURE----- From bagel.alderman at protonmail.com Thu Jan 4 17:56:41 2018 From: bagel.alderman at protonmail.com (Bagel Alderman) Date: Thu, 04 Jan 2018 11:56:41 -0500 Subject: Obtaining Key Stubs From Smartcard In-Reply-To: <37d31b07-42da-c0cc-d8bc-737a390e02e5@digitalbrains.com> References: <37d31b07-42da-c0cc-d8bc-737a390e02e5@digitalbrains.com> Message-ID: -------- Original Message -------- Subject: Re: Obtaining Key Stubs From Smartcard Local Time: January 4, 2018 4:27 AM UTC Time: January 4, 2018 10:27 AM From: peter at digitalbrains.com To: Bagel Alderman , gnupg-users at gnupg.org >Could you post commands entered and their result? We can't tell what goes wrong just by this description. Command entered(Ubuntu 16.04): gpg2 --card-status Result (some card data replaced with ""): Reader............: Yubico Yubikey NEO OTP U2F CCID 00 00 Application ID....: D2760001240102000006053043400000 Version...........: 2.0 Manufacturer......: Yubico Serial number.....: Name of cardholder: Language prefs....: en Sex...............: unspecified URL of public key.: '' Login data........: Signature PIN.....: forced Key attributes....: rsa2048 rsa2048 rsa2048 Max. PIN lengths..: 127 127 127 PIN retry counter.: 3 3 3 Signature counter.: 20 Signature key.....: created...: 2018-01-02 20:50:36 Encryption key....: created...: 2018-01-02 20:51:07 Authentication key: created...: 2018-01-02 20:51:31 General key info..: [none] After that, I run gpg2 -K to confirm I don't have stubs for the keys on the card. >By the way, a quicker method than using keytocard, deleting the local stubs, and importing the sub-keys from a backup is using keytocard and then not saving the changes. That way, the key is both on the card and on disk. Good to know, thanks. Please let me know if there's anything else I can check that'd be useful for diagnosing this. I appreciate your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Thu Jan 4 17:51:20 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 4 Jan 2018 17:51:20 +0100 Subject: GnuPG on Android [was: Re: FAQ and GNU] In-Reply-To: <87po9tg32t.fsf@fifthhorseman.net> References: <87tvz69mua.wl-neal@walfield.org> <87po9tg32t.fsf@fifthhorseman.net> Message-ID: <201801041751.26654.bernhard@intevation.de> Hi, note that a search for "Android" in wiki.gnupg.org would have shown you the Guardian port of GnuPG 2.1 to Android. (I've added additional details now.) Am Mittwoch 11 Oktober 2017 16:40:42 schrieb Daniel Kahn Gillmor: > here's the project i was thinking of that was farthest along in terms of > system integration on Android is: > > ? ?https://guardianproject.info/code/gnupg/ In 2016 I've downloaded and briefly tried the app. It also was available from the Free Software app store for Android: fdroid. So it indeed build and ran. The 2016 study for using OpenPGP on Android (in German) linked from https://wiki.gnupg.org/Gpg4all2015?highlight=(Android) has a more elaborate discussion of the port. It tests the 2014 version that was supposed to be installed from the app store between 100k and 500k times. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From ben at adversary.org Thu Jan 4 22:04:59 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 5 Jan 2018 08:04:59 +1100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <12300523.20180104004058@my_localhost_LG> References: <12300523.20180104004058@my_localhost_LG> Message-ID: <20180104210459.5xwkubj7rdxrtzei@adversary.org> On Thu, Jan 04, 2018 at 12:40:59AM +0000, MFPA wrote: > > For example, my ISP [0] says "All staff keys are signed using the > company signing key. This is very much like a traditional company > seal. Only the director has access to this key and it is only used > for signing other keys. If/when a member of staff leaves a > revocation is issued of that signature and loaded on to keyservers." > > [0] Cute, but they're fast approaching the point where anyone with a decent beowolf cluster and an axe to grind could mess with that 1K certification key they're using there. Perhaps one of their loyal customers with extensive experience in weird edge cases of PGP and GPG use could smack them upside of the proverbial head with a clue-by-four. ;) Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From lewisurn at gmail.com Thu Jan 4 22:21:31 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 4 Jan 2018 13:21:31 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> Message-ID: On 01/04/2018 12:25 AM, Andrew Gallagher wrote: >> On 4 Jan 2018, at 04:42, Lou Wynn wrote: >> >> It has a client key and uses it to log into the server, which is >> similar to SSH key authentication, to retrieve the private key after >> authentication. > This bit confuses me. If you already store a private key locally, why use it to download a second private key? If you?re using a key escrow system then surely you just need to upload the private key once and keep a local copy? > > A There is no key escrow in my design because a user's private key should not be accessible to anyone else including the administrator. For an organization, granting the administrator too much, unnecessary privilege is dangerous especially when he leaves. Let me try to explain it in another way. Each end user has an email key. When she uses multiple email clients, each client plugin has a key pair serving as the identity of the client plugin. The client plugin registers itself on the server with its public key when the client plugin is installed or initialized. This key belongs to the plugin and is used for the plugin to log into the server. The administrator and/or the end user can monitor how many client plugins the user uses. The administrator may disable the login of a particular client plugin if it is compromised such as an employee loses his computer. In addition, the administrator may optionally set up a policy that requires the user to choose a login password except for the public-key authentication of the client plugin. After a client plugin logs in successfully, the server sends the user's encrypted email key to the client. Thanks, Lou From kristian.fiskerstrand at sumptuouscapital.com Thu Jan 4 22:31:07 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 4 Jan 2018 22:31:07 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> Message-ID: <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> On 01/04/2018 10:21 PM, Lou Wynn wrote: > After a client plugin logs in successfully, the server sends the user's > encrypted email key to the client. Aren't you better off with a gateway solution like PGP Universal / Symantec Encryption Server (or for that matter if GPGRelay is still alive) ? That never exposes key material to client, i.e always operates within corporate infrastructure and removes a lot of complexity and allows for easier indexing/searching. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Leadership is a potent combination of strategy and character. But if you must be without one, be without the strategy." (Norman Schwarzkopf) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lewisurn at gmail.com Thu Jan 4 22:58:06 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 4 Jan 2018 13:58:06 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> Message-ID: <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> On 01/04/2018 01:31 PM, Kristian Fiskerstrand wrote: > On 01/04/2018 10:21 PM, Lou Wynn wrote: >> After a client plugin logs in successfully, the server sends the user's >> encrypted email key to the client. > Aren't you better off with a gateway solution like PGP Universal / > Symantec Encryption Server (or for that matter if GPGRelay is still > alive) ? That never exposes key material to client, i.e always operates > within corporate infrastructure and removes a lot of complexity and > allows for easier indexing/searching. > It's doable, but I'd like to make sure that I understand what you mean by "within corporate infrastructure?" Do you mean the client plugin sends requests to the server to decrypt and verify received messages? This is definitely a trade-off between key security and performance. But I don't see any obvious benefits given that the user's computer that runs the client plugin also belongs to corporate infrastructure. If the user's computer is compromised, then the administrator simply clean up the computer and re-install or re-initialize user's email client, which includes the client plugin. In my design, each end user does not have a permanent identity like in OpenPGP where he needs to accumulate his reputation for "trustworthiness." The only authority is the organization's root key. Among other things, a user's key is simply a way of declaring that the email message is authorized by the user who has been certified by the organization's root key. In this situation, a user's key is not more important than his email account. Thanks, Lou From lewisurn at gmail.com Thu Jan 4 23:04:05 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 4 Jan 2018 14:04:05 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <20180104210459.5xwkubj7rdxrtzei@adversary.org> References: <12300523.20180104004058@my_localhost_LG> <20180104210459.5xwkubj7rdxrtzei@adversary.org> Message-ID: <5e8adf34-bd5d-4406-6599-03caad161f66@gmail.com> On 01/04/2018 01:04 PM, Ben McGinnes wrote: > On Thu, Jan 04, 2018 at 12:40:59AM +0000, MFPA wrote: >> For example, my ISP [0] says "All staff keys are signed using the >> company signing key. This is very much like a traditional company >> seal. Only the director has access to this key and it is only used >> for signing other keys. If/when a member of staff leaves a >> revocation is issued of that signature and loaded on to keyservers." >> >> [0] > Cute, but they're fast approaching the point where anyone with a > decent beowolf cluster and an axe to grind could mess with that 1K > certification key they're using there. Can you explain what the problem is? I don't really know what you mean, but I've love to hear. Thanks, Lou From kristian.fiskerstrand at sumptuouscapital.com Thu Jan 4 23:04:49 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 4 Jan 2018 23:04:49 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <7db7f27c-bf3e-28dc-32ca-6da8662052c9@gmail.com> References: <12300523.20180104004058@my_localhost_LG> <7db7f27c-bf3e-28dc-32ca-6da8662052c9@gmail.com> Message-ID: <727a9f22-5d06-2034-646a-db55dcf82d6e@sumptuouscapital.com> On 01/04/2018 10:38 PM, Lou Wynn wrote: > On 01/04/2018 03:02 AM, Kristian Fiskerstrand wrote: >> On 01/04/2018 02:34 AM, Lou Wynn wrote: >>> No, there is no business unit level certifying key. An enterprise only >>> has one root key, which is the ultimate certificate authority for its >>> own employees and business partners. >> I normally recommend separating those, as the value for external parties >> that might want to trust this CA for certifying employees but not other >> third parties. > I don't think it necessary to use business unit level certifying keys in > my design. It introduces management overhead which shadows its benefits. > If you understand the concept of trust realm/trust group and its > verification methods I described before, then there is no need for a key > hierarchy at all. Can you describe a use case that demands the use of > unit level certifying key? I'll try to explain how to implement it with > trust realm and groups. I didn't necessarily say businsess unit level CA, but separation between employee and business partner CAs. >> As for access to private key material, I normally recommend that the end >> user never has access to any secret key material, but only access to >> using subkeys (never the primary) using smartcard tokens. > I completely agree, and indeed in my system, an end user never needs to > directly access his secret key. Actually, he does not need to access his > public key either. This is what I mean by zero configuration on client > side, both for trust management and key management. > > Thanks, > Lou > -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Carpe noctem Seize the night -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Jan 4 23:08:23 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 4 Jan 2018 23:08:23 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> Message-ID: <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> On 01/04/2018 10:58 PM, Lou Wynn wrote: > It's doable, but I'd like to make sure that I understand what you > mean by "within corporate infrastructure?" Do you mean the client > plugin sends requests to the server to decrypt and verify received > messages? no, there isn't necessarily a client plugin, the gateway decrypts the message before it hits the internal email server, so end-user sees un-encrypted message, this is protecting transport, but security of on-site is ensures through different channels > This is definitely a trade-off between key security and performance. > But I don't see any obvious benefits given that the user's computer > that runs the client plugin also belongs to corporate infrastructure. > If the user's computer is compromised, then the administrator simply > clean up the computer and re-install or re-initialize user's email > client, which includes the client plugin. I don't see this as disagreeing, this means you don't have any benefit from storing the email in encrypted form once it hits the corporate network, so you're better off decryption it at gateway anyways. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "A committee is a group that keeps minutes and loses hours." (Milton Berle) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lewisurn at gmail.com Thu Jan 4 23:14:41 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 4 Jan 2018 14:14:41 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <727a9f22-5d06-2034-646a-db55dcf82d6e@sumptuouscapital.com> References: <12300523.20180104004058@my_localhost_LG> <7db7f27c-bf3e-28dc-32ca-6da8662052c9@gmail.com> <727a9f22-5d06-2034-646a-db55dcf82d6e@sumptuouscapital.com> Message-ID: On 01/04/2018 02:04 PM, Kristian Fiskerstrand wrote: >> I don't think it necessary to use business unit level certifying keys in >> my design. It introduces management overhead which shadows its benefits. >> If you understand the concept of trust realm/trust group and its >> verification methods I described before, then there is no need for a key >> hierarchy at all. Can you describe a use case that demands the use of >> unit level certifying key? I'll try to explain how to implement it with >> trust realm and groups. > I didn't necessarily say businsess unit level CA, but separation between > employee and business partner CAs. Compared to using two CAs, my design introduces two properties to a certificate. One is the certificate type, which is "p" for a partner and "e" for an employee. The other property is the trust group, which is a list of groups and tells the certificate verifier the groups that the key belongs to. These two properties are implemented as notations of the certificate. Thanks, Lou From lewisurn at gmail.com Thu Jan 4 23:24:35 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 4 Jan 2018 14:24:35 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> Message-ID: <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> On 01/04/2018 02:08 PM, Kristian Fiskerstrand wrote: > no, there isn't necessarily a client plugin, the gateway decrypts the > message before it hits the internal email server, so end-user sees > un-encrypted message, this is protecting transport, but security of > on-site is ensures through different channels I see. The gateway solution is contradictory to my end-to-end email security goal, which requires that only the end user can use his own private key. The gateway is a total disaster if the gateway is breached. > I don't see this as disagreeing, this means you don't have any benefit > from storing the email in encrypted form once it hits the corporate > network, so you're better off decryption it at gateway anyways. > I guess that you missed the auditing key part. I introduced it to meet auditing requirements or scanning of messages without using end user's private keys. Thanks, Lou From ben at adversary.org Thu Jan 4 23:28:18 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 5 Jan 2018 09:28:18 +1100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> Message-ID: <20180104222818.dolhf4py76c7qchl@adversary.org> On Wed, Jan 03, 2018 at 05:34:30PM -0800, Lou Wynn wrote: > > The management of users' private key is a little more complicated. I > use two levels of protection. One level is at the organization. An > organization actually has a fourth key, which I call the guard key, > to encrypt the password of user's private key. This guard key is > also managed by the key management system. In addition, a user can > choose another her own password to encrypt the key password too. That just spreads the potential points of human failure and you run the risk that anyone with access to this guard key would be able to abuse the position to access an employee's credentials (saying they don't have access to the private key doesn't hold any weight on a company intranet where they've probably already got root/admin access). So it'd be too easy for some unscrupulous sys admin (you might trust you, but what happens when you leave, do you know your successor?) has a personal issue with someone in, say, marketing and stitches them up with a few choice forged and signed emails. No, that's a *bad* plan and creates all sorts of horrible legal problems for the company or at least has the very real potential to do so. It seems to me, though, that the idea was to provide a means for the company to repudiate an employee's key even if the employee was no longer available. Perhaps they were fired or just became very ill or any of a host of reasons with varying degrees of potential drama attached. This is a legitimate issue in the corporate environment, but the solution to it is not to maintain an escrow on private keys and passphrases which could subsequently be abused by a technically proficient person within the company. What you should do instead is keep an encrypted and archived copy of the revocation certificate for each employee's key. That way it is still possible to declare that the key and/or employee is no longer sanctioned, but without providing a means where anyone with access to this system could either intercept encrypted communications sent to that key or forge messages appearing to come from it. Any other option is going to end up in a legal dispute eventually and will probably cost *far* more than what you think you're saving yourself from now. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Jan 4 23:57:42 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 4 Jan 2018 23:57:42 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> Message-ID: <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> On 01/04/2018 11:24 PM, Lou Wynn wrote: > I guess that you missed the auditing key part. I introduced it to meet > auditing requirements or scanning of messages without using end user's > private keys. but you add the requirement that all end users sending email to you require to validate the auditing key as well (auditing is likely wrong word, archiving is more likely relevant). for auditing you certainly want gpg-agent monitoring of assuan channel in separate domain. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Amantes sunt amentes Lovers are lunatics -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Jan 4 23:59:03 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 4 Jan 2018 23:59:03 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> <7db7f27c-bf3e-28dc-32ca-6da8662052c9@gmail.com> <727a9f22-5d06-2034-646a-db55dcf82d6e@sumptuouscapital.com> Message-ID: <5013b8f1-cdab-691c-5c2c-4abd7fa2d08c@sumptuouscapital.com> On 01/04/2018 11:14 PM, Lou Wynn wrote: > Compared to using two CAs, my design introduces two properties to a > certificate. One is the certificate type, which is "p" for a partner and > "e" for an employee. why not make it compatible with rfc4880 directly? your proposal would require client handling of e.g notation data? -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Amantes sunt amentes Lovers are lunatics -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lewisurn at gmail.com Fri Jan 5 00:51:38 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 4 Jan 2018 15:51:38 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <5013b8f1-cdab-691c-5c2c-4abd7fa2d08c@sumptuouscapital.com> References: <12300523.20180104004058@my_localhost_LG> <7db7f27c-bf3e-28dc-32ca-6da8662052c9@gmail.com> <727a9f22-5d06-2034-646a-db55dcf82d6e@sumptuouscapital.com> <5013b8f1-cdab-691c-5c2c-4abd7fa2d08c@sumptuouscapital.com> Message-ID: On 01/04/2018 02:59 PM, Kristian Fiskerstrand wrote: > On 01/04/2018 11:14 PM, Lou Wynn wrote: >> Compared to using two CAs, my design introduces two properties to a >> certificate. One is the certificate type, which is "p" for a partner and >> "e" for an employee. > why not make it compatible with rfc4880 directly? your proposal would > require client handling of e.g notation data? This is exactly the reason for my modernizing web of trust. I cannot find a way to make it compatible with rfc4880 and meet all my goals. I'd love to hear your alternatives if it is possible. For example, I'd like to deprecate how trust is assigned values and used in the rfc. However, I'd love to use existing good mechanisms as many as possible, such as the entire PGP data format. As for changes to PGP, I do require new certificate properties and certificate validations to enforce trust realms and groups. Thanks, Lou From lewisurn at gmail.com Fri Jan 5 01:04:05 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 4 Jan 2018 16:04:05 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> Message-ID: On 01/04/2018 02:57 PM, Kristian Fiskerstrand wrote: > On 01/04/2018 11:24 PM, Lou Wynn wrote: > but you add the requirement that all end users sending email to you > require to validate the auditing key as well (auditing is likely wrong > word, archiving is more likely relevant). for auditing you certainly > want gpg-agent monitoring of assuan channel in separate domain. I don't get the exact meaning of this paragraph. I'll try to explain a little. If the administrator sets up the auditing policy (which implies that the auditing is an option), then the plugins of employees will also use the auditing key to encrypt a message besides receiver's public key. This is a little different from what I said earlier about users' plugins because this is a design decision which has not been finalized: whether to make employees or employees plus partners to use the auditing key. This might become an option too. Thanks, Lou From kristian.fiskerstrand at sumptuouscapital.com Fri Jan 5 01:06:57 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 5 Jan 2018 01:06:57 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> Message-ID: On 01/05/2018 01:04 AM, Lou Wynn wrote: > On 01/04/2018 02:57 PM, Kristian Fiskerstrand wrote: >> On 01/04/2018 11:24 PM, Lou Wynn wrote: >> but you add the requirement that all end users sending email to you >> require to validate the auditing key as well (auditing is likely wrong >> word, archiving is more likely relevant). for auditing you certainly >> want gpg-agent monitoring of assuan channel in separate domain. > I don't get the exact meaning of this paragraph. > > I'll try to explain a little. If the administrator sets up the auditing > policy (which implies that the auditing is an option), then the plugins > of employees will also use the auditing key to encrypt a message besides > receiver's public key. This is a little different from what I said > earlier about users' plugins because this is a design decision which has > not been finalized: whether to make employees or employees plus partners > to use the auditing key. This might become an option too. But in the end it doesn't matter, as the organization anyways has access to the private key material of the employee. So a third party "auditing key" is irrespective of any access goals. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Aut dosce, aut disce, aut discede Either teach, or study, or leave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lewisurn at gmail.com Fri Jan 5 01:12:20 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 4 Jan 2018 16:12:20 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> Message-ID: On 01/04/2018 04:06 PM, Kristian Fiskerstrand wrote: > But in the end it doesn't matter, as the organization anyways has access > to the private key material of the employee. So a third party "auditing > key" is irrespective of any access goals. > I guess that you've missed somewhere I said in my previous posts that the end user chooses his own password to protect his key password, which is meant to prevent others from using his private keys. Thanks, Lou From kristian.fiskerstrand at sumptuouscapital.com Fri Jan 5 01:15:12 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 5 Jan 2018 01:15:12 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> Message-ID: <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> On 01/05/2018 01:12 AM, Lou Wynn wrote: > I guess that you've missed somewhere I said in my previous posts that > the end user chooses his own password to protect his key password, which > is meant to prevent others from using his private keys. At which point I'm wondering about your priorities, if the corporation doesn't have access to the data (without the specific encryption key being included) what is the value? -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "At 18 our convictions are hills from which we look; At 45 they are caves in which we hide." (F. Scott Fitzgerald) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lewisurn at gmail.com Fri Jan 5 01:31:12 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 4 Jan 2018 16:31:12 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <20180104222818.dolhf4py76c7qchl@adversary.org> References: <12300523.20180104004058@my_localhost_LG> <20180104222818.dolhf4py76c7qchl@adversary.org> Message-ID: On 01/04/2018 02:28 PM, Ben McGinnes wrote: > On Wed, Jan 03, 2018 at 05:34:30PM -0800, Lou Wynn wrote: >> The management of users' private key is a little more complicated. I >> use two levels of protection. One level is at the organization. An >> organization actually has a fourth key, which I call the guard key, >> to encrypt the password of user's private key. This guard key is >> also managed by the key management system. In addition, a user can >> choose another her own password to encrypt the key password too. > That just spreads the potential points of human failure and you run > the risk that anyone with access to this guard key would be able to > abuse the position to access an employee's credentials (saying they > don't have access to the private key doesn't hold any weight on a > company intranet where they've probably already got root/admin > access). So it'd be too easy for some unscrupulous sys admin (you > might trust you, but what happens when you leave, do you know your > successor?) has a personal issue with someone in, say, marketing and > stitches them up with a few choice forged and signed emails. > > No, that's a *bad* plan and creates all sorts of horrible legal > problems for the company or at least has the very real potential to do > so. I think that I simplified my original description too much. The two levels of protection works like this. 1. The employee chooses his own password, which is used to encrypt his private key. 2. Then the encrypted key is encrypted with the guard key. When a client plugin passes authentication, the sever decrypts from 2's result and sends it to the client. This key material is still encrypted by the employee's own password. The decryption of 1 happens at the client plugin. My estimates is that there exist different types of organizations. Some want to access employee's key, and some don't. So For the former, they can choose to skip the first level of protection. For the latter, they can require to use it. An organization can only change from using the second protection only to using both, but not the other way around. Thanks, Lou From lewisurn at gmail.com Fri Jan 5 01:42:27 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 4 Jan 2018 16:42:27 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> <20180104222818.dolhf4py76c7qchl@adversary.org> Message-ID: <797890c2-bddf-2f83-dc6b-983cd685e43d@gmail.com> On 01/04/2018 04:31 PM, Lou Wynn wrote: > I think that I simplified my original description too much. The two > levels of protection works like this. > 1. The employee chooses his own password, which is used to encrypt his > private key. > > 2. Then the encrypted key is encrypted with the guard key. > > When a client plugin passes authentication, the sever decrypts from 2's > result and sends it to the client. I'm sorry for missing another step in sending a key to the client. After the server decrypts the encrypted key material with the guard key, it uses the public key of the client plugin to encrypt it and sends it to the client. The client plugin decrypts it first with the plugin key, and then the user's own password is required to decrypt the private key. The guard key and the plugin key here are used to defy the man-in-the-middle in either direction and provide secure channels. Thanks, Lou From lewisurn at gmail.com Fri Jan 5 01:46:16 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 4 Jan 2018 16:46:16 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> Message-ID: <082e09bd-ce6f-6ffa-3652-0f2b83475f20@gmail.com> On 01/04/2018 04:15 PM, Kristian Fiskerstrand wrote: > On 01/05/2018 01:12 AM, Lou Wynn wrote: >> I guess that you've missed somewhere I said in my previous posts that >> the end user chooses his own password to protect his key password, which >> is meant to prevent others from using his private keys. > At which point I'm wondering about your priorities, if the corporation > doesn't have access to the data (without the specific encryption key > being included) what is the value? Sorry, I don't get it. Can you explain your question again? What data, in which scenario? Thanks, Lou From kristian.fiskerstrand at sumptuouscapital.com Fri Jan 5 09:18:50 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 5 Jan 2018 09:18:50 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <082e09bd-ce6f-6ffa-3652-0f2b83475f20@gmail.com> References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> <082e09bd-ce6f-6ffa-3652-0f2b83475f20@gmail.com> Message-ID: On 01/05/2018 01:46 AM, Lou Wynn wrote: > On 01/04/2018 04:15 PM, Kristian Fiskerstrand wrote: >> On 01/05/2018 01:12 AM, Lou Wynn wrote: >>> I guess that you've missed somewhere I said in my previous posts that >>> the end user chooses his own password to protect his key password, which >>> is meant to prevent others from using his private keys. >> At which point I'm wondering about your priorities, if the corporation >> doesn't have access to the data (without the specific encryption key >> being included) what is the value? > Sorry, I don't get it. Can you explain your question again? What data, > in which scenario? > Businesses have reasonable need to access their data, so they need to have access to his private keys, which contradicts "which is meant to prevent others from using his private keys", although reading it again I presume you're limiting the statement to non-authorized personnel in the normal scenario? -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "In politics stupidity is not a handicap." (Napoleon Bonaparte) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lewisurn at gmail.com Fri Jan 5 09:41:57 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Fri, 5 Jan 2018 00:41:57 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> <082e09bd-ce6f-6ffa-3652-0f2b83475f20@gmail.com> Message-ID: <803a96c4-464b-a866-5781-ddf485bc6726@gmail.com> On 01/05/2018 12:18 AM, Kristian Fiskerstrand wrote: > Businesses have reasonable need to access their data, so they need to > have access to his private keys, which contradicts "which > is meant to prevent others from using his private keys", although > reading it again I presume you're limiting the statement to > non-authorized personnel in the normal scenario? This reason is vague and invalid. The purpose of a private key is two-fold: encryption and message authorization. The only need for an organization to access their data is decrypting the encrypted data, which is satisfied by the auditing key. I don't see any valid reason to damage message authorization. I'd suggest you read Ben McGinnes's post. If you still insist that there is value in accessing employees' private key, then I would say that you belong to the type of organizations that *want* to access employee's private keys although doing so causes more damages. I described the two categories of organizations when replying Ben's post. This is another reason that I want to modernize PGP for organizations because when people use PGP in such an environment they tend to make dangerous decisions such as key escrow or encryption gateway to meet organizational management requirements while compromising message authorization. Thanks, Lou From kristian.fiskerstrand at sumptuouscapital.com Fri Jan 5 10:10:15 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 5 Jan 2018 10:10:15 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <803a96c4-464b-a866-5781-ddf485bc6726@gmail.com> References: <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> <082e09bd-ce6f-6ffa-3652-0f2b83475f20@gmail.com> <803a96c4-464b-a866-5781-ddf485bc6726@gmail.com> Message-ID: <54ba6eaa-f5bf-95ba-6d50-00144b6140aa@sumptuouscapital.com> On 01/05/2018 09:41 AM, Lou Wynn wrote: > On 01/05/2018 12:18 AM, Kristian Fiskerstrand wrote: >> Businesses have reasonable need to access their data, so they need to >> have access to his private keys, which contradicts "which >> is meant to prevent others from using his private keys", although >> reading it again I presume you're limiting the statement to >> non-authorized personnel in the normal scenario? > This reason is vague and invalid. The purpose of a private key is > two-fold: encryption and message authorization. The only need for an > organization to access their data is decrypting the encrypted data, > which is satisfied by the auditing key. I don't see any valid reason to > damage message authorization. There are easily scenarios where a customer forgets to add the "auditing key", making the data unavailable to the organization, in particular in context of loss of employee. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Success is getting what you want. Happiness is wanting what you get" (Dale Carnegie) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Fri Jan 5 10:13:52 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 5 Jan 2018 09:13:52 +0000 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <803a96c4-464b-a866-5781-ddf485bc6726@gmail.com> References: <12300523.20180104004058@my_localhost_LG> <63c961e8-1821-19cd-1aaa-2bb0d03f9b08@gmail.com> <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> <082e09bd-ce6f-6ffa-3652-0f2b83475f20@gmail.com> <803a96c4-464b-a866-5781-ddf485bc6726@gmail.com> Message-ID: <526D75B1-577B-476D-8458-6EA9F4AFADB5@andrewg.com> > On 5 Jan 2018, at 08:41, Lou Wynn wrote: > > The only need for an > organization to access their data is decrypting the encrypted data, > which is satisfied by the auditing key. The standard way of doing this without allowing for impersonation is escrow of the encryption subkey only. This can be done by encrypting the E subkey to the auditing key, the private key of which is presumably well controlled. A From kristian.fiskerstrand at sumptuouscapital.com Fri Jan 5 10:16:51 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 5 Jan 2018 10:16:51 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <526D75B1-577B-476D-8458-6EA9F4AFADB5@andrewg.com> References: <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> <082e09bd-ce6f-6ffa-3652-0f2b83475f20@gmail.com> <803a96c4-464b-a866-5781-ddf485bc6726@gmail.com> <526D75B1-577B-476D-8458-6EA9F4AFADB5@andrewg.com> Message-ID: <3cbf69ec-1e03-5257-abd4-c45b9c71456d@sumptuouscapital.com> On 01/05/2018 10:13 AM, Andrew Gallagher wrote: > >> On 5 Jan 2018, at 08:41, Lou Wynn wrote: >> >> The only need for an >> organization to access their data is decrypting the encrypted data, >> which is satisfied by the auditing key. > > The standard way of doing this without allowing for impersonation is escrow of the encryption subkey only. This can be done by encrypting the E subkey to the auditing key, the private key of which is presumably well controlled. The issue with that is that as long as the employee has private key for primary the individual can create new subkeys, and the primary will always have signing capability (if not always specified as usage flag). In most setups the employee won't need/shouldn't have the private key info for the primary for this (and a few other) reasons. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "The journey of a thousand miles begins with one step." (Lao Tzu) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Fri Jan 5 14:59:54 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Fri, 5 Jan 2018 13:59:54 +0000 Subject: How do you find out the Keygrip of a v3 key? Message-ID: <1316753480.20180105135954@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Is it possible to find out the Keygrip of a version 3 key? These old keys are not supported in GnuPG 2.1/2.2 and the - --with-keygrip option is not valid in GnuPG 2.0 or 1.4. I have googled, but could not come up with a search term that produced any relevant hits. - -- Best regards MFPA Was time invented by an Irishman named O'Clock? -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWk+E218UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +tNWAQCWgeBFvYv9dqAvgkeG6GJOnhosGfFoPPTTyRxFhTKKsAD+Lbz6jwTXEMvj aBQ/l+ZexkqtjcjFKn4YUy8qvdju7wOJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWk+E218UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/xPwEACPFcMFJeOe1QwSrtHeeVj0YTa1 9/xrjHeX4XKOFcexZiDjBiJKXg0PSc8eqwPoY7EHvbP9TmSeEeD4g270x3lYthwZ 96G5NAeSrXM6BUsPz/W724uS21YZSzTlh2E/SRg1d1WkJWwzpWXFDF9SG/5Rf7iq ePVyZpcd6F2yYSp9Fi+CN+PNNKD+d4tLYM3sxrnT2lFF6oKiAcUIM2MkaiHKeWDR RsXSnAG5nFdAvxTQvlAyCCbuTRx1q7e6CVYUXILGEnJaNb5gIjH7r+X9zYPH/jZl jjZ5zs92lfWsVPjX+6yUUoC0paZPylxUBQwEZ28auEo5JM6y3DZl0j0cz+JHjOT/ L08Kz1EwEzgmkgh/+kgRv9XrwwTbGjwhmTXYY8zpPhb7qBsVsFF4IDO1OU/0f7mr nb0TCFRY/77Uq1N5msNmsfC9OsLNUH+LVm8oxsT/sDo0DshTegHiW42Yw/8ZxpSw /9J6mT/tVfd1DYhWLCcyXdWQei0exS7u3D6gcz/tY6bluBvMTTw+7XO1KwdHEvCz re6cFQGA3xbsQQQCYexXqEinw4uSv2oheK2ZJm8R7GcvsWGqbQlebWLcyVXFHc0f J6PuF9w2kUVWidlkFWnG8lkZRQSSOUtjnDMN5me2jAYQWU69y+OLfTnaPbDXrY45 XKhSFQ0AW77Zepl+Ug== =Oc0k -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Fri Jan 5 15:37:12 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 5 Jan 2018 15:37:12 +0100 Subject: How do you find out the Keygrip of a v3 key? In-Reply-To: <1316753480.20180105135954@my_localhost_LG> References: <1316753480.20180105135954@my_localhost_LG> Message-ID: On 01/05/2018 02:59 PM, MFPA wrote: > These old keys are not supported in GnuPG 2.1/2.2 and the > - --with-keygrip option is not valid in GnuPG 2.0 or 1.4. > > I have googled, but could not come up with a search term that produced > any relevant hits. I'd start with libgcrypt's gcry_pk_get_keygrip() -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Excellence is not a singular act but a habit. You are what you do repeatedly." (Shaquille O'Neal) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lewisurn at gmail.com Fri Jan 5 17:29:39 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Fri, 5 Jan 2018 08:29:39 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <54ba6eaa-f5bf-95ba-6d50-00144b6140aa@sumptuouscapital.com> References: <1288953570.20180104023723@my_localhost_LG> <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> <082e09bd-ce6f-6ffa-3652-0f2b83475f20@gmail.com> <803a96c4-464b-a866-5781-ddf485bc6726@gmail.com> <54ba6eaa-f5bf-95ba-6d50-00144b6140aa@sumptuouscapital.com> Message-ID: On 01/05/2018 01:10 AM, Kristian Fiskerstrand wrote: > There are easily scenarios where a customer forgets to add the "auditing > key", making the data unavailable to the organization, in particular in > context of loss of employee. > The auditing key is certified by the root key and stays with the latter in my design. Only the administrator can make policy to turn on/off auditing, the client plugin takes corresponding actions automatically. End users don't need to do anything, namely, using or not using the auditing key to encrypt is completely transparent to end users. As a result, there is no such issue of "forgetting to add it." Thanks, Lou From dkg at fifthhorseman.net Fri Jan 5 17:45:25 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Jan 2018 11:45:25 -0500 Subject: Upgrading from gpg1 to gpg2: lots of trouble, need help In-Reply-To: <20171221051859.GB5261@raf.org> References: <20171218090102.GA23081@raf.org> <87lgi0oueq.fsf@fifthhorseman.net> <20171220031126.GB20576@raf.org> <877ethmoyp.fsf@fifthhorseman.net> <20171221051859.GB5261@raf.org> Message-ID: <87efn4b6fu.fsf@fifthhorseman.net> On Thu 2017-12-21 16:19:00 +1100, raf wrote: > Sorry, I thought I already did. The 4th point above does not > work. When the public-facing host connects via ssh to the > key management host, and runs gpg, instead of it successully > connecting to the existing gpg-agent process that I started > minutes earlier, it starts a new gpg-agent process which > doesn't know the passphrase and so the decryption fails. > > Here are the gpg-agent processes after I start the first gpg-agent > process and preset the passphrase: > > /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \ > --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash --login > > Here are the gpg-agent processes after an inoming ssh connection that > attempts to use gpg: > > /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \ > --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash --login > gpg-agent --homedir /etc/thing/.gnupg --use-standard-socket --daemon > > That second gpg-agent process should not exist. The gpg > process that caused it to be started should have connected > to the existing gpg-agent process. The sockets for it > existed but perhaps there was some reason why it didn't use > them. > > There must be some reason why gpg thinks it needs to start > gpg-agent. Perhaps it's because it's a different "user > session". They are from two different ssh connections after > all. this is the part that i'm unable to reproduce. Are both of these processes running as the same user account? does something at some point destroy or mask the standard socket created by the first process, so that a new gpg invocation decides to start up a new instance of gpg-agent? if your old session was being terminated, then you'd expect the first agent to actually disappear. that's not happening. and neither of these agents is beign launched by systemd, because if it were it would have a --supervised . > But when I su to the user in question, I get: > > > systemctl --user is-enabled gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket > Failed to connect to bus: No such file or directory > > But it still reports as enabled with --global. > Maybe that's enough. I don't know. are you su'ing with a login shell (i.e. with - or -l or --login), or not? > I am completely failing to understand what's going on here. :-) > Is systemd handling the sockets or not? There's no /run/user > directory for this user so probably not. Maybe I don't > understand --user and --global or systemd in general. why is there no /run/user for this user? if you're running a modern version of systemd, and your user has actually started a session, there should be a /run/user created automatically. --dkg From lewisurn at gmail.com Fri Jan 5 17:47:29 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Fri, 5 Jan 2018 08:47:29 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <20180104222818.dolhf4py76c7qchl@adversary.org> References: <12300523.20180104004058@my_localhost_LG> <20180104222818.dolhf4py76c7qchl@adversary.org> Message-ID: On 01/04/2018 02:28 PM, Ben McGinnes wrote: > It seems to me, though, that the idea was to provide a means for the > company to repudiate an employee's key even if the employee was no > longer available. This is just one of the benefits enabled by my goals which I stated at the beginning, and it is most related to central management of keys. There are systems that have attempted to solve one or two of them with the cost of sacrificing others. My take is doing them all with the new trust model and its supporting mechanisms. Thanks, Lou From kristian.fiskerstrand at sumptuouscapital.com Fri Jan 5 21:54:18 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 5 Jan 2018 21:54:18 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: References: <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> <082e09bd-ce6f-6ffa-3652-0f2b83475f20@gmail.com> <803a96c4-464b-a866-5781-ddf485bc6726@gmail.com> <54ba6eaa-f5bf-95ba-6d50-00144b6140aa@sumptuouscapital.com> Message-ID: <2175f016-3ca5-af32-07a7-3a87eaaee2e0@sumptuouscapital.com> On 01/05/2018 05:29 PM, Lou Wynn wrote: > On 01/05/2018 01:10 AM, Kristian Fiskerstrand wrote: >> There are easily scenarios where a customer forgets to add the "auditing >> key", making the data unavailable to the organization, in particular in >> context of loss of employee. >> > The auditing key is certified by the root key and stays with the latter > in my design. Only the administrator can make policy to turn on/off > auditing, the client plugin takes corresponding actions automatically. > End users don't need to do anything, namely, using or not using the > auditing key to encrypt is completely transparent to end users. As a > result, there is no such issue of "forgetting to add it." Can you please elaborate on how this would be compatible with existing implementations of RFC4880? -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "A ship is safe in harbour, but that's not what ships are for" (Will Shedd) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lewisurn at gmail.com Sat Jan 6 00:23:57 2018 From: lewisurn at gmail.com (Lou Wynn) Date: Fri, 5 Jan 2018 15:23:57 -0800 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <2175f016-3ca5-af32-07a7-3a87eaaee2e0@sumptuouscapital.com> References: <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> <082e09bd-ce6f-6ffa-3652-0f2b83475f20@gmail.com> <803a96c4-464b-a866-5781-ddf485bc6726@gmail.com> <54ba6eaa-f5bf-95ba-6d50-00144b6140aa@sumptuouscapital.com> <2175f016-3ca5-af32-07a7-3a87eaaee2e0@sumptuouscapital.com> Message-ID: <7680a20f-90a8-9844-8ee6-8bb11f1c3876@gmail.com> On 01/05/2018 12:54 PM, Kristian Fiskerstrand wrote: > On 01/05/2018 05:29 PM, Lou Wynn wrote: >> The auditing key is certified by the root key and stays with the latter >> in my design. Only the administrator can make policy to turn on/off >> auditing, the client plugin takes corresponding actions automatically. >> End users don't need to do anything, namely, using or not using the >> auditing key to encrypt is completely transparent to end users. As a >> result, there is no such issue of "forgetting to add it." > Can you please elaborate on how this would be compatible with existing > implementations of RFC4880? > > If you asked about the auditing key compatibility, then it is probably not the right question because RFC4880 does not talk about it at all. My client plugin takes automatic action to encrypt a message with two keys and sends to one receiver, which I don't think violates the RFC. However, there is a potentially issue related to compatibility for the system as a whole depending on the direction. For example, if you import your current PGP key into my system, then you can still use the key without a problem because as a part of the importing process the server adds a new certificate with necessary properties made by the certifying key. The client plugin of my system will recognize your key as valid once you have this certificate. In the other direction, if you export a key from my system and want to use it in your current PGP client, you can do so because a key in my system is still a valid PGP key. However, you don't have any benefits of my system such as trust realm/group support because your current PGP client does not enforce the autonomous certification authority model. Thanks, Lou From kristian.fiskerstrand at sumptuouscapital.com Sat Jan 6 00:31:09 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sat, 6 Jan 2018 00:31:09 +0100 Subject: Modernizing Web-of-trust for Organizations In-Reply-To: <7680a20f-90a8-9844-8ee6-8bb11f1c3876@gmail.com> References: <15baa97d-b0f2-33ea-9fbb-6f6c0e9158e6@sumptuouscapital.com> <58c71004-2dbe-0a10-fc58-7c2777427a76@gmail.com> <095aa42b-c253-96a8-4606-581bc12b2e71@sumptuouscapital.com> <5d10bc4f-4e28-0972-ebae-93decd0cd2b8@gmail.com> <953ed43d-fc89-b2f0-235e-aee020835706@sumptuouscapital.com> <57ff2ef1-d968-82e8-dd0a-533e7f61b2b0@sumptuouscapital.com> <082e09bd-ce6f-6ffa-3652-0f2b83475f20@gmail.com> <803a96c4-464b-a866-5781-ddf485bc6726@gmail.com> <54ba6eaa-f5bf-95ba-6d50-00144b6140aa@sumptuouscapital.com> <2175f016-3ca5-af32-07a7-3a87eaaee2e0@sumptuouscapital.com> <7680a20f-90a8-9844-8ee6-8bb11f1c3876@gmail.com> Message-ID: <530295ba-a651-a1c0-a250-86ea3f95b9d1@sumptuouscapital.com> On 01/06/2018 12:23 AM, Lou Wynn wrote: > On 01/05/2018 12:54 PM, Kristian Fiskerstrand wrote: >> On 01/05/2018 05:29 PM, Lou Wynn wrote: >>> The auditing key is certified by the root key and stays with the latter >>> in my design. Only the administrator can make policy to turn on/off >>> auditing, the client plugin takes corresponding actions automatically. >>> End users don't need to do anything, namely, using or not using the >>> auditing key to encrypt is completely transparent to end users. As a >>> result, there is no such issue of "forgetting to add it." >> Can you please elaborate on how this would be compatible with existing >> implementations of RFC4880? >> >> > If you asked about the auditing key compatibility, then it is probably > not the right question because RFC4880 does not talk about it at all. My > client plugin takes automatic action to encrypt a message with two keys > and sends to one receiver, which I don't think violates the RFC. The primary issue would be requiring everyone to use your client for the scheme to work. There are ways to handle the issues you propose within the existing ecosystem that won't have this requirement, and as such will be superior. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "We can only see a short distance ahead, but we can see plenty there that needs to be done." (Alan Turing) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sat Jan 6 13:15:07 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 6 Jan 2018 13:15:07 +0100 Subject: Obtaining Key Stubs From Smartcard In-Reply-To: References: <37d31b07-42da-c0cc-d8bc-737a390e02e5@digitalbrains.com> Message-ID: On 04/01/18 17:56, Bagel Alderman wrote: > Please let me know if there's anything else I can check that'd be useful > for diagnosing this. I appreciate your help. You don't show the process, just the end result. I'm thinking more along the line of: gpg2 --with-subkey-fingerprint -K shows the private key is known, primary is offline and subkeys are on a card. The # in sec# indicates the primary is offline, the > in ssb> indicates the subkeys are on card. A mocked up output is like this: --8<---------------cut here---------------start------------->8--- sec# rsa2048 2009-11-12 [C] [expires: 2019-10-13] [fingerprint] uid [ultimate] Itsa me ssb> rsa2048 2009-11-12 [S] [expires: 2019-10-13] [fingerprint] Card serial no. = FFFE 87061340 ssb> rsa2048 2009-11-12 [E] [expires: 2019-10-13] [fingerprint] Card serial no. = FFFE 87061340 --8<---------------cut here---------------end--------------->8--- (It would be nice if the documentation indicates that --with-subkey-fingerprint also lists the card serial no. I had a suspicion it might work and it did.) But, we're discussing how to change to a different smartcard. So let's do that. The primary is already offline, we lose nothing there, and the stubs we're trying to lose. Let's delete the secret key. It would be a good idea to keep a backup of the whole .gnupg dir in any case, but I'm not showing that. gpg2 --delete-secret-keys mario --8<---------------cut here---------------start------------->8--- sec rsa2048/[keyid] 2009-11-12 Itsa me Delete this key from the keyring? (y/N) y This is a secret key! - really delete? (y/N) y --8<---------------cut here---------------end--------------->8--- Check it's gone: gpg2 -K gpg: error reading key: No secret key Stick in the smartcard we want to bind; and lo and behold: gpg2 --card-status --8<---------------cut here---------------start------------->8--- General key info..: sub rsa2048/[keyid] 2009-11-12 Itsa me sec# rsa2048/[keyid] created: 2009-11-12 expires: 2019-10-13 ssb> rsa2048/[keyid] created: 2009-11-12 expires: 2019-10-13 card-no: FFFE 12345678 ssb> rsa2048/[keyid] created: 2009-11-12 expires: 2019-10-13 card-no: FFFE 12345678 --8<---------------cut here---------------end--------------->8--- For good measure, do a: gpg2 --with-subkey-fingerprint -K This is the level of detail I meant. It works for me. Where does it go wrong for you? 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 peter at digitalbrains.com Sat Jan 6 13:32:45 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 6 Jan 2018 13:32:45 +0100 Subject: Obtaining Key Stubs From Smartcard In-Reply-To: References: <37d31b07-42da-c0cc-d8bc-737a390e02e5@digitalbrains.com> Message-ID: <9080e1af-f69e-0ffe-b40a-02785dbd8adf@digitalbrains.com> On 06/01/18 13:15, Peter Lebbing wrote: > It works for me. Where does it go wrong for you? Odd... it's working sometimes, and sometimes it's not. Sometimes, it will not get rid of the stubs on --delete-secret-key, or --delete-key for that matter. A different way of doing it is: gpg-connect-agent > learn --force /bye 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 peter at digitalbrains.com Sat Jan 6 13:43:08 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 6 Jan 2018 13:43:08 +0100 Subject: Obtaining Key Stubs From Smartcard In-Reply-To: <9080e1af-f69e-0ffe-b40a-02785dbd8adf@digitalbrains.com> References: <37d31b07-42da-c0cc-d8bc-737a390e02e5@digitalbrains.com> <9080e1af-f69e-0ffe-b40a-02785dbd8adf@digitalbrains.com> Message-ID: I love talking to myself... On 06/01/18 13:32, Peter Lebbing wrote: > gpg-connect-agent >> learn --force /bye Cute. I should have noticed my "rewrap" went wrong. It's either: gpg-connect-agent > learn --force > /bye or: gpg-connect-agent "learn --force" /bye 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 gnupg at raf.org Sun Jan 7 13:23:16 2018 From: gnupg at raf.org (gnupg at raf.org) Date: Sun, 7 Jan 2018 23:23:16 +1100 Subject: Upgrading from gpg1 to gpg2: lots of trouble, need help In-Reply-To: <87efn4b6fu.fsf@fifthhorseman.net> References: <20171218090102.GA23081@raf.org> <87lgi0oueq.fsf@fifthhorseman.net> <20171220031126.GB20576@raf.org> <877ethmoyp.fsf@fifthhorseman.net> <20171221051859.GB5261@raf.org> <87efn4b6fu.fsf@fifthhorseman.net> Message-ID: <20180107122316.GA7845@raf.org> Daniel Kahn Gillmor wrote: > On Thu 2017-12-21 16:19:00 +1100, raf wrote: > > Sorry, I thought I already did. The 4th point above does not > > work. When the public-facing host connects via ssh to the > > key management host, and runs gpg, instead of it successully > > connecting to the existing gpg-agent process that I started > > minutes earlier, it starts a new gpg-agent process which > > doesn't know the passphrase and so the decryption fails. > > > > Here are the gpg-agent processes after I start the first gpg-agent > > process and preset the passphrase: > > > > /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \ > > --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash --login > > > > Here are the gpg-agent processes after an inoming ssh connection that > > attempts to use gpg: > > > > /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \ > > --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash --login > > gpg-agent --homedir /etc/thing/.gnupg --use-standard-socket --daemon > > > > That second gpg-agent process should not exist. The gpg > > process that caused it to be started should have connected > > to the existing gpg-agent process. The sockets for it > > existed but perhaps there was some reason why it didn't use > > them. > > > > There must be some reason why gpg thinks it needs to start > > gpg-agent. Perhaps it's because it's a different "user > > session". They are from two different ssh connections after > > all. > > this is the part that i'm unable to reproduce. > > Are both of these processes running as the same user account? Yes. They are both owned by the user I am calling "thing". > does something at some point destroy or mask the standard socket created > by the first process, so that a new gpg invocation decides to start up a > new instance of gpg-agent? Nothing that I am aware of. The sockets are still there in the file system. However, as soon as the incoming ssh connection runs gpg which starts its own new gpg-agent, the original screen+sudo+gpg-agent+bash "session" can no longer decrypt the data. It's behaving "as if" the new gpg-agent has taken over the sockets so connections via them no longer access the first gpg-agent that knows the passphrase but rather access the second gpg-agent that doesn't know the passphrase. I'm not saying that that is what is happening, just that such behaviour might look like what I'm seeing. > if your old session was being terminated, then you'd expect the first > agent to actually disappear. that's not happening. > > and neither of these agents is beign launched by systemd, because if it > were it would have a --supervised . > > > But when I su to the user in question, I get: > > > > > systemctl --user is-enabled gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket > > Failed to connect to bus: No such file or directory > > > > But it still reports as enabled with --global. > > Maybe that's enough. I don't know. > > are you su'ing with a login shell (i.e. with - or -l or --login), or > not? I would have used "-" but I was only using su for the purpose of checking the systemctl's gpg-agent enabled status. I just tried it again with "-" and got the same result as above. For the actual decryption, I'm using sudo. From the original post, the command to set things up contains something like: /usr/bin/screen -- \ /usr/bin/sudo -u thing --set-home -- \ /usr/bin/gpg-agent --homedir /etc/thing/.gnupg \ --allow-preset-passphrase \ --default-cache-ttl 3600 \ --max-cache-ttl 3600 \ --daemon $gpg_agent_info -- \ /bin/bash --login So the sudo doesn't have "-i" for a login shell (because gpg-agent is run instead) but bash is run with "--login". > > I am completely failing to understand what's going on here. :-) > > Is systemd handling the sockets or not? There's no /run/user > > directory for this user so probably not. Maybe I don't > > understand --user and --global or systemd in general. > > why is there no /run/user for this user? if you're running a modern > version of systemd, and your user has actually started a session, there > should be a /run/user created automatically. I don't know why. It's systemd 232-25+deb9u1. > --dkg The main thing is that you can't reproduce the behaviour that I'm seeing with the incoming ssh connection running gpg. I take that as a good sign. It means that what I am trying to do should work. When I get back to work, I'll do some tracing and get a better look at what is happening when the incoming ssh connection runs gpg and compare it to gpg when run from the screen session before the incoming ssh connection takes place (while it still works and can decrypt data). Thanks, raf From c-blair at illinois.edu Sat Jan 6 06:27:08 2018 From: c-blair at illinois.edu (Charles E. Blair) Date: Fri, 5 Jan 2018 23:27:08 -0600 Subject: symmetric encryption is not working Message-ID: <20180105232708.2fa84ead@ceblair> I have been using gpg (GnuPG) 2.1.18 on a debian linux for several years. In the last few days, I have noticed that symmetric encryption is not working. The command gpg -c --cipher-algo AES testfile creates testfile.gpg after asking for a passphrase. However, the command gpg testfile.gpg yields the message > gpg: WARNING: no command supplied. Trying to guess what you mean ... > gpg: AES encrypted data > gpg: encrypted with 1 passphrase and creates a plaintext file without asking for a passphrase. -- My e-mail service is unreliable. Please try again if no reply in a few days. gpg: F7C9 B577 1E5D C732 63F1 A9D2 A399 D202 50E8 50D1 From michael at wadadli.me Sat Jan 6 07:39:42 2018 From: michael at wadadli.me (Michael Singh) Date: Fri, 5 Jan 2018 22:39:42 -0800 Subject: Import keys from .gnupg folder Message-ID: Hi all, I was a bit ignorant to the nuances of importing/exporting GPG keys, and as a result I simply copied the.gnupg folder from my home directory and wiped my hard drive. Is it possible to import these keys on another installation from this folder? The public key is on a public key-server, and I have the private keys in the folder. The version of GPG on RHEL7.4 is 2.0.22, while Arch happens to be on 2.2.4-1. Would this be problematic? -- Michael Singh M: 914-266-0601 W: www.wadadli.me F: 5E0E FD46 4592 1682 A4B6 5F62 761E 4940 A177 3B38 Sent via Migadu.com, world's easiest email hosting From peter at digitalbrains.com Sun Jan 7 14:57:26 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 7 Jan 2018 14:57:26 +0100 Subject: symmetric encryption is not working In-Reply-To: <20180105232708.2fa84ead@ceblair> References: <20180105232708.2fa84ead@ceblair> Message-ID: <9fcbf82b-7712-4080-ebd6-4299e6ddeb79@digitalbrains.com> On 06/01/18 06:27, Charles E. Blair wrote: > and creates a plaintext file without asking for > a passphrase. Your gpg-agent is probably caching the passphrase. You can evict the cache with: gpgconf --reload gpg-agent After that, it will prompt you for the passphrase again. 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 peter at digitalbrains.com Sun Jan 7 15:01:31 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 7 Jan 2018 15:01:31 +0100 Subject: Import keys from .gnupg folder In-Reply-To: References: Message-ID: On 06/01/18 07:39, Michael Singh wrote: > Is it possible to import these keys on another > installation from this folder? Yes, that is possible. However, you could also just copy the directory in your new home directory. Upgrading from 2.0 to 2.2 will do the right thing. If you already have a .gnupg dir there, but you didn't do anything worthwhile with GnuPG yet, you can just move that to a backup location, and throw away the backup once you're confident everything works. However, it is good practice to remove the file "random_seed". This file should be specific to a single location and not shared. 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 tlikonen at iki.fi Sun Jan 7 15:11:15 2018 From: tlikonen at iki.fi (Teemu Likonen) Date: Sun, 07 Jan 2018 16:11:15 +0200 Subject: Import keys from .gnupg folder In-Reply-To: (Michael Singh's message of "Fri, 5 Jan 2018 22:39:42 -0800") References: Message-ID: <87tvvxzrlo.fsf@iki.fi> Michael Singh [2018-01-05 22:39:42-08] wrote: > I was a bit ignorant to the nuances of importing/exporting GPG keys, and > as a result I simply copied the.gnupg folder from my home directory and > wiped my hard drive. Is it possible to import these keys on another > installation from this folder? The public key is on a public key-server, > and I have the private keys in the folder. > > The version of GPG on RHEL7.4 is 2.0.22, while Arch happens to be on > 2.2.4-1. Would this be problematic? Gpg 2.0 uses secring.gpg file for its secret keyring. Gpg 2.1 uses private-keys-v1.d directory for secret keyring but 2.1 automatically converts the old secring.gpg to the new format. -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Sun Jan 7 15:12:08 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sun, 7 Jan 2018 14:12:08 +0000 Subject: How do you find out the Keygrip of a v3 key? In-Reply-To: References: <1316753480.20180105135954@my_localhost_LG> Message-ID: <618851286.20180107141208@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday 5 January 2018 at 2:37:12 PM, in , Kristian Fiskerstrand wrote:- > I'd start with libgcrypt's gcry_pk_get_keygrip() Thanks. Any pointers how I could invoke that from Windows? - -- Best regards MFPA An obstinate man does not hold opinions. They hold him. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWlIquV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +qcfAP9d+uOqsdihf1PFQfi2HAZ35/LJjC7TcfbeNd3GJPjbegD/cjqYYLg9fqmC 5nSGkekIXtsFT7Lmialc7zYMptkIPgWJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWlIquV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/zneD/9E47CnKIaUAUOGsoVJ0/UOhlj8 MzkEZUTOCnxb7zdcnYpkAHAZYc1u6YV/fcv1HJ984lsD29yBdpJsRFhHL4QbqOIF W8tVEprkgJ0YBMhQqOkjOBEgkhwZHGU/OR0Uok8Ivk7Eco6NC7Gvs3rjV6IkTBX1 loxQ17nB/UatGN2sn9EGkvN3vy6FunZIpRfYXrToQA8/EQYqnXbN1LFLNn/oyR4l DrFJz1mJOifmlJKM2lUEVZCWPkmT3MxKH3JXazY6nJ0sKP3CSquCdIu3wIyKSy5H LOTwl9pCEdne5TjzQsBDKpinFzMv3VDJe+9Tlt4P1y4US4JIEJF9X5uY2dAF1ZuR QAm6x/gYkijU5rp2mJrEvXVzzN+jfM5l/Q75mUtx7walsMT6j1/EZAFevxMGXe/1 7ob0zQQdafvIXEqIkdQs1GRHdGUHNegZNuSoHLwM/9t1grVKtoGdOM4XuHgtRP1/ BAVvCBsUW4AdVgEFfsTKZmSqPmmAGYiNs//KZ1jtZzGbDvOcAGR8VIY4HG0d5SLw 4NZjfPV+ZpBOrfW3xFFucaGZRRUPDOrgO5ONqWKbcyL+d9aD6H8e7S6VregD5EtT 7yy1ScRw/A5IgR1FowoMaiiT7w0xyjYLQFMkMH9qGPVr2zkWcGQKuX1Ft1W3Pxhg oIkXoF1WmBLhY71eCg== =za7N -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sun Jan 7 17:39:39 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 7 Jan 2018 10:39:39 -0600 Subject: Import keys from .gnupg folder In-Reply-To: References: Message-ID: <908b6358-25f8-5753-76a8-eee99fca4087@sixdemonbag.org> > Yes, that is possible. However, you could also just copy the directory > in your new home directory. Upgrading from 2.0 to 2.2 will do the right > thing. Obligatory drum beating: I wrote a tool, Sherpa, to help ease migration between different GnuPG versions. https://rjhansen.github.io/sherpa/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From philip.jackson at nordnet.fr Sun Jan 7 17:10:25 2018 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Sun, 7 Jan 2018 17:10:25 +0100 Subject: symmetric encryption is not working In-Reply-To: <20180105232708.2fa84ead@ceblair> References: <20180105232708.2fa84ead@ceblair> Message-ID: <5d1cce35-f999-1e4a-c566-26008fe0b268@nordnet.fr> On 06/01/18 06:27, Charles E. Blair wrote: > However, the command > > gpg testfile.gpg yields the message > >> gpg: WARNING: no command supplied. Trying to guess what you mean ... >> gpg: AES encrypted data >> gpg: encrypted with 1 passphrase > and creates a plaintext file without asking for > a passphrase. It would seem that the command '-d' is missing. gpg -d testfile.gpg works for me. And requests the password before decrypting. Philip From bernhard at intevation.de Mon Jan 8 11:35:33 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 8 Jan 2018 11:35:33 +0100 Subject: Tool: Sherpa: (Re: Import keys from .gnupg folder) In-Reply-To: <908b6358-25f8-5753-76a8-eee99fca4087@sixdemonbag.org> References: <908b6358-25f8-5753-76a8-eee99fca4087@sixdemonbag.org> Message-ID: <201801081135.37548.bernhard@intevation.de> Am Sonntag 07 Januar 2018 17:39:39 schrieb Robert J. Hansen: > Obligatory drum beating: I wrote a tool, Sherpa, to help ease migration > between different GnuPG versions. > > https://rjhansen.github.io/sherpa/ Mentioned in the wiki now, at https://wiki.gnupg.org/Tools Would be interesting to know what the experiences of other people are (and why sherpa is not considered ready for regular users yet.) (Adding info to the wiki is always appreciated, we are a community with a lot of people and spread out knowledge.) Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Mon Jan 8 16:11:24 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 8 Jan 2018 10:11:24 -0500 Subject: Tool: Sherpa: (Re: Import keys from .gnupg folder) In-Reply-To: <201801081135.37548.bernhard@intevation.de> References: <908b6358-25f8-5753-76a8-eee99fca4087@sixdemonbag.org> <201801081135.37548.bernhard@intevation.de> Message-ID: <153ea044-ff74-be8f-aff5-f7051f87eb4b@sixdemonbag.org> > Would be interesting to know what the experiences of other people are > (and why sherpa is not considered ready for regular users yet.) Inadequate testing. It's in a "it works for the core dev and two other people" stage, which to me screams not ready for the real world. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon Jan 8 17:38:33 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 08 Jan 2018 11:38:33 -0500 Subject: Tool: Sherpa: (Re: Import keys from .gnupg folder) In-Reply-To: <201801081135.37548.bernhard@intevation.de> References: <908b6358-25f8-5753-76a8-eee99fca4087@sixdemonbag.org> <201801081135.37548.bernhard@intevation.de> Message-ID: <87efn08fw6.fsf@fifthhorseman.net> On Mon 2018-01-08 11:35:33 +0100, Bernhard Reiter wrote: > Am Sonntag 07 Januar 2018 17:39:39 schrieb Robert J. Hansen: >> Obligatory drum beating: I wrote a tool, Sherpa, to help ease migration >> between different GnuPG versions. >> >> https://rjhansen.github.io/sherpa/ > > Mentioned in the wiki now, at > https://wiki.gnupg.org/Tools > > Would be interesting to know what the experiences of other people are > (and why sherpa is not considered ready for regular users yet.) note that there are two things that could/should be migrated when moving to 2.1.x or later (the "modern" development branch of GnuPG): * secret keys (from secring.gpg to private-keys-v1.d/*.key --should happen automatically) * public keys (from pubring.gpg to pubring.kbx) public key migration currently does not happen automatically because the "modern" branch can use both pubring.gpg and pubring.kbx, and there is an (i believe misguided) desire to facilitate co-installation of the "classic" branch with the "modern" branch. debian's GnuPG packaging supplies /usr/bin/migrate-pubring-from-classic-gpg which should handle the full migration in a safe way and leave the user without any legacy pubring.gpg. Regards, --dkg From bernhard at intevation.de Tue Jan 9 08:36:25 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Jan 2018 08:36:25 +0100 Subject: Tool: Sherpa: (Re: Import keys from .gnupg folder) In-Reply-To: <87efn08fw6.fsf@fifthhorseman.net> References: <201801081135.37548.bernhard@intevation.de> <87efn08fw6.fsf@fifthhorseman.net> Message-ID: <201801090836.25346.bernhard@intevation.de> Am Montag 08 Januar 2018 17:38:33 schrieb Daniel Kahn Gillmor: > debian's GnuPG packaging supplies > /usr/bin/migrate-pubring-from-classic-gpg which should handle the full > migration in a safe way and leave the user without any legacy > pubring.gpg. Feel free to add it to the wiki.gnupg.org. :) (Where is the source code for the tool if I would want to use it outside of the Debian package?) Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bagel.alderman at protonmail.com Tue Jan 9 17:14:13 2018 From: bagel.alderman at protonmail.com (Bagel Alderman) Date: Tue, 09 Jan 2018 11:14:13 -0500 Subject: Obtaining Key Stubs From Smartcard - Solved Message-ID: I stumbled across my answer. I didn't realize the public key was necessary for the private key stubs to appear with "gpg2 -K" and become usable. It turns out my system *was* registering the stubs under ~/.gnupg/private-keys-v1.d/, probably the whole time. All I needed to do was to import my public key to make the stubs from either of my smart cards useful. Thanks again for all your help, I know it often isn't easy working with someone as new to a technology as I am to GnuPG. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Jan 9 18:14:38 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 09 Jan 2018 12:14:38 -0500 Subject: Tool: Sherpa: (Re: Import keys from .gnupg folder) In-Reply-To: <201801090836.25346.bernhard@intevation.de> References: <201801081135.37548.bernhard@intevation.de> <87efn08fw6.fsf@fifthhorseman.net> <201801090836.25346.bernhard@intevation.de> Message-ID: <87mv1n54zl.fsf@fifthhorseman.net> On Tue 2018-01-09 08:36:25 +0100, Bernhard Reiter wrote: > Am Montag 08 Januar 2018 17:38:33 schrieb Daniel Kahn Gillmor: >> debian's GnuPG packaging supplies >> /usr/bin/migrate-pubring-from-classic-gpg which should handle the full >> migration in a safe way and leave the user without any legacy >> pubring.gpg. > > Feel free to add it to the wiki.gnupg.org. :) > (Where is the source code for the tool if I would want to use it outside of > the Debian package?) it's a shell script -- the tool is the source :) at the moment, you can find it at https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git/tree/debian/migrate-pubring-from-classic-gpg though that's likely to migrate to salsa.debian.org soon, as alioth (the machine that hosts anonscm.debian.org) is going away this year. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From nbsd4ever at gmail.com Wed Jan 10 10:25:06 2018 From: nbsd4ever at gmail.com (Henry) Date: Wed, 10 Jan 2018 18:25:06 +0900 Subject: is there a preferred order to building dependencies for gnupg2 Message-ID: There are five libraries required to build gnupg2: libgpg-error, libgcrypt, libassuan, libksba and npth. Is there a preferred order in which they should be built? TIA Henry From nbsd4ever at gmail.com Wed Jan 10 10:17:41 2018 From: nbsd4ever at gmail.com (Henry) Date: Wed, 10 Jan 2018 18:17:41 +0900 Subject: libgcrypt-1.8.2: glitch in configure ?? Message-ID: Trying to build libgcrypt from source, but it failed with: " In file included from t-lock.c:31:0: /usr/local/include/pthread.h:285:42: error: conflicting types for ?pthread_t? typedef struct pthread_st *pthread_t; ^ In file included from /usr/include/sys/types.h:360:0, from /usr/include/stdlib.h:41, from t-lock.c:25: /usr/include/pthread_types.h:65:30: note: previous declaration of ?pthread_t? s here typedef struct __pthread_st *pthread_t; " In case it's important, uname -srp ==>> NetBSD 7.0.2 i386 There are two pthread.h files on this machine: /usr/include/pthread.h and /usr/local/include/pthread.h Somehow the system headers and local headers seem to be getting mixed. I don't know how to correctly fix the problem, but by editing line 31 of tests/t-lock.c and filling in the full path "/usr/include/pthread.h", the build completed. I don't know if it is related to the above problem or not, but "make check" halted at "PASS: curves". After an hour, I stopped it with ^C: gmake[2]: *** [Makefile:864: check-TESTS] Interrupt gmake[1]: *** [Makefile:987: check-am] Interrupt gmake: *** [Makefile:477: check-recursive] Interrupt Regards, Henry From dgouttegattat at incenp.org Wed Jan 10 12:39:54 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 10 Jan 2018 11:39:54 +0000 Subject: is there a preferred order to building dependencies for gnupg2 In-Reply-To: References: Message-ID: <79de399d-875f-8d74-d169-310d84edea5a@incenp.org> On 01/10/2018 09:25 AM, Henry wrote: > There are five libraries required to build gnupg2: libgpg-error, > libgcrypt, libassuan, libksba and npth. > > Is there a preferred order in which they should be built? Libgpg-error should be built first as it is required by all other libraries except npth. Apart from that, there is no dependencies between the other libraries and they can be built in any order. For example, when I compile GnuPG for Slackware, I do this (on a fresh VM with a "vanilla" Slackware): 1) Build libgpg-error and npth (in any order). 2) Install libgpg-error. 3) Build libgcrypt, libassuan, and libksba (in any order). 4) Install npth, libgcrypt, libassuan, and libksba. 5) Build gnupg. (This should be suitable for any GNU/Linux system beyond Slackware. However, I don't know about building GnuPG on/for other systems.) Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Rajireddy.Saddi.osv at genco.com Wed Jan 10 14:51:24 2018 From: Rajireddy.Saddi.osv at genco.com (Rajireddy Saddi (OSV)) Date: Wed, 10 Jan 2018 13:51:24 +0000 Subject: skipped: Unusable public key error Message-ID: <4686398BFECAB0428133AD04DBF639524685AB@resexmbx2.gencoatc.prv> Hi, I am using GPG 2.2.3 I have imported key successfully and did edit and trust I used below command for encryption but I am getting below error skipped: Unusable public key error gpg --pinentry-mode loopback --sign --encrypt --armor -u xxxxx -o E:\New\test.txt.gpg -r xxxxx --passphrase mypasspharse E:\New\test.txt Please let me the reason for error, please could you help on this, it is urgent for me. Thanks, Raji CONFIDENTIALITY NOTICE: This e-mail and the attachment(s) hereto (if any) contain confidential information that is privileged and intended only for the addressee(s) hereof. If you are not an intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or the accompanying attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by return e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg-users at spodhuis.org Thu Jan 11 01:40:48 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Wed, 10 Jan 2018 19:40:48 -0500 Subject: is there a preferred order to building dependencies for gnupg2 In-Reply-To: <79de399d-875f-8d74-d169-310d84edea5a@incenp.org> References: <79de399d-875f-8d74-d169-310d84edea5a@incenp.org> Message-ID: <20180111004048.GA92972@tower.spodhuis.org> On 2018-01-10 at 11:39 +0000, Damien Goutte-Gattat wrote: > On 01/10/2018 09:25 AM, Henry wrote: > > There are five libraries required to build gnupg2: libgpg-error, > > libgcrypt, libassuan, libksba and npth. > > > > Is there a preferred order in which they should be built? > > Libgpg-error should be built first as it is required by all other libraries > except npth. > > Apart from that, there is no dependencies between the other libraries and > they can be built in any order. For myself: I keep a file with "A before B" rules, one per line, and the start of my build uses tsort(1) to get a final ordering. My GnuPG package sets includes gnutls, and thus nettle, which adds a little complexity. % tsort < confs/dependencies.tsort-in | xargs libgpg-error npth gmp libassuan libksba libgcrypt nettle pinentry gnutls gnupg22 -------------------8< confs/dependencies.tsort-in >8-------------------- gnupg22 gnupg22 gmp nettle nettle gnutls gnutls gnupg22 npth gnupg22 libgpg-error libgcrypt libgpg-error libksba libgpg-error libassuan libgpg-error pinentry libgpg-error gnupg22 libgcrypt gnupg22 libksba gnupg22 libassuan pinentry libassuan gnupg22 pinentry gnupg22 -------------------8< confs/dependencies.tsort-in >8-------------------- From allan at archlinux.org Thu Jan 11 07:19:10 2018 From: allan at archlinux.org (Allan McRae) Date: Thu, 11 Jan 2018 16:19:10 +1000 Subject: Extract signature key ID with gpgme Message-ID: Hi, I am looking for a way to extract the issuer key ID from a signature file using gpgme without firstly having verified the signature. Basically, doing something like what gpg --list-packets does. My software current has a homemade sig file parser that extracts the key ID from a number of signature files, then it confirms all needed keys are in the keyring before going onto verify the files. I'd like to replace the homemade parser with something more robust. Thanks, Allan From wk at gnupg.org Thu Jan 11 09:17:38 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Jan 2018 09:17:38 +0100 Subject: is there a preferred order to building dependencies for gnupg2 In-Reply-To: <79de399d-875f-8d74-d169-310d84edea5a@incenp.org> (Damien Goutte-Gattat's message of "Wed, 10 Jan 2018 11:39:54 +0000") References: <79de399d-875f-8d74-d169-310d84edea5a@incenp.org> Message-ID: <87po6gizbx.fsf@wheatstone.g10code.de> On Wed, 10 Jan 2018 12:39, dgouttegattat at incenp.org said: > Libgpg-error should be built first as it is required by all other > libraries except npth. Right. I have a standard build order, though. This is codified in the speedo build script make -f $GNUPGSRC/build-aux/speedo.mk Would it be useful to add a target to list the suggested build order and maybe another one to include suggested configure options? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Jan 11 14:26:04 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 11 Jan 2018 08:26:04 -0500 Subject: Upgrading from gpg1 to gpg2: lots of trouble, need help In-Reply-To: <20180107122316.GA7845@raf.org> References: <20171218090102.GA23081@raf.org> <87lgi0oueq.fsf@fifthhorseman.net> <20171220031126.GB20576@raf.org> <877ethmoyp.fsf@fifthhorseman.net> <20171221051859.GB5261@raf.org> <87efn4b6fu.fsf@fifthhorseman.net> <20180107122316.GA7845@raf.org> Message-ID: <87shbc1q8j.fsf@fifthhorseman.net> On Sun 2018-01-07 23:23:16 +1100, gnupg at raf.org wrote: > For the actual decryption, I'm using sudo. From the original > post, the command to set things up contains something like: > > /usr/bin/screen -- \ > /usr/bin/sudo -u thing --set-home -- \ > /usr/bin/gpg-agent --homedir /etc/thing/.gnupg \ > --allow-preset-passphrase \ > --default-cache-ttl 3600 \ > --max-cache-ttl 3600 \ > --daemon $gpg_agent_info -- \ > /bin/bash --login this is deliberately launching a second agent, outside of the basic supervision that should already be in place. If you want to use the standard system agent, please do not launch a separate agent. This should be as simple as: screen -- sudo -u thing --login or, if you're doing this as root already, then you don't need sudo at all, and it could just be: screen -- su - testuser If this is run from cron, it will spawn a new session, and that session will have a systemd session manager capable of spawning gpg-agent as needed. unfortunately, it will not spawn a new session if run from an existing session, see the discussion at https://github.com/systemd/systemd/issues/7451 . if you want to manually start a new session for a new user from within an existing session on a machine managed by systemd, apparently machinectl may be the way to go, but i haven't explored that in full. hope this helps, --dkg From dkg at fifthhorseman.net Thu Jan 11 14:48:19 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 11 Jan 2018 08:48:19 -0500 Subject: Extract signature key ID with gpgme In-Reply-To: References: Message-ID: <87h8rs1p7g.fsf@fifthhorseman.net> On Thu 2018-01-11 16:19:10 +1000, Allan McRae wrote: > I am looking for a way to extract the issuer key ID from a signature > file using gpgme without firstly having verified the signature. > Basically, doing something like what gpg --list-packets does. > > My software current has a homemade sig file parser that extracts the key > ID from a number of signature files, then it confirms all needed keys > are in the keyring before going onto verify the files. I'd like to > replace the homemade parser with something more robust. I don't see a way to do this with gpgme besides first trying to verify the signature, parsing the results, and using the info from those parsed results. But i can see why you'd want to do this, particularly if the thing signed is large and potentially expensive to verify. anyway, i've opened an issue to track this feature request: https://dev.gnupg.org/T3734 regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Thu Jan 11 20:51:03 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Jan 2018 20:51:03 +0100 Subject: Extract signature key ID with gpgme In-Reply-To: (Allan McRae's message of "Thu, 11 Jan 2018 16:19:10 +1000") References: Message-ID: <87y3l4fa3c.fsf@wheatstone.g10code.de> On Thu, 11 Jan 2018 07:19, allan at archlinux.org said: > I am looking for a way to extract the issuer key ID from a signature > file using gpgme without firstly having verified the signature. There is no API for this and I am not sure how to do this best. The straightforward method would be to let gpgme run something gpg --dry-run --verify but that might even need changes to gpg. In case you want to do that for a lot of files it might be to slow without changing gpg to be used as a co-process. A dedicated API for and a simple parser in GPGME might really be better. Note that we already have a limited OpenPGP parser in gpgme to implement gpgme_data_identify. > My software current has a homemade sig file parser that extracts the key > ID from a number of signature files, then it confirms all needed keys > are in the keyring before going onto verify the files. I'd like to What is your assumptions on the number of files to test in one go? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nbsd4ever at gmail.com Sat Jan 13 10:18:01 2018 From: nbsd4ever at gmail.com (Henry) Date: Sat, 13 Jan 2018 18:18:01 +0900 Subject: BUG report gnupg-2.2.4 (or npth) Message-ID: I can't build gnupg-2.2.4 because npth.h includes headers with conflicting types. % uname -srp ==>> NetBSD 7.0.2 i386 % ./configure --enable-g13 --enable-symcryptrun --enable-wks-tools \ --enable-selinux-support --with-npth-prefix=/usr/local \ --with-readline=/usr/local Output before "gmake[3]: *** [Makefile:2050: libcommonpth_a-sysutils.o] Error 1": In file included from /usr/local/include/npth.h:52:0, from sysutils.c:72: /usr/local/include/pthread.h:357:18: error: conflicting types for ?pthread_kill extern int pthread_kill(pthread_t, int); ^ In file included from /usr/local/include/npth.h:50:0, from sysutils.c:72: /usr/include/signal.h:69:5: note: previous declaration of ?pthread_kill? was he int pthread_kill(pthread_t, int); ^ I can build gnupg-2.2.4 if I don't use npth, but then the tests (gmake check) fail. Regards, Henry From mail at maciej.szmigiero.name Sun Jan 14 01:01:01 2018 From: mail at maciej.szmigiero.name (Maciej S. Szmigiero) Date: Sun, 14 Jan 2018 01:01:01 +0100 Subject: SCM SPR332 PIN entry doesn't work Message-ID: Hi all, I've just received a SCM SPR332 from FLOSS-Shop (marked as "SPR332 V2" on its bottom side) and while its basic reader functionality seems to work just fine I can't get the secure PIN entry mode to work at all. I've tried two different OpenPGP cards, tried both GnuPG built-in CCID driver and the pcsc-lite one to no avail. I've even tried the latest vendor Windows driver (with OpenSC and a constant length PIN verify operation), but the behavior in each of these setups was always the same: Upon typing and accepting a PIN the "key" LED on the reader continues to blink for a few seconds, then the reader responds with "64 00" result at the USB interface level (which is probably the code for "SPE [Secure PIN Entry] operation timed out" error) and then it doesn't want to communicate with the card anymore. A relevant log snippet from GnuPG built-in CCID driver: DBG: prompting for pinpad entry '||Please unlock the card%0A%0A Number: 0005 00005B0E%0AHolder: ' DBG: ccid-driver: sending escape sequence to switch to a case 1 APDU DBG: ccid-driver: PC_to_RDR_Escape: DBG: ccid-driver: dwLength ..........: 3 DBG: ccid-driver: bSlot .............: 0 DBG: ccid-driver: bSeq ..............: 56 DBG: ccid-driver: [0007] 00 00 00 80 02 00 DBG: ccid-driver: RDR_to_PC_Escape: DBG: ccid-driver: dwLength ..........: 0 DBG: ccid-driver: bSlot .............: 0 DBG: ccid-driver: bSeq ..............: 56 DBG: ccid-driver: bStatus ...........: 0 DBG: ccid-driver: buffer[9] .........: 00 DBG: ccid-driver: PC_to_RDR_Secure: DBG: ccid-driver: dwLength ..........: 19 DBG: ccid-driver: bSlot .............: 0 DBG: ccid-driver: bSeq ..............: 57 DBG: ccid-driver: bBMI ..............: 0x00 DBG: ccid-driver: wLevelParameter ...: 0x0000 DBG: ccid-driver: [0010] 00 00 82 00 00 19 DBG: ccid-driver: [0016] 06 02 01 09 04 00 00 00 00 00 20 00 82 DBG: ccid-driver: RDR_to_PC_DataBlock: DBG: ccid-driver: dwLength ..........: 2 DBG: ccid-driver: bSlot .............: 0 DBG: ccid-driver: bSeq ..............: 57 DBG: ccid-driver: bStatus ...........: 0 DBG: ccid-driver: [0010] 64 00 DBG: dismiss pinpad entry prompt verify CHV2 failed: Operation cancelled app_check_pin failed: Operation cancelled DBG: ccid-driver: PC_to_RDR_XfrBlock: DBG: ccid-driver: dwLength ..........: 9 DBG: ccid-driver: bSlot .............: 0 DBG: ccid-driver: bSeq ..............: 58 DBG: ccid-driver: bBWI ..............: 0x04 DBG: ccid-driver: wLevelParameter ...: 0x0000 DBG: ccid-driver: [0010] 00 00 05 00 CA 00 DBG: ccid-driver: [0016] 6E 00 A1 DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT ccid_transceive failed: (0x1000a) apdu_send_simple(0) failed: card I/O error DBG: ccid-driver: PC_to_RDR_XfrBlock: DBG: ccid-driver: dwLength ..........: 9 DBG: ccid-driver: bSlot .............: 0 DBG: ccid-driver: bSeq ..............: 59 DBG: ccid-driver: bBWI ..............: 0x04 DBG: ccid-driver: wLevelParameter ...: 0x0000 DBG: ccid-driver: [0010] 00 00 05 00 CA 00 DBG: ccid-driver: [0016] C5 00 0A DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT ccid_transceive failed: (0x1000a) apdu_send_simple(0) failed: card I/O error I've tried also an EMV card with this reader, the behavior is slightly different in this case: the typed PIN is accepted immediately, but "00 82 00 82" T=1 protocol error is returned at the USB interface level. And the card communication still works after this. The same cards (two OpenPGP ones and one EMV) accept PIN input without problems using exactly the same software setup when driven by a different PIN pad reader (a HP smart card keyboard). What's interesting is that the reader reports firmware version 7.0 while all the references I could find talk about firmware version 6.01. The vendor Windows driver also has a firmware version check utility that explicitly checks for firmware version 6.01 (unfortunately, it is just a checking tool without up- or down-grade capability). Now, I wonder: did anybody earlier spotted a similar behavior with this or other SCM/Identiv readers? Or is it possible that this reader is loaded with some non-standard firmware? It reports as "SPRx32 USB Smart Card Reader", which suggests the firmware should be common with a well-tested SPR532 model. Thanks, Maciej From allan at archlinux.org Sun Jan 14 02:24:43 2018 From: allan at archlinux.org (Allan McRae) Date: Sun, 14 Jan 2018 11:24:43 +1000 Subject: Extract signature key ID with gpgme In-Reply-To: <87y3l4fa3c.fsf@wheatstone.g10code.de> References: <87y3l4fa3c.fsf@wheatstone.g10code.de> Message-ID: On 12/01/18 05:51, Werner Koch wrote: > On Thu, 11 Jan 2018 07:19, allan at archlinux.org said: > >> I am looking for a way to extract the issuer key ID from a signature >> file using gpgme without firstly having verified the signature. > > There is no API for this and I am not sure how to do this best. The > straightforward method would be to let gpgme run something gpg --dry-run > --verify but that might even need changes to gpg. > > In case you want to do that for a lot of files it might be to slow > without changing gpg to be used as a co-process. A dedicated API for > and a simple parser in GPGME might really be better. Note that we > already have a limited OpenPGP parser in gpgme to implement > gpgme_data_identify. I had a look at src/data_identify.c. The current parser already detects a signature subpacket, so it would "just" need to extract the issuer key ID from that packet, which is fairly straight forward. There would also be some refactoring needed to the parser to allow it to be used more generally than it is currently able. If someone tells me what the preferred API would look like, I can make a start on implementing this. >> My software current has a homemade sig file parser that extracts the key >> ID from a number of signature files, then it confirms all needed keys >> are in the keyring before going onto verify the files. I'd like to > > What is your assumptions on the number of files to test in one go? This is the "pacman" package manager, so usual would be anywhere from one to hundreds of files needing verified. The way Arch Linux is set up to use it, every packager uses their own signing key which are signed by 3+ fully trusted distribution master keys. So it is useful to verify all signing keys are present in the keyring before processing the verification. Thanks, Allan From gniibe at fsij.org Mon Jan 15 02:47:57 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 15 Jan 2018 10:47:57 +0900 Subject: BUG report gnupg-2.2.4 (or npth) In-Reply-To: References: Message-ID: <87y3kzki42.fsf@iwagami.gniibe.org> Hello, I think that you have some different Pthread library in /usr/local. Henry wrote: > /usr/local/include/pthread.h:357:18: error: conflicting types for ^^^^^^^^^^^ I wonder if you have installed GNU Pth. Please try without Pth. -- From gnupg at raf.org Mon Jan 15 03:09:24 2018 From: gnupg at raf.org (gnupg at raf.org) Date: Mon, 15 Jan 2018 13:09:24 +1100 Subject: Upgrading from gpg1 to gpg2: lots of trouble, need help In-Reply-To: <87shbc1q8j.fsf@fifthhorseman.net> References: <20171218090102.GA23081@raf.org> <87lgi0oueq.fsf@fifthhorseman.net> <20171220031126.GB20576@raf.org> <877ethmoyp.fsf@fifthhorseman.net> <20171221051859.GB5261@raf.org> <87efn4b6fu.fsf@fifthhorseman.net> <20180107122316.GA7845@raf.org> <87shbc1q8j.fsf@fifthhorseman.net> Message-ID: <20180115020924.GA14338@raf.org> Daniel Kahn Gillmor wrote: > On Sun 2018-01-07 23:23:16 +1100, gnupg at raf.org wrote: > > For the actual decryption, I'm using sudo. From the original > > post, the command to set things up contains something like: > > > > /usr/bin/screen -- \ > > /usr/bin/sudo -u thing --set-home -- \ > > /usr/bin/gpg-agent --homedir /etc/thing/.gnupg \ > > --allow-preset-passphrase \ > > --default-cache-ttl 3600 \ > > --max-cache-ttl 3600 \ > > --daemon $gpg_agent_info -- \ > > /bin/bash --login > > this is deliberately launching a second agent, outside of the basic > supervision that should already be in place. No. It's starting the *first* agent. Remember, I had disabled systemd's handling of gpg-agent so there is no supervising gpg-agent process started by systemd. When I showed the two gpg-agent processes that existed after the incoming ssh connection ran gpg, they were the only two gpg-agent processes owned by the 'thing' user. There was no supervising one or I would have shown that one as well. The problem is that the subsequent incoming ssh connection runs gpg and that gpg process starts a second gpg-agent process (which has no knowledge of the passphrase) rather than connecting to this first gpg-agent process (which does have knowledge of the passphrase - at least it does until the new gpg-agent is started possibly because it took over the sockets that were created by the first gpg-agent process). > If you want to use the standard system agent, please do not launch a > separate agent. As I stated some time ago, I don't want to use the "standard system agent" because I don't trust systemd to know when it's ok to remove resources. I have had too much trouble caused by systemd concluding that it was time to remove crucial resources to be able trust it with anything that I need to rely on. > This should be as simple as: > > screen -- sudo -u thing --login > > or, if you're doing this as root already, then you don't need sudo at > all, and it could just be: > > screen -- su - testuser It's not run as root. > If this is run from cron, it will spawn a new session, and that session > will have a systemd session manager capable of spawning gpg-agent as > needed. It's not run from cron. It wouldn't make sense to run it from cron. > unfortunately, it will not spawn a new session if run from an existing > session, see the discussion at > https://github.com/systemd/systemd/issues/7451 . > > if you want to manually start a new session for a new user from within > an existing session on a machine managed by systemd, apparently > machinectl may be the way to go, but i haven't explored that in full. That must explain why systemd didn't create a /var/run subdirectory for the 'thing' user during the sudo process (when I re-enabled systemd's handling of gpg-agent). But machinectl seems to be for containers. I'd rather not go there since it might not be right since I'm not using containers. It seems like a hack. I think this is just another argument/example to support my preference for avoiding the additional complexity of systemd here and just using gnupg by itself. > hope this helps, > > --dkg Thanks. I appreciate the effort and research but it doesn't really help. It doesn't address the issue of the incoming ssh connection's gpg process starting up a new gpg-agent process rather than connecting to the existing one. But don't worry. I'm sure I've wasted enough of your time. When I get time, I'll debug what's happening and either realise what needs to be done or work around it somehow. Thanks, raf From jason.lawrence at linuxmail.org Mon Jan 15 06:43:20 2018 From: jason.lawrence at linuxmail.org (Jason Lawrence) Date: Mon, 15 Jan 2018 06:43:20 +0100 Subject: Hide UID From Public Key Server By Poison Your Key? Message-ID: Hi all, For of all, I am sorry for using a temporary email address. Let's say, you have accidentally associated your real name to the key under your online name and upload it to public key server, which allows anyone to connect your online identity to the person in real life. Since you can never remove anything from the public key server, You are wondering if you can add something to it -- for example, add another 100 of UIDs with other people's real name and emails so people can not find out which one is yours, and append another 100 of digital signature so people get tired before figure out which one is from valid user. Since it is easy to fake system time for PGP, you can mix my real UID in middle of all these. The problem is, how will the public key server handle 2 keys with duplicated timestamp? Just an idea, it might be more efficient if I just commit online suicide (throw away my current identity). Best regret Jason From rjh at sixdemonbag.org Mon Jan 15 08:13:50 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 15 Jan 2018 02:13:50 -0500 Subject: Hide UID From Public Key Server By Poison Your Key? In-Reply-To: References: Message-ID: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> > Let's say, you have accidentally associated your > real name to the key under your online name and > upload it to public key server, which allows > anyone to connect your online identity to the > person in real life. Uh -- how? There is no mechanism in the keyserver to do this. That's why you have to validate certificates you receive from the keyserver. The fact there's a UID named "Robert J. Hansen " on key 0xB44427C7 provides you with precisely *zero* evidence that I'm Rob Hansen or that Rob Hansen even exists. For all you know my name is Maurice Micklethorpe. > Since you can never remove > anything from the public key server, You are > wondering if you can add something to it -- for > example, add another 100 of UIDs with other > people's real name and emails so people can not > find out which one is yours, and append another > 100 of digital signature so people get tired > before figure out which one is from valid user. I rarely use language like this, but this time I think it's warranted: This is a total dick move. Don't do this. You'll make yourself a lot of enemies, and if you pick the wrong real names and emails, some of those people are pretty damn good at figuring out what's going on. Don't put real names and emails belonging to other people on your cert. It's *rude*. If someone goes looking for "Robert J. Hansen " I want them to see one cert is newest and I want them to use that one. If you go about putting my name and email address on your cert, I'm going to get cross. Again: this is a total dick move. Don't do this. From Ryan-Scarr at hotmail.co.uk Sun Jan 14 23:57:24 2018 From: Ryan-Scarr at hotmail.co.uk (Ryan Scarr) Date: Sun, 14 Jan 2018 22:57:24 +0000 Subject: GPG public key HELP Message-ID: I#m trying to convert it into an alrogrithim by opening it with the note pad so I can purchase, but it doesn?t change it into the correct one so that other people know my certification? How do I change my public file into a format that I can ive to other users? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.lawrence at linuxmail.org Mon Jan 15 06:47:21 2018 From: jason.lawrence at linuxmail.org (Jason Lawrence) Date: Mon, 15 Jan 2018 06:47:21 +0100 Subject: Hide UID From Public Key Server By Poison Your Key? Message-ID: An HTML attachment was scrubbed... URL: From leo at gaspard.io Mon Jan 15 09:14:36 2018 From: leo at gaspard.io (Leo Gaspard) Date: Mon, 15 Jan 2018 09:14:36 +0100 Subject: Remove public key from keyserver (was: Re: Hide UID From Public Key Server By Poison Your Key?) In-Reply-To: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> Message-ID: <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> On 01/15/2018 08:13 AM, Robert J. Hansen wrote:>> Since you can never remove >> anything from the public key server, You are >> wondering if you can add something to it -- for >> example, add another 100 of UIDs with other >> people's real name and emails so people can not >> find out which one is yours, and append another >> 100 of digital signature so people get tired >> before figure out which one is from valid user. > > I rarely use language like this, but this time I think it's warranted: > > This is a total dick move. Don't do this. You'll make yourself a lot > of enemies, and if you pick the wrong real names and emails, some of > those people are pretty damn good at figuring out what's going on. > > Don't put real names and emails belonging to other people on your cert. > It's *rude*. If someone goes looking for "Robert J. Hansen > " I want them to see one cert is newest and I want > them to use that one. If you go about putting my name and email address > on your cert, I'm going to get cross. > > Again: this is a total dick move. Don't do this. That said, it raises the interesting question of revocation of data on keyservers (and the associated legal issues in operating keyservers, as the operator is supposed to comply with requests to remove personally-identifiable information from it). I was just thinking, would it be possible to have a tag (a UID with special meaning, like ?please-remove-me at srs-keyservers.net??) for which the signature would be verified by the keyserver, and that would cause it to drop everything from its storage apart from this tag? This way the ?please remove me? tag would just naturally propagate across keyservers, and all up-to-date-enough keyservers will drop all the data associated with the key except the tag and the master public key (basically, the strict minimum to check the said tag). That said I guess ideas like this have already likely been discussed before? From dirk.gottschalk1980 at googlemail.com Mon Jan 15 14:22:24 2018 From: dirk.gottschalk1980 at googlemail.com (dirk.gottschalk1980 at googlemail.com) Date: Mon, 15 Jan 2018 14:22:24 +0100 Subject: GPG public key HELP In-Reply-To: References: Message-ID: <1516022544.4065.1.camel@googlemail.com> Hi. What are you trying to do? Do you just want to transfer you public key via email or anything like that? Then try: gpg2 -a --eyport > filename.asc This gives you an ascii armored key that you can transfer in any way you want. Regards, Dirk Am Sonntag, den 14.01.2018, 22:57 +0000 schrieb Ryan Scarr: > I#m trying to convert it into an alrogrithim by opening it with the > note pad so I can purchase, but it doesn?t change it into the correct > one so that other people know my certification? How do I change my > public file into a format that I can ive to other users? > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From bernhard at intevation.de Mon Jan 15 16:03:27 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 15 Jan 2018 16:03:27 +0100 Subject: skipped: Unusable public key error In-Reply-To: <4686398BFECAB0428133AD04DBF639524685AB@resexmbx2.gencoatc.prv> References: <4686398BFECAB0428133AD04DBF639524685AB@resexmbx2.gencoatc.prv> Message-ID: <201801151603.27599.bernhard@intevation.de> Am Mittwoch 10 Januar 2018 14:51:24 schrieb Rajireddy Saddi (OSV): > I used below command for encryption but I am getting below error > skipped: Unusable public key error Try the same command with more verbosity, e.g. by adding the following options, try to get more verbose if you do not see the reason -v -vv -vvv --debug-all Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Mon Jan 15 16:18:41 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 15 Jan 2018 16:18:41 +0100 Subject: LWN 'Future directions for PGP' 2018-01-03 Message-ID: <201801151618.49232.bernhard@intevation.de> LWN has an article that mentions NetPGP, NeoPG, GnuPG and key distribution idea. January 3, 2018 contributed by J. B. Crawford https://lwn.net/Articles/742542/ I've added some comments about recent advancements of concepts, especially WKD. Also I've added Netpgp and NeoPG to https://wiki.gnupg.org/OtherFreeSoftwareOpenPGP to keep track of whats out there. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From jason.lawrence at linuxmail.org Mon Jan 15 17:14:40 2018 From: jason.lawrence at linuxmail.org (Jason Lawrence) Date: Mon, 15 Jan 2018 17:14:40 +0100 Subject: Remove public key from keyserver (was: Hide UID From Public Key Server By Poison Your Key?) In-Reply-To: <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> Message-ID: > That said I guess ideas like this have already > likely been discussed before? Good luck with that, the similar discussing has been hold years and nothing ever changed. Last time I checked, a discussing in 2005 was labeled as "Remove public key from keyserver No.74" ? Sent:?Monday, January 15, 2018 at 4:14 PM From:?"Leo Gaspard" To:?gnupg-users at gnupg.org Subject:?Remove public key from keyserver (was: Re: Hide UID From Public Key Server By Poison Your Key?) On 01/15/2018 08:13 AM, Robert J. Hansen wrote:>> Since you can never remove >> anything from the public key server, You are >> wondering if you can add something to it -- for >> example, add another 100 of UIDs with other >> people's real name and emails so people can not >> find out which one is yours, and append another >> 100 of digital signature so people get tired >> before figure out which one is from valid user. > > I rarely use language like this, but this time I think it's warranted: > > This is a total dick move. Don't do this. You'll make yourself a lot > of enemies, and if you pick the wrong real names and emails, some of > those people are pretty damn good at figuring out what's going on. > > Don't put real names and emails belonging to other people on your cert. > It's *rude*. If someone goes looking for "Robert J. Hansen > " I want them to see one cert is newest and I want > them to use that one. If you go about putting my name and email address > on your cert, I'm going to get cross. > > Again: this is a total dick move. Don't do this. That said, it raises the interesting question of revocation of data on keyservers (and the associated legal issues in operating keyservers, as the operator is supposed to comply with requests to remove personally-identifiable information from it). I was just thinking, would it be possible to have a tag (a UID with special meaning, like ?please-remove-me at srs-keyservers.net??) for which the signature would be verified by the keyserver, and that would cause it to drop everything from its storage apart from this tag? This way the ?please remove me? tag would just naturally propagate across keyservers, and all up-to-date-enough keyservers will drop all the data associated with the key except the tag and the master public key (basically, the strict minimum to check the said tag). That said I guess ideas like this have already likely been discussed before? _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From stefan.claas at posteo.de Mon Jan 15 17:39:54 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Mon, 15 Jan 2018 17:39:54 +0100 Subject: Remove public key from keyserver (was: Hide UID From Public Key Server By Poison Your Key?) In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> Message-ID: <20180115173652.14f43a5d@iria.my-fqdn.de> On Mon, 15 Jan 2018 17:14:40 +0100, Jason Lawrence wrote: > > That said I guess ideas like this have already > > likely been discussed before? > > Good luck with that, the similar discussing has > been hold years and nothing ever changed. Last > time I checked, a discussing in 2005 was labeled > as "Remove public key from keyserver No.74" > ? > > Sent:?Monday, January 15, 2018 at 4:14 PM > From:?"Leo Gaspard" > To:?gnupg-users at gnupg.org > Subject:?Remove public key from keyserver (was: Re: Hide UID From > Public Key Server By Poison Your Key?) On 01/15/2018 08:13 AM, Robert > J. Hansen wrote:>> Since you can never remove > >> anything from the public key server, You are > >> wondering if you can add something to it -- for > >> example, add another 100 of UIDs with other > >> people's real name and emails so people can not > >> find out which one is yours, and append another > >> 100 of digital signature so people get tired > >> before figure out which one is from valid user. > > > > I rarely use language like this, but this time I think it's > > warranted: > > > > This is a total dick move. Don't do this. You'll make yourself a lot > > of enemies, and if you pick the wrong real names and emails, some of > > those people are pretty damn good at figuring out what's going on. > > > > Don't put real names and emails belonging to other people on your > > cert. It's *rude*. If someone goes looking for "Robert J. Hansen > > " I want them to see one cert is newest and I > > want them to use that one. If you go about putting my name and > > email address on your cert, I'm going to get cross. > > > > Again: this is a total dick move. Don't do this. > > That said, it raises the interesting question of revocation of data on > keyservers (and the associated legal issues in operating keyservers, > as the operator is supposed to comply with requests to remove > personally-identifiable information from it). > > I was just thinking, would it be possible to have a tag (a UID with > special meaning, like ?please-remove-me at srs-keyservers.net??) for > which the signature would be verified by the keyserver, and that > would cause it to drop everything from its storage apart from this > tag? This way the ?please remove me? tag would just naturally > propagate across keyservers, and all up-to-date-enough keyservers > will drop all the data associated with the key except the tag and the > master public key (basically, the strict minimum to check the said > tag). > > That said I guess ideas like this have already > lhttps://en.wikipedia.org/wiki/Right_to_be_forgottenikely been > discussed before? Maybe we need (a court) case were a PGP user requests the removal of his / her keys until the operators and code maintainers wake up? Or PGP users simply forget those old fashioned geek key servers and use modern solutions like keybase.io for example. https://en.wikipedia.org/wiki/Right_to_be_forgotten Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From peter at digitalbrains.com Mon Jan 15 19:47:39 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 15 Jan 2018 19:47:39 +0100 Subject: Remove public key from keyserver In-Reply-To: <20180115173652.14f43a5d@iria.my-fqdn.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> Message-ID: <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> On 15/01/18 17:39, Stefan Claas wrote: > Maybe we need (a court) case were a PGP user requests the removal > of his / her keys until the operators and code maintainers wake up? Wow, you're entertaining an interesting notion of what is "needed"! Let's hope most people will just let keyserver operators alone while they offer their kind service for free to the world. What is "needed" if you must, is someone thinking of a way to incorporate cryptographic validation into the whole gossip and what not process. Not turning loose the lawyers on people offering a free service. I can't believe what I'm hearing here. Just, wow. 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 andrewg at andrewg.com Mon Jan 15 19:53:26 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 15 Jan 2018 18:53:26 +0000 Subject: Remove public key from keyserver (was: Hide UID From Public Key Server By Poison Your Key?) In-Reply-To: <20180115173652.14f43a5d@iria.my-fqdn.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> Message-ID: <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> > On 15 Jan 2018, at 16:39, Stefan Claas wrote: > > Maybe we need (a court) case were a PGP user requests the removal > of his / her keys until the operators and code maintainers wake up? You also need to prove that removal is technically possible. Otherwise all that such a court case will achieve is to shut down the keyservers. A From stefan.claas at posteo.de Mon Jan 15 20:21:23 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Mon, 15 Jan 2018 20:21:23 +0100 Subject: Remove public key from keyserver In-Reply-To: <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> Message-ID: <20180115201951.3dc884d9@iria.my-fqdn.de> On Mon, 15 Jan 2018 19:47:39 +0100, Peter Lebbing wrote: > On 15/01/18 17:39, Stefan Claas wrote: > > Maybe we need (a court) case were a PGP user requests the removal > > of his / her keys until the operators and code maintainers wake > > up? > > Wow, you're entertaining an interesting notion of what is "needed"! > > Let's hope most people will just let keyserver operators alone while > they offer their kind service for free to the world. > > What is "needed" if you must, is someone thinking of a way to > incorporate cryptographic validation into the whole gossip and what > not process. Not turning loose the lawyers on people offering a free > service. I can't believe what I'm hearing here. Just, wow. How long do we have now those old fashioned key servers, and was there ever been made attempts by the software maintainers to modernize the code, like you are saying incorporating crypto validation? O.k. Werner invented WKD which solves those problems, if i'm not mistaken, but is it besides keybase.io widely deployed? The old pgp.com key server solved those problems also nicely, if i remember correctly. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From stefan.claas at posteo.de Mon Jan 15 20:24:18 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Mon, 15 Jan 2018 20:24:18 +0100 Subject: Remove public key from keyserver In-Reply-To: <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> Message-ID: <20180115202409.1e0873b0@iria.my-fqdn.de> On Mon, 15 Jan 2018 18:53:26 +0000, Andrew Gallagher wrote: > > On 15 Jan 2018, at 16:39, Stefan Claas > > wrote: > > > > Maybe we need (a court) case were a PGP user requests the removal > > of his / her keys until the operators and code maintainers wake > > up? > > You also need to prove that removal is technically possible. > Otherwise all that such a court case will achieve is to shut down the > keyservers. Correct, but would it be really a big loss if we would loose all the old fashioned key servers tomorrow? For me not. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From rjh at sixdemonbag.org Mon Jan 15 20:39:56 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 15 Jan 2018 14:39:56 -0500 Subject: Remove public key from keyserver In-Reply-To: <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> Message-ID: <9a1f2fb7-b5eb-f105-ccdb-7bfad2410d94@sixdemonbag.org> > I was just thinking, would it be possible to have a tag (a UID with > special meaning, like ?please-remove-me at srs-keyservers.net??) for which > the signature would be verified by the keyserver, and that would cause > it to drop everything from its storage apart from this tag? Nope. SKS has no cryptographic code in it. It does no evaluation of certificates or signatures. Adding this feature would require a vast amount of effort to add RFC4880 signature verification into the core of SKS. And it would also destroy one of the design goals of SKS, which is "the keyserver never discards data". To implement this would require a completely new keyserver implementation, one with considerably more code, which would *by design* drop certificates. I'd say it would take about five years for such a re-work to come to maturity and be trusted. So yes, it can be done, but it's not something to be done lightly, nor without a ton of buy-in from the existing keyserver community. > That said I guess ideas like this have already likely been discussed before? Many times. There appears to be no easy fix. From rjh at sixdemonbag.org Mon Jan 15 20:42:29 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 15 Jan 2018 14:42:29 -0500 Subject: Remove public key from keyserver In-Reply-To: <20180115173652.14f43a5d@iria.my-fqdn.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> Message-ID: > Maybe we need (a court) case were a PGP user requests the removal > of his / her keys until the operators and code maintainers wake up? Already happened back in 2010. https://lists.nongnu.org/archive/html/sks-devel/2010-09/msg00009.html From rjh at sixdemonbag.org Mon Jan 15 21:00:34 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 15 Jan 2018 15:00:34 -0500 Subject: Remove public key from keyserver In-Reply-To: <20180115201951.3dc884d9@iria.my-fqdn.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> Message-ID: <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> > How long do we have now those old fashioned key servers SKS came out in 2003. It largely replaced PKS, which was widely considered old and broken. SKS was Yaron Minsky's Ph.D thesis, wherein he developed some really cutting-edge math to make key sync fast and reliable. "Old-fashioned" is not the phrase I'd use to describe something considerably newer than GnuPG. >, and was > there ever been made attempts by the software maintainers to > modernize the code It's from 2003. It doesn't need modernization. Keyservers are designed the way they are for a reason. If keyservers *never ever discard or modify existing data*, then you can easily identify any code which theoretically might be able to discard data as a bug, a vulnerability, or tampering with it by a malicious actor. It makes code review easier and it makes it difficult for repressive regimes to surreptitiously take down certificates belonging to dissidents. This "we never discard or modify existing data, we only ever add new data" rule has some *really really nice* properties for information security. However, it also comes with a downside: we can't discard or modify existing data. It's a package deal. When SKS was being built in the early 2000s there were vigorous discussions about what properties we wanted in a keyserver. We knew exactly what we were getting into. Please, learn why it was built before you go about saying it was built badly. > The old pgp.com key server solved those problems also nicely, if i > remember correctly. I worked at PGP Security during that time period. It really didn't. If we'd received a court order compelling us to remove a cert from the keyserver and not tell anyone, we could have complied. That gave the flaming heebie-jeebies to at least three engineers on the floor, including the keyserver admin, a guy named Randy Harmon. Whether you embrace a "our keyserver can delete things" or "our keyserver is delete-free" model, that decision has immediate consequences you will not like. From rjh at sixdemonbag.org Mon Jan 15 21:09:52 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 15 Jan 2018 15:09:52 -0500 Subject: Remove public key from keyserver In-Reply-To: <20180115202409.1e0873b0@iria.my-fqdn.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <20180115202409.1e0873b0@iria.my-fqdn.de> Message-ID: <0870a6b8-5bfa-cf2f-a7c5-555946fec99b@sixdemonbag.org> > Correct, but would it be really a big loss if we would loose all the > old fashioned key servers tomorrow? For me not. I personally know Syrians and Iranians who have given me bear hugs at conferences when they hear I'm involved with GnuPG, Enigmail, and am on the periphery of SKS. A common theme with these people is they believe, on the basis of reasonable evidence, that their governments are involved in active campaigns to intercept and/or degrade communications, including by CNO means. I have been asked probably ten times in the past five years by dissidents, "Can I trust the keyservers? Is there any way to tamper with the data on them?" I have always told them the keyservers are trustworthy, and that they are designed to never delete or modify existing data. This seems to be a great relief to those dissidents. If the keyserver network were to go away tomorrow, it would definitely impact people in repressive regimes. From stefan.claas at posteo.de Mon Jan 15 21:23:08 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Mon, 15 Jan 2018 21:23:08 +0100 Subject: Remove public key from keyserver In-Reply-To: <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> Message-ID: <20180115212308.740173a7@iria.my-fqdn.de> On Mon, 15 Jan 2018 15:00:34 -0500, Robert J. Hansen wrote: > > How long do we have now those old fashioned key servers > > SKS came out in 2003. It largely replaced PKS, which was widely > considered old and broken. SKS was Yaron Minsky's Ph.D thesis, > wherein he developed some really cutting-edge math to make key sync > fast and reliable. > > "Old-fashioned" is not the phrase I'd use to describe something > considerably newer than GnuPG. > > >, and was > > there ever been made attempts by the software maintainers to > > modernize the code > > It's from 2003. It doesn't need modernization. No? I for one would like to be sure that i am the only person who can upload my public key to a key server directory. Example: Bob does some nasty things with Alice her key which she don't like, or better said hate. Since there is no key removal currently implemented how should she deal with that? > Keyservers are designed the way they are for a reason. If keyservers > *never ever discard or modify existing data*, then you can easily > identify any code which theoretically might be able to discard data > as a bug, a vulnerability, or tampering with it by a malicious > actor. It makes code review easier and it makes it difficult for > repressive regimes to surreptitiously take down certificates > belonging to dissidents. > > This "we never discard or modify existing data, we only ever add new > data" rule has some *really really nice* properties for information > security. However, it also comes with a downside: we can't discard or > modify existing data. > > It's a package deal. When SKS was being built in the early 2000s > there were vigorous discussions about what properties we wanted in a > keyserver. We knew exactly what we were getting into. > > Please, learn why it was built before you go about saying it was built > badly. > > > The old pgp.com key server solved those problems also nicely, if i > > remember correctly. > > I worked at PGP Security during that time period. It really didn't. > If we'd received a court order compelling us to remove a cert from the > keyserver and not tell anyone, we could have complied. That gave the > flaming heebie-jeebies to at least three engineers on the floor, > including the keyserver admin, a guy named Randy Harmon. > > Whether you embrace a "our keyserver can delete things" or "our > keyserver is delete-free" model, that decision has immediate > consequences you will not like. Well, i personally liked the option that i could delete my key. https://support.symantec.com/en_US/article.TECH148870.html Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From jason.lawrence at linuxmail.org Mon Jan 15 17:12:03 2018 From: jason.lawrence at linuxmail.org (Jason Lawrence) Date: Mon, 15 Jan 2018 17:12:03 +0100 Subject: Hide UID From Public Key Server By Poison Your Key? In-Reply-To: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> Message-ID: An HTML attachment was scrubbed... URL: From m.mansfeld at mansfeld-elektronik.de Mon Jan 15 20:27:14 2018 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Mon, 15 Jan 2018 20:27:14 +0100 Subject: Remove public key from keyserver (was: Hide UID From Public Key Server By Poison Your Key?) In-Reply-To: <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> References: , <20180115173652.14f43a5d@iria.my-fqdn.de>, <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> Message-ID: <5A5D0092.27641.26C778C@m.mansfeld.mansfeld-elektronik.de> On 15 Jan 2018 at 18:53, Andrew Gallagher wrote: > > > On 15 Jan 2018, at 16:39, Stefan Claas > > wrote: > > > > Maybe we need (a court) case were a PGP user requests the removal of > > his / her keys until the operators and code maintainers wake up? > > You also need to prove that removal is technically possible. Otherwise > all that such a court case will achieve is to shut down the > keyservers. OK, THIS should be basically possible to implement, in the same way like a new or updated key propagates itself. Not now but would be a good idea. And with no warranty however that this key is not anywhere else backbackbackupped and eventually loaded up again.... Exists any flag for pubkeys "please do never ever store this key on a keyserver", if not, would be a good idea, too. There are many reasons NOT to want a key on the keyservers. Regards Matthias -- OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF From listofactor at mail.ru Mon Jan 15 21:25:22 2018 From: listofactor at mail.ru (listo factor) Date: Mon, 15 Jan 2018 20:25:22 +0000 Subject: a step in the right direction In-Reply-To: <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> Message-ID: <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> On 01/15/2018 06:53 PM, Andrew Gallagher wrote: > >> On 15 Jan 2018, at 16:39, Stefan Claas wrote: >> >> Maybe we need (a court) case were a PGP user requests the removal >> of his / her keys until the operators and code maintainers wake up? > > You also need to prove that removal is technically possible. Otherwise all that such a court case will achieve is to shut down the keyservers. Which would be step in the right direction when compared with the current situation. From m.mansfeld at mansfeld-elektronik.de Mon Jan 15 22:13:20 2018 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Mon, 15 Jan 2018 22:13:20 +0100 Subject: Remove public key from keyserver In-Reply-To: <20180115212308.740173a7@iria.my-fqdn.de> References: , <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org>, <20180115212308.740173a7@iria.my-fqdn.de> Message-ID: <5A5D1970.32429.2CD9950@m.mansfeld.mansfeld-elektronik.de> On 15 Jan 2018 at 21:23, Stefan Claas wrote: > On Mon, 15 Jan 2018 15:00:34 -0500, Robert J. Hansen wrote: > > > How long do we have now those old fashioned key servers > > > > SKS came out in 2003. It largely replaced PKS, which was widely > > considered old and broken. SKS was Yaron Minsky's Ph.D thesis, > > wherein he developed some really cutting-edge math to make key sync > > fast and reliable. > > > > "Old-fashioned" is not the phrase I'd use to describe something > > considerably newer than GnuPG. > > > > >, and was > > > there ever been made attempts by the software maintainers to > > > modernize the code > > > > It's from 2003. It doesn't need modernization. > > No? I for one would like to be sure that i am the only person who can > upload my public key to a key server directory. > could this be implemented in a way that the _upload_ (not the spreading between keyservers) requires signing? (unless it is a revocation certificate)? > Example: Bob does some nasty things with Alice her key which she > don't like, or better said hate. Since there is no key removal > currently implemented how should she deal with that? Or it may be desirable/necessary not to disclose connections between specific persons, User IDs etc., thus to remove critical signatures. Regards Matthias -- OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF From rjh at sixdemonbag.org Mon Jan 15 23:45:49 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 15 Jan 2018 17:45:49 -0500 Subject: a step in the right direction In-Reply-To: <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> Message-ID: <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> > Which would be step in the right direction when compared > with the current situation. ... shutting down a keyserver network relied on by literally tens of thousands of people, to say nothing about OS distributions, is a "step in the right direction"? Okay. Fine. Let's say you wave a magic wand and you're able to make the keyserver network go away. What are the immediate, *predictable*, consequences? First, people in bad places like Syria and Iran lose the ability to easily get public keys for journalists in free countries. The neat thing about the pool is nobody knows exactly who all is in it. Years ago for some months I ran a covert keyserver to see how practical it would be for people in hostile regimes: my keyserver was not part of the public pool, but synced with it. That's useful because a regime might firewall off the entire pool, but so long as covert nodes exist the whole of the network is still accessible even in information-controlling regimes. Second, your operating system -- if you're running something like a Linux distro, or macOS using Homebrew, or heck, even Windows with msys2/mingw -- *BREAKS*. You can't get updates any more. Let's look at why, using the package manager in msys2/mingw/Arch Linux. It's called pacman. In pacman, each package is signed by the package maintainer. The package maintainer's certificate is in turn signed by at least three other pacman maintainer certs. E.g., if you manage a package called "fooblitzsky", you sign the fooblitzsky packages with your cert, and three msys2 maintainers sign your cert. This way, end users can be confident that you, the maintainer, personally authorized this release, and that you're trusted by the msys2 team. Now that you've taken down the keyserver network, you go to install fooblitzsky, and ... uh ... wait. You can get the package, but you have no way of getting the maintainer's cert to verify the package. _Literally every major FOSS package manager breaks. Updates become impossible._ Let that sink in for a moment. I don't think you understand anything about the ecosystem here. You're advocating burning down a _critically important part of the entire FOSS landscape._ From andrewg at andrewg.com Tue Jan 16 00:19:02 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 15 Jan 2018 23:19:02 +0000 Subject: Remove public key from keyserver In-Reply-To: <5A5D1970.32429.2CD9950@m.mansfeld.mansfeld-elektronik.de> References: <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> <20180115212308.740173a7@iria.my-fqdn.de> <5A5D1970.32429.2CD9950@m.mansfeld.mansfeld-elektronik.de> Message-ID: <527A29FA-CE29-459A-A82B-F40A8AE88C65@andrewg.com> > On 15 Jan 2018, at 21:13, Matthias Mansfeld wrote: > > could this be implemented in a way that the _upload_ (not the > spreading between keyservers) requires signing? (unless it is a > revocation certificate)? So long as there is one keyserver somewhere in the ecosystem that fails to enforce this, I don?t see the point... A From rjh at sixdemonbag.org Tue Jan 16 00:32:07 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 15 Jan 2018 18:32:07 -0500 Subject: Remove public key from keyserver In-Reply-To: <5A5D1970.32429.2CD9950@m.mansfeld.mansfeld-elektronik.de> References: <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> <20180115212308.740173a7@iria.my-fqdn.de> <5A5D1970.32429.2CD9950@m.mansfeld.mansfeld-elektronik.de> Message-ID: (Responding here because Stefan's message hasn't hit my mail server yet) >>> It's from 2003. It doesn't need modernization. >> >> No? I for one would like to be sure that i am the only person who can >> upload my public key to a key server directory. Which is not a modernization issue. It's a feature request, and the feature you're asking for is DRM. Literally. You're asking that the keyserver network be rewritten to give you the ability to manage how information, which you think belongs to you, gets shared: that's DRM. DRM schemes are awful and they don't work. From rjh at sixdemonbag.org Tue Jan 16 01:01:52 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 15 Jan 2018 19:01:52 -0500 Subject: Hide UID From Public Key Server By Poison Your Key? In-Reply-To: References: Message-ID: > Just an idea, it might be more efficient if I just > commit online suicide (throw away my current > identity). I should also add: in addition to being a dick move, this approach doesn't work. It's genuinely counterproductive. If I were to see a certificate with a hundred different UIDs, I'd immediately start digging around. This is not what you want: in the course of poisoning your cert you've made it odd, unusual, and interesting. Next thing I'd do would be to start scouring the internet for these usernames. Most would simply not have any trail associated with them whatsoever: I'd email them and get bounce messages to confirm it. I've now largely cured your attempt at poisoning your cert. I'm down to a handful of user IDs. One of them will have a very carefully-curated digital trail. The others will not. Congratulations: I've just found the identity you want to keep secret. Now I know there's some connection between this identity and the small number of user IDs that are left after depoisoning. Now it's just a matter of time until I figure out who you are and what fake identity you're using... and here's the rub: until I saw over 100 UIDs on your cert, I wouldn't have given a damn and wouldn't have bothered. The worst thing you can do in your situation is to draw attention to your mistake. Your poisoning attempt is genuinely counterproductive. You're making yourself visible. I cannot advise against this course of action strongly enough. Burning your current fake identity is probably far safer and more effective. From listofactor at mail.ru Tue Jan 16 02:02:11 2018 From: listofactor at mail.ru (listo factor) Date: Tue, 16 Jan 2018 01:02:11 +0000 Subject: a step in the right direction In-Reply-To: <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> Message-ID: On 01/15/2018 10:45 PM, Robert J. Hansen - rjh at sixdemonbag.org wrote: >> Which would be step in the right direction when compared >> with the current situation. > ..> First, people in bad places like Syria and Iran lose the ability to... I would never allow my opinion of what are the "good places" and what are the "bad places" to enter into a technical discussion. (On immigration, or on security engineering). ... > _Literally every major FOSS package manager breaks. Updates become > impossible._ > > Let that sink in for a moment. > > I don't think you understand anything about the ecosystem here. You're > advocating burning down a _critically important part of the entire FOSS > landscape._ Burning it down is not what I was advocating. I am advocating orderly evacuation and replacement of a system that has clearly outlived its usefulnesses. If it is not replaced in time, it will, at some point, burn ignited by forces we have no control over. ~Then~ it will have to be abandoned in rather more painful manner - just as you are alluding to. EU legislation, among other things, will see to that. The times are changing, and nobody is free to keep serving publicly someone else's private information over the objections of the owner. "This is the way we always did it" is a poor response and it will not be a valid one forever. From rjh at sixdemonbag.org Tue Jan 16 02:17:01 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 15 Jan 2018 20:17:01 -0500 Subject: a step in the right direction In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> Message-ID: <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> > I would never allow my opinion of what are the "good places" and what > are the "bad places" to enter into a technical discussion. > (On immigration, or on security engineering). I think you'll have a hard time convincing people that when speaking about human rights activists in North Korea, it's somehow inappropriate to say they're living in a bad place. Repressive governments are real threats to human rights, and it doesn't do anyone any good to pretend otherwise. > Burning it down is not what I was advocating. I am advocating orderly > evacuation and replacement of a system that has clearly outlived its > usefulnesses. No, you're not. Evacuation and replacement requires a replacement exists. The moment you present an alternative that's running and working and stable, *then* we can have a discussion about moving to the exits. > EU legislation, among other things, will see to that. The times are > changing, and nobody is free to keep serving publicly someone else's > private information over the objections of the owner. US keyservers are. The only thing EU regulations will do is end keyservers in the EU. The SKS community has been discussing a considerably worse nightmare scenario for the past seven years. There have been a number of flawed proposals made in that time period. Your time might be better spent perusing the last seven years of sks-devel to learn what has already been proposed and the flaws in each of them. From listofactor at mail.ru Tue Jan 16 04:24:33 2018 From: listofactor at mail.ru (listo factor) Date: Tue, 16 Jan 2018 03:24:33 +0000 Subject: a step in the right direction In-Reply-To: <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> Message-ID: <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> On 01/16/2018 01:17 AM, Robert J. Hansen - rjh at sixdemonbag.org wrote: > The SKS community has been discussing a considerably worse nightmare > scenario for the past seven years. Considering the possibility that this particular system will be forced to conform to a more contemporary (and I would argue more enlightened) legislative framework in respect to the right to privacy (cf., https://en.wikipedia.org/wiki/Right_to_be_forgotten) should not be viewed as "discussing a [...] nightmare scenario", it should be considered as planning for demands that will be placed on the system by developments outside of it, i.e., by developments of the society that the system is supposed to serve. If there is merit to the principle that an Internet server operator can not keep publicly serving private data over the objections of the owner (the same as today, after many battles, he can no longer publicly serve data of commercial value over the objections of its owner), then it is not unreasonable to assume that most enlightened jurisdictions will sooner or later enact such legislation. Yes, it is DRM, but in my view ethically much more justifiable than DRM over the data of commercial value. The fact that one large jurisdiction is well on its way with enacting this, while another is not there yet, should be viewed as a fortunate circumstance, one that buys us time to do what needs to be done, not as an excuse to bury our heads in the sand. From wk at gnupg.org Tue Jan 16 08:52:44 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Jan 2018 08:52:44 +0100 Subject: Remove public key from keyserver In-Reply-To: <20180115201951.3dc884d9@iria.my-fqdn.de> (Stefan Claas's message of "Mon, 15 Jan 2018 20:21:23 +0100") References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> Message-ID: <878tcyckab.fsf@wheatstone.g10code.de> On Mon, 15 Jan 2018 20:21, stefan.claas at posteo.de said: > O.k. Werner invented WKD which solves those problems, if i'm not > mistaken, but is it besides keybase.io widely deployed? Nope. The Web Key Directory solves exactly one problem: How to initially map a mail address to a key. This directory is hosted by the provider of the mail address because that is the only entity which controls the mail address. Once this mail address has been mapped keyservers can be used to get revocations and updates of the key. Unfortunately it is not yet widely supported; you can help to make it better known. I wonder why you seem to suggest the US based keybase.io as a better solution. After all keybase.io is a service which connects private data to private data of other sites and that all in the public. I would consider this a real privacy problem compared to a public mail address on a keyserver with no other associated private data. The mail address is a technical necessity to send mail; mapping the mail address to a key is a technical necessity to send encrypted mail. So what keyservers do is to provide a directory of public keys - in the same way as white pages of the phone systems. Nobody requires you to enter you phone number / public key into a directory. But if you want to receive phone calls / encrypted mails you need to somehow publish this data. You can't remove your name from white pages either - they used to be printed in sometimes millions of copies. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue Jan 16 09:20:54 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Jan 2018 03:20:54 -0500 Subject: a step in the right direction In-Reply-To: <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> Message-ID: <63372eaf-9ea0-72bb-4484-c37a250261eb@sixdemonbag.org> (I originally composed this on a mobile device and it was held for moderation. Re-sending it from my laptop.) ===== (Apologies for the terseness: on a mobile device) > should not be viewed as "discussing a [...] nightmare scenario", I am darkly amused at someone who has not done the research into what the nightmare scenario *is* telling me that it's not a nightmare scenario. The nightmare scenario is malcontents realize the keyserver network is a multijurisdictional, redundant, distributed database from which data cannot be deleted... and decide this makes it an ideal way to distribute child porn. The moment that happens, the keyserver network goes down hard as every keyserver operator everywhere gets exposed to massive criminal liability. We've known about it for several years. We've been thinking about how to counter it for several years. It turns out that countering it is a *really hard job*. If you make it possible to delete records from a keyserver, you open the door to all kinds of shenanigans that governments could force keyserver operators to do on their behalf. How do you make it possible to delete records from a keyserver, while at the same time keeping the keyserver resistant to malicious tampering from adversaries? This is an incredibly hard question to address. And frankly, you're not adding a single iota to the discussion. But if you want to continue it, I'd suggest speaking up over at sks-devel at gnu.org, where people have been having this discussion off and on for years. From rjh at sixdemonbag.org Tue Jan 16 09:25:52 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Jan 2018 03:25:52 -0500 Subject: a step in the right direction In-Reply-To: <63372eaf-9ea0-72bb-4484-c37a250261eb@sixdemonbag.org> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <63372eaf-9ea0-72bb-4484-c37a250261eb@sixdemonbag.org> Message-ID: > I'd suggest speaking up over at sks-devel at gnu.org, where people have Correction: sks-devel at nongnu.org From stefan.claas at posteo.de Tue Jan 16 09:46:40 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 16 Jan 2018 09:46:40 +0100 Subject: Remove public key from keyserver In-Reply-To: References: <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> <20180115212308.740173a7@iria.my-fqdn.de> <5A5D1970.32429.2CD9950@m.mansfeld.mansfeld-elektronik.de> Message-ID: Am 16.01.2018 um 00:32 schrieb Robert J. Hansen: > (Responding here because Stefan's message hasn't hit my mail server yet) My previous message to you and the list was bounced from your mail server. > >>>> It's from 2003. It doesn't need modernization. >>> No? I for one would like to be sure that i am the only person who can >>> upload my public key to a key server directory. > Which is not a modernization issue. It's a feature request, and the > feature you're asking for is DRM. Literally. You're asking that the > keyserver network be rewritten to give you the ability to manage how > information, which you think belongs to you, gets shared: that's DRM. > DRM schemes are awful and they don't work. > O.K. than it is a feature request. You also triggered something in me with the words " which you think belongs to you". If i am not mistaken you have also a keybase account, if not i applogize. How about this; let's make "your" public key the ideal canditate for a global trollwot session, were every GnuPG Linux user can participate and add some funny things to "your" public key. This would be also interesting to see how many signatures a public key can bear. Maybe people can do also other things with "your" pub key and post the used techniques here, like i did in the past with Erika Mustermann's pub key and the added fake sig from Werner. This would imho give you and people you talk to in conferences etc. also a better view what i am talking about. Best regards Stefan From gnupg at leo.gaspard.ninja Tue Jan 16 09:48:20 2018 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Tue, 16 Jan 2018 09:48:20 +0100 Subject: a step in the right direction In-Reply-To: <63372eaf-9ea0-72bb-4484-c37a250261eb@sixdemonbag.org> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <63372eaf-9ea0-72bb-4484-c37a250261eb@sixdemonbag.org> Message-ID: <9eb195f1-b9bf-6bd9-3f5f-6656caca7a8e@gaspard.io> On 01/16/2018 09:20 AM, Robert J. Hansen wrote:>> should not be viewed as "discussing a [...] nightmare scenario", > > I am darkly amused at someone who has not done the research into what > the nightmare scenario *is* telling me that it's not a nightmare scenario. > > The nightmare scenario is malcontents realize the keyserver network is a > multijurisdictional, redundant, distributed database from which data > cannot be deleted... and decide this makes it an ideal way to distribute > child porn. The moment that happens, the keyserver network goes down > hard as every keyserver operator everywhere gets exposed to massive > criminal liability. > > We've known about it for several years. We've been thinking about how > to counter it for several years. It turns out that countering it is a > *really hard job*. If you make it possible to delete records from a > keyserver, you open the door to all kinds of shenanigans that > governments could force keyserver operators to do on their behalf. I think this may be the reason why others than you are much more optimistic than you about all this: I don't think we are considering this scenario, only the much more restricted case of ?I want to remove information associated with my private key?. In which case there is no need of trusted introducers who would be allowed to moderate data, or anything like this: the owner of the key could just sign the deletion token with the said key. Handling network-wide censorship of information published is a much harder scenario, as the network was designed to be censorship-resistent. And it looks like a nice property we would want to keep at network-level in my opinion, though in order to accomodate local jurisdictions keyserver operators could maybe want not to store eg. photo IDs or the like -- just like if I understand correctly the case of someone sueing to get his key removed from keyservers lead to the addition of an option for keyserver operators to refuse syncing certain keys. That said, I did read your ?To implement this would require a completely new keyserver implementation, [?]? ; this message was just to maybe cast some light on why some people look much more optimistic about this than you are. From wk at gnupg.org Tue Jan 16 10:18:34 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Jan 2018 10:18:34 +0100 Subject: Remove public key from keyserver In-Reply-To: (Stefan Claas's message of "Tue, 16 Jan 2018 09:46:40 +0100") References: <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> <20180115212308.740173a7@iria.my-fqdn.de> <5A5D1970.32429.2CD9950@m.mansfeld.mansfeld-elektronik.de> Message-ID: <87shb6b1qt.fsf@wheatstone.g10code.de> On Tue, 16 Jan 2018 09:46, stefan.claas at posteo.de said: > and add some funny things to "your" public key. This would be > also interesting to see how many signatures a public key can bear. You may look at my key to see funny things and thousands of key signatures from made up users. They print a messges if viewed in a keyserver listing. Right, these key signatures allow for a DoS and eventually we should do something about them. As of now I resort to import-filter drop-sig= sig_created_d=2015-12-24 import-filter drop-sig=|| sig_created_d=2016-03-16 import-filter drop-sig=|| sig_created_d=2016-03-19 import-filter drop-sig=|| sig_created_d=2016-03-20 to keep my _local_ copy of the key at a reasonable size. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From stefan.claas at posteo.de Tue Jan 16 10:43:27 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 16 Jan 2018 10:43:27 +0100 Subject: Remove public key from keyserver In-Reply-To: <87shb6b1qt.fsf@wheatstone.g10code.de> References: <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> <20180115212308.740173a7@iria.my-fqdn.de> <5A5D1970.32429.2CD9950@m.mansfeld.mansfeld-elektronik.de> <87shb6b1qt.fsf@wheatstone.g10code.de> Message-ID: <2c204877-6e12-db36-f6a0-d38d1c842f49@posteo.de> Am 16.01.2018 um 10:18 schrieb Werner Koch: > On Tue, 16 Jan 2018 09:46, stefan.claas at posteo.de said: > >> and add some funny things to "your" public key. This would be >> also interesting to see how many signatures a public key can bear. > You may look at my key to see funny things and thousands of key > signatures from made up users. They print a messges if viewed in a > keyserver listing. > > Right, these key signatures allow for a DoS and eventually we should do > something about them. As of now I resort to > > import-filter drop-sig= sig_created_d=2015-12-24 > import-filter drop-sig=|| sig_created_d=2016-03-16 > import-filter drop-sig=|| sig_created_d=2016-03-19 > import-filter drop-sig=|| sig_created_d=2016-03-20 > > to keep my _local_ copy of the key at a reasonable size. I have read also once on Wikipedia about that a DoS is possible, but the Wiki Artikel gives no figures on how much Signatures are needed to carry out such an attack. And what would be your proposal to eventually circumwent this? Regards Stefan From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 11:12:43 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 11:12:43 +0100 Subject: Remove public key from keyserver In-Reply-To: <20180115212308.740173a7@iria.my-fqdn.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> <20180115212308.740173a7@iria.my-fqdn.de> Message-ID: <6fe6a651-b901-f9cd-57e9-2a6105a2a9ac@sumptuouscapital.com> On 01/15/2018 09:23 PM, Stefan Claas wrote: > No? I for one would like to be sure that i am the only person who > can upload my public key to a key server directory. This seems to be based on a misconception whereby you're attributing properties of a certificate authority to the keyservers. OpenPGP already has a method for certification from CAs, and that is by providing a signature on the appropriate UID on the public keyblock. As long as the signature is propagated on the keyserver network, these roles can be appropriately isolated and the decision of whether or not to trust a specific CA is left to the user performing the trust calculation, incidentally also allowing for signatures from multiple CAs. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Fabricando fit faber Practice makes perfect -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Jan 16 11:35:39 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 16 Jan 2018 11:35:39 +0100 Subject: a step in the right direction In-Reply-To: <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> Message-ID: On 16/01/18 04:24, listo factor via Gnupg-users wrote: > Considering the possibility that this particular system will > be forced to conform to a more contemporary (and I would argue > more enlightened) legislative framework in respect to the right to > privacy (cf., https://en.wikipedia.org/wiki/Right_to_be_forgotten) So how about I insert some private information of somebody into the "more contemporary" Bitcoin blockchain. Would you advocate that everybody removes copies of the blockchain? Wouldn't that mean an end to Bitcoin? Or do you consider blockchains to be outmoded technology from a different era? Just kidding :-). > then it is not unreasonable to assume that most enlightened > jurisdictions will sooner or later enact such legislation. Yes, it > is DRM, but in my view ethically much more justifiable than DRM over > the data of commercial value. What about those enlightened jurisdictions where anything not conforming to a strict interpretation of the local major religion is forbidden? Should country A get to forbid anything that is not directly conforming to religion 1 and country B forbid anything not conforming to religion 2, and this world-wide? Perhaps then we can use all those high-bandwidth links to exchange nothing but kitten pictures... provided there isn't a religion forbidding the depiction of animals. Why would you honour the EU's request to purge unwanted information from the internet world-wide, but not honour country A and B? Who decides what is "ethically justifiable" and what not? Do we need a world-wide vote on which commission is the most enlightened to decide this? Would such a vote require a majority, a large majority or be unanimous? And who decides these parameters anyway? And when there's a radical regime change somewhere in the world, do we go back to the drawing board? (Oh, by the way, usually when I talk about DRM, I'm talking about giving somebody data but restricting the ways in which they can use that data. It's not clear to me how DRM applies when you want to simply not give data at all, to anybody. But this is not really pertinent to the discussion, so never mind.) 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 stefan.claas at posteo.de Tue Jan 16 11:40:10 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 16 Jan 2018 11:40:10 +0100 Subject: Remove public key from keyserver In-Reply-To: <6fe6a651-b901-f9cd-57e9-2a6105a2a9ac@sumptuouscapital.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> <20180115212308.740173a7@iria.my-fqdn.de> <6fe6a651-b901-f9cd-57e9-2a6105a2a9ac@sumptuouscapital.com> Message-ID: <39570449-d3f1-023e-546a-abd212635cf8@posteo.de> Am 16.01.2018 um 11:12 schrieb Kristian Fiskerstrand: > On 01/15/2018 09:23 PM, Stefan Claas wrote: >> No? I for one would like to be sure that i am the only person who >> can upload my public key to a key server directory. > This seems to be based on a misconception whereby you're attributing > properties of a certificate authority to the keyservers. OpenPGP already > has a method for certification from CAs, and that is by providing a > signature on the appropriate UID on the public keyblock. As long as the > signature is propagated on the keyserver network, these roles can be > appropriately isolated and the decision of whether or not to trust a > specific CA is left to the user performing the trust calculation, > incidentally also allowing for signatures from multiple CAs. > I'm not sure what you are talking about, a language barrier from my side,sorry. The CA in Germany (Governikus) i have used sends me my certified key back to my email address and does not publish my pub key on key servers. Regards Stefan From stefan.claas at posteo.de Tue Jan 16 11:57:10 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 16 Jan 2018 11:57:10 +0100 Subject: a step in the right direction In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> Message-ID: <438623af-b0d2-d993-9d8d-9ff91b77318b@posteo.de> Am 16.01.2018 um 11:35 schrieb Peter Lebbing: > On 16/01/18 04:24, listo factor via Gnupg-users wrote: >> Considering the possibility that this particular system will >> be forced to conform to a more contemporary (and I would argue >> more enlightened) legislative framework in respect to the right to >> privacy (cf., https://en.wikipedia.org/wiki/Right_to_be_forgotten) > So how about I insert some private information of somebody into the > "more contemporary" Bitcoin blockchain. Would you advocate that > everybody removes copies of the blockchain? Wouldn't that mean an end to > Bitcoin? > > The blockchain is not anonymous and the origin can be traced back, right? And do people always look into blockchain data, when using their wallet to do transactions? With public WWW key servers it is imho different. Regards Stefan From andrewg at andrewg.com Tue Jan 16 12:51:03 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 16 Jan 2018 11:51:03 +0000 Subject: a step in the right direction In-Reply-To: <438623af-b0d2-d993-9d8d-9ff91b77318b@posteo.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <438623af-b0d2-d993-9d8d-9ff91b77318b@posteo.de> Message-ID: <7054cb10-714a-2d1a-5adf-3b6d3bdcbd84@andrewg.com> On 16/01/18 10:57, Stefan Claas wrote: > And do people always look into blockchain data, when using their wallet to > do transactions? With public WWW key servers it is imho different. This is an important distinction. Ordinary users should not be browsing the raw data. They should be using tools such as Enigmail that filter out unverified data from their default views. Sure, if you want to go looking for all the junk signatures on people's keys you can, but it shouldn't be displayed as a matter of course. Now, for various reasons a lot of us on this list have spent far too much of our lives looking at the raw keyserver data. And similarly, I have no doubt that a lot of early Bitcoin adopters have looked at the raw blockchain data. So we have to distinguish between what is available if one is sufficiently motivated to go and look, and what is shown to the majority of users. The vandalism problem is solved by clients not displaying unverified content. Whereas the "nightmare scenario" happens entirely out of view of the average user, but has more serious consequences. Let's not mix them up. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Tue Jan 16 13:34:42 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 16 Jan 2018 13:34:42 +0100 Subject: a step in the right direction In-Reply-To: <7054cb10-714a-2d1a-5adf-3b6d3bdcbd84@andrewg.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <438623af-b0d2-d993-9d8d-9ff91b77318b@posteo.de> <7054cb10-714a-2d1a-5adf-3b6d3bdcbd84@andrewg.com> Message-ID: <343133d7-0495-5db5-e3e3-408d6c130c6e@posteo.de> Am 16.01.2018 um 12:51 schrieb Andrew Gallagher: > > So we have to distinguish between what is available if one is > sufficiently motivated to go and look, and what is shown to the majority > of users. The vandalism problem is solved by clients not displaying > unverified content. Whereas the "nightmare scenario" happens entirely > out of view of the average user, but has more serious consequences. > Let's not mix them up. There might be also another problem in the future, not for GnuPG users, but for key servers. I don't know if such software already exists but how about using key servers as message storing/retrival system, so that people can avoid the classic smtp route for their PGP encrypted messages. Well, just a thought... Regards Stefan From andrewg at andrewg.com Tue Jan 16 13:38:48 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 16 Jan 2018 12:38:48 +0000 Subject: a step in the right direction In-Reply-To: <343133d7-0495-5db5-e3e3-408d6c130c6e@posteo.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <438623af-b0d2-d993-9d8d-9ff91b77318b@posteo.de> <7054cb10-714a-2d1a-5adf-3b6d3bdcbd84@andrewg.com> <343133d7-0495-5db5-e3e3-408d6c130c6e@posteo.de> Message-ID: On 16/01/18 12:34, Stefan Claas wrote: > I don't know if such software already exists but how about using key > servers > as message storing/retrival system, so that people can avoid the classic > smtp > route for their PGP encrypted messages. Well, just a thought... Isn't that called USENET? -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Tue Jan 16 13:45:47 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 16 Jan 2018 13:45:47 +0100 Subject: a step in the right direction In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <438623af-b0d2-d993-9d8d-9ff91b77318b@posteo.de> <7054cb10-714a-2d1a-5adf-3b6d3bdcbd84@andrewg.com> <343133d7-0495-5db5-e3e3-408d6c130c6e@posteo.de> Message-ID: Am 16.01.2018 um 13:38 schrieb Andrew Gallagher: > On 16/01/18 12:34, Stefan Claas wrote: >> I don't know if such software already exists but how about using key >> servers >> as message storing/retrival system, so that people can avoid the classic >> smtp >> route for their PGP encrypted messages. Well, just a thought... > Isn't that called USENET? Yes, something like Usenet's alt.anonymous.messages, for people who don't know or have Usenet access. Regards Stefan From nbsd4ever at gmail.com Tue Jan 16 14:12:40 2018 From: nbsd4ever at gmail.com (Henry) Date: Tue, 16 Jan 2018 22:12:40 +0900 Subject: My MISTAKE! not a bug Re: BUG report gnupg-2.2.4 (or npth) Message-ID: I'm very, very sorry to have wasted people's time. The problem was that I configured GNUpth incorrectly. I used "enable-pthread option when I should have done the opposite, disable. Many apologies, Henry 2018-01-15 10:47 GMT+09:00 NIIBE Yutaka : > Hello, > > I think that you have some different Pthread library in /usr/local. > > Henry wrote: >> /usr/local/include/pthread.h:357:18: error: conflicting types for > ^^^^^^^^^^^ > > I wonder if you have installed GNU Pth. Please try without Pth. > -- From rjh at sixdemonbag.org Tue Jan 16 15:54:37 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Jan 2018 09:54:37 -0500 Subject: a step in the right direction In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> Message-ID: > (Oh, by the way, usually when I talk about DRM, I'm talking about giving > somebody data but restricting the ways in which they can use that data. > It's not clear to me how DRM applies when you want to simply not give > data at all, to anybody. But this is not really pertinent to the > discussion, so never mind.) I was the one who brought up DRM. What Stefan and Listo want is some mechanism by which, if I have a copy of their public key, I can be prohibited from sharing that with a keyserver. How I get to use data in my possession is controlled by a third party -- that's DRM. In this case it's a voluntary, half-assed DRM scheme, but it's still in the family of DRM schemes. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Tue Jan 16 16:34:57 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 16 Jan 2018 16:34:57 +0100 Subject: Remove public key from keyserver In-Reply-To: <878tcyckab.fsf@wheatstone.g10code.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <878tcyckab.fsf@wheatstone.g10code.de> Message-ID: <20180116163442.0e7eca3d@iria.my-fqdn.de> On Tue, 16 Jan 2018 08:52:44 +0100, Werner Koch wrote: > I wonder why you seem to suggest the US based keybase.io as a better > solution. After all keybase.io is a service which connects private > data to private data of other sites and that all in the public. I > would consider this a real privacy problem compared to a public mail > address on a keyserver with no other associated private data. (sorry for the late reply, i did not see this message this morning) Well, it is up to the user what he / she publishes on keybase.io besides the public key. He / she is not forced to provide any identity via other web sites etc. Doing this is a method they have implemented as sort of another way of a web of trust, so to speak. Why do i prefer keybase.io over the old key server system? Because i am in control of my public key there, so that nobody can do funny things with my key, like it is possible with the old key servers. If people would like to sign my key they would have to provide me my signed key so that i can upload it to keybase and not like the other way the old key servers let people do, without my approval first. > The mail address is a technical necessity to send mail; mapping the > mail address to a key is a technical necessity to send encrypted > mail. So what keyservers do is to provide a directory of public keys > - in the same way as white pages of the phone systems. Nobody > requires you to enter you phone number / public key into a > directory. But if you want to receive phone calls / encrypted mails > you need to somehow publish this data. You can't remove your name > from white pages either - they used to be printed in sometimes > millions of copies. Understood, but what speaks against a (syncing) public key server system like the old pgp.com key server was, compared to the regular key servers, which don't allow deletion of a key, by the owner and if i remember correctly also only upload by the owner. As it is of now with SKS and Co. i think in 2018 such a key server model does not help for a clean database, which everybody can look up, nor does it help users to protect their keys nor deleting their keys, in case they like to do so. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From rjh at sixdemonbag.org Tue Jan 16 16:35:09 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Jan 2018 10:35:09 -0500 Subject: Remove public key from keyserver In-Reply-To: References: <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> <20180115212308.740173a7@iria.my-fqdn.de> <5A5D1970.32429.2CD9950@m.mansfeld.mansfeld-elektronik.de> Message-ID: > O.K. than it is a feature request. You also triggered something in me > with the words "which you think belongs to you". That's because you think information *does* belong to you. But information doesn't belong to anyone: the nature of information is that it has no owners. You can place restrictions on what people do with information -- maybe -- but you can't make information into a possession any more than you can declare you own mathematics. The fact an EU committee has declared otherwise strikes me as like the legend of King Canute. When his advisers told him his power was without limit, Canute took them to the ocean and let them watch as he ordered the tide to not come in. The tide came in anyway, thus proving Canute's point to his advisers -- just because they say it's so doesn't mean it's so. None of this is to say you have no privacy interest in your data, nor that our laws shouldn't facilitate you having some control over your private data. But our laws also shouldn't be written in such a way as to lead people to think they can *own* information. > If i am not mistaken you have also a keybase account Yep. > How about this; let's make "your" public key the ideal canditate for a > global trollwot session, were every GnuPG Linux user can participate > and add some funny things to "your" public key. You seem to be under the belief I don't see this as a problem. As a quick check in the archives will show you, I've been talking about this problem for at least eight years. And I know Werner's been dealing with this problem for even longer. Just because I think you understand neither the problem nor the deeply problematic aspects of your proposed fixes, does not mean I disagree there's a problem. > This would imho give you and people you talk to in conferences etc. > also a better view what i am talking about. I already know exactly what you're concerned about. I share in those concerns. I do not believe you're contributing to finding an answer to these problems. From stefan.claas at posteo.de Tue Jan 16 16:46:48 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 16 Jan 2018 16:46:48 +0100 Subject: WKD was Remove public key from keyserver In-Reply-To: <878tcyckab.fsf@wheatstone.g10code.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <878tcyckab.fsf@wheatstone.g10code.de> Message-ID: <20180116164635.75e94e3a@iria.my-fqdn.de> On Tue, 16 Jan 2018 08:52:44 +0100, Werner Koch wrote: > On Mon, 15 Jan 2018 20:21, stefan.claas at posteo.de said: > > > O.k. Werner invented WKD which solves those problems, if i'm not > > mistaken, but is it besides keybase.io widely deployed? > > Nope. The Web Key Directory solves exactly one problem: How to > initially map a mail address to a key. This directory is hosted by > the provider of the mail address because that is the only entity which > controls the mail address. O.k. thanks for the clarification! > Once this mail address has been mapped keyservers can be used to get > revocations and updates of the key. This part i do not understand... i send the rev cert or my updated key again to WKD and then i can search a regular key server for the updated key? > Unfortunately it is not yet widely supported; you can help to make it > better known. Well, i really would like to promote WKD at other places. The problem i have with posteo's WKD implementation is that their policy is pretty strict, which i personally don't like and i told them so. I would like to see a mail provider using WKD which allows the user to use his certified key. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From psusi at ubuntu.com Tue Jan 16 15:16:03 2018 From: psusi at ubuntu.com (Phil Susi) Date: Tue, 16 Jan 2018 09:16:03 -0500 Subject: "right to be forgotten" nonsense In-Reply-To: <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> Message-ID: <80d95947-7d15-c824-d935-2918f9cdd855@ubuntu.com> On 1/15/2018 10:24 PM, listo factor via Gnupg-users wrote: > If there is merit to the principle that an Internet server operator > can not keep publicly serving private data over the objections of > the owner (the same as today, after many battles, he can no longer There isn't merit. It became public, not private, the moment you published it. I have the right to free speech, the EU be damned. Are these numbnuts going to demand that libraries black out newspaper articles on microfilm because they mention someone that doesn't like the coverage of themselves? Sure, I molested children 5 years ago, but I have the "right to be forgotten" so when anyone searches for my name on the Internet they won't find out. Give me a break. From rjh at sixdemonbag.org Tue Jan 16 16:56:39 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Jan 2018 10:56:39 -0500 Subject: Remove public key from keyserver In-Reply-To: <20180116163442.0e7eca3d@iria.my-fqdn.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <878tcyckab.fsf@wheatstone.g10code.de> <20180116163442.0e7eca3d@iria.my-fqdn.de> Message-ID: <8aa790dc-d3ae-4cf8-6800-606fb4eef57d@sixdemonbag.org> > Understood, but what speaks against a (syncing) public key server > system like the old pgp.com key server was, compared to the regular > key servers, which don't allow deletion of a key, by the owner and if > i remember correctly also only upload by the owner. The pgp.com keyserver had some serious problems. When I was at PGP Security there were at least three engineers on the floor -- myself, Len Sassaman, and Randy Harmon (the keyserver admin!) -- who thought the keyserver was a pretty marginal idea specifically because we could be compelled by governments to do unpleasant things. None of us used that keyserver in our own personal lives. The pgp.com keyserver is also a *standalone* server. It does not sync with the keyserver network. (Search for 0xB44427C7, for instance. My cert has been in the SKS network for years, but as of this writing isn't in the pgp.com keyserver.) That's important for several reasons. It means it's very easy for governments to blackhole, for instance. And it also means it's possible to drop certificates. One of the other reasons SKS doesn't allow dropping information is because it lets two disagreeing keyservers figure out very easily what the canonical and correct data is: it is the union of the disparate data. As soon as you change this to allow for discarding data, suddenly each certificate needs to bear with it some way to prove to other keyservers that it's the most recent record and thus correct. Now you get into needing trusted timestamps, certifications of changes, adding crypto code into SKS, and ... things get out of hand quickly. If you like the PGP Global Directory, go for it. Use it! It still exists. But please, understand why SKS works the way it does before telling people to change it. From dkg at fifthhorseman.net Tue Jan 16 15:54:07 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 16 Jan 2018 09:54:07 -0500 Subject: a step in the right direction In-Reply-To: <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> Message-ID: <873735yhv4.fsf@fifthhorseman.net> On Mon 2018-01-15 17:45:49 -0500, Robert J. Hansen wrote: > _Literally every major FOSS package manager breaks. Updates become > impossible._ while i agree with rjh that destruction of the current SKS-based keyserver network (either by technical or legal means) would today be a net loss, this statement goes too far. the debian package manager does not directly use the keyserver network, and debian archive signing keys are themselves distributed as debian packages. the keyservers can occasionally be used as a way to find updated keys for a system that has been offline for years, to "re-bootstrap" the package manager, but dpkg and apt are certainly not reliant on the keyserver network to do their thing. Third-party repositories also do not need the keyservers to function properly, if they're configured in a sensible way: https://wiki.debian.org/DebianRepository/UseThirdParty Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue Jan 16 17:05:03 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Jan 2018 11:05:03 -0500 Subject: a step in the right direction In-Reply-To: <873735yhv4.fsf@fifthhorseman.net> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <873735yhv4.fsf@fifthhorseman.net> Message-ID: > while i agree with rjh that destruction of the current SKS-based > keyserver network (either by technical or legal means) would today be a > net loss, this statement goes too far. I welcome the correction, but I stand by my statement. Many users, particularly in corporate environments, roll their own packages and rely on the keyservers to propagate those signing keys worldwide. I know I've seen RHEL corporate networks doing this; I _believe_ I've seen Ubuntu-based corporate networks doing this. (Back in 2016 I wound up doing just this task for an RHEL network, while my officemate handled the Ubuntu machines -- I have no hands-on experience with the Ubuntu side of things, just recollections of hearing my officemate talk about them.) It is correct, though, to say official Debian packages would have minimal disruption. Thank you. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Jan 16 17:26:49 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 16 Jan 2018 17:26:49 +0100 Subject: DRM? (was: a step in the right direction) In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> Message-ID: <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> On 16/01/18 15:54, Robert J. Hansen wrote: > What Stefan and Listo want is some mechanism by which, if I have a copy > of their public key, I can be prohibited from sharing that with a > keyserver. I think that's not really the issue. You can share the key all you want, it just won't be provided to others /by/ the keyserver, that is the crux. You could of course run your own keyserver if you want it to do something different. I am in the possession of this very mail I'm typing now, yet I can't make it show up if somebody types in . That doesn't mean that the GnuPG webserver is implementing DRM to prevent me to share my own e-mail. It's basic access control when only the operator can change the website, not DRM, and cryptography is used to facilitate the access control. The mechanism to prove you are the owner of a public key is pretty much in place :-). A mechanism where you can have a signed statement saying "on 2018-01-16, I allow my key to show up on keyservers", and a signed statement saying "from 2018-04-01 on you should no longer expose this key to clients" is not DRM, IMHO, just authentication. Anybody could upload this statement to the keyserver. But it will only be cryptographically valid if *created* by the holder of the private key. I'm not saying this is the way to go. Just that I don't see it as DRM as far as I understand. This "right to be forgotten" is obviously management of restrictions on the dissemination of data. It's just not digital so far. My 2 cents, 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 rjh at sixdemonbag.org Tue Jan 16 17:42:29 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Jan 2018 11:42:29 -0500 Subject: DRM? In-Reply-To: <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> Message-ID: > The mechanism to prove you are the owner of a public key is pretty much > in place :-). A mechanism where you can have a signed statement saying > "on 2018-01-16, I allow my key to show up on keyservers" It is theoretically and practically possible to have a keyserver that honors such requests, but what many people want is *enforcement*. Not merely a voluntary system that's trivially circumventable, but some mechanism by which their public keys can be actively kept out of circulation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 17:47:45 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 17:47:45 +0100 Subject: DRM? In-Reply-To: <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> Message-ID: <3ae6a7e7-0b56-ccc1-7dff-44ce87bc8193@sumptuouscapital.com> On 01/16/2018 05:26 PM, Peter Lebbing wrote: > A mechanism where you can have a signed statement saying > "on 2018-01-16, I allow my key to show up on keyservers", and a signed > statement saying "from 2018-04-01 on you should no longer expose this > key to clients" I'm somewhat interested in hearing how this scheme would work in the case of a compromised private key. Mainly; (i) How would you distribute revocation certificates (ii) Would you trust a signature for removal of keyblock provided to the keyserver (a) after a revocation certificate has been added (b) before a revocation has been added (as measured on the specific keyserver). (iii) iff (ii)(a) and (ii)(b) differ; how would you handle a sync conflict of said data? -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "If you don't drive your business, you will be driven out of business" (B. C. Forbes) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Jan 16 18:05:54 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 16 Jan 2018 18:05:54 +0100 Subject: DRM? In-Reply-To: <3ae6a7e7-0b56-ccc1-7dff-44ce87bc8193@sumptuouscapital.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <3ae6a7e7-0b56-ccc1-7dff-44ce87bc8193@sumptuouscapital.com> Message-ID: <4a4c3456-53cd-3c00-f9c9-faf6565e854a@digitalbrains.com> On 16/01/18 17:47, Kristian Fiskerstrand wrote: > I'm somewhat interested in hearing how this scheme would work in the > case of a compromised private key. Mainly; I was merely using the description of the basics of it as a means to show how it would be access control rather than DRM. All the thorny extra issues I never even seriously considered is part of why I also said "I'm not saying this is the way to go." > (iii) iff (ii)(a) and (ii)(b) differ; how would you handle a sync > conflict of said data? Sounds really, really difficult to solve. Perhaps impossible? Since I'm not advocating implementing this in the first case, I'm not spending many computation cycles on the issue either :-). It might be there is an imperfect but acceptable solution, though. The problem with that is again litigation: "What do you mean, you can't remove me? You have a removal feature! See you in court!" Cheers, 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 peter at digitalbrains.com Tue Jan 16 18:11:52 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 16 Jan 2018 18:11:52 +0100 Subject: DRM? In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> Message-ID: <40dcae7b-485c-61f4-442d-23efe531a176@digitalbrains.com> On 16/01/18 17:42, Robert J. Hansen wrote: > [...] what many people want is *enforcement*. Now, /that/ would be DRM, I agree. I just considered "what well-configured keyservers in the keyserver pool should do" as the boundary of the problem statement. Just like a well-configured webserver will not change their homepage when a random person on the internet asks for it. Cheers, 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 kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 18:12:10 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 18:12:10 +0100 Subject: DRM? In-Reply-To: <4a4c3456-53cd-3c00-f9c9-faf6565e854a@digitalbrains.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <3ae6a7e7-0b56-ccc1-7dff-44ce87bc8193@sumptuouscapital.com> <4a4c3456-53cd-3c00-f9c9-faf6565e854a@digitalbrains.com> Message-ID: On 01/16/2018 06:05 PM, Peter Lebbing wrote: > On 16/01/18 17:47, Kristian Fiskerstrand wrote: >> I'm somewhat interested in hearing how this scheme would work in the >> case of a compromised private key. Mainly; > I was merely using the description of the basics of it as a means to > show how it would be access control rather than DRM. I'd personally agree that the whole right to be forgotten EU is talking about is a form of DRM, whereby they want individuals to be able to wipe out any trace of their historical behavior after said behavior has been published / happened, but through legal means rather than a technical restriction. Actually there are many aspects of GDPR that is quite hostile to both free speech and businesses. I would agree access control would be relevant up to the point that the information is public to begin with. in the current state EU seems to be building strongly on roots of left-wing bias and a liberal's wet dream of a society. /me goes back to re-reading the Fountainhead and dreams of a world where people have principles and take responsibility for their actions... :) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "If your kids are giving you a headache, follow the directions on the aspirin bottle, especially the part that says "keep away from children." (Neil McElroy) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gnupg at leo.gaspard.ninja Tue Jan 16 18:19:56 2018 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Tue, 16 Jan 2018 18:19:56 +0100 Subject: DRM? In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> Message-ID: <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> On 01/16/2018 05:42 PM, Robert J. Hansen wrote: >> The mechanism to prove you are the owner of a public key is pretty much >> in place :-). A mechanism where you can have a signed statement saying >> "on 2018-01-16, I allow my key to show up on keyservers" > > It is theoretically and practically possible to have a keyserver that > honors such requests, but what many people want is *enforcement*. Not > merely a voluntary system that's trivially circumventable, but some > mechanism by which their public keys can be actively kept out of > circulation. Well, if such requests were honored, this would fix the OP's answer (ie. ?how do I hide the fact I mistakenly associated two unrelated UIDs on my key?, if I understood correctly), as well as requests pertaining to the EU's ?right to be forgotten? (modulo people who would have lost their private key and still claim this right, but I guess the extraordinary measures taken for the last time it was invoked would still be possible). So that's at least a good part of the current problem solved, I think -- though obviously nothing close to the nightmare scenario or people wanting to DRM their keys. Also, there are flaws with this approach (like after a private key compromise, it would allow to prevent dissemination of the revocation certificate) [1], but fixes like allowing the statement to be ?on 2018-04-01, please expose only the master key and its revocation certificate(s) to clients? would likely handle this particular issue. All I'm saying is that a system like this one is not a silver bullet solution, but may handle a few of the current complaints against the SKS network? [1] It looks like Kristian has written more about it during my typing this mail if I can guess from Peter's answer, though Kristian's mail didn't land in my mailbox yet. From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 18:33:19 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 18:33:19 +0100 Subject: DRM? In-Reply-To: <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> Message-ID: <055c362f-750a-8640-90a5-6ff946922333@sumptuouscapital.com> On 01/16/2018 06:19 PM, Leo Gaspard wrote: > Also, there are flaws with this approach (like after a private key > compromise, it would allow to prevent dissemination of the revocation > certificate) [1], but fixes like allowing the statement to be ?on > 2018-04-01, please expose only the master key and its revocation > certificate(s) to clients? would likely handle this particular issue. > > All I'm saying is that a system like this one is not a silver bullet > solution, but may handle a few of the current complaints against the SKS > network? Not really (and that is ignoring disagreement with the complaints to begin with). One issue with the first statement "please allow to be on keyserver" is that it doesn't provide any verification that the email in UID (or just the name) is accurate, so most of the complains regarding occurrence of multiple matches for a search would not be honored, as you could anyways create multiple keyblocks with this property. To answer that request for feature, you need to make the keyserver a de-facto CA instead of separating the roles, and performing some ID verification at upload point, for email this might be a simple robot-signing, but email addresses changes over time, and a key might be relevant even after changing email providers to verify historical signatures etc. But for OpenPGP this isn't an issue to begin with. No keyblock should be used without first verifying the material, which historically is mostly done through fingerprint exchanges / key signing parties. If wanting to introduce a CA in the system, nothing is stopping you, and you will find some discussion on robo-signers etc e.g at [0], but it doesn't require any changes on the keyserver side, exactly because that is just a data store and distribution point without any other responsibility. Obviously the same goes for a TOFU model and WKD, which still can use the keyserver network as distribution point for updates of expirations/revocations/etc... References: [0] https://wiki.gnupg.org/OpenPGPEmailSummit201512/EmailValidation?action=AttachFile&do=get&target=EmailValidation20151207.pdf -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Aut dosce, aut disce, aut discede Either teach, or study, or leave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Tue Jan 16 19:05:49 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 16 Jan 2018 18:05:49 +0000 Subject: DRM? In-Reply-To: <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> Message-ID: <649d3cf6-ddbf-6643-f012-360e1d479456@andrewg.com> On 16/01/18 17:19, Leo Gaspard wrote: > Well, if such requests were honored, this would fix the OP's answer (ie. > ?how do I hide the fact I mistakenly associated two unrelated UIDs on my > key?, if I understood correctly), as well as requests pertaining to the > EU's ?right to be forgotten? The right to be forgotten is not absolute. For example, it does not require that published news be unpublished, although it does sometimes ask that published news not show up in search results. It also does not require that search engine operators scrub their internal databases. It is technically difficult to prevent keys from being propagated because altering or deleting data packets breaks the assumptions upon which the reconciliation algorithm is founded. But there is nothing to stop individual servers from scrubbing search results of keys that have a valid "nopublish cert" (however this may be technically implemented). This would not affect SKS reconciliation and would reduce the computational overhead. IF something like this were to be implemented, then only searches for IDs should be stripped. Searches on fingerprints should always return data, in order to ensure that revocation certificates are still distributed. "Nopublish" certs could also be used by well-behaved clients as a guard against accidental disclosure, even if preventing malicious disclosure is technically impossible. If we were worried about the *legal* implications of right to be forgotten, then this could be a defensible fallback position. But it is not a solution to many of the *practical* problems in privacy protection. Ultimately, the PGP ecosystem prioritises security over privacy. They are not the same thing, and in some cases they are in conflict. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Tue Jan 16 19:12:11 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 16 Jan 2018 18:12:11 +0000 Subject: DRM? In-Reply-To: <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> Message-ID: <7ac8eb83-1dae-a0fb-c65d-b0dbe1dc6a36@andrewg.com> On 16/01/18 17:19, Leo Gaspard wrote: > ?on 2018-04-01, please expose only the master key and its revocation > certificate(s) to clients? IF you wanted to go this route, it would be easier for keyservers to only serve the master key + revocation cert for *all* cases where a revocation cert exists. What does it matter who signed a key that has been revoked, or what IDs it used to be tied to? It's dead, throw it away. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 19:15:45 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 19:15:45 +0100 Subject: DRM? In-Reply-To: <7ac8eb83-1dae-a0fb-c65d-b0dbe1dc6a36@andrewg.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> <7ac8eb83-1dae-a0fb-c65d-b0dbe1dc6a36@andrewg.com> Message-ID: <9b052599-5d6b-bbe9-49dd-37e1948b9564@sumptuouscapital.com> On 01/16/2018 07:12 PM, Andrew Gallagher wrote: > On 16/01/18 17:19, Leo Gaspard wrote: >> ?on 2018-04-01, please expose only the master key and its revocation >> certificate(s) to clients? > > IF you wanted to go this route, it would be easier for keyservers to > only serve the master key + revocation cert for *all* cases where a > revocation cert exists. What does it matter who signed a key that has > been revoked, or what IDs it used to be tied to? It's dead, throw it away. The important thing would actually be that the data is retained in the database, as that wouldn't break sync. Aside from that the keyservers would have to implement cryptography and verify that the revocation certificate is accurate, this is within the scope of feasibility, although wouldn't do anything one way or the other with regards to security. Whether it would help privacy is also a questionable matter, as the full data store is downloadable, so anyone can download it containing the data wanting to be hidden. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest." (Confucius) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gnupg at leo.gaspard.ninja Tue Jan 16 19:17:58 2018 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Tue, 16 Jan 2018 19:17:58 +0100 Subject: DRM? In-Reply-To: <055c362f-750a-8640-90a5-6ff946922333@sumptuouscapital.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> <055c362f-750a-8640-90a5-6ff946922333@sumptuouscapital.com> Message-ID: On 01/16/2018 06:33 PM, Kristian Fiskerstrand wrote: > On 01/16/2018 06:19 PM, Leo Gaspard wrote: >> Also, there are flaws with this approach (like after a private key >> compromise, it would allow to prevent dissemination of the revocation >> certificate) [1], but fixes like allowing the statement to be ?on >> 2018-04-01, please expose only the master key and its revocation >> certificate(s) to clients? would likely handle this particular issue. >> >> All I'm saying is that a system like this one is not a silver bullet >> solution, but may handle a few of the current complaints against the SKS >> network? > > Not really (and that is ignoring disagreement with the complaints to > begin with). > > One issue with the first statement "please allow to be on keyserver" is > that it doesn't provide any verification that the email in UID (or just > the name) is accurate, so most of the complains regarding occurrence of > multiple matches for a search would not be honored, as you could anyways > create multiple keyblocks with this property. Hmm, I was thinking only about de-listing information someone inadvertently made public, not about having the keyservers become CAs (which I don't think should happen, even though from a UI perspective it's easier when things are centralized). I must say I basically took only the ?please delist me? signature packet into account in my answer, not the ?please list me?, as I don't think it would bring large improvements. That said, thanks for the link! Just curious, I never saw information about this in enigmail, do you know whether it has been implemented yet? From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 19:23:33 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 19:23:33 +0100 Subject: DRM? In-Reply-To: References: <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> <055c362f-750a-8640-90a5-6ff946922333@sumptuouscapital.com> Message-ID: <33ecb114-95dc-d69c-7a58-8b6889c385c4@sumptuouscapital.com> On 01/16/2018 07:17 PM, Leo Gaspard wrote: > That said, thanks for the link! Just curious, I never saw information > about this in enigmail, do you know whether it has been implemented yet? First and foremost you'd have to establish the robot-ca with an API of some sort. I'm not aware of any production rollout, although I believe a proof of concept was written based on it for a thesis. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "A government that robs Peter to pay Paul can always depend on the support of Paul." (George Bernard Shaw) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jan 16 19:36:30 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Jan 2018 19:36:30 +0100 Subject: Remove public key from keyserver In-Reply-To: <20180116163442.0e7eca3d@iria.my-fqdn.de> (Stefan Claas's message of "Tue, 16 Jan 2018 16:34:57 +0100") References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <878tcyckab.fsf@wheatstone.g10code.de> <20180116163442.0e7eca3d@iria.my-fqdn.de> Message-ID: <87h8rlbqhd.fsf@wheatstone.g10code.de> On Tue, 16 Jan 2018 16:34, stefan.claas at posteo.de said: > the public key. He / she is not forced to provide any identity via other > web sites etc. Doing this is a method they have implemented as sort I know, but keybase.io's goal is (or was, back when I tested it) to use those connections to somehow prove an identity. It is a neat idea for the facebook generation. Privacy is something different. > Why do i prefer keybase.io over the old key server system? Because > i am in control of my public key there, so that nobody can do funny They are in control of your key - not you. You can ask them to do something without key but in the end the owners of this service decide what they allow you to do and what key they want to publish or stop publishing. Or to shutdown their service. Compare that to the keyservers: They have been around for 25 years and you can still find all keys ever uploaded there (I am not sure whether PGP 2.3 keys are still supported, though). There is no single entity controlling this network. > Understood, but what speaks against a (syncing) public key server > system like the old pgp.com key server was, compared to the regular As Robert already noted: The pgp.com keyserver was a single database under the control of one entity which did for technical reasons not syncing with the keyserver network. IIRC, in the early days Randy sometimes uploaded keys to the keyserver network but never imported keys. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Tue Jan 16 19:50:45 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 16 Jan 2018 18:50:45 +0000 Subject: DRM? In-Reply-To: <9b052599-5d6b-bbe9-49dd-37e1948b9564@sumptuouscapital.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> <7ac8eb83-1dae-a0fb-c65d-b0dbe1dc6a36@andrewg.com> <9b052599-5d6b-bbe9-49dd-37e1948b9564@sumptuousc apital.com> Message-ID: > On 16 Jan 2018, at 18:15, Kristian Fiskerstrand wrote: > >> On 01/16/2018 07:12 PM, Andrew Gallagher wrote: >>> On 16/01/18 17:19, Leo Gaspard wrote: >>> ?on 2018-04-01, please expose only the master key and its revocation >>> certificate(s) to clients? >> >> IF you wanted to go this route, it would be easier for keyservers to >> only serve the master key + revocation cert for *all* cases where a >> revocation cert exists. What does it matter who signed a key that has >> been revoked, or what IDs it used to be tied to? It's dead, throw it away. > > The important thing would actually be that the data is retained in the > database, as that wouldn't break sync. Yes, absolutely. This would be a presentational fix. It would also be a method of giving people a way around right to be forgotten - revoke your cert and your info becomes more or less unsearchable. > this is within the scope of feasibility, > although wouldn't do anything one way or the other with regards to > security. Whether it would help privacy is also a questionable matter, > as the full data store is downloadable, so anyone can download it > containing the data wanting to be hidden. Agreed. I was thinking more along the lines of having some method of causing signature vandalism to expire. A From wk at gnupg.org Tue Jan 16 19:51:17 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Jan 2018 19:51:17 +0100 Subject: WKD was Remove public key from keyserver In-Reply-To: <20180116164635.75e94e3a@iria.my-fqdn.de> (Stefan Claas's message of "Tue, 16 Jan 2018 16:46:48 +0100") References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <878tcyckab.fsf@wheatstone.g10code.de> <20180116164635.75e94e3a@iria.my-fqdn.de> Message-ID: <87d129bpsq.fsf@wheatstone.g10code.de> On Tue, 16 Jan 2018 16:46, stefan.claas at posteo.de said: > This part i do not understand... i send the rev cert or my updated key > again to WKD and then i can search a regular key server for the updated A revoked key does not make sense in the WKD. Either the key exists and proves that this is the intended key for the mail address or it does not exist. There is no real revocation service. However, I would suggest to also upload the key to the keyservers so that it is easy to get revocation certificates and new subkeys from an independent party - no need to rely for this on the mail provider. We definitely want to refine some things there but that requires a wider deployment. > i have with posteo's WKD implementation is that their policy is pretty > strict, which i personally don't like and i told them so. I would like Posteo does only allows the mail address (addr-spec) and no real name in the key for data protection reasons. Thus a $ wget -O- posteo.de/.well-known/openpgpkey/policy 2>/dev/null # Policy for draft-koch-openpgp-webkey-service-04 mailbox-only auth-submit shows this policy flag. If you upload your key using a tool employing gpg-wks-client (e.g. Kmail or Enigmail) this policy will be detected and if a plain addr-spec only user0id does not exists a new user-id will be created and sent to posteo. The real problem with Posteo is that they use invalid certificates for all but the posteo.de domain. Thus my posteo.net account does not work because they redirect to posteo.de but do not include posteo.net in the certificate for the initial access to posteo.net. Bummer. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 20:08:08 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 20:08:08 +0100 Subject: DRM? In-Reply-To: References: <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> <7ac8eb83-1dae-a0fb-c65d-b0dbe1dc6a36@andrewg.com> <9b052599-5d6b-bbe9-49dd-37e1948b9564@sumptuousc apital.com> Message-ID: <13d06b1d-8697-ae84-dcfa-135bfef83d0a@sumptuouscapital.com> On 01/16/2018 07:50 PM, Andrew Gallagher wrote: > Agreed. I was thinking more along the lines of having some method of > causing signature vandalism to expire. They don't really constitute an issue either for security or privacy, though. If looking at keyserver directly (which you really shouldn't do, your client will filter unknown keys and actually verify the rest) you will see all kinds of interesting things like the Christmas present of ["funny sks"] on my keyblock some years ago. But it doesn't constitute an *issue* when OpenPGP is used correctly. References: ["funny sks"] https://sks-keyservers.net/pks/lookup?op=vindex&search=0x94CBAFDD30345109561835AA0B7F8B60E3EDFAE3 -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "A committee is a group that keeps minutes and loses hours." (Milton Berle) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Tue Jan 16 20:37:59 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 16 Jan 2018 20:37:59 +0100 Subject: Remove public key from keyserver In-Reply-To: <87h8rlbqhd.fsf@wheatstone.g10code.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <878tcyckab.fsf@wheatstone.g10code.de> <20180116163442.0e7eca3d@iria.my-fqdn.de> <87h8rlbqhd.fsf@wheatstone.g10code.de> Message-ID: <20180116203759.6f0955ae@iria.my-fqdn.de> On Tue, 16 Jan 2018 19:36:30 +0100, Werner Koch wrote: > On Tue, 16 Jan 2018 16:34, stefan.claas at posteo.de said: > > > the public key. He / she is not forced to provide any identity via > > other web sites etc. Doing this is a method they have implemented > > as sort > > I know, but keybase.io's goal is (or was, back when I tested it) to > use those connections to somehow prove an identity. It is a neat > idea for the facebook generation. Privacy is something different. Agreed. But the word privacy would then also mean to me that users who uploaded their public keys on key servers would not reveal that they know each other as shown with their signatures, which the classical WoT somehow requires, instead of using local sigs. > > Why do i prefer keybase.io over the old key server system? Because > > i am in control of my public key there, so that nobody can do > > funny > > They are in control of your key - not you. You can ask them to do > something without key but in the end the owners of this service decide > what they allow you to do and what key they want to publish or stop > publishing. Or to shutdown their service. > > Compare that to the keyservers: They have been around for 25 years and > you can still find all keys ever uploaded there (I am not sure whether > PGP 2.3 keys are still supported, though). There is no single entity > controlling this network. To me this seems to be the only advantage that the network can't be controlled. If IMHO key removal by the owner and upload only by the owner could be implemented in the future than that would pretty nice. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From stefan.claas at posteo.de Tue Jan 16 20:41:42 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 16 Jan 2018 20:41:42 +0100 Subject: WKD was Remove public key from keyserver In-Reply-To: <87d129bpsq.fsf@wheatstone.g10code.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <878tcyckab.fsf@wheatstone.g10code.de> <20180116164635.75e94e3a@iria.my-fqdn.de> <87d129bpsq.fsf@wheatstone.g10code.de> Message-ID: <20180116204142.33421640@iria.my-fqdn.de> On Tue, 16 Jan 2018 19:51:17 +0100, Werner Koch wrote: > We definitely want to refine some things there but that requires a > wider deployment. I will for sure follow the WKD development and hope that also more mail providers will offer a WKD service. > > i have with posteo's WKD implementation is that their policy is > > pretty strict, which i personally don't like and i told them so. I > > would like > > Posteo does only allows the mail address (addr-spec) and no real name > in the key for data protection reasons. Thus a > > $ wget -O- posteo.de/.well-known/openpgpkey/policy 2>/dev/null > # Policy for draft-koch-openpgp-webkey-service-04 > mailbox-only > auth-submit > > shows this policy flag. If you upload your key using a tool employing > gpg-wks-client (e.g. Kmail or Enigmail) this policy will be detected > and if a plain addr-spec only user0id does not exists a new user-id > will be created and sent to posteo. > > The real problem with Posteo is that they use invalid certificates for > all but the posteo.de domain. Thus my posteo.net account does not > work because they redirect to posteo.de but do not include posteo.net > in the certificate for the initial access to posteo.net. Bummer. Thanks for the information, much appreciated! Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From james.cutler at consultant.com Tue Jan 16 19:57:54 2018 From: james.cutler at consultant.com (James R Cutler) Date: Tue, 16 Jan 2018 13:57:54 -0500 Subject: DRM? In-Reply-To: <33ecb114-95dc-d69c-7a58-8b6889c385c4@sumptuouscapital.com> References: <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> <055c362f-750a-8640-90a5-6ff946922333@sumptuouscapital.com> <33ecb114-95dc-d69c-7a58-8b6889c385c4@sumptuouscapital.com> Message-ID: Can anyone explain in the context of this discussion just what ?public? in ?public key? is supposed to mean explicitly and implicitly? James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 21:23:36 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 21:23:36 +0100 Subject: DRM? In-Reply-To: References: <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> <055c362f-750a-8640-90a5-6ff946922333@sumptuouscapital.com> <33ecb114-95dc-d69c-7a58-8b6889c385c4@sumptuouscapital.com> Message-ID: <88988391-e7f5-8bfa-8d86-db1f2c74c57b@sumptuouscapital.com> On 01/16/2018 07:57 PM, James R Cutler wrote: > Can anyone explain in the context of this discussion just what ?public? > in ?public key? is supposed to mean explicitly and implicitly? The public keyblock as explained in RFC4880? NB: I'm using the term keyblock rather than public key as to not mix protocol specific metadata and cryptographic matters. The public keyblock contains more data than the public key, including UID/UATs and subkeys that are on their own consisting of multiple public keys in a cryptographic context. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Vincit qui se vincit He who conquers conquers self -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Jan 16 21:38:20 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Jan 2018 15:38:20 -0500 Subject: DRM? In-Reply-To: References: <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> <055c362f-750a-8640-90a5-6ff946922333@sumptuouscapital.com> <33ecb114-95dc-d69c-7a58-8b6889c385c4@sumptuouscapital.com> Message-ID: > Can anyone explain in the context of this discussion just what ?public? > in ?public key? is supposed to mean explicitly and implicitly? Public: it may be shared freely with the world. Private: it must not be shared freely with the world. (Fundamentally you're right, in that what Stefan et. al. are asking for is for public certificates to become private certificates.) From duane at nofroth.com Tue Jan 16 20:21:09 2018 From: duane at nofroth.com (Duane Whitty) Date: Tue, 16 Jan 2018 15:21:09 -0400 Subject: a step in the right direction In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> Message-ID: <414688c2-071d-a362-ca63-40461b790be8@nofroth.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 18-01-16 10:54 AM, Robert J. Hansen wrote: >> (Oh, by the way, usually when I talk about DRM, I'm talking about >> giving somebody data but restricting the ways in which they can >> use that data. It's not clear to me how DRM applies when you want >> to simply not give data at all, to anybody. But this is not >> really pertinent to the discussion, so never mind.) > > I was the one who brought up DRM. > > What Stefan and Listo want is some mechanism by which, if I have a > copy of their public key, I can be prohibited from sharing that > with a keyserver. How I get to use data in my possession is > controlled by a third party -- that's DRM. In this case it's a > voluntary, half-assed DRM scheme, but it's still in the family of > DRM schemes. > > > > > _______________________________________________ Gnupg-users mailing > list Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Maybe something akin to patent law here would work better than a technological solution. Once you share something it is public unless you force the the receiving party to sign a non-disclosure document. Once you share your public key with even one person it is in the public domain. If you want to make it painful enough to prevent this from happening have the receiving party sign a contract of non-disclosure which stipulates what the penalties will be if the break the contract. Just my two cents and I'm sure it doesn't cover everything. Best Regards, Duane - -- Duane Whitty duane at nofroth.com -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaXlCfAAoJEOJfpr8UVxtkwgsH/3V+ZCc839yIENQDgp/Z7/Yj 3TVRRw/ELswj9emAebtIMiY5EYvQp3zhL71sTnXq8+ez0k2oc68ow4oxnwpl+9K1 psQiPVm45ouQlBlS9YJ6O8KBQRFARmP3fDt+JAwQ9a/PJRfqefdk93gVM89T+9VM V6NzkR9ktyokNmKhKi48oVXIVw2XX2DG2fuspI2QwZLqtt0PxmGdDuyiWmFZKigW mWU3evTAkzQtslsppVNenJjZjrz7XIqt/xq/CEf/PgfreeY+g7chm+fzpdvSuTMu 9hJWOkXBTx+W40/5GbLyzpSYlKcUyu8evrN8Z9Uo5CtX0E+c30cCQ0auLkPKV8o= =KRTM -----END PGP SIGNATURE----- From m.mansfeld at mansfeld-elektronik.de Tue Jan 16 22:33:47 2018 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Tue, 16 Jan 2018 22:33:47 +0100 Subject: DRM? In-Reply-To: <13d06b1d-8697-ae84-dcfa-135bfef83d0a@sumptuouscapital.com> References: , , <13d06b1d-8697-ae84-dcfa-135bfef83d0a@sumptuouscapital.com> Message-ID: <5A5E6FBB.2820.806ADA6@m.mansfeld.mansfeld-elektronik.de> On 16 Jan 2018 at 20:08, Kristian Fiskerstrand wrote: > On 01/16/2018 07:50 PM, Andrew Gallagher wrote: > > Agreed. I was thinking more along the lines of having some method of > > causing signature vandalism to expire. > > They don't really constitute an issue either for security or privacy, > though. They DO, if unwanted or rashly made signatures on pubkeys disclose connections between people, groups etc.. Regards Matthias -- OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 22:37:23 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 22:37:23 +0100 Subject: Remove public key from keyserver In-Reply-To: <20180116203759.6f0955ae@iria.my-fqdn.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <878tcyckab.fsf@wheatstone.g10code.de> <20180116163442.0e7eca3d@iria.my-fqdn.de> <87h8rlbqhd.fsf@wheatstone.g10code.de> <20180116203759.6f0955ae@iria.my-fqdn.de> Message-ID: <3df795d2-64fa-d391-7028-eea9745c1e0a@sumptuouscapital.com> On 01/16/2018 08:37 PM, Stefan Claas wrote: >> I know, but keybase.io's goal is (or was, back when I tested it) to >> use those connections to somehow prove an identity. It is a neat >> idea for the facebook generation. Privacy is something different. > Agreed. But the word privacy would then also mean to me that > users who uploaded their public keys on key servers would not > reveal that they know each other as shown with their signatures, > which the classical WoT somehow requires, instead of using local sigs. > A distinction need to be made here, "know each other" actually means ever having confidence that the public keyblock belongs to that person. That doesn't imply a very deep relationship except for having met at one point to exchange information. You don't really attribute anything except possibly having looked at a governmental issued ID at some point. But yes, this comes back to security != privacy -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- qui tacet consentire videtur He who is silent is taken to agree -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 22:41:01 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 22:41:01 +0100 Subject: Remove public key from keyserver In-Reply-To: <39570449-d3f1-023e-546a-abd212635cf8@posteo.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> <20180115212308.740173a7@iria.my-fqdn.de> <6fe6a651-b901-f9cd-57e9-2a6105a2a9ac@sumptuouscapital.com> <39570449-d3f1-023e-546a-abd212635cf8@posteo.de> Message-ID: <9ed0b7f7-cde5-39ac-e2b3-a46f4446b9b2@sumptuouscapital.com> On 01/16/2018 11:40 AM, Stefan Claas wrote: > Am 16.01.2018 um 11:12 schrieb Kristian Fiskerstrand: > >> On 01/15/2018 09:23 PM, Stefan Claas wrote: >>> No? I for one would like to be sure that i am the only person who >>> can upload my public key to a key server directory. >> This seems to be based on a misconception whereby you're attributing >> properties of a certificate authority to the keyservers. OpenPGP already >> has a method for certification from CAs, and that is by providing a >> signature on the appropriate UID on the public keyblock. As long as the >> signature is propagated on the keyserver network, these roles can be >> appropriately isolated and the decision of whether or not to trust a >> specific CA is left to the user performing the trust calculation, >> incidentally also allowing for signatures from multiple CAs. >> > I'm not sure what you are talking about, a language barrier from my > side,sorry. > > The CA in Germany (Governikus) i have used sends me my certified key > back to my > email address and does not publish my pub key on key servers. I'm not sure how to put it more clearly, but this seems to bring the discussion into very specific territory. OpenPGP as a specification handles this nicely, and whether a CA signature is published publicly or not doesn't change the modus operandus. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "The best way to predict the future is to invent it" (Alan Kay) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 22:45:37 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 22:45:37 +0100 Subject: DRM? In-Reply-To: <5A5E6FBB.2820.806ADA6@m.mansfeld.mansfeld-elektronik.de> References: <13d06b1d-8697-ae84-dcfa-135bfef83d0a@sumptuouscapital.com> <5A5E6FBB.2820.806ADA6@m.mansfeld.mansfeld-elektronik.de> Message-ID: <292ec30d-d6ed-f73e-36ae-8da16bff7c61@sumptuouscapital.com> On 01/16/2018 10:33 PM, Matthias Mansfeld wrote: > On 16 Jan 2018 at 20:08, Kristian Fiskerstrand wrote: > >> On 01/16/2018 07:50 PM, Andrew Gallagher wrote: >>> Agreed. I was thinking more along the lines of having some method of >>> causing signature vandalism to expire. >> They don't really constitute an issue either for security or privacy, >> though. > They DO, if unwanted or rashly made signatures on pubkeys disclose > connections between people, groups etc.. by "vandalism", I'm taking trollwot cases into account, which doesn't affect anything to the extent it is DoS-able. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Happiness in intelligent people is the rarest thing I know." (Ernest Hemingway) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Jan 16 19:40:36 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 16 Jan 2018 13:40:36 -0500 Subject: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction] In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> Message-ID: <87zi5dwst7.fsf@fifthhorseman.net> On Tue 2018-01-16 01:02:11 +0000, listo factor via Gnupg-users wrote: > Burning it down is not what I was advocating. I am advocating orderly > evacuation and replacement of a system that has clearly outlived its > usefulnesses. If it is not replaced in time, it will, at some point, > burn ignited by forces we have no control over. ~Then~ it will have > to be abandoned in rather more painful manner - just as you are > alluding to. While i think we disagree on "has outlived its usefulnesses", i would agree that planning and preparing for catastrophic keyserver network failure is a good idea. What i haven't seen in this thread is a list of the variety of proposals for OpenPGP key distribution that do *not* require the global append-only keyserver network. So in the hopes of making this a productive discussion, i'll list a few. Already briefly mentioned are: * Web Key Directory (WKD) Mail provider publishes public keys of users via https to a well-known location. https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-05 * Keybase social media and other avenues for key publication, identification, and corroboration. https://keybase.io A few other approaches are: * DNS OPENPGPKEY records DNS lookups of public keys (or hashes of public keys for confirmation) https://tools.ietf.org/html/rfc7929 * Autocrypt In-band key exchange (in every e-mail message) removes the need for external distribution mechanisms for all messages but the first. https://autocrypt.org/ * VVV DNS (SRV) discovery of HKP service operated by the mail provider. https://keys4all.de/media/beschreibung-vvv-loesung.pdf I'm sure i've missed some other distribution/verification/update mechanism, and would be happy to see constructive pointers. Of the above, i'm most leaning toward Autocrypt today, because it does not require involvement of any third party -- as long as both sides of the e-mail use an autocrypt-capable client, there is no additional information leakage. Note that the different schemes have different properties in terms of: * information leakage * cryptographic verification * third-party control * censorship * ... The keyserver network (or some future variant of it) can of course play a role in parallel to any or all of these. for example, keyservers are particularly well-situated to offer key revocation, updates to expiry, and subkey rotation, none of which would necessarily involve names or e-mail addresses. It would be interesting to see a network of keyserver operators that: (a) did cryptographic verification, and rejected packets that could not be verified (also: required cryptographic verifications of cross-signatures for signing-capable subkeys) (b) rejected all User IDs and User Attributes and certifications over those components (c) rejected all third-party certifications -- so data attached to a given primary key is only accepted when certified by that primary key. This would basically be a network that facilitates update/revocation/key-rotation, without exposing any names or e-mail addresses to the public by default; it could be run in parallel with the existing keyserver network. i don't know how well we could bridge the two networks, though and it'd be a shame to have to upload updated keys to both networks manually. :/ anyway, hopefully this gives some concrete, positive next steps that folks who want the keyserver network to go away can take, rather than trying to burn it all down :) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 16 22:56:58 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Jan 2018 22:56:58 +0100 Subject: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction] In-Reply-To: <87zi5dwst7.fsf@fifthhorseman.net> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <87zi5dwst7.fsf@fifthhorseman.net> Message-ID: <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote: > The keyserver network (or some future variant of it) can of course play > a role in parallel to any or all of these. for example, keyservers are > particularly well-situated to offer key revocation, updates to expiry, > and subkey rotation, none of which would necessarily involve names or > e-mail addresses. > > It would be interesting to see a network of keyserver operators that: > > (a) did cryptographic verification, and rejected packets that could not > be verified (also: required cryptographic verifications of > cross-signatures for signing-capable subkeys) > > (b) rejected all User IDs and User Attributes and certifications over > those components > > (c) rejected all third-party certifications -- so data attached to a > given primary key is only accepted when certified by that primary > key. > thanks for this post Daniel, my primary question would be what advantage is gained by this verification being done by an arbitrary third party rather by a trusted client running locally, which is the current modus operandus. Any keyserver action doing this would just shift responsibilities to a third party for something better served (and already happens) locally. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Bene diagnoscitur, bene curatur Something that is well diagnosed can be cured well -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gnupg at leo.gaspard.ninja Tue Jan 16 23:26:57 2018 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Tue, 16 Jan 2018 23:26:57 +0100 Subject: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction] In-Reply-To: <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <87zi5dwst7.fsf@fifthhorseman.net> <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> Message-ID: <9b8c2cf8-db5b-09cc-985f-0dc00eede2ef@gaspard.io> On 01/16/2018 10:56 PM, Kristian Fiskerstrand wrote: > On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote: > >> The keyserver network (or some future variant of it) can of course play >> a role in parallel to any or all of these. for example, keyservers are >> particularly well-situated to offer key revocation, updates to expiry, >> and subkey rotation, none of which would necessarily involve names or >> e-mail addresses. >> >> It would be interesting to see a network of keyserver operators that: >> >> (a) did cryptographic verification, and rejected packets that could not >> be verified (also: required cryptographic verifications of >> cross-signatures for signing-capable subkeys) >> >> (b) rejected all User IDs and User Attributes and certifications over >> those components >> >> (c) rejected all third-party certifications -- so data attached to a >> given primary key is only accepted when certified by that primary >> key. >> > > thanks for this post Daniel, my primary question would be what advantage > is gained by this verification being done by an arbitrary third party > rather by a trusted client running locally, which is the current modus > operandus. Any keyserver action doing this would just shift > responsibilities to a third party for something better served (and > already happens) locally. I guess one argument could be ?when lazy people use the keyserver network, they likely get not-too-bad data?. I seem to remember that when a keyserver returned multiple keys to GnuPG, GnuPG imported both, even when searching for a fingerprint and the fingerprint didn't match, at some point in the last few years? If even GnuPG can fail at properly sanitizing the data received by keyservers (and I hope I'm not mistaken in this memory), I guess having such keyservers only serve curated data when used in their ?nominal? use could help a bit. It could also help limit the impact of the nightmare scenario RJH has described, by making sure all the data is ?cryptographically valid and matching?, thus making it harder to just propagate arbitrary data down the network. Then I don't have the structure of an OpenPGP key in mind, so maybe this would not work due to fields in the key that could be set to arbitrary data anyways From vedaal at nym.hush.com Tue Jan 16 22:24:53 2018 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 16 Jan 2018 16:24:53 -0500 Subject: DRM Message-ID: <20180116212454.74F65C054F@smtp.hushmail.com> Robert J. Hansen rjh at sixdemonbag.org wrote on Tue Jan 16 17:42:29 CET 2018 : ... >> The mechanism to prove you are the owner of a public key is pretty much >> in place :-). A mechanism where you can have a signed statement saying >> "on 2018-01-16, I allow my key to show up on keyservers" >It is theoretically and practically possible to have a keyserver that >honors such requests, but what many people want is *enforcement*. Not >merely a voluntary system that's trivially circumventable, but some >mechanism by which their public keys can be actively kept out of >circulation. ===== It could be done automatically by the keyservers if they wanted to, and if they made it that *the only way* a Public key can be uploaded to that keyserver, if it were accompanied by a signed statement by that key, stating " I allow my key to show up on keyservers". Ideally, if this could be done by gnupg by editing the key, much the same as editing an e-mail address, it would streamline the process; i.e. something like this: gpg --edit-key foo ... Secret key is available. ... [ultimate] (1). foo gpg> --allow-keyserver-publication gpg: This requires you to sign that you allow keyserver publication of your key, and will be added as a comment to your key. Do you really want to do this? Y/N gpg: Please enter passphrase to sign gpg; your key now has a comment "Keyserver Publication Allowed" gpg: you may upload this key to any participating keyserver or something along those lines, assuming that keyservers will abide by this and require this 'comment' before accepting a key vedaal From andrewg at andrewg.com Wed Jan 17 02:09:43 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Jan 2018 01:09:43 +0000 Subject: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction] In-Reply-To: <9b8c2cf8-db5b-09cc-985f-0dc00eede2ef@gaspard.io> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <87zi5dwst7.fsf@fifthhorseman.net> <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> <9b8c2cf8-db5b-09cc-985f-0dc00eede2ef@gaspard.io> Message-ID: <9568C38B-3E9B-44A3-8509-19AF4328CB9F@andrewg.com> > On 16 Jan 2018, at 22:26, Leo Gaspard wrote: > > It could also help limit the impact of the nightmare scenario RJH has > described, by making sure all the data is ?cryptographically valid and > matching?, thus making it harder to just propagate arbitrary data down > the network. It would make it *very* slightly more computationally expensive to pull off, but would not limit the impact one bit. A From dkg at fifthhorseman.net Wed Jan 17 01:20:49 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 16 Jan 2018 19:20:49 -0500 Subject: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction] In-Reply-To: <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <87zi5dwst7.fsf@fifthhorseman.net> <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> Message-ID: <87efmpwd26.fsf@fifthhorseman.net> On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote: > thanks for this post Daniel, my primary question would be what advantage > is gained by this verification being done by an arbitrary third party > rather by a trusted client running locally, which is the current modus > operandus. Any keyserver action doing this would just shift > responsibilities to a third party for something better served (and > already happens) locally. the advantage is spam-abatement -- the keyservers have to keep track of what is attached to each blob they transport/persist. if all signatures that they transport for a given blob are cryptographically certified, then only the original uploader of that blob can make assertions about it; other people can't spam the blob to make it untransportable. --dkg From listofactor at mail.ru Wed Jan 17 03:47:16 2018 From: listofactor at mail.ru (listo factor) Date: Wed, 17 Jan 2018 02:47:16 +0000 Subject: Privacy vs. security In-Reply-To: <649d3cf6-ddbf-6643-f012-360e1d479456@andrewg.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> <649d3cf6-ddbf-6643-f012-360e1d479456@andrewg.com> Message-ID: On 01/16/2018 06:05 PM, Andrew Gallagher - andrewg at andrewg.com wrote: > > Ultimately, the PGP ecosystem prioritises security over privacy. They > are not the same thing, and in some cases they are in conflict. > Somewhat of a generalization, but essentially correct. More precisely - if I may - it's point of balance between the privacy and security represents our thinking about the relative importance of these two categories at the time the system was conceived, decades ago. Since that time, our view about the importance of security has changed very little. Our view about the importance and desirability of privacy has changed a whole lot. Consequently, it is time to re-examine the point of balance between the two. From dank at kegel.com Wed Jan 17 01:26:49 2018 From: dank at kegel.com (Dan Kegel) Date: Tue, 16 Jan 2018 16:26:49 -0800 Subject: Will gpg 1.x remain supported for the foreseeable future? Message-ID: Hey all, I'm starting to suspect that using version 2.x of gnupg is simply not a good idea when writing shell scripts that have to run unattended and not touch system keychains or agents. I worked hard to jump through hoops to use version 2 in such an environment, but then I ran into the fact that even the latest apt from debian does not support version 2's keybox format, so I had to drop back to gpg version 1 anyway. Is version 1 going to remain available, I hope? Version 2 simply seems a poor fit for scripting. Thanks, Dan From rjh at sixdemonbag.org Wed Jan 17 03:52:11 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Jan 2018 21:52:11 -0500 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: References: Message-ID: > Is version 1 going to remain available, I hope? Version 2 simply > seems a poor fit for scripting. The game plan has always been to retire 1.4 as soon as practical. Do not rely on it existing in the future. From gnupg at raf.org Wed Jan 17 04:24:59 2018 From: gnupg at raf.org (gnupg at raf.org) Date: Wed, 17 Jan 2018 14:24:59 +1100 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: References: Message-ID: <20180117032459.GA22448@raf.org> Robert J. Hansen wrote: > > Is version 1 going to remain available, I hope? Version 2 simply > > seems a poor fit for scripting. > > The game plan has always been to retire 1.4 as soon as practical. Do > not rely on it existing in the future. that's a shame. i hope someone creates a non-gui, non-curses pinentry program before that happens (that can work inside a gvim window). cheers, raf From rjh at sixdemonbag.org Wed Jan 17 04:37:52 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Jan 2018 22:37:52 -0500 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: <20180117032459.GA22448@raf.org> References: <20180117032459.GA22448@raf.org> Message-ID: <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> > that's a shame. I should also say some more things about it, like -- * it's not going away in the near future * we know people like to use it for servers * it's a lot of work to keep two codebases going * new crypto, like ECC, will not be backported to 1.4 * new features will probably not be backported * if you need 1.4 support, contact g10 Code GmbH :) From dank at kegel.com Wed Jan 17 05:10:38 2018 From: dank at kegel.com (Dan Kegel) Date: Tue, 16 Jan 2018 20:10:38 -0800 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> References: <20180117032459.GA22448@raf.org> <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> Message-ID: On Tue, Jan 16, 2018 at 7:37 PM, Robert J. Hansen wrote: > * it's not going away in the near future > * we know people like to use it for servers > * it's a lot of work to keep two codebases going > * new crypto, like ECC, will not be backported to 1.4 > * new features will probably not be backported > * if you need 1.4 support, contact g10 Code GmbH Thanks. When I try to use gpg to manipulate secure apt repositories in the real world, my head explodes. I'm sure it will all seem reasonable after I figure things out. I've only been at it off and on for a couple years. - Dan From nbsd4ever at gmail.com Wed Jan 17 07:50:35 2018 From: nbsd4ever at gmail.com (Henry) Date: Wed, 17 Jan 2018 15:50:35 +0900 Subject: gnupg-2.2.4: how to deal with failed tests Message-ID: I finally got gnugp2 built without any fatal errors. Most of the tests passed, but the following tests failed: tests/openpgp/issue2346.scm tests/openpgp/ssh-export.scm tests/openpgp/export.scm tests/openpgp/ecc.scm tests/openpgp/armor.scm I am not hip on using a binary that fails its tests. Grateful for any advice on how to configure/build gnupg2 so that it passes all its tests. TIA Henry From wk at gnupg.org Wed Jan 17 09:42:07 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jan 2018 09:42:07 +0100 Subject: Remove public key from keyserver In-Reply-To: <20180116203759.6f0955ae@iria.my-fqdn.de> (Stefan Claas's message of "Tue, 16 Jan 2018 20:37:59 +0100") References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <878tcyckab.fsf@wheatstone.g10code.de> <20180116163442.0e7eca3d@iria.my-fqdn.de> <87h8rlbqhd.fsf@wheatstone.g10code.de> <20180116203759.6f0955ae@iria.my-fqdn.de> Message-ID: <871sioc1wg.fsf@wheatstone.g10code.de> On Tue, 16 Jan 2018 20:37, stefan.claas at posteo.de said: > users who uploaded their public keys on key servers would not > reveal that they know each other as shown with their signatures, > which the classical WoT somehow requires, instead of using local sigs. I do not know most of the people whose key I signed in the last 25 year. For a long time I had the policy to sign keys only after having seen an identity card in real life. That policy was my own - others may have different policies. I have also noticed quite some signature on my key From people I definitely never had met (even before the fun signature think started). Thus the conclusion that a key signature indicates that the owners of those keys know each other is not correct. Modulo some definition of "know". Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Jan 17 09:57:12 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 17 Jan 2018 09:57:12 +0100 Subject: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction] In-Reply-To: <87efmpwd26.fsf@fifthhorseman.net> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <87zi5dwst7.fsf@fifthhorseman.net> <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> <87efmpwd26.fsf@fifthhorseman.net> Message-ID: On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote: > On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote: >> thanks for this post Daniel, my primary question would be what advantage >> is gained by this verification being done by an arbitrary third party >> rather by a trusted client running locally, which is the current modus >> operandus. Any keyserver action doing this would just shift >> responsibilities to a third party for something better served (and >> already happens) locally. > > the advantage is spam-abatement -- the keyservers have to keep track of > what is attached to each blob they transport/persist. if all signatures > that they transport for a given blob are cryptographically certified, > then only the original uploader of that blob can make assertions about > it; other people can't spam the blob to make it untransportable. All the certificates used in trollwot are technically correct. You can still use the same mechanisms as you control the other key material, and can use intentionally weak key material if wanting to speed things up. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "We all die. The goal isn't to live forever, the goal is to create something that will." (Chuck Palahniuk) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Jan 17 09:58:21 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jan 2018 09:58:21 +0100 Subject: key distribution/verification/update mechanisms other than keyservers In-Reply-To: <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Tue, 16 Jan 2018 22:56:58 +0100") References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <87zi5dwst7.fsf@fifthhorseman.net> <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> Message-ID: <87wp0gamky.fsf@wheatstone.g10code.de> On Tue, 16 Jan 2018 22:56, kristian.fiskerstrand at sumptuouscapital.com said: >> (c) rejected all third-party certifications -- so data attached to a >> given primary key is only accepted when certified by that primary >> key. >> > > thanks for this post Daniel, my primary question would be what advantage > is gained by this verification being done by an arbitrary third party This can help to avoid DoS attacks. I would love to see that to get my key down to a reasonable size. OpenPGP specifies Key Server Preferences (5.2.3.17) with just one flag: First octet: 0x80 = No-modify the key holder requests that this key only be modified or updated by the key holder or an administrator of the key server. By default GnuPG sets this flag but unfortunately it has no effect because it is not defined on how the keyserver can check this condition. A way to implement this without requiring an external protocol would be an extension to OpenPGP to either allow an Embedded Signature (5.2.3.26) in a key signature. With ECC this would not increase the size of a key signature too much. It puts a burden on the keyservers to check this signature during an upload, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jan 17 10:02:27 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jan 2018 10:02:27 +0100 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: (Robert J. Hansen's message of "Tue, 16 Jan 2018 21:52:11 -0500") References: Message-ID: <87shb4ame4.fsf@wheatstone.g10code.de> On Wed, 17 Jan 2018 03:52, rjh at sixdemonbag.org said: > The game plan has always been to retire 1.4 as soon as practical. Do > not rely on it existing in the future. Kind of: 1.4 will be kept alive for use with PGP 2 encrypted and signated data and maybe for old platforms. However, modern algorithms won't be added to 1.4. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jan 17 10:09:50 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jan 2018 10:09:50 +0100 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: (Dan Kegel's message of "Tue, 16 Jan 2018 16:26:49 -0800") References: Message-ID: <87o9lsam1t.fsf@wheatstone.g10code.de> On Wed, 17 Jan 2018 01:26, dank at kegel.com said: > I'm starting to suspect that using version 2.x of gnupg is simply not > a good idea when writing shell scripts that have to run unattended > and not touch system keychains or agents. Actually 2.2 is much easier to script than 2.1. Watch out for all these new --quick-foo commands. There are also very useful new --export-options and --import-options. Regarding the passphrase to protect private keys: Please rethink your design if you need a passphrase for unattended systems. If that does not work for you: --pinentry-mode=loopback works reasonable well. > from debian does not support version 2's keybox format, so I had > to drop back to gpg version 1 anyway. I am stating this for nearly 20 years: The format of pubring.gpg or pubring.kbx is intern to the gpg implementation and does not constitute any specified API. The same goes for most files in GnuPG's home directory. To work with public or private keys the --import and --export commands are to be used. Just in case: Always use --batch, --status-fd, and --with-colon in scripts. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jan 17 10:15:43 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jan 2018 10:15:43 +0100 Subject: gnupg-2.2.4: how to deal with failed tests In-Reply-To: (Henry's message of "Wed, 17 Jan 2018 15:50:35 +0900") References: Message-ID: <87k1wgals0.fsf@wheatstone.g10code.de> On Wed, 17 Jan 2018 07:50, nbsd4ever at gmail.com said: > tests/openpgp/armor.scm There will be a file tests/openpgp/armor.scm.log which should give you some more insight. You can alos run single tests or all in a more verbose mode. See the ERADME file in the tests directory. > Grateful for any advice on how to configure/build gnupg2 so that Our Jenkins is currentluy not running but we used to run tests also on OpenBSD without failures. I also test from time on FreeBSD. Thus I am sure it will be only a minor problem on your installation. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Jan 17 10:59:16 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 17 Jan 2018 10:59:16 +0100 Subject: gnupg-2.2.4: how to deal with failed tests In-Reply-To: References: Message-ID: <0d92e643-7fe4-655e-c903-c4ff9ffa326d@sumptuouscapital.com> On 01/17/2018 07:50 AM, Henry wrote: > I finally got gnugp2 built without any fatal errors. > Most of the tests passed, but the following tests failed: > tests/openpgp/issue2346.scm > tests/openpgp/ssh-export.scm > tests/openpgp/export.scm > tests/openpgp/ecc.scm > tests/openpgp/armor.scm > > I am not hip on using a binary that fails its tests. > Grateful for any advice on how to configure/build gnupg2 so that > it passes all its tests. > Some observations on test * in Gentoo we've had to shorten the socket path length, max is 108 chars of which 42 is used by gpgscm by default. * Parallel tests fail if building without tofu support * sparc architecture has a failure in tests/openpgp/quick-key-manipulation.scm:219 on assert -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From nbsd4ever at gmail.com Wed Jan 17 12:02:14 2018 From: nbsd4ever at gmail.com (Henry) Date: Wed, 17 Jan 2018 20:02:14 +0900 Subject: help using netpgpverify anyone? Message-ID: There was a post recently which introduced NetPGP. Is there someone who has used it successfully to verify the signiture on a binary file? I could use help on how to form a working command line. I tried `netpgpverify -k ~/.gnupg/pubring.gpg gnupg-1.4.22.tar.bz2.sig` in a directory containing gnupg-1.4.22.tar.bz2, but I get the output: Ignoring unusual/reserved signature subpacket 33 [above line repeated 12 times] weird type of sig! 16 read_sigpkt: can't read sigs v3 can't read keyring I've tried many other possible command lines, but no luck so far. TIA for any help. From tlikonen at iki.fi Wed Jan 17 14:10:24 2018 From: tlikonen at iki.fi (Teemu Likonen) Date: Wed, 17 Jan 2018 15:10:24 +0200 Subject: key distribution/verification/update mechanisms other than keyservers In-Reply-To: <87wp0gamky.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 17 Jan 2018 09:58:21 +0100") References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <87zi5dwst7.fsf@fifthhorseman.net> <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> <87wp0gamky.fsf@wheatstone.g10code.de> Message-ID: <87po68637j.fsf@iki.fi> Werner Koch [2018-01-17 09:58:21+01] wrote: >>> (c) rejected all third-party certifications -- so data attached to >>> a given primary key is only accepted when certified by that primary >>> key. > This can help to avoid DoS attacks. I would love to see that to get my > key down to a reasonable size. Not quite related but... I tend to think that on client side it would be good idea to "clean" by default. (I like to do that.) keyserver-options import-clean,export-clean -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From nbsd4ever at gmail.com Wed Jan 17 15:18:26 2018 From: nbsd4ever at gmail.com (Henry) Date: Wed, 17 Jan 2018 23:18:26 +0900 Subject: gnupg-2.2.4: how to deal with failed tests In-Reply-To: <87k1wgals0.fsf@wheatstone.g10code.de> References: <87k1wgals0.fsf@wheatstone.g10code.de> Message-ID: Thank you very much. The log files seem to indicate there is some problem involving import of "secret keys". Still, I have no idea how to solve this problem. Excerpts from those files below. -- Henry issue2346.scm.log, ssh-export.scm.log,and ecc.scm.log all have in common the following: "gpg: importing secret keys not allowed" export.scm.log has as the last line: "gpg --no-permission-warning --always-trust --output - --export-secret-keys D74C 5F22 -" armor.scm.log has: "Importing alpha_seckey (((/usr/local/src/gnupg-2.2.4/g10/gpg --no-permission-warning --always-trust --o utput - --import -) 4408 2))" 2018-01-17 18:15 GMT+09:00 Werner Koch : > On Wed, 17 Jan 2018 07:50, nbsd4ever at gmail.com said: > >> tests/openpgp/armor.scm > > There will be a file > > tests/openpgp/armor.scm.log > > which should give you some more insight. You can alos run single tests > or all in a more verbose mode. See the ERADME file in the tests directory. > >> Grateful for any advice on how to configure/build gnupg2 so that > > Our Jenkins is currentluy not running but we used to run tests also on > OpenBSD without failures. I also test from time on FreeBSD. Thus I am > sure it will be only a minor problem on your installation. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Jan 17 05:31:53 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 16 Jan 2018 23:31:53 -0500 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: References: <20180117032459.GA22448@raf.org> <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> Message-ID: <87wp0humva.fsf@fifthhorseman.net> On Tue 2018-01-16 20:10:38 -0800, Dan Kegel wrote: > When I try to use gpg to manipulate secure apt repositories in the > real world, my head explodes. hi there! what kind of manipulation are you doing of secure apt repositories with gpg? are you talking about signing the repo as an author? or about configuring for a client? or distributing public keys for the repo? or about verifying signatures as a client? each use case is slightly different, but there should be reasonable, non-head-explode-y tooling available for all of them. --dkg From dkg at fifthhorseman.net Wed Jan 17 05:36:56 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 16 Jan 2018 23:36:56 -0500 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: References: Message-ID: <87tvvlummv.fsf@fifthhorseman.net> On Tue 2018-01-16 16:26:49 -0800, Dan Kegel wrote: > I worked hard to jump through hoops to use version 2 in such > an environment, but then I ran into the fact that even the latest apt > from debian does not support version 2's keybox format, so I had > to drop back to gpg version 1 anyway. apt always uses the "transferable public key" form for its OpenPGP dependencies, which is specified in RFC 4880. a simple linear concatenation of these transferable public keys is a "keyring", which apt knows how to ingest. The "keybox" format is not used by any tool outside of the GnuPG suite, and it doesn't have nearly as much documentation or history as the transferable public key format. i tend to treat *.kbx the same way i treat private-keys-v1.d -- as part of GnuPG internals, not as part of its public interface. If you want to generate a clean "keyring" it should be straightforward to do so with any version of GnuPG just by using --export. You can import a keyring into any version of GnuPG with --import. if you're in the habit of using GnuPG in order to create some file within its internal "home directory" and then extract that for some other use (like sending handing some internal file from there to apt) -- please don't do that. The internals of the GnuPG homedir have never explicitly been part of the publicly-exposed API. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From psusi at ubuntu.com Wed Jan 17 15:38:45 2018 From: psusi at ubuntu.com (Phil Susi) Date: Wed, 17 Jan 2018 09:38:45 -0500 Subject: DOS attack? In-Reply-To: <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <18152340-7899-8055-e3ed-c17816968d99@sixdemonbag.org> Message-ID: On 1/15/2018 3:00 PM, Robert J. Hansen wrote: > It's from 2003. It doesn't need modernization. > > Keyservers are designed the way they are for a reason. If keyservers > *never ever discard or modify existing data*, then you can easily > identify any code which theoretically might be able to discard data as a > bug, a vulnerability, or tampering with it by a malicious actor. It > makes code review easier and it makes it difficult for repressive > regimes to surreptitiously take down certificates belonging to dissidents. > > This "we never discard or modify existing data, we only ever add new > data" rule has some *really really nice* properties for information > security. However, it also comes with a downside: we can't discard or > modify existing data. > > It's a package deal. When SKS was being built in the early 2000s there > were vigorous discussions about what properties we wanted in a > keyserver. We knew exactly what we were getting into. If data can't be deleted, and it isn't even verified by the server when it is added, then can't someone DOS my key, or possibly the entire network, by appending infinite garbage to it? From stefan.claas at posteo.de Wed Jan 17 16:20:52 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 17 Jan 2018 16:20:52 +0100 Subject: Remove public key from keyserver In-Reply-To: <871sioc1wg.fsf@wheatstone.g10code.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <05659466-6129-6644-a8ee-2a09e263b4e4@digitalbrains.com> <20180115201951.3dc884d9@iria.my-fqdn.de> <878tcyckab.fsf@wheatstone.g10code.de> <20180116163442.0e7eca3d@iria.my-fqdn.de> <87h8rlbqhd.fsf@wheatstone.g10code.de> <20180116203759.6f0955ae@iria.my-fqdn.de> <871sioc1wg.fsf@wheatstone.g10code.de> Message-ID: <20180117162052.4a00adfb@iria.my-fqdn.de> On Wed, 17 Jan 2018 09:42:07 +0100, Werner Koch wrote: > On Tue, 16 Jan 2018 20:37, stefan.claas at posteo.de said: > > > users who uploaded their public keys on key servers would not > > reveal that they know each other as shown with their signatures, > > which the classical WoT somehow requires, instead of using local > > sigs. > > I do not know most of the people whose key I signed in the last 25 > year. For a long time I had the policy to sign keys only after having > seen an identity card in real life. That policy was my own - others > may have different policies. I have also noticed quite some > signature on my key From people I definitely never had met (even > before the fun signature think started). Thanks for pointing this out. When looking in the past on sigs, via WWW key servers i always had the impression that people do a lot of "fan" signing, thus making the classical WoT somewhat untrustworthy to me, because those fans have never met you or others in person. Should we ever see a new key server model, replacing the current one, and only owners can upload their keys i think this would help to eliminate those fan sigs too, which IMHO have no weight, unless of course the owner of that key with fan sigs would also verify and sign those signers. > Thus the conclusion that a key signature indicates that the owners of > those keys know each other is not correct. Modulo some definition of > "know". Maybe a sig4 = family, long time friends which does not involve verification of ID card documents. ... :-) Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From dkg at fifthhorseman.net Wed Jan 17 16:32:05 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 17 Jan 2018 10:32:05 -0500 Subject: key distribution/verification/update mechanisms other than keyservers In-Reply-To: <87wp0gamky.fsf@wheatstone.g10code.de> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <87zi5dwst7.fsf@fifthhorseman.net> <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> <87wp0gamky.fsf@wheatstone.g10code.de> Message-ID: <87a7xcv6ve.fsf@fifthhorseman.net> On Wed 2018-01-17 09:58:21 +0100, Werner Koch wrote: > On Tue, 16 Jan 2018 22:56, kristian.fiskerstrand at sumptuouscapital.com > said: > >>> (c) rejected all third-party certifications -- so data attached to a >>> given primary key is only accepted when certified by that primary >>> key. >>> >> >> thanks for this post Daniel, my primary question would be what advantage >> is gained by this verification being done by an arbitrary third party > > This can help to avoid DoS attacks. I would love to see that to get my > key down to a reasonable size. > > OpenPGP specifies Key Server Preferences (5.2.3.17) with just one flag: > > First octet: 0x80 = No-modify the key holder requests that this key > only be modified or updated by the key holder or an administrator of > the key server. > > By default GnuPG sets this flag but unfortunately it has no effect > because it is not defined on how the keyserver can check this condition. please see also the thread on sks-devel from december 2016 with the subject "nokeyserver annotation" -- if we're designing a new, parallel, more narrowly-focused keyserver network we should make sure to include that as well. > A way to implement this without requiring an external protocol would be > an extension to OpenPGP to either allow an Embedded Signature (5.2.3.26) > in a key signature. With ECC this would not increase the size of a key > signature too much. It puts a burden on the keyservers to check this > signature during an upload, though. I think you're describing a way to permit such a narrowly-scoped keyserver to be slightly more broad -- to allow third-party certifications to be published. i don't think you need an extension to OpenPGP at all to do this -- you just need policy. The policy could be (for example): * if a third-party certification is present, discard it unless all of the following are true: a) it has the "issuer fingerprint" subpacket in the hashed subpackets b) the issuing key is itself is known to the keyserver c) the certification is cryptographically correct d) there is an Embedded Signature subpacket in the unhashed subpackets from the primary key, over the existing signature *with unhashed subpackets discarded* e) the embedded signature is cryptographically valid but the simplest thing would be to start without third-party certifications at all -- making this strictly for self-certification updates (expiry, revocation, key-rotation). wdyt? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From andrewg at andrewg.com Wed Jan 17 16:51:07 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Jan 2018 15:51:07 +0000 Subject: key distribution/verification/update mechanisms other than keyservers In-Reply-To: <87a7xcv6ve.fsf@fifthhorseman.net> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <87zi5dwst7.fsf@fifthhorseman.net> <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> <87wp0gamky.fsf@wheatstone.g10code.de> <87a7xcv6ve.fsf@fifthhorseman.net> Message-ID: <2998f91d-2c26-b0e3-05e5-3625c7561dc8@andrewg.com> On 17/01/18 15:32, Daniel Kahn Gillmor wrote: > i don't think you need an extension to OpenPGP at all to do this -- you > just need policy. The policy could be (for example): The main technical question is where should this policy be applied? 1. At upload stage - easy to implement, but requires all keyservers to cooperate. It also means starting from an empty set, effectively building a parallel keyserver network from scratch. 2. At replication stage - this would be effective, but to the best of our knowledge would cripple the algorithm. 3. At search/display stage - almost as easy as 1, although more computationally intensive as it would need to be calculated per download (caching may help). Can be retrofitted to existing keyservers. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Jan 17 20:12:03 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jan 2018 20:12:03 +0100 Subject: gnupg-2.2.4: how to deal with failed tests In-Reply-To: (Henry's message of "Wed, 17 Jan 2018 23:18:26 +0900") References: <87k1wgals0.fsf@wheatstone.g10code.de> Message-ID: <87y3kw8flo.fsf@wheatstone.g10code.de> On Wed, 17 Jan 2018 15:18, nbsd4ever at gmail.com said: > "gpg: importing secret keys not allowed" Which means you are trying to import from a keyserver, WKD, DANE etc. That is very strange. How did you build gnupg, did you checked the signature of the source, is there anything special in your setup? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From johanw at vulcan.xs4all.nl Wed Jan 17 19:25:55 2018 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 17 Jan 2018 19:25:55 +0100 Subject: "right to be forgotten" nonsense In-Reply-To: <80d95947-7d15-c824-d935-2918f9cdd855@ubuntu.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <80d95947-7d15-c824-d935-2918f9cdd855@ubuntu.com> Message-ID: <5A5F9533.3010208@vulcan.xs4all.nl> On 16-01-2018 15:16, Phil Susi wrote: > There isn't merit. It became public, not private, the moment you > published it. I have the right to free speech, the EU be damned. Are > these numbnuts going to demand that libraries black out newspaper > articles on microfilm because they mention someone that doesn't like the > coverage of themselves? No, they will "only" try to make it hard for anyone to find that article. Not that I agree with it but that's the intended scope. > Sure, I molested children 5 years ago, but I > have the "right to be forgotten" so when anyone searches for my name on > the Internet they won't find out. Give me a break. Using this right to wipe published convictions is explicitly stated as a reason to refuse the right to be forgotten. The same for some other issues, like public statements of politicians. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From dank at kegel.com Thu Jan 18 00:09:45 2018 From: dank at kegel.com (Dan Kegel) Date: Wed, 17 Jan 2018 15:09:45 -0800 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: <87wp0humva.fsf@fifthhorseman.net> References: <20180117032459.GA22448@raf.org> <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> <87wp0humva.fsf@fifthhorseman.net> Message-ID: On Tue, Jan 16, 2018 at 8:31 PM, Daniel Kahn Gillmor wrote: > On Tue 2018-01-16 20:10:38 -0800, Dan Kegel wrote: > > When I try to use gpg to manipulate secure apt repositories in the > > real world, my head explodes. > > hi there! what kind of manipulation are you doing of secure apt > repositories with gpg? > > are you talking about signing the repo as an author? or about > configuring for a client? or distributing public keys for the repo? or > about verifying signatures as a client? Yes to all four questions. Here's the user story. - I maintain a secure apt repository at pkgs.foobar.com following best practices in https://wiki.debian.org/DebianRepository/UseThirdParty - the key that signs my repository is trusted by debian developers in the pgp web of trust - To my users, I send via a trusted offline mechanism a copy of a package foobar-archive.deb - When they install that package, it installs the files /usr/share/keyrings/foobar-archive.gpg, and /etc/apt/sources.list.d/foobar-archive.list - The latter file's entries say signed-by=/usr/share/keyrings/foobar-archive.gpg - The package depends on debian-archive-keyring (to leverage the web of trust as suggested in 'man secure-apt') - My users are happy that simply installing one package establishes trust and lets them apt-get from my repo with no pesky errors from ubuntu 17.10 about my server having an invalid or untrusted signature - Updates to foobar-archive are delivered via secure apt. So much magic. It took me a while to figure that path out, and I'm still not quite sure I've got it right, still working on getting my regression tests to pass. There don't seem to be a wealth of accurate examples that are both kosher and up to date. Most of my angst comes from having to come up two learning curves simultaneously with tools that are used by fairly small communities and thus have some rough edges still (debian packaging and gpg commandline tools), and have lots of stale stories out on the web about how to work around problems that no longer exist. I also have to support a range of versions of gpg, can't insist on the latest. Happily, in preparation for supporting Ubuntu 17.10, I verified that I can drop support for versions of gpg and apt older than the ones in Ubuntu 16.04. While my foobar-archive.deb may seem superficially similar to debian-archive-keyring.deb, the latter does things in its postinstall step that establish trust at the system level in a way that doesn't seem like a good example for third party apt repositories to use as an example. That package is not to be confused with the similarly named debian-keyring package, which is completely kosher and just installs key(ring)s into /usr/share/keyrings, but does not of itself establish trust. - Dan From dkg at fifthhorseman.net Thu Jan 18 00:25:32 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 17 Jan 2018 18:25:32 -0500 Subject: key distribution/verification/update mechanisms other than keyservers In-Reply-To: <2998f91d-2c26-b0e3-05e5-3625c7561dc8@andrewg.com> References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <87zi5dwst7.fsf@fifthhorseman.net> <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> <87wp0gamky.fsf@wheatstone.g10code.de> <87a7xcv6ve.fsf@fifthhorseman.net> <2998f91d-2c26-b0e3-05e5-3625c7561dc8@andrewg.com> Message-ID: <874lnkukyb.fsf@fifthhorseman.net> On Wed 2018-01-17 15:51:07 +0000, Andrew Gallagher wrote: > On 17/01/18 15:32, Daniel Kahn Gillmor wrote: >> i don't think you need an extension to OpenPGP at all to do this -- you >> just need policy. The policy could be (for example): > > The main technical question is where should this policy be applied? read in the context of the discussion in the thread (i know -- it's 90 messages long, hard to keep up!), we're talking about a parallel keyserver network here, so the policy would be applied at upload time (which also means it happens at "replication" time). > 3. At search/display stage - almost as easy as 1, although more > computationally intensive as it would need to be calculated per download > (caching may help). Can be retrofitted to existing keyservers. I think a better way to consider retrofitting to existing keyservers would be if existing keyservers could maintain the idea of two filtersets concurrently. then, if they're gossiping with a peer who insists on filterset A (the existing dominant filterset), they work only with the certificate material that belongs to that particular filterset. if they're gossiping with a peer who can do the new constrained filterset (we'll call it B), then they work only with the certificate material that belongs to that filterset. but internally they know about the union of all of that certificate material. If we had a few keyservers capable of that kind of operation with both A and B, then we could keep the B-only keyservers in sync during a migration. sadly, i don't have such an implementation and i don't know how to do that work in the time i have available. --dkg From dkg at fifthhorseman.net Thu Jan 18 02:20:30 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 17 Jan 2018 20:20:30 -0500 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: References: <20180117032459.GA22448@raf.org> <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> <87wp0humva.fsf@fifthhorseman.net> Message-ID: <871sioufmp.fsf@fifthhorseman.net> On Wed 2018-01-17 15:09:45 -0800, Dan Kegel wrote: > Yes to all four questions. Here's the user story. cool, your user story all makes sense to me except this bit: > - The package depends on debian-archive-keyring (to leverage > the web of trust as suggested in 'man secure-apt') (itym 'man apt-secure', right?) if you're expecting ubuntu (or any other non-debian) users to install this, then you're actually increasing their attack surface, because this package will place debian archive keys as "trusted" keys automatically (meaning "any archive that is signed by them is considered legitimate), when they weren't present on the system before. I don't see the part of apt-secure(8) that says anything about needing this, and i don't see how it "leverages the web of trust" -- can you explain this more? Without a clear justification, i think you should remove this dependency. > I also have to support a range of versions of gpg, can't insist > on the latest. Happily, in preparation for supporting Ubuntu 17.10, > I verified that I can drop support for versions of gpg and apt > older than the ones in Ubuntu 16.04. what i'm not hearing is an explicit example of how you are using gpg -- as the archive maintainer, surely you manage the archive itself on a system of your choice. for me, that would be a debian stable system, with reprepro or something like that, which should already know how to call out to gpg. as the developer of the foobar-archive package, you shouldn't need to invoke gpg at all in your package build scripts other than just --import and --export, which should be pretty standard across all versions of gpg. your end users don't actually need full-blown gpg at all -- modern versions of apt depend explicitly (and minimally) on gpgv, since all they do is verify signatures based on a set of acceptable keys. > While my foobar-archive.deb may seem superficially similar to > debian-archive-keyring.deb, the latter does things > in its postinstall step that establish trust at the system > level in a way that doesn't seem like a good example for > third party apt repositories to use as an example. yep, agreed. (which is why i'm surprised to see your dependency on debian-archive-keyring) You may also be interested in https://bugs.debian.org/861695, fwiw. All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dank at kegel.com Thu Jan 18 05:58:21 2018 From: dank at kegel.com (Dan Kegel) Date: Wed, 17 Jan 2018 20:58:21 -0800 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: <871sioufmp.fsf@fifthhorseman.net> References: <20180117032459.GA22448@raf.org> <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> <87wp0humva.fsf@fifthhorseman.net> <871sioufmp.fsf@fifthhorseman.net> Message-ID: On Wed, Jan 17, 2018 at 5:20 PM, Daniel Kahn Gillmor wrote: > > - The package depends on debian-archive-keyring (to leverage > > the web of trust as suggested in 'man secure-apt') > > (itym 'man apt-secure', right?) right. > if you're expecting ubuntu (or any other non-debian) users to install > this, then you're actually increasing their attack surface Correct. Glad to hear it's a crazy idea, happy to drop it, just need to understand how trust is established, and how to use the tools. > what i'm not hearing is an explicit example of how you are using gpg -- > as the archive maintainer, surely you manage the archive itself on a > system of your choice. for me, that would be a debian stable system, > with reprepro or something like that, which should already know how to > call out to gpg. > > as the developer of the foobar-archive package, you shouldn't need to > invoke gpg at all in your package build scripts other than just --import > and --export, which should be pretty standard across all versions of > gpg. Does one even need --import and --export while building foobar-archive; aren't the thing being imported and the thing being exported the same format? Just ferry active-keys/foobar-archive.gpg straight into /usr/share/keyrings/foobar-archive.gpg? (I saw a note about stripping off trust packets, since they're less portable. Wonder if that's related.) > You may also be interested in https://bugs.debian.org/861695, fwiw. Yes, I read that earlier with interest. Happy to be chatting with a grandmaster, as it were. What I am missing is how dropping a key into /usr/share/keyrings, and then pointing to it with signed-by=, actually establishes trust. I mean, it makes sense and all, but when I write a regression test script that : - sets GNUPGHOME to an empty directory - generates a key - creates a repo using reprepro signed by that key - creates a dummy package - adds it to the repo - tries to access the repo with 'apt-get update' it says the repo key is bad. Such a script is long enough than a secure apt beginner like me is unlikely to be able to get it right quickly. Here's the bit where it explodes, with debugging prints enabled: + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get -q -q update inside VerifyGetSigners Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg verify --status-fd 3 /tmp/apt.sig.UbNAaM /tmp/apt.data.5w6fyj Read: [GNUPG:] ERRSIG 77D1F0D4EC3422C4 1 8 01 1516232802 9 Got ERRSIG Read: [GNUPG:] NO_PUBKEY 77D1F0D4EC3422C4 Got NO_PUBKEY So I'm forgetting something important, like avoiding breaking things when I set up an isolated GNUPGHOME or apt config, or forgetting to mark the key I just generated as trusted, or not understanding how apt-key works, or just plain being dumb. My next move is probably reading apt-key and trying to understand it. Alternately, I could try ripping out all the gpg1 support in my scripts. That probably won't help, but would be satisfying :-) - Dan From nbsd4ever at gmail.com Thu Jan 18 15:41:55 2018 From: nbsd4ever at gmail.com (Henry) Date: Thu, 18 Jan 2018 23:41:55 +0900 Subject: gnupg-2.2.4: how to deal with failed tests In-Reply-To: <87y3kw8flo.fsf@wheatstone.g10code.de> References: <87k1wgals0.fsf@wheatstone.g10code.de> <87y3kw8flo.fsf@wheatstone.g10code.de> Message-ID: 2018-01-18 4:12 GMT+09:00 Werner Koch : > On Wed, 17 Jan 2018 15:18, nbsd4ever at gmail.com said: > >> "gpg: importing secret keys not allowed" > > Which means you are trying to import from a keyserver, WKD, DANE etc. I do not know; the tests are trying to do it, AFAIK. > That is very strange. How did you build gnupg, did you checked the > signature of the source, is there anything special in your setup? Source was checked with gnupg1, which in turn was only checked with sha1 checksum. % setenv LDFLAGS "-Wl,-R/usr/local/lib -L/usr/local/lib -L/usr/lib" % ./configure --enable-g13 --enable-symcryptrun --enable-wks-tools \ --enable-selinux-support --with-libgpg-error-prefix=/usr/local \ --with-npth-prefix=/usr/local --with-libgcrypt-prefix=/usr/local \ --with-libassuan-prefix=/usr/local --with-ksba-prefix==/usr/local \ --with-readline=/usr/local % gmake (Reason for LDFLAGS is that get an error during tests like "can't find shared object libgcrypt.so") Thank you, Henry > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jan 18 19:27:09 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Jan 2018 19:27:09 +0100 Subject: gnupg-2.2.4: how to deal with failed tests In-Reply-To: (Henry's message of "Thu, 18 Jan 2018 23:41:55 +0900") References: <87k1wgals0.fsf@wheatstone.g10code.de> <87y3kw8flo.fsf@wheatstone.g10code.de> Message-ID: <87y3kv6n0i.fsf@wheatstone.g10code.de> On Thu, 18 Jan 2018 15:41, nbsd4ever at gmail.com said: > --enable-selinux-support --with-libgpg-error-prefix=/usr/local \ ^^^^^^^^^^^^^^^^^^^^^^ Ah! There is a second case where you see the reported error message: #ifdef ENABLE_SELINUX_HACKS if (1) { /* We don't allow importing secret keys because that may be used to put a secret key into the keyring and the user might later be tricked into signing stuff with that key. */ log_error (_("importing secret keys not allowed\n")); return 0; } #endif I wonder why you enable this at all. I doubt that NetBSD supports SElinux. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dank at kegel.com Thu Jan 18 23:49:44 2018 From: dank at kegel.com (Dan Kegel) Date: Thu, 18 Jan 2018 14:49:44 -0800 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: References: <20180117032459.GA22448@raf.org> <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> <87wp0humva.fsf@fifthhorseman.net> <871sioufmp.fsf@fifthhorseman.net> Message-ID: On Wed, Jan 17, 2018 at 8:58 PM, Dan Kegel wrote: > Here's the bit where it explodes, > > + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp > APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get -q -q > update > inside VerifyGetSigners > Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring > /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg verify > --status-fd 3 /tmp/apt.sig.UbNAaM /tmp/apt.data.5w6fyj > Read: [GNUPG:] ERRSIG 77D1F0D4EC3422C4 1 8 01 1516232802 9 > Got ERRSIG > Read: [GNUPG:] NO_PUBKEY 77D1F0D4EC3422C4 > Got NO_PUBKEY One little clue: apt evidently runs apt-key as user _apt, and /tmp/obs_localbuild_gpghome_dank.tmp/ is owned by me, with permissions 700. So apt-key can't read it. Whee! And if I try creating it with permissions 755, gpg complains about unsafe permissions. I'm still stuck in a twisty maze of little passages, all different. I probably should boil down my test to a simple linear script so I can ask for help properly... - Dan From 2017-r3sgs86x8e-lists-groups at riseup.net Fri Jan 19 01:37:36 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Fri, 19 Jan 2018 00:37:36 +0000 Subject: DRM? In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <13430688-f0d9-c43c-14c1-0ed8e125d4f9@sixdemonbag.org> <057f9bdd-0b37-289f-cbf9-8aaed8b7addc@mail.ru> <2eeee32a-755c-8f5c-8e83-568004cbd29b@digitalbrains.com> <96984096-68f9-de3c-1538-4fa6a6906672@gaspard.io> <7ac8eb83-1dae-a0fb-c65d-b0dbe1dc6a36@andrewg.com> <9b052599-5d6b-bbe9-49dd-37e1948b9564@sumptuousc apital.com> Message-ID: <1499171409.20180119003736@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tuesday 16 January 2018 at 6:50:45 PM, in , Andrew Gallagher wrote:- > Agreed. I was thinking more along the lines of having > some method > of causing signature vandalism to expire. Perhaps this could be achieved by introducing a "certification acceptance signature" calculated over a certification that you were happy to keep on your key? - -- Best regards MFPA Wait. You think I'm right? -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWmE90V8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +hqVAQDaLYjl+DH/MMkM5b8XAvR82SMIqzdGYvqnZNIdimLbFQD/Vg7WIlGxktC1 SzxDJkIawQ9T4nCHCJNZbO3/EWEppwaJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWmE90l8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/9G1D/9JMe2exEnkEZr3kZqtjuVUOkwD +5EeEyEQ0yX1j6haOQ8ErHuuV1QNjU+QpZfFUsyXQijkBitSdQyuKXMOlObWvFMj WtGPQNqIjRq170T1Psf/+ug7NFmXEuqvpJCytiQHfq3GuybHfy3EeCdy98b2oEWc T94h4KDUhDZ3ArjmMzQQqtJBDVGxtHaRo/lWisOi7GlMDDbIqF7XdRHqgRIuPwF5 vtwSHDXGfPyeCpyHMadYXTNsX3y8hlhVRQdnGbD5hMNpdxLvfCFvFZSZpBWQY7el tGQad4vsLHkSKZ5dtYnjm8A0U82VNquEVLytKuoAx4jqETiqPBNL9cwVmhRGTHGC 0r/wDEK5pyDHphvbpjt94KfoA2Dyz90zcqVSachwTOTC4u+BdtwRjZ//7m6M/dkr Z64UQMnu0lIYkD3tvH7wNE6CcfBnSM6mcZO7H8KleIYsgwdc8sB2p0ogq6ezi06C 95xNCnsEg/vMH54vK54N++tvq09psst9wOTosfwktdCqNrHuYDUA2HDrH/O+kTZ4 X3WBl5kbn97bNnpS78gu+CZK9aohvS7s8ON/elIwlUZJILD8u0oCgNHLRn0r9W9G NMe0ItPnoLlXarIl/RI4KMNNagPKmcnW2d50+ZFatQ/WHwibvZpo9vKr+0fuTVM/ O9wgKMtNvRQOPKOqBw== =VyAk -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Fri Jan 19 04:52:28 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 18 Jan 2018 22:52:28 -0500 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: References: <20180117032459.GA22448@raf.org> <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> <87wp0humva.fsf@fifthhorseman.net> <871sioufmp.fsf@fifthhorseman.net> Message-ID: <871sim5wub.fsf@fifthhorseman.net> On Wed 2018-01-17 20:58:21 -0800, Dan Kegel wrote: > Does one even need --import and --export while building foobar-archive; > aren't the thing being imported and the thing being exported > the same format? i don't know -- what are you importing? if the thing you're importing is already a clean Transferable Public Key, then you are right: you can deploy it with /bin/cp or /bin/cat or /usr/bin/install :) > (I saw a note about stripping off trust packets, since they're less > portable. Wonder if that's related.) trust packets aren't part of a Transferable Public Key -- if you're seeing trust packets, then the thing you're working with was never a Transferable Public Key in the first place :/ > What I am missing is how dropping a key into /usr/share/keyrings, > and then pointing to it with signed-by=, actually establishes > trust. hm, that pesky "trust" word again ;) -- let's be clear what we mean about it. The actions you describe above mean that the user is willing to rely on this key to certify the archive listing from your APT repository. this is a narrowly-scoped "trust", because it also means that the user will *not* accept signatures from the key in question on any *other* repository. This is good -- in the security sense of "trusted", we want to *reduce* trust, not expand it, right? things that you trust can violate that trust and you're helpless. > I mean, it makes sense and all, but when I write a > regression test script that : > - sets GNUPGHOME to an empty directory > - generates a key > - creates a repo using reprepro signed by that key > - creates a dummy package > - adds it to the repo > - tries to access the repo with 'apt-get update' if this is the only thing happening, apt will indeed fail, because it has never heard of the "new key" that was just created -- why should it accept signatures from that new key? how are you configuring the target system to point to the repo? how are you telling it where to find the key? I'd expect somewhere in there to be a "gpg --export" of the newly-created key, into a simple file that can be picked up later. > + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get -q -q update > inside VerifyGetSigners > Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring > /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg verify > --status-fd 3 /tmp/apt.sig.UbNAaM /tmp/apt.data.5w6fyj > Read: [GNUPG:] ERRSIG 77D1F0D4EC3422C4 1 8 01 1516232802 9 > Got ERRSIG > Read: [GNUPG:] NO_PUBKEY 77D1F0D4EC3422C4 > Got NO_PUBKEY this looks strange to me -- you seem to be using a --keyring that is *inside* the GNUPGHOME that you've set (/tmp/obs_localbuild_gnupghome_dank.tmp/). that GnuPG homedir is really not part of the GnuPG API contract -- and anything you put in that homedir could potentially be overwritten by GnuPG itself. How is /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg being generated? This seems like the sticking point to me. > or forgetting to mark the key I just generated as trusted there's no need to mark any keys as "trusted" with GnuPG for apt's sake. Apt represents its "trust" (willingness to rely on a key to generate acceptable signatures over an archive) in one of two ways: a) placement in /etc/apt/trusted.gpg or /etc/apt/trusted.gpg.d/*.gpg b) placement elsewhere in the filesystem, pointed to by a signed-by option in a line in /etc/apt/sources.list or /etc/apt/sources.list.d/*.list; or pointed to by a Signed-By: header in a stanza in /etc/apt/sources.list.d/*.source (see sources.list(5) for more details about the way that signed-by can be presented). the keys placed in the filesystem at the locations described in (a) are acceptable for making signatures over *every* apt repository configured on the system, except those with an explicit signed-by directive, which are more constrained. The keys referred to via signed-by are the only acceptable keys for the associated apt repo. does that make sense? --dkg From dank at kegel.com Fri Jan 19 04:58:52 2018 From: dank at kegel.com (Dan Kegel) Date: Thu, 18 Jan 2018 19:58:52 -0800 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: <871sim5wub.fsf@fifthhorseman.net> References: <20180117032459.GA22448@raf.org> <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> <87wp0humva.fsf@fifthhorseman.net> <871sioufmp.fsf@fifthhorseman.net> <871sim5wub.fsf@fifthhorseman.net> Message-ID: On Thu, Jan 18, 2018 at 7:52 PM, Daniel Kahn Gillmor wrote: > if this is the only thing happening, apt will indeed fail, because it > has never heard of the "new key" that was just created -- why should it > accept signatures from that new key? > > how are you configuring the target system to point to the repo? how are > you telling it where to find the key? By installing my package, which drops the key into /usr/share/keyrings and creates the lists.d entries with signed-by. That ought to suffice, I gather, but I'm tripping over shoelaces somewhere. > this looks strange to me -- you seem to be using a --keyring that is > *inside* the GNUPGHOME that you've set > (/tmp/obs_localbuild_gnupghome_dank.tmp/). > > that GnuPG homedir is really not part of the GnuPG API contract -- and > anything you put in that homedir could potentially be overwritten by > GnuPG itself. How is > /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg being > generated? It's just a regression test script. I'm cleaning it up and will post it once it's legible and avoids sins like that. > The keys referred to via signed-by are the only acceptable keys for the > associated apt repo. > > does that make sense? That'd be great if it worked. Since it's hard to explain what's broken without a simple script showing exactly what I'm doing, let's just hold that thought until I post one. - Dan From skissane at medallia.com Fri Jan 19 09:57:56 2018 From: skissane at medallia.com (Simon Kissane) Date: Fri, 19 Jan 2018 19:57:56 +1100 Subject: failed to convert unprotected openpgp key: Checksum error Message-ID: Hi I have written some code in Java to generate private/public keys, and export them in OpenPGP format (using BouncyCastle's OpenPGP classes). However, when I try to decrypt data encrypted with the private key, I get a "failed to convert unprotected openpgp key: Checksum error" I presume there is something about the key file that GPG doesn't like? But can anyone tell me what it is? I am using GnuPG 2.2.4 on macOS 10.12.6. Here is my private key: https://gist.github.com/skissane/3d1109708be0d4167d8cf16db5fa2e3c (This is just a test key generated for testing purposes, so it is fine to share it publicly.) Now, run this script against that private key file: https://gist.github.com/skissane/d8291e9719d43bfb5eee58ee579c76fb Like so: ./testGpg.sh testPrivateKey.asc You will note the errors from gpg-agent: gpg-agent[29270]: failed to convert unprotected openpgp key: Checksum error gpg-agent[29270]: failed to read the secret key gpg-agent[29270]: command 'PKDECRYPT' failed: Checksum error gpg-agent[29270]: DBG: chan_7 -> ERR 67108874 Checksum error What confuses me is the key imports into the GPG home fine, the error only happens when I try to use it to perform decryption. If the key format was wrong, I would have thought the error would have happened when I tried to import it. Thanks Simon From nbsd4ever at gmail.com Fri Jan 19 14:23:59 2018 From: nbsd4ever at gmail.com (Henry) Date: Fri, 19 Jan 2018 22:23:59 +0900 Subject: gnupg-2.2.4: how to deal with failed tests In-Reply-To: <87y3kv6n0i.fsf@wheatstone.g10code.de> References: <87k1wgals0.fsf@wheatstone.g10code.de> <87y3kw8flo.fsf@wheatstone.g10code.de> <87y3kv6n0i.fsf@wheatstone.g10code.de> Message-ID: THANK YOU!! THANK YOU!! Configured simply with: % ./configure --enable-g13 --enable-symcryptrun --enable-wks-tools \ --with-readline=/usr/local and all tests run seemed to PASS. (I will later be installing gnupg2 on darwin and ubuntu.) Henry 2018-01-19 3:27 GMT+09:00 Werner Koch : > On Thu, 18 Jan 2018 15:41, nbsd4ever at gmail.com said: > >> --enable-selinux-support --with-libgpg-error-prefix=/usr/local \ > ^^^^^^^^^^^^^^^^^^^^^^ > > Ah! There is a second case where you see the reported error message: > > #ifdef ENABLE_SELINUX_HACKS > if (1) > { > /* We don't allow importing secret keys because that may be used > to put a secret key into the keyring and the user might later > be tricked into signing stuff with that key. */ > log_error (_("importing secret keys not allowed\n")); > return 0; > } > #endif > > I wonder why you enable this at all. I doubt that NetBSD supports > SElinux. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dentaldiva2378 at yahoo.com Fri Jan 19 16:50:22 2018 From: dentaldiva2378 at yahoo.com (Shannon Mess) Date: Fri, 19 Jan 2018 15:50:22 +0000 (UTC) Subject: gnupg-2.2.4: how to deal with failed tests In-Reply-To: References: <87k1wgals0.fsf@wheatstone.g10code.de> <87y3kw8flo.fsf@wheatstone.g10code.de> <87y3kv6n0i.fsf@wheatstone.g10code.de> Message-ID: <1204741851.1427878.1516377022811@mail.yahoo.com> REMOVE my email address from this thread!? On Friday, January 19, 2018, 8:27:25 AM EST, Henry wrote: THANK YOU!! THANK YOU!! Configured simply with: % ./configure --enable-g13 --enable-symcryptrun --enable-wks-tools \ ? --with-readline=/usr/local and all tests run seemed to PASS. (I will later be installing gnupg2 on darwin and ubuntu.) Henry 2018-01-19 3:27 GMT+09:00 Werner Koch : > On Thu, 18 Jan 2018 15:41, nbsd4ever at gmail.com said: > >>? --enable-selinux-support --with-libgpg-error-prefix=/usr/local \ >? ? ? ^^^^^^^^^^^^^^^^^^^^^^ > > Ah!? There is a second case where you see the reported error message: > > #ifdef ENABLE_SELINUX_HACKS >? if (1) >? ? { >? ? ? /* We don't allow importing secret keys because that may be used >? ? ? ? ? to put a secret key into the keyring and the user might later >? ? ? ? ? be tricked into signing stuff with that key.? */ >? ? ? log_error (_("importing secret keys not allowed\n")); >? ? ? return 0; >? ? } > #endif > > I wonder why you enable this at all.? I doubt that NetBSD supports > SElinux. > > > Salam-Shalom, > >? ? Werner > > -- > Die Gedanken sind frei.? Ausnahmen regelt ein Bundesgesetz. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Sat Jan 20 16:20:52 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sat, 20 Jan 2018 15:20:52 +0000 Subject: gnupg-2.2.4: how to deal with failed tests In-Reply-To: <1204741851.1427878.1516377022811@mail.yahoo.com> References: <87k1wgals0.fsf@wheatstone.g10code.de> <87y3kw8flo.fsf@wheatstone.g10code.de> <87y3kv6n0i.fsf@wheatstone.g10code.de> <1204741851.1427878.1516377022811@mail.yahoo.com> Message-ID: <2910211309.20180120152052@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday 19 January 2018 at 3:50:22 PM, in , Shannon Mess via Gnupg-users wrote:- > REMOVE my email address from this thread! You are subscribed to the mailing list or not subscribed to it. There is no feature to be removed from an individual discussion thread. In the event you wish to unsubscribe from the list, you can do this at the bottom of the page linked below. http://lists.gnupg.org/mailman/listinfo/gnupg-users Or by sending an email to with the single word "unsubscribe" (without quotes) as the message subject. - -- Best regards MFPA Confusion is always the most honest response -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWmNeVl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +g8jAPoC6PCVQoqrx1gRu594ArZhnzd76l+7LbOQTlhGcUjHJgD9FidVLnA2bKur CES7AV/7RburSe5CU/sNl8eAHzIoawWJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWmNeVl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/0nvD/94it3CD7AuoJXFwzt8pIAdqGkN LiPQhXhrzodc3KMKB8m2WDVuGPA6yzYa7fMRdFIhnlADbm39jlFNYl3bHk+L1xnp Lz5n+moj9tf7/+/Yn+K7SaBdRTtvk9QO0YZe3pfsfBOiLxgSXg5Ub5JNknF3gTMB pa1OziTSN5TYelsNtVVrvOrYvXEqKs/GeRnexdJMUi42oGDxlbLZtLjDQ+KxbLbk JiBTFdTrritRQ4QTOPqp4NGFGumLtu81tiJPRZFELKUTRfHPDMV8QblqTFXUwSU3 TjWBNmOfWkdPu9wY/dofH9aEcbMj0qbFAMppGyK83MwFo47zrdhGXbVhzjceZtPI g/zGnGSvvIarU7GcK/GA/icZiRdXyR3jLpGmVg1BBka8KfHfIEWT6SB+8Y/AR3oc /rmduYkUUfmJggDRzpFXsHgOY68j/f8GOIeBRl1yidg52tBuoXWLQbVn4L/bz/KF yD9CQPDt7pcOo5AmutkxIT+qj3D4KDdQwWwiFwXdh/vUKxdlM/FZHO0XkoaIRPQn SZLeAnfAUOVw4B20EfY1Cmnv1mxG4jqKegNEFgtaywP9ywYeXfYbYKtpircYReY6 h99vHlXt9M6YAAZoO+Xr4wB8h1M8UvA3ZEVdRgtXIWe/1MMAc9/i3vc209VjHQvA bt7S/gLIPiGBpfadMQ== =47as -----END PGP SIGNATURE----- From mail at maciej.szmigiero.name Sun Jan 21 00:16:53 2018 From: mail at maciej.szmigiero.name (Maciej S. Szmigiero) Date: Sun, 21 Jan 2018 00:16:53 +0100 Subject: SCM SPR332 PIN entry doesn't work In-Reply-To: References: Message-ID: <21fbf99f-49a8-745e-8804-34266f546f54@maciej.szmigiero.name> On 14.01.2018 01:01, Maciej S. Szmigiero wrote: > Hi all, > > I've just received a SCM SPR332 from FLOSS-Shop (marked as "SPR332 V2" > on its bottom side) and while its basic reader functionality seems to work > just fine I can't get the secure PIN entry mode to work at all. > > I've tried two different OpenPGP cards, tried both GnuPG built-in CCID > driver and the pcsc-lite one to no avail. > > I've even tried the latest vendor Windows driver (with OpenSC and a constant > length PIN verify operation), but the behavior in each of these setups was > always the same: > Upon typing and accepting a PIN the "key" LED on the reader continues to > blink for a few seconds, then the reader responds with "64 00" result at > the USB interface level (which is probably the code for > "SPE [Secure PIN Entry] operation timed out" error) and then it doesn't > want to communicate with the card anymore. > > A relevant log snippet from GnuPG built-in CCID driver: > DBG: prompting for pinpad entry '||Please unlock the card%0A%0A Number: 0005 00005B0E%0AHolder: ' > DBG: ccid-driver: sending escape sequence to switch to a case 1 APDU > DBG: ccid-driver: PC_to_RDR_Escape: > DBG: ccid-driver: dwLength ..........: 3 > DBG: ccid-driver: bSlot .............: 0 > DBG: ccid-driver: bSeq ..............: 56 > DBG: ccid-driver: [0007] 00 00 00 80 02 00 > DBG: ccid-driver: RDR_to_PC_Escape: > DBG: ccid-driver: dwLength ..........: 0 > DBG: ccid-driver: bSlot .............: 0 > DBG: ccid-driver: bSeq ..............: 56 > DBG: ccid-driver: bStatus ...........: 0 > DBG: ccid-driver: buffer[9] .........: 00 > DBG: ccid-driver: PC_to_RDR_Secure: > DBG: ccid-driver: dwLength ..........: 19 > DBG: ccid-driver: bSlot .............: 0 > DBG: ccid-driver: bSeq ..............: 57 > DBG: ccid-driver: bBMI ..............: 0x00 > DBG: ccid-driver: wLevelParameter ...: 0x0000 > DBG: ccid-driver: [0010] 00 00 82 00 00 19 > DBG: ccid-driver: [0016] 06 02 01 09 04 00 00 00 00 00 20 00 82 > DBG: ccid-driver: RDR_to_PC_DataBlock: > DBG: ccid-driver: dwLength ..........: 2 > DBG: ccid-driver: bSlot .............: 0 > DBG: ccid-driver: bSeq ..............: 57 > DBG: ccid-driver: bStatus ...........: 0 > DBG: ccid-driver: [0010] 64 00 > DBG: dismiss pinpad entry prompt > verify CHV2 failed: Operation cancelled > app_check_pin failed: Operation cancelled > DBG: ccid-driver: PC_to_RDR_XfrBlock: > DBG: ccid-driver: dwLength ..........: 9 > DBG: ccid-driver: bSlot .............: 0 > DBG: ccid-driver: bSeq ..............: 58 > DBG: ccid-driver: bBWI ..............: 0x04 > DBG: ccid-driver: wLevelParameter ...: 0x0000 > DBG: ccid-driver: [0010] 00 00 05 00 CA 00 > DBG: ccid-driver: [0016] 6E 00 A1 > DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT > ccid_transceive failed: (0x1000a) > apdu_send_simple(0) failed: card I/O error > DBG: ccid-driver: PC_to_RDR_XfrBlock: > DBG: ccid-driver: dwLength ..........: 9 > DBG: ccid-driver: bSlot .............: 0 > DBG: ccid-driver: bSeq ..............: 59 > DBG: ccid-driver: bBWI ..............: 0x04 > DBG: ccid-driver: wLevelParameter ...: 0x0000 > DBG: ccid-driver: [0010] 00 00 05 00 CA 00 > DBG: ccid-driver: [0016] C5 00 0A > DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT > ccid_transceive failed: (0x1000a) > apdu_send_simple(0) failed: card I/O error > > I've tried also an EMV card with this reader, the behavior > is slightly different in this case: the typed PIN is accepted > immediately, but "00 82 00 82" T=1 protocol error is returned > at the USB interface level. > And the card communication still works after this. > > The same cards (two OpenPGP ones and one EMV) accept PIN input without > problems using exactly the same software setup when driven by a > different PIN pad reader (a HP smart card keyboard). > > What's interesting is that the reader reports firmware version 7.0 > while all the references I could find talk about firmware version 6.01. > > The vendor Windows driver also has a firmware version check utility > that explicitly checks for firmware version 6.01 (unfortunately, > it is just a checking tool without up- or down-grade capability). > > Now, I wonder: did anybody earlier spotted a similar behavior with this > or other SCM/Identiv readers? > Or is it possible that this reader is loaded with some non-standard > firmware? > It reports as "SPRx32 USB Smart Card Reader", which suggests the firmware > should be common with a well-tested SPR532 model. Has anybody used this reader as a PIN pad successfully or had similar issues? Thanks, Maciej From dank at kegel.com Sun Jan 21 00:40:19 2018 From: dank at kegel.com (Dan Kegel) Date: Sat, 20 Jan 2018 15:40:19 -0800 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: References: <20180117032459.GA22448@raf.org> <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> <87wp0humva.fsf@fifthhorseman.net> <871sioufmp.fsf@fifthhorseman.net> <871sim5wub.fsf@fifthhorseman.net> Message-ID: On Thu, Jan 18, 2018 at 7:58 PM, Dan Kegel wrote: >> The keys referred to via signed-by are the only acceptable keys for the >> associated apt repo. >> >> does that make sense? > > That'd be great if it worked. Since it's hard to explain what's broken > without a simple script showing exactly what I'm doing, let's just > hold that thought until I post one. I spent a little while cleaning up my script and found the problem, whew! Here's part of the log: + gpg2 -q --pinentry-mode loopback --passphrase --personal-digest-preferences SHA256 --gen-key gpg.in.tmp + gpg2 --armor --export temp-repo at example.com ... + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get update ... Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring /tmp/obs_localbuild_keyrings_dank.tmp/keyrings/localhost.gpg verify --status-fd 3 /tmp/apt.sig.nD3tum /tmp/apt.data.OVJLiX Read: [GNUPG:] ERRSIG 505A301EE37484C6 1 8 01 1516484740 9 Got ERRSIG Read: [GNUPG:] NO_PUBKEY 505A301EE37484C6 Even with apt debug logging on, that wasn't enough to make the problem obvious. I had to add exec 2> /tmp/apt-key.log.$$ set -x to the top of /usr/bin/apt-key. Grepping for that key in /tmp/apt-key*, I found + gpgv --homedir /tmp/tmp.oM7RZ707db --keyring /tmp/obs_localbuild_keyrings_dank.tmp/keyrings/localhost.gpg --ignore-time-conflict --status-fd 3 /tmp/apt.sig.nD3tum /tmp/apt.data.OVJLiX gpgv: Signature made Sat Jan 20 13:45:40 2018 PST using RSA key ID E37484C6 gpgv: [don't know]: invalid packet (ctb=2d) gpgv: keydb_search failed: invalid packet gpgv: Can't check signature: public key not found Well, well. That 'invalid packet' appears to be a telltale sign of using --armor where one shouldn't, and looking at my first log, you can see a --armor. Removing it made everything happy. So this was a case of a) dumb user and b) poor diagnostics from apt. Also, now that I've ripped out all gpg1 support from my script, I realize that gpg-agent is nearly well behaved. Only possible rough spots I ran into were: - having to enable pinentry (ubuntu 16.04's gpg is old) - not knowing a clean way to tidy up an old gnupghome and its agent without hanging if the agent is missing - the gpg man page says --dearmor isn't very useful. I beg to differ :-) - might save time and anguish if apt-key (and thus gpg[v]?) accepted armored keyrings even if filename ends in .gpg Thanks for the encouragement. All's well that ends well. I'm sure I'll trip over my shoelaces again soon enough! - Dan From tmz at pobox.com Sun Jan 21 01:08:56 2018 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 20 Jan 2018 19:08:56 -0500 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: References: <20180117032459.GA22448@raf.org> <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> <87wp0humva.fsf@fifthhorseman.net> <871sioufmp.fsf@fifthhorseman.net> <871sim5wub.fsf@fifthhorseman.net> Message-ID: <20180121000856.GT1427@zaya.teonanacatl.net> Dan Kegel wrote: > - might save time and anguish if apt-key (and thus gpg[v]?) accepted > armored keyrings even if filename ends in .gpg I think that's https://dev.gnupg.org/T2290, in case you want to follow it or submit a patch to implement it. Werner did provide some details about how it would ideally be done. If I was more capable with C, I'd give it a try since I'd like to see gpgv work with armored keyrings too. -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something. -- Robert Heinlein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From dank at kegel.com Sun Jan 21 03:19:10 2018 From: dank at kegel.com (Dan Kegel) Date: Sat, 20 Jan 2018 18:19:10 -0800 Subject: Will gpg 1.x remain supported for the foreseeable future? In-Reply-To: <20180121000856.GT1427@zaya.teonanacatl.net> References: <20180117032459.GA22448@raf.org> <8cba0ba6-bfc3-ab07-498e-c60c4bb6f10b@sixdemonbag.org> <87wp0humva.fsf@fifthhorseman.net> <871sioufmp.fsf@fifthhorseman.net> <871sim5wub.fsf@fifthhorseman.net> <20180121000856.GT1427@zaya.teonanacatl.net> Message-ID: On Sat, Jan 20, 2018 at 4:08 PM, Todd Zullinger wrote: > I think that's https://dev.gnupg.org/T2290 Thanks. Say, anyone know how to get bug tracker problems resolved? Somehow my email address there lacks a dot before .com, so I can't get confirmation emails. - Dan From doron.behar at gmail.com Sun Jan 21 17:41:54 2018 From: doron.behar at gmail.com (Doron Behar) Date: Sun, 21 Jan 2018 18:41:54 +0200 Subject: Why exactly does pinentry fails with gpg-agent and ssh support? Message-ID: <20180121164154.toj5wok32y7i55rx@NUC.localdomain> Hello everyone, I've recently encountered the problem explained in item #3 here: https://www.gnupg.org/documentation/manuals/gnupg/Common-Problems.html and I would like to discuss it. I use the `systemd` user service provided with Arch Linux and it's `ExecStart` is: /usr/bin/gpg-agent --supervised I followed the recommended instructions on the official website and on the Arch Linux's wiki (https://wiki.archlinux.org/index.php/GnuPG#SSH_agent) I also read the following bugs / threads: https://unix.stackexchange.com/questions/217737/pinentry-fails-with-gpg-agent-and-ssh https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851440 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854376 As far as I understand, because I use `systemd`'s user service, whenever I want to unlock an authentication key I need to run the command `gpg-connect-agent updatestartuptty /bye`. ## My question is this: The official documentation says: > SSH has no way to tell the gpg-agent what terminal or X display it is > running on. So when remotely logging into a box where a gpg-agent with > SSH support is running, the pinentry will get popped up on whatever > display the gpg-agent has been started. Perhaps it would be possible to create some kind of feature request / patch / merge request for ssh and enabling users to run this command before connecting to an ssh server? BTW I encountered a stackoverflow question on the subject that raises the same problem: https://stackoverflow.com/questions/32574142/can-i-set-up-a-before-hook-on-certain-ssh-hosts From cousinwednesday at mail.com Mon Jan 22 01:36:17 2018 From: cousinwednesday at mail.com (Zechariah Seth) Date: Mon, 22 Jan 2018 01:36:17 +0100 Subject: failed to convert unprotected openpgp key: Checksum error Message-ID: Simon Kissane wrote: > (This is just a test key generated for testing purposes, so it is fine > to share it publicly.) Interesting "User ID" on that key: "root:testGpg:key_54503F79_3794_456C_8725_8977A68B71C1" I hope no one is foolish enough to import your key and run your script. From skissane at medallia.com Mon Jan 22 03:40:33 2018 From: skissane at medallia.com (Simon Kissane) Date: Mon, 22 Jan 2018 13:40:33 +1100 Subject: failed to convert unprotected openpgp key: Checksum error In-Reply-To: References: Message-ID: On Mon, Jan 22, 2018 at 11:36 AM, Zechariah Seth wrote: > Simon Kissane wrote: >> (This is just a test key generated for testing purposes, so it is fine >> to share it publicly.) > > Interesting "User ID" on that key: > "root:testGpg:key_54503F79_3794_456C_8725_8977A68B71C1" > > I hope no one is foolish enough to import your key and run your script. Hi Zechariah, thank you for taking the time to have a look at this for me. It sounds like you are concerned that running my script may import some strange key into your GPG home. If you read the script, you will see that it creates two new GPG homes under a temporary directory, so no odd keys are going to be imported into your day-to-day GPG config. I realise the User ID is weird. To explain, in the use case I am working on we are only using GPG for file encryption/decryption using keys pre-agreed out of band. As such, we aren't actually using any of the PGP "web-of-trust" functionality, and the actual User IDs are rather irrelevant. Maybe we should just use S/MIME or CMS instead (and I'm looking into that option), but since we are already using GPG for this I was looking at how to possibly integrate our existing usage of GPG with an external key management system. That said, I have changed my key generation code to generate more normal looking User IDs, as you can see with this key: https://gist.github.com/skissane/a64756f32e62fbc5b51ee1f4eef22575 which has User ID: Test Key 123 And, if you run the new key against my script, you get the same error, showing that problem (whatever it is) isn't the User ID. (My reading of RFC4880 section 5.11 is that having an email in the User ID is just a convention not mandatory, so software should be robust in the face of User IDs breaking that convention.) Thank you Simon On Mon, Jan 22, 2018 at 11:36 AM, Zechariah Seth wrote: > Simon Kissane wrote: >> (This is just a test key generated for testing purposes, so it is fine >> to share it publicly.) > > Interesting "User ID" on that key: > "root:testGpg:key_54503F79_3794_456C_8725_8977A68B71C1" > > I hope no one is foolish enough to import your key and run your script. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From wk at gnupg.org Mon Jan 22 08:33:44 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Jan 2018 08:33:44 +0100 Subject: failed to convert unprotected openpgp key: Checksum error In-Reply-To: (Simon Kissane's message of "Mon, 22 Jan 2018 13:40:33 +1100") References: Message-ID: <87shay2vqf.fsf@wheatstone.g10code.de> On Mon, 22 Jan 2018 03:40, skissane at medallia.com said: > showing that problem (whatever it is) isn't the User ID. (My reading of RFC4880 > section 5.11 is that having an email in the User ID is just a convention not > mandatory, so software should be robust in the face of User IDs breaking that Correct. Actually, specifying a mail address with -r or --locate-key changes GnuPG's behaviour in that it tries to find the key in a configured online directory (by default WKD). >> "root:testGpg:key_54503F79_3794_456C_8725_8977A68B71C1" That is an acceptable user-id. I would have used a dot as delimiter but that is a personal taste. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Jan 22 08:43:41 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Jan 2018 08:43:41 +0100 Subject: Why exactly does pinentry fails with gpg-agent and ssh support? In-Reply-To: <20180121164154.toj5wok32y7i55rx@NUC.localdomain> (Doron Behar's message of "Sun, 21 Jan 2018 18:41:54 +0200") References: <20180121164154.toj5wok32y7i55rx@NUC.localdomain> Message-ID: <87o9lm2v9u.fsf@wheatstone.g10code.de> On Sun, 21 Jan 2018 17:41, doron.behar at gmail.com said: > As far as I understand, because I use `systemd`'s user service, whenever > I want to unlock an authentication key I need to run the command > `gpg-connect-agent updatestartuptty /bye`. Although I have no experience with the peculiarities of the --supervised mode, there is no need to run the updatestartuptty command. That command is only used to switch gpg-agent's default $DISPLAY and tty to the one active in the shell you run this command. This is required because the ssh-agent protocol has no way to tell gpg-agent (or ssh-agent) the DISPLAY/tty which shall be used to pop-up the Pinentry. Another problem with ssh is that ssh can't start gpg-agent on the the fly. Thus you need to make sure that gpg-agent has already been started when you use ssh. A way to ensure this is to run gpg -K which lists all your private keys and as a side-effects starts gpg-agent. You can also do gpg-connect-agent /bye because it exhibits the same side-effect. The suggested way to start gpg-agent for ssh is to use gpgconf --launch gpg-agent Salam-Shalom, Werner p.s. And the best solution would be to extended the ssh-agent protocol and openssh to allow starting of an arbitrary process and conveying some environment variables. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andre at colomb.de Mon Jan 22 09:36:34 2018 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Mon, 22 Jan 2018 09:36:34 +0100 Subject: Why exactly does pinentry fails with gpg-agent and ssh support? In-Reply-To: <87o9lm2v9u.fsf@wheatstone.g10code.de> References: <20180121164154.toj5wok32y7i55rx@NUC.localdomain> <87o9lm2v9u.fsf@wheatstone.g10code.de> Message-ID: <507a6896-5941-547b-db7c-501acc679637@colomb.de> On 2018-01-22 08:43, Werner Koch wrote: >> As far as I understand, because I use `systemd`'s user service, whenever >> I want to unlock an authentication key I need to run the command >> `gpg-connect-agent updatestartuptty /bye`. > > Although I have no experience with the peculiarities of the --supervised > mode, there is no need to run the updatestartuptty command. That command > is only used to switch gpg-agent's default $DISPLAY and tty to the one > active in the shell you run this command. This is required because the > ssh-agent protocol has no way to tell gpg-agent (or ssh-agent) the > DISPLAY/tty which shall be used to pop-up the Pinentry. I can confirm that it actually IS necessary to send "updatestartuptty" for ssh-agent functionality to work in this scenario. The gpg-agent process started by systemd's user session has no $DISPLAY and no $GPG_TTY set (looking at /proc/###/environ). Its cmdline does not contain --supervised either. I always wondered why I got the message "agent refused operation" when using an SSH key from gpg-agent. Restarting gpg-agent manually after logging in was my workaround thus far, but today I found out that updatestartuptty suffices. Strange thing is, I could use the GPG part of gpg-agent already before issuing that command. Why does that behave differently? Can something be done to the systemd user unit file so the process gets told the correct $DISPLAY at least? Kind regards Andr? -- Greetings... From: Andr? Colomb From peter at digitalbrains.com Mon Jan 22 11:52:21 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 22 Jan 2018 11:52:21 +0100 Subject: Why exactly does pinentry fails with gpg-agent and ssh support? In-Reply-To: <507a6896-5941-547b-db7c-501acc679637@colomb.de> References: <20180121164154.toj5wok32y7i55rx@NUC.localdomain> <87o9lm2v9u.fsf@wheatstone.g10code.de> <507a6896-5941-547b-db7c-501acc679637@colomb.de> Message-ID: <1c90403a-8143-1d6d-57bb-de7664ba0502@digitalbrains.com> On 22/01/18 09:36, Andr? Colomb wrote: > Strange thing is, I could use the GPG part of gpg-agent already before > issuing that command. Why does that behave differently? Because GnuPG *does* pass TTY and display to the agent. > Can something be done to the systemd user unit file so the process gets > told the correct $DISPLAY at least? It works for me out-of-the-box on Debian stretch/stable, supervised by systemd... if I SSH before I do any GnuPG stuff, it correctly prompts me in the (graphical) session that started the agent. So something must be different in your installation. 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 dkg at fifthhorseman.net Mon Jan 22 11:34:10 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 22 Jan 2018 11:34:10 +0100 Subject: Why exactly does pinentry fails with gpg-agent and ssh support? In-Reply-To: <87o9lm2v9u.fsf@wheatstone.g10code.de> References: <20180121164154.toj5wok32y7i55rx@NUC.localdomain> <87o9lm2v9u.fsf@wheatstone.g10code.de> Message-ID: <87bmhmji71.fsf@fifthhorseman.net> On Mon 2018-01-22 08:43:41 +0100, Werner Koch wrote: > Another problem with ssh is that ssh can't start gpg-agent on the the > fly. Thus you need to make sure that gpg-agent has already been started > when you use ssh. A way to ensure this is to run > > gpg -K the systemd user service takes care of automatically launching the gpg-agent when the user connects to it via the ssh-agent protocol, so this isn't required when using systemd. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Mon Jan 22 13:31:43 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 22 Jan 2018 13:31:43 +0100 Subject: [OT] Re: failed to convert unprotected openpgp key: Checksum error In-Reply-To: <87shay2vqf.fsf@wheatstone.g10code.de> References: <87shay2vqf.fsf@wheatstone.g10code.de> Message-ID: <930c1f30-fc04-2257-cd2a-a913e7f9e5cd@sumptuouscapital.com> On 01/22/2018 08:33 AM, Werner Koch wrote: > That is an acceptable user-id. I would have used a dot as delimiter but > that is a personal taste. Dot is a permitted part of username in POSIX though, while : is not :) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Don't be afraid to go out on a limb. That's where the fruit is." (H. Jackson Browne) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon Jan 22 12:53:45 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 22 Jan 2018 12:53:45 +0100 Subject: Why exactly does pinentry fails with gpg-agent and ssh support? In-Reply-To: <1c90403a-8143-1d6d-57bb-de7664ba0502@digitalbrains.com> References: <20180121164154.toj5wok32y7i55rx@NUC.localdomain> <87o9lm2v9u.fsf@wheatstone.g10code.de> <507a6896-5941-547b-db7c-501acc679637@colomb.de> <1c90403a-8143-1d6d-57bb-de7664ba0502@digitalbrains.com> Message-ID: <87zi56hzxy.fsf@fifthhorseman.net> On Mon 2018-01-22 11:52:21 +0100, Peter Lebbing wrote: > It works for me out-of-the-box on Debian stretch/stable, supervised by > systemd... if I SSH before I do any GnuPG stuff, it correctly prompts me > in the (graphical) session that started the agent. So something must be > different in your installation. It may also depend on how the session itself is started. Maybe one of you is starting the user session in non-graphical mode (either a vt login, or maybe ssh?), while the other one is starting it directly from a graphical display manager? do you have dbus-user-session installed? (it is recommended) --dkg From andre at colomb.de Mon Jan 22 18:06:48 2018 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Mon, 22 Jan 2018 18:06:48 +0100 Subject: Why exactly does pinentry fails with gpg-agent and ssh support? In-Reply-To: <87zi56hzxy.fsf@fifthhorseman.net> References: <20180121164154.toj5wok32y7i55rx@NUC.localdomain> <87o9lm2v9u.fsf@wheatstone.g10code.de> <507a6896-5941-547b-db7c-501acc679637@colomb.de> <1c90403a-8143-1d6d-57bb-de7664ba0502@digitalbrains.com> <87zi56hzxy.fsf@fifthhorseman.net> Message-ID: <24226ee0-bf39-c35c-aef1-46d56f2d4d90@colomb.de> Hello Daniel, I'm on Ubuntu 17.10 with GnuPG 2.1.15, by the way. Daniel Kahn Gillmor wrote on 2018-01-22 12:53 (UTC+0100) > It may also depend on how the session itself is started. Maybe one of > you is starting the user session in non-graphical mode (either a vt > login, or maybe ssh?), while the other one is starting it directly from > a graphical display manager? The session is started by GDM3, using the vanilla gnome-session scripts (not the adapted ubuntu-session, also based on GNOME 3). The systemd user unit file is copied from /usr/lib/systemd/user/gpg-agent.service and the Upstart-specific "initctl" command line commented out. The main difference I see here is that I have enabled the user unit by symlinking from ~/.config/systemd/user/default.target.wants/, whereas the Ubuntu package includes the symlink in /usr/lib/systemd/user/graphical-session-pre.target.wants/. acolomb at barnov:~$ systemctl --user status gpg-agent.service Loaded: loaded (/home/acolomb/.config/systemd/user/gpg-agent.service; enabled; vendor preset: enabled) > do you have dbus-user-session installed? (it is recommended) Yes. (from your other message:) > the systemd user service takes care of automatically launching the > gpg-agent when the user connects to it via the ssh-agent protocol, so > this isn't required when using systemd. I can't see how it does that in my packaged Ubuntu version (2.1.15), there is no gpg-agent.socket unit file anywhere? Any other ideas on how to debug this? What logging should I enable for gpg-agent and how? Btw. it affects both my Yubikey as well as file-based authentication subkeys, so not specific to scdaemon apparently. Regards Andr? -- Greetings... From: Andr? Colomb From daniele at grinta.net Mon Jan 22 18:31:25 2018 From: daniele at grinta.net (Daniele Nicolodi) Date: Mon, 22 Jan 2018 10:31:25 -0700 Subject: [OT] Re: failed to convert unprotected openpgp key: Checksum error In-Reply-To: <930c1f30-fc04-2257-cd2a-a913e7f9e5cd@sumptuouscapital.com> References: <87shay2vqf.fsf@wheatstone.g10code.de> <930c1f30-fc04-2257-cd2a-a913e7f9e5cd@sumptuouscapital.com> Message-ID: On 1/22/18 5:31 AM, Kristian Fiskerstrand wrote: > On 01/22/2018 08:33 AM, Werner Koch wrote: >> That is an acceptable user-id. I would have used a dot as delimiter but >> that is a personal taste. > > Dot is a permitted part of username in POSIX though, while : is not :) Uh? As far as I know, the only characters not allowed are / and null. Cheers, Daniele From kristian.fiskerstrand at sumptuouscapital.com Mon Jan 22 20:30:35 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 22 Jan 2018 20:30:35 +0100 Subject: [OT] Re: failed to convert unprotected openpgp key: Checksum error In-Reply-To: References: <87shay2vqf.fsf@wheatstone.g10code.de> <930c1f30-fc04-2257-cd2a-a913e7f9e5cd@sumptuouscapital.com> Message-ID: On 01/22/2018 06:31 PM, Daniele Nicolodi wrote: > On 1/22/18 5:31 AM, Kristian Fiskerstrand wrote: >> On 01/22/2018 08:33 AM, Werner Koch wrote: >>> That is an acceptable user-id. I would have used a dot as delimiter but >>> that is a personal taste. >> >> Dot is a permitted part of username in POSIX though, while : is not :) > > Uh? As far as I know, the only characters not allowed are / and null. http://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap03.html#tag_03_426 3.426 User Name A string that is used to identify a user; see also User Database. To be portable across systems conforming to IEEE Std 1003.1-2001, the value is composed of characters from the portable filename character set. The hyphen should not be used as the first character of a portable user name. http://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap03.html#tag_03_276 The set of characters from which portable filenames are constructed. A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ - -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Cogito ergo sum I think, therefore I am -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From daniele at grinta.net Mon Jan 22 20:46:01 2018 From: daniele at grinta.net (Daniele Nicolodi) Date: Mon, 22 Jan 2018 12:46:01 -0700 Subject: [OT] Re: failed to convert unprotected openpgp key: Checksum error In-Reply-To: References: <87shay2vqf.fsf@wheatstone.g10code.de> <930c1f30-fc04-2257-cd2a-a913e7f9e5cd@sumptuouscapital.com> Message-ID: On 1/22/18 12:30 PM, Kristian Fiskerstrand wrote: > On 01/22/2018 06:31 PM, Daniele Nicolodi wrote: >> On 1/22/18 5:31 AM, Kristian Fiskerstrand wrote: >>> On 01/22/2018 08:33 AM, Werner Koch wrote: >>>> That is an acceptable user-id. I would have used a dot as delimiter but >>>> that is a personal taste. >>> >>> Dot is a permitted part of username in POSIX though, while : is not :) >> >> Uh? As far as I know, the only characters not allowed are / and null. > > http://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap03.html#tag_03_426 > > 3.426 User Name Sorry, I should not be writing email before my morning coffee: I read filenames instead than usernames. Cheers, Daniele From gnupg-users at spodhuis.org Mon Jan 22 21:37:37 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Mon, 22 Jan 2018 15:37:37 -0500 Subject: failed to convert unprotected openpgp key: Checksum error In-Reply-To: References: Message-ID: <20180122203737.GA6255@tower.spodhuis.org> On 2018-01-19 at 19:57 +1100, Simon Kissane wrote: > However, when I try to decrypt data encrypted with the private key, I > get a "failed to convert unprotected openpgp key: Checksum error" Simpler check: % gpg --export-secret-key gpg: key 4252EB6983CE74C44F549B6F8666715904EE61F2: error receiving key from agent: Checksum error - skipped gpg: WARNING: nothing exported If I use `gpg --expert --full-generate-key` to make an SCEA RSA/4096 key, then it looks almost identical in structure to yours. If I just `gpg --import` a dearmored version of the key, then I get a checksum error at that time: gpg: key 68F870F8C0FAA42B: public key "root:testGpg:key_54503F79_3794_456C_8725_8977A68B71C1" imported gpg: key 68F870F8C0FAA42B/68F870F8C0FAA42B: error sending to agent: Checksum error so something in the scripted setup you created suppressed that error message, which is Unfortunate by GnuPG. The key still ends up added to the keyring in the above, even with the error, but it's unusable. This might be a bug in GnuPG: IMO if it's broken and will never be usable, then it should not be added and gpg should exit false. So at this point, it looks to me like it really is an incorrect checksum, exposing unfortunate edge-case handling in GnuPG. -Phil From simon at josefsson.org Tue Jan 23 09:01:25 2018 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 23 Jan 2018 09:01:25 +0100 Subject: "best" ed25519/curve25519 setup? In-Reply-To: <20180101183331.GA7187__38237.3872948394$1514838024$gmane$org@localhost.localdomain> (Guilhem Moulin's message of "Mon, 1 Jan 2018 19:33:31 +0100") References: <87a7xxso71.fsf@latte.josefsson.org> <20180101183331.GA7187__38237.3872948394$1514838024$gmane$org@localhost.localdomain> Message-ID: <87d121ovfu.fsf@latte.josefsson.org> Guilhem Moulin writes: > Hi Simon, > > On Mon, 01 Jan 2018 at 14:28:34 +0100, Simon Josefsson wrote: >> I want to use ed25519/curve25519, but right now I have an offline >> master RSA key with three subkeys. Does it work well to add new >> subkeys for Ed25519/Curve25519? What is the user experience in >> various applications? I'm thinking MUAs, SSH, git, gpg itself, and >> also more exotic approaches like K9Mail. > > AFAICT multiple Ed25519/Curve25519 subkeys work fine, with the following > caveats: > > * You'll want to sign with both your Ed25519 and non-ECC (sub-)keys, > otherwise non-ECC capable OpenPGP implementations won't be able to > verify your data signatures. You can do this by adding > > local-user $FINGERPRINT! > > for each (sub)key to sign with (note the trailing exclamation mark > to specify the subkey). Have you noticed any problem with this approach? I could imagine some software might be equally confused by two signatures, or become confused that GnuPG "under the hood" adds another signature. > * You'll want to create your Curve25519 encryption subkey *after* the > non-ECC one, as `gpg --encrypt --recipient $KEYID` only uses the > most recent valid encryption-capable subkey, I think. So if you > have an older non-ECC encryption subkey, older gpg(1) will encrypt > to it while ?2.1 will use the Curve25519 encryption subkey. That is an important aspect, thank you! >> The alternative for me of course is to create a brand new key, with an >> offline Ed25519 master key, plus some subkeys. Has anyone done this, >> and can share their experience? > > IMHO it's too early to use an Ed25519 master key in production, because > there are still a lot of legacy systems out there and that will make the > whole key unusable for encryption and verification. It's fine to start > bring such key to KSPs to improve its reputation and have a less painful > key rollover later, though :-) I already have a good RSA-based master key setup: RSA offline master key RSA subkey for signature RSA subkey for decryption RSA subkey for authentication So I'm thinking that my new setup should be 25519-based. Would you want to use separate Curve25519 keys for authentication and signatures? So I guess the "perfect" setup for me would then be to add the following new key: Ed25519 offline master key Ed25519 subkey for signature Curve25519 subkey for authentication Curve25519 subkey for decryption ? I could adopt the middle way and continue to use my current RSA-based key and a new Ed25519-based key, and have both algorithms available as subkeys. RSA offline master key RSA subkey for signature RSA subkey for decryption RSA subkey for authentication Ed25519 subkey for signature Curve25519 subkey for authentication Curve25519 subkey for decryption Ed25519 offline master key RSA subkey for signature RSA subkey for decryption RSA subkey for authentication Ed25519 subkey for signature Curve25519 subkey for authentication Curve25519 subkey for decryption I wonder if I should re-use the RSA subkeys from my current key into the new one... I suppose for SSH it would be useful, but for anything OpenPGP-related it should be based on the master key id, right? Algorithm migration is really tricky... /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From dgray4656 at yahoo.com Tue Jan 23 02:12:55 2018 From: dgray4656 at yahoo.com (David Gray) Date: Mon, 22 Jan 2018 20:12:55 -0500 Subject: GnuPG 2.2.4 on Windows - problems accessing some HKPS keyservers Message-ID: <00e901d393e7$4d94eb50$e8bec1f0$@yahoo.com> Good Evening - I'm running GnuPG 2.2.4 on Windows. I'm able to successfully query the SKS keyserver pool via HKPS (hkps://hkps.pool.sks-keyservers.net) with no problems. I'm trying to query the hkps://keys.mailvelope.com keyserver, and I'm not having any luck. I suspect I don't have the appropriate hkp-cacert referenced in the dirmngr, but I got the certificate by browsing to https://keys.mailserver.com, exporting the root cert in the certification path as a Base-64 encoded X.509 file (with .pem extension) and copying it to my gnupg home directory, and the hkp-cacert line in dirmngr.conf references that .PEM file. The cert thumbprint shows: ad7e1c28b064ef8f6003402014c3d0e3370eb58a in windows certmgr, and the full contents of that .pem file appear at the bottom of this message for reference. I'm hoping someone may be able to point me in the right direction to troubleshoot this a bit further - I suspect I've done something wrong but I'm not sure how to identify exactly what it is. Details below - Thanks! Dave This is what I get when I attempt to lookup the key for patrick at enigmail.com at hkps://keys.mailvelope.com: C:\Users\dave>gpg --debug-all -vvv --search-keys patrick at enigmail.com gpg: reading options from 'C:/Users/dave/AppData/Roaming/gnupg/gpg.conf' gpg: using character set 'CP437' gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: DBG: [not enabled in the source] start gpg: DBG: chan_0x00000180 <- # Home: C:/Users/dave/AppData/Roaming/gnupg gpg: DBG: chan_0x00000180 <- # Config: C:/Users/dave/AppData/Roaming/gnupg/dirmngr.conf gpg: DBG: chan_0x00000180 <- OK Dirmngr 2.2.4 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_0x00000180 -> GETINFO version gpg: DBG: chan_0x00000180 <- D 2.2.4 gpg: DBG: chan_0x00000180 <- OK gpg: DBG: chan_0x00000180 -> KEYSERVER --clear hkps://keys.mailvelope.com/ gpg: DBG: chan_0x00000180 <- OK gpg: DBG: chan_0x00000180 -> KS_SEARCH -- patrick at enigmail.com gpg: DBG: chan_0x00000180 <- ERR 285212985 Wrong name gpg: error searching keyserver: Wrong name gpg: keyserver search failed: Wrong name gpg: DBG: chan_0x00000180 -> BYE gpg: DBG: [not enabled in the source] stop gpg: keydb: handles=0 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=0 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x00000000 calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks The corresponding logs from dirmngr show: 2018-01-22 19:40:43 dirmngr[1664] handler for fd 864 started 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 -> # Home: C:/Users/dave/AppData/Roaming/gnupg 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 -> # Config: C:/Users/dave/AppData/Roaming/gnupg/dirmngr.conf 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 -> OK Dirmngr 2.2.4 at your service 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 <- GETINFO version 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 -> D 2.2.4 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 -> OK 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 <- KEYSERVER --clear hkps://keys.mailvelope.com/ 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 -> OK 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 <- KS_SEARCH -- patrick at enigmail.com 2018-01-22 19:40:43 dirmngr[1664] TLS handshake failed: Wrong name 2018-01-22 19:40:43 dirmngr[1664] error connecting to 'https://52.50.100.145:443': Wrong name 2018-01-22 19:40:43 dirmngr[1664] command 'KS_SEARCH' failed: Wrong name 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 -> ERR 285212985 Wrong name 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 <- BYE 2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x00000360 -> OK closing connection 2018-01-22 19:40:43 dirmngr[1664] handler for fd 864 terminated By contrast, this is what I get when I query the SKS pool for the same key via HKPS: C:\Users\dave>gpg --debug-all -vvv --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys patrick at enigmail.com gpg: reading options from 'C:/Users/dave/AppData/Roaming/gnupg/gpg.conf' gpg: using character set 'CP437' gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: DBG: [not enabled in the source] start gpg: DBG: chan_0x00000190 <- # Home: C:/Users/dave/AppData/Roaming/gnupg gpg: DBG: chan_0x00000190 <- # Config: C:/Users/dave/AppData/Roaming/gnupg/dirmngr.conf gpg: DBG: chan_0x00000190 <- OK Dirmngr 2.2.4 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_0x00000190 -> GETINFO version gpg: DBG: chan_0x00000190 <- D 2.2.4 gpg: DBG: chan_0x00000190 <- OK gpg: DBG: chan_0x00000190 -> KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net gpg: DBG: chan_0x00000190 <- OK gpg: DBG: chan_0x00000190 -> KS_SEARCH -- patrick at enigmail.com gpg: DBG: chan_0x00000190 <- S PROGRESS tick ? 0 0 gpg: DBG: chan_0x00000190 <- S PROGRESS tick ? 0 0 gpg: DBG: chan_0x00000190 <- S SOURCE https://37.191.226.104:443 gpg: DBG: chan_0x00000190 <- D info:1:1%0A gpg: data source: https://37.191.226.104:443 gpg: DBG: chan_0x00000190 <- D pub:933D9948DC0FA861471B10A9D8A807C7CCEC227B:17:1024:994599961:1549612809:r% 0A gpg: DBG: chan_0x00000190 <- D uid:Test 555 :1101921390::%0A gpg: DBG: chan_0x00000190 <- D uid:Patrick Brunschwig :1242047020::%0A gpg: DBG: chan_0x00000190 <- D uid:Patrick Brunschwig :1101921390::%0A gpg: DBG: chan_0x00000190 <- D uid:Patrick Brunschwig :1101921389::%0A gpg: DBG: chan_0x00000190 <- D uid:Patrick Brunschwig :1116168518::%0A gpg: DBG: chan_0x00000190 <- D uid:Patrick Brunschwig :1136221739::%0A gpg: DBG: chan_0x00000190 <- D uat::::%0A gpg: DBG: chan_0x00000190 <- D %0D%0A gpg: DBG: chan_0x00000190 <- OK gpg: DBG: iobuf-1.0: close '?' (1) Test 555 Patrick Brunschwig Patrick Brunschwig Patrick Brunschwig Patrick Brunschwig Patrick Brunschwig 1024 bit DSA key 0xD8A807C7CCEC227B, created: 2001-07-08, expires: 2019-02-08 (revoked) Keys 1-1 of 1 for "patrick at enigmail.com". Enter number(s), N)ext, or Q)uit > N gpg: DBG: chan_0x00000190 -> BYE gpg: DBG: [not enabled in the source] stop gpg: keydb: handles=0 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=0 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x00000000 calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks and the corresponding dirmngr logs from this attempt show: 2018-01-22 20:05:47 dirmngr[1664] handler for fd 860 started 2018-01-22 20:05:47 dirmngr[1664] DBG: chan_0x0000035c -> # Home: C:/Users/dave/AppData/Roaming/gnupg 2018-01-22 20:05:47 dirmngr[1664] DBG: chan_0x0000035c -> # Config: C:/Users/dave/AppData/Roaming/gnupg/dirmngr.conf 2018-01-22 20:05:47 dirmngr[1664] DBG: chan_0x0000035c -> OK Dirmngr 2.2.4 at your service 2018-01-22 20:05:47 dirmngr[1664] DBG: chan_0x0000035c <- GETINFO version 2018-01-22 20:05:47 dirmngr[1664] DBG: chan_0x0000035c -> D 2.2.4 2018-01-22 20:05:47 dirmngr[1664] DBG: chan_0x0000035c -> OK 2018-01-22 20:05:47 dirmngr[1664] DBG: chan_0x0000035c <- KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net 2018-01-22 20:05:47 dirmngr[1664] DBG: chan_0x0000035c -> OK 2018-01-22 20:05:47 dirmngr[1664] DBG: chan_0x0000035c <- KS_SEARCH -- patrick at enigmail.com 2018-01-22 20:05:47 dirmngr[1664] DBG: chan_0x0000035c -> S PROGRESS tick ? 0 0 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2a02:c205:3001:3626::1]' 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2606:1c00:2802::b]' 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2001:738:0:600:216:3eff:fe02:42]' 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2001:470:1:116::6]' 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '216.66.15.2' 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '193.224.163.43' 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '193.164.133.100' 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '192.94.109.73' 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '176.9.147.41' 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '51.15.0.17' 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '37.191.226.104' 2018-01-22 20:05:47 dirmngr[1664] resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '18.9.60.141' 2018-01-22 20:06:02 dirmngr[1664] can't connect to '2606:1c00:2802::b': ec=0 2018-01-22 20:06:02 dirmngr[1664] error connecting to 'https://[2606:1c00:2802::b]:443': Unknown error 2018-01-22 20:06:02 dirmngr[1664] selecting a different host due to a timeout 2018-01-22 20:06:17 dirmngr[1664] can't connect to '2a02:c205:3001:3626::1': ec=0 2018-01-22 20:06:17 dirmngr[1664] error connecting to 'https://[2a02:c205:3001:3626::1]:443': Unknown error 2018-01-22 20:06:17 dirmngr[1664] selecting a different host due to a timeout 2018-01-22 20:06:18 dirmngr[1664] certificate already cached 2018-01-22 20:06:18 dirmngr[1664] DBG: BEGIN Certificate 'subject': 2018-01-22 20:06:18 dirmngr[1664] DBG: serial: 008C 2018-01-22 20:06:18 dirmngr[1664] DBG: notBefore: 2017-09-06 22:18:20 2018-01-22 20:06:18 dirmngr[1664] DBG: notAfter: 2018-09-06 22:18:20 2018-01-22 20:06:18 dirmngr[1664] DBG: issuer: CN=sks-keyservers.net CA,O=sks-keyservers.net CA,ST=Oslo,C=NO 2018-01-22 20:06:18 dirmngr[1664] DBG: subject: CN=keys2.kfwebs.net,O=keys2.kfwebs.net,ST=Oslo,C=NO 2018-01-22 20:06:18 dirmngr[1664] DBG: aka: (8:dns-name28:hkps.pool.sks-keyservers.net) 2018-01-22 20:06:18 dirmngr[1664] DBG: aka: (8:dns-name25:*.pool.sks-keyservers.net) 2018-01-22 20:06:18 dirmngr[1664] DBG: aka: (8:dns-name23:pool.sks-keyservers.net) 2018-01-22 20:06:18 dirmngr[1664] DBG: aka: (8:dns-name16:keys2.kfwebs.net) 2018-01-22 20:06:18 dirmngr[1664] DBG: hash algo: 1.2.840.113549.1.1.11 2018-01-22 20:06:18 dirmngr[1664] DBG: SHA1 fingerprint: FED7648D5B388FF1637A561EF288EAC2BF965BA9 2018-01-22 20:06:18 dirmngr[1664] DBG: END Certificate 2018-01-22 20:06:18 dirmngr[1664] DBG: got issuer's certificate: 2018-01-22 20:06:18 dirmngr[1664] DBG: BEGIN Certificate 'issuer': 2018-01-22 20:06:18 dirmngr[1664] DBG: serial: 00AF73C8B4CF9F808F 2018-01-22 20:06:18 dirmngr[1664] DBG: notBefore: 2012-10-09 00:33:37 2018-01-22 20:06:18 dirmngr[1664] DBG: notAfter: 2022-10-07 00:33:37 2018-01-22 20:06:18 dirmngr[1664] DBG: issuer: CN=sks-keyservers.net CA,O=sks-keyservers.net CA,ST=Oslo,C=NO 2018-01-22 20:06:18 dirmngr[1664] DBG: subject: CN=sks-keyservers.net CA,O=sks-keyservers.net CA,ST=Oslo,C=NO 2018-01-22 20:06:18 dirmngr[1664] DBG: hash algo: 1.2.840.113549.1.1.5 2018-01-22 20:06:18 dirmngr[1664] DBG: SHA1 fingerprint: 791B27A38E667F8027814D4E68E7C478A45D5A17 2018-01-22 20:06:18 dirmngr[1664] DBG: END Certificate 2018-01-22 20:06:18 dirmngr[1664] DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 33 3A 72 73 61 28 31 3A 73 35 31 32 3A 27 65 15 7A CD E7 9B CC 33 78 40 55 A6 0A F7 54 57 DC DF 46 F3 3A 40 28 A4 A7 E9 F0 CD B8 F6 7E 18 9D 46 D6 6D AD 73 C6 06 00 D9 89 44 A3 FE 0C 28 DB 93 A6 9E 01 27 BD FC 72 03 98 26 37 7A 9F 20 21 B3 94 DE FE 0F 70 BE D2 47 74 5C A1 60 83 26 17 04 69 90 43 78 D2 9D C5 6B D4 34 D9 5A C5 0A 50 AA 40 31 98 9A 36 B3 6E 6B 1A ED 68 5B 6E 3B B3 E0 35 9C E7 6A EA C4 AC 7D 12 8F D8 22 EE 03 84 CA 16 73 79 C8 78 9B 91 0D 99 65 F8 C7 A5 70 A5 FC 1A 31 4E 0F 2B 28 7C DE 69 0C 29 9F E1 53 E0 03 0D BA D4 E2 3F 85 3D 5B D3 6F 86 64 C0 BF 83 B5 7F 08 59 70 0C 3E 18 57 D4 9C B5 63 5F 2C 3D 78 F4 70 12 A0 35 C1 52 F4 67 61 06 D9 F9 2B A5 C6 D9 21 37 E8 C1 D0 0A F6 74 62 ED 7E 7F 1D 9D 33 A9 47 35 A3 1F C7 85 38 33 DE D8 04 7A 58 56 5C 50 17 EC 4A A9 19 C7 8F 21 9C C8 5C AB 64 B3 AA 82 1D 6D 43 89 03 A7 51 69 BA E1 F6 09 84 5E C5 98 F3 19 4B DD 03 ED 8C 64 41 53 3B 24 CC CF B2 FA FD B9 19 9F 0B AA 02 9B 8E 42 3C AB 6B 7D F9 35 94 2D 66 5C 44 F4 94 37 6F BD F6 F4 57 F3 90 60 13 FD AE 8C 71 90 C7 5B 40 C0 4D 1F 89 CA E7 20 9D 6B B4 5E 8A 1A 1A AA A3 5D 99 35 40 3F 4A 6F 13 CD 0F E8 17 E9 FA 88 CD CB 0D A3 7A 21 CD 11 42 30 BC FC BE 6C 23 A9 8F 61 CD 78 B5 77 B6 5B 47 97 49 69 C8 EE 9F 32 A3 C7 15 29 D2 36 BB 1B 06 37 AC F5 B5 7D A2 A7 A4 30 0C 24 DD AA BB 21 12 40 29 DE 9D 5A 85 25 03 E3 AD 7A 2F 42 3E 41 3F B1 2E 6B 69 8E 62 66 52 A9 4A A4 0F 72 54 1D B9 E9 76 D4 D8 B8 8F AF 1C 1A 98 1E F5 41 2E F2 10 0B 16 14 72 F9 1F 95 4F 5F 79 9F 51 C8 7E 01 6F 2B EF 13 B3 33 4D 6C ED 01 FC B2 A9 8C FE D0 42 71 4C E9 2E 72 67 DB F6 8C 74 50 29 29 28 34 3A 68 61 73 68 36 3A 73 68 61 32 35 36 29 29 2018-01-22 20:06:18 dirmngr[1664] DBG: PKCS#1 block type 1 encoded data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420b7 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 34580c763563ab00a14e9cd7340e3efae03e4458694ca86a2dab9a2d397525 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420b7 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 34580c763563ab00a14e9cd7340e3efae03e4458694ca86a2dab9a2d397525 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify sig:+2765157acde79bcc33784055a60af75457dcdf46f33a4028a4a7e9f0cdb8f67e \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 189d46d66dad73c60600d98944a3fe0c28db93a69e0127bdfc72039826377a9f \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 2021b394defe0f70bed247745ca1608326170469904378d29dc56bd434d95ac5 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 0a50aa4031989a36b36e6b1aed685b6e3bb3e0359ce76aeac4ac7d128fd822ee \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 0384ca167379c8789b910d9965f8c7a570a5fc1a314e0f2b287cde690c299fe1 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 53e0030dbad4e23f853d5bd36f8664c0bf83b57f0859700c3e1857d49cb5635f \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 2c3d78f47012a035c152f4676106d9f92ba5c6d92137e8c1d00af67462ed7e7f \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 1d9d33a94735a31fc7853833ded8047a58565c5017ec4aa919c78f219cc85cab \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 64b3aa821d6d438903a75169bae1f609845ec598f3194bdd03ed8c6441533b24 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: cccfb2fafdb9199f0baa029b8e423cab6b7df935942d665c44f494376fbdf6f4 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 57f3906013fdae8c7190c75b40c04d1f89cae7209d6bb45e8a1a1aaaa35d9935 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 403f4a6f13cd0fe817e9fa88cdcb0da37a21cd114230bcfcbe6c23a98f61cd78 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: b577b65b47974969c8ee9f32a3c71529d236bb1b0637acf5b57da2a7a4300c24 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ddaabb21124029de9d5a852503e3ad7a2f423e413fb12e6b698e626652a94aa4 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 0f72541db9e976d4d8b88faf1c1a981ef5412ef2100b161472f91f954f5f799f \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 51c87e016f2bef13b3334d6ced01fcb2a98cfed042714ce92e7267dbf68c7450 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify n:+d76c5b2e0f5d63540a44b72fffe7addd06a8dddd570a01199eb0f784f0da33c3 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 3e27de830c50a33157906e88e80e132b50892d73ef7f3d143f46816323e64cd6 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 9d0e29da07d4f88c8c1de2b9f197ee7d1a2126aa437721f3ecbf926332429498 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 99ef393d0311594468ed54648c31e56a5fa6b077991f35fea9b85e4020998ae6 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 8272d777fa490c0324ef2d45e396f9cd6a1f883e65ebbee5a657083d16c58692 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 7a9034ce0d787f5c476d17bd4401e68e74418ebf21839823b4196a9214390c30 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: f4e589e2c0ff4ae0153733e31c14623fdc0f97b4641b92918b1814053785dd5c \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 19f06e7b470f65a407d87631424e335c3f12dc5e3af747d186bfad922e60c86e \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 890d1ebb68aa7704818baa6edfe395a45f5858a7e617cb0984ce23386926c662 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 1c7c8681467eaf5471f3c4be9d9aa1cf2ee6c76a8c3b25872533335bf79b7646 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 6e1c043a756396363a2492f13316a0c67659480638db8659dedef513f327dbb7 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 66db0fb1151ba8cbc2448efd5df814f778284ce4a68dc2b8f420eff2bbc90522 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 0598035bd9ff5e6a313fadc894dfcab35557fec37fb4cd796c8daa3279ac19ad \ 2018-01-22 20:06:18 dirmngr[1664] DBG: d0ce8da471bb0ab512901cbda7c2618a68233f9af4165124820fa5c83f95efd1 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: fdf2041f5603f7a5b2480b3d12a4141fd85ff6b724b8acb9bee3dacf7dc39a8e \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 25c4bb2869726ce0bac023ff5163aed9729c7d6bf669cd697e1efab2d6cef539 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify e:+010001 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420b7 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 34580c763563ab00a14e9cd7340e3efae03e4458694ca86a2dab9a2d397525 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify => Good 2018-01-22 20:06:18 dirmngr[1664] DBG: gcry_pk_verify: Success 2018-01-22 20:06:18 dirmngr[1664] certificate is good 2018-01-22 20:06:18 dirmngr[1664] DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 33 3A 72 73 61 28 31 3A 73 35 31 32 3A 11 39 79 D8 C2 ED E0 D5 98 C7 CA 57 B2 DD F6 48 E5 A2 CF B1 A1 35 ED C3 88 99 54 DE 84 2F 03 70 8A 61 9B 61 CE 31 1F E1 61 34 CB F9 5D 06 E0 FF AE 80 7F BA C5 E4 4B 29 21 CC 1D 94 ED 48 12 1A E8 60 CB D3 7E 37 E3 2F 42 06 EC 06 BC 01 42 31 4D 86 57 CC 3D DB F6 7B 6A 99 00 85 D2 D3 A1 90 3F 5F F8 96 3F 68 DE 69 52 61 C6 01 1C 1F CB 8F AE 74 A5 AA 83 C1 70 A0 BD 3E B8 14 CD 06 1F 49 92 64 2E 60 7E DE 31 1A DC 72 AB BB 2D 5A 6C 93 F9 80 07 50 BF 0B DC 3E 9B D8 46 72 33 51 CF 5F 64 E0 EC 56 69 47 54 50 42 97 67 65 BB F8 87 87 68 78 1A 62 F8 0D AD AB 46 45 0C 95 B5 53 76 2A 01 51 82 2F 33 27 1D 3A 4A 47 E7 02 5F B7 3C 3B 72 98 EC B9 D1 9A B3 43 C0 44 35 C2 15 F1 B2 2A 1C 01 44 56 3B 5E 9E E5 6E 3B 54 E5 1C F4 19 CD 38 94 FA E1 0D FD 29 14 4F 7C 03 0E 23 25 1A 45 79 63 23 A5 75 04 68 6D 5C AB B0 FA E3 54 69 81 C3 1F 3C 5B CE 1D 8E 3B AE F0 D3 4B B5 C9 39 A5 13 07 04 63 98 3B 7C F7 AB 3A BC C0 DC 68 6F EE 5C 96 D0 8E EC E6 9B 1D D6 D8 87 72 87 7B 39 48 8D 06 4C 76 F4 23 03 0A 61 BE 1E 05 42 29 40 E9 C1 70 4E FB 56 70 98 A8 AB CD D4 D5 58 02 A8 56 8D 76 D8 ED 76 AC 66 FB 33 09 17 0E 1B E5 B7 16 A3 5A 1C E2 BF 9F FD 2E 79 BD 2E 8A 37 4B 6A 7F 94 7F 8A 75 6E 36 C0 A3 1F 1E 00 E4 12 FF C6 B7 6F 39 09 CD DC 81 35 42 86 C7 50 48 2B 62 01 2F D6 E7 FC 7A DA BD 20 CE 88 D4 52 9D 9F D1 DE 5F 46 65 AB 97 D2 DB BB 20 80 E5 44 22 0B 5D 2C 9E 6B 3B B4 6A 3F EF 75 3D D8 15 05 CF 72 FB 79 16 47 F9 C2 23 53 A3 9D DF EF 6F E3 60 42 5D EA AA 61 5A BA 68 2A AA F0 1B 04 E9 45 40 8C 85 82 14 B7 AE 61 B1 3C 42 88 92 79 9C A7 B7 F6 1E 3A B2 29 29 28 34 3A 68 61 73 68 34 3A 73 68 61 31 29 29 2018-01-22 20:06:18 dirmngr[1664] DBG: PKCS#1 block type 1 encoded data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffff0030213009 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 06052b0e03021a050004148cde40bdb9afea05d403948f6bfd58aaab1566b2 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffff0030213009 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 06052b0e03021a050004148cde40bdb9afea05d403948f6bfd58aaab1566b2 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify sig:+113979d8c2ede0d598c7ca57b2ddf648e5a2cfb1a135edc3889954de842f0370 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 8a619b61ce311fe16134cbf95d06e0ffae807fbac5e44b2921cc1d94ed48121a \ 2018-01-22 20:06:18 dirmngr[1664] DBG: e860cbd37e37e32f4206ec06bc0142314d8657cc3ddbf67b6a990085d2d3a190 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 3f5ff8963f68de695261c6011c1fcb8fae74a5aa83c170a0bd3eb814cd061f49 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 92642e607ede311adc72abbb2d5a6c93f9800750bf0bdc3e9bd846723351cf5f \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 64e0ec566947545042976765bbf8878768781a62f80dadab46450c95b553762a \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 0151822f33271d3a4a47e7025fb73c3b7298ecb9d19ab343c04435c215f1b22a \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 1c0144563b5e9ee56e3b54e51cf419cd3894fae10dfd29144f7c030e23251a45 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 796323a57504686d5cabb0fae3546981c31f3c5bce1d8e3baef0d34bb5c939a5 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 13070463983b7cf7ab3abcc0dc686fee5c96d08eece69b1dd6d88772877b3948 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 8d064c76f423030a61be1e05422940e9c1704efb567098a8abcdd4d55802a856 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 8d76d8ed76ac66fb3309170e1be5b716a35a1ce2bf9ffd2e79bd2e8a374b6a7f \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 947f8a756e36c0a31f1e00e412ffc6b76f3909cddc81354286c750482b62012f \ 2018-01-22 20:06:18 dirmngr[1664] DBG: d6e7fc7adabd20ce88d4529d9fd1de5f4665ab97d2dbbb2080e544220b5d2c9e \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 6b3bb46a3fef753dd81505cf72fb791647f9c22353a39ddfef6fe360425deaaa \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 615aba682aaaf01b04e945408c858214b7ae61b13c428892799ca7b7f61e3ab2 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify n:+d76c5b2e0f5d63540a44b72fffe7addd06a8dddd570a01199eb0f784f0da33c3 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 3e27de830c50a33157906e88e80e132b50892d73ef7f3d143f46816323e64cd6 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 9d0e29da07d4f88c8c1de2b9f197ee7d1a2126aa437721f3ecbf926332429498 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 99ef393d0311594468ed54648c31e56a5fa6b077991f35fea9b85e4020998ae6 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 8272d777fa490c0324ef2d45e396f9cd6a1f883e65ebbee5a657083d16c58692 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 7a9034ce0d787f5c476d17bd4401e68e74418ebf21839823b4196a9214390c30 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: f4e589e2c0ff4ae0153733e31c14623fdc0f97b4641b92918b1814053785dd5c \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 19f06e7b470f65a407d87631424e335c3f12dc5e3af747d186bfad922e60c86e \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 890d1ebb68aa7704818baa6edfe395a45f5858a7e617cb0984ce23386926c662 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 1c7c8681467eaf5471f3c4be9d9aa1cf2ee6c76a8c3b25872533335bf79b7646 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 6e1c043a756396363a2492f13316a0c67659480638db8659dedef513f327dbb7 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 66db0fb1151ba8cbc2448efd5df814f778284ce4a68dc2b8f420eff2bbc90522 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 0598035bd9ff5e6a313fadc894dfcab35557fec37fb4cd796c8daa3279ac19ad \ 2018-01-22 20:06:18 dirmngr[1664] DBG: d0ce8da471bb0ab512901cbda7c2618a68233f9af4165124820fa5c83f95efd1 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: fdf2041f5603f7a5b2480b3d12a4141fd85ff6b724b8acb9bee3dacf7dc39a8e \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 25c4bb2869726ce0bac023ff5163aed9729c7d6bf669cd697e1efab2d6cef539 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify e:+010001 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffff0030213009 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 06052b0e03021a050004148cde40bdb9afea05d403948f6bfd58aaab1566b2 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify => Good 2018-01-22 20:06:18 dirmngr[1664] DBG: gcry_pk_verify: Success 2018-01-22 20:06:18 dirmngr[1664] root certificate is good and trusted 2018-01-22 20:06:18 dirmngr[1664] certificate chain is good 2018-01-22 20:06:18 dirmngr[1664] certificate #00AF73C8B4CF9F808F/CN=sks-keyservers.net CA,O=sks-keyservers.net CA,ST=Oslo,C=NO 2018-01-22 20:06:18 dirmngr[1664] certificate #008C/CN=sks-keyservers.net CA,O=sks-keyservers.net CA,ST=Oslo,C=NO 2018-01-22 20:06:18 dirmngr[1664] target certificate is valid 2018-01-22 20:06:18 dirmngr[1664] DBG: PKCS#1 block type 1 encoded data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffff003051300d0609608648016503040203050004408c \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ee675e5d7a7513f6c119654bb7758b668db4fad75bb6eac11987f8f8e2f254a6 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: bef24ae7378f261990efabc7f1dc24b576a5f028f2dfa333023343167effa5 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffff003051300d0609608648016503040203050004408c \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ee675e5d7a7513f6c119654bb7758b668db4fad75bb6eac11987f8f8e2f254a6 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: bef24ae7378f261990efabc7f1dc24b576a5f028f2dfa333023343167effa5 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify sig:+1f6d6188d6bd04f6fab65fa3346ac72f11451b11bd1b9f2c509b543f11e1f103 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 83ea12abf1cc7c8c5aaa985f73a38c67de7fe22a3cb42fb6a3bb41b6554c5920 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 3c982c5fb395325e3e24005e2ddb8389c82f0bcb70adcce3b9213402fb64b7ba \ 2018-01-22 20:06:18 dirmngr[1664] DBG: d3dc6f3bf20b21e0c5b0e6032b09624e1368f582303f9f1fe525238f25d70afd \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 14c90c3ce6c3e1a838ce26404355cfa699bf2dcf2bb966f281f1113791378b2a \ 2018-01-22 20:06:18 dirmngr[1664] DBG: b3f75709b9605f465b5bbb65ae57b835ccd1bafd31794b8d59953eb5e1c7fccd \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 5d3e4ea5e95a9ec18ce25ed484423873e45a538bf2fbc84df64daeef0343ccab \ 2018-01-22 20:06:18 dirmngr[1664] DBG: fdf2cb9890ab7f640af06c1f399b7a736192854c2591bb83b5704bbf23d7a9f0 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 7ff9383f2b31b90564e08b88f23cb6e5f830f145e886fca60873ac8629c59e50 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 7038ea0e8ec223929c4882cbc45c459f3aa21dedaff434395167b699324294c5 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 574e35352781fde20233a7dbe42012c93ca383996004285d2c93d3f447fa501d \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 238f3dcfd654bf6a58b668bf7a0a272d5faf68a061e18154a225cf79e3f51d8a \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ef894734a6cc9e75e3f58aafb75c26ebd3b3bb853f8c8165130d68e10d1882c4 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: e68f5fee507a5888abad9a9f5ae48cba75540fddc164cfc2dcee53b7aed3832d \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 96083f30799407f52c6db332c5723bc8c667b6f4c1c51ae761dbf6e049db8927 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 631ad2fc0ff2d559f8a048856073802da758d02ff17a8c1476651b298d30ba18 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify n:+ba5bbf2732d7bf06ef9b1e6d2af59d419c9f17dda8e6c1939fa9d32547db4c8a \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 9c8324ebadd560e1108d45bbd1a8e74d261a2f06cf9978051bc9eb858df85799 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 8ea3d4afa2ad35bd355719a90de157cdfaaac7a04263edc4ffa11558a825050b \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 8afba9953da51d6464d563c85306a0c4d4aad86cc244a504f38e370adeb65844 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: e1a17f01d6fc5e04f07926f51539162310f42f2180c1f3157a282213851fe473 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 77c0b0aa3e01c291e781bb162ad1afeaed1deb364d4dec99fdb5541751e00cf1 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: f0838e922d905b087db5816794537f769d360f1e85ebc17757d8d0716f83635d \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 05e2ec1ef3b7e4b3ee1ab9bc6a4a55231f6052b0a17d8daacedadad614be4504 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: f6e159b2cb30ccf54cdaeb3ab525ccb300ca51cf68e6890508025dad5aedcbed \ 2018-01-22 20:06:18 dirmngr[1664] DBG: e84a69bb1d256834b13d872f17ddff69d5a7c3f99008ca9ed2a868fd96681967 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 04dcb403b553a050c8659258485be418c42bf4d6f24c6b0d92b7afcfa6258592 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 216c24ed334fb8887946afee2c70ceff4130f661f96375013c310e981641ba0b \ 2018-01-22 20:06:18 dirmngr[1664] DBG: aa8b0555d3d157ce7e9e554b57495e2a3c3071f4892bebf201261e651e5be10c \ 2018-01-22 20:06:18 dirmngr[1664] DBG: a780bfcbf930de3d07152dcbb1c8e8bc5be2e972dcd7272b1a5e31b6d5b54e81 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 94bb54f4ffca3a93d80011bf4164c52856bd45aabf7c7093e0d25e2ce5d84aff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: 8236398507ff9eccb7f7971687d3f24e9a832f79538eefee798a7d2da7d4abf5 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify e:+010001 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ffffffffffffffffffffff003051300d0609608648016503040203050004408c \ 2018-01-22 20:06:18 dirmngr[1664] DBG: ee675e5d7a7513f6c119654bb7758b668db4fad75bb6eac11987f8f8e2f254a6 \ 2018-01-22 20:06:18 dirmngr[1664] DBG: bef24ae7378f261990efabc7f1dc24b576a5f028f2dfa333023343167effa5 2018-01-22 20:06:18 dirmngr[1664] DBG: rsa_verify => Good 2018-01-22 20:06:18 dirmngr[1664] DBG: chan_0x0000035c -> S PROGRESS tick ? 0 0 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> S SOURCE https://37.191.226.104:443 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> D info:1:1%0A 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> D pub:933D9948DC0FA861471B10A9D8A807C7CCEC227B:17:1024:994599961:1549612809:r% 0A 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> D uid:Test 555 :1101921390::%0A 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> D uid:Patrick Brunschwig :1242047020::%0A 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> D uid:Patrick Brunschwig :1101921390::%0A 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> D uid:Patrick Brunschwig :1101921389::%0A 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> D uid:Patrick Brunschwig :1116168518::%0A 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> D uid:Patrick Brunschwig :1136221739::%0A 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> D uat::::%0A 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> D %0D%0A 2018-01-22 20:06:19 dirmngr[1664] DBG: chan_0x0000035c -> OK 2018-01-22 20:06:35 dirmngr[1664] DBG: chan_0x0000035c <- BYE 2018-01-22 20:06:35 dirmngr[1664] DBG: chan_0x0000035c -> OK closing connection 2018-01-22 20:06:35 dirmngr[1664] handler for fd 860 terminated The .PEM file I've imported is below: -----BEGIN CERTIFICATE----- MIIEDzCCAvegAwIBAgIBADANBgkqhkiG9w0BAQUFADBoMQswCQYDVQQGEwJVUzEl MCMGA1UEChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMp U3RhcmZpZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDQw NjI5MTczOTE2WhcNMzQwNjI5MTczOTE2WjBoMQswCQYDVQQGEwJVUzElMCMGA1UE ChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMpU3RhcmZp ZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3 DQEBAQUAA4IBDQAwggEIAoIBAQC3Msj+6XGmBIWtDBFk385N78gDGIc/oav7PKaf 8MOh2tTYbitTkPskpD6E8J7oX+zlJ0T1KKY/e97gKvDIr1MvnsoFAZMej2YcOadN +lq2cwQlZut3f+dZxkqZJRRU6ybH838Z1TBwj6+wRir/resp7defqgSHo9T5iaU0 X9tDkYI22WY8sbi5gv2cOj4QyDvvBmVmepsZGD3/cVE8MC5fvj13c7JdBmzDI1aa K4UmkhynArPkPw2vCHmCuDY96pzTNbO8acr1zJ3o/WSNF4Azbl5KXZnJHoe0nRrA 1W4TNSNe35tfPe/W93bC6j67eA0cQmdrBNj41tpvi/JEoAGrAgEDo4HFMIHCMB0G A1UdDgQWBBS/X7fRzt0fhvRbVazc1xDCDqmI5zCBkgYDVR0jBIGKMIGHgBS/X7fR zt0fhvRbVazc1xDCDqmI56FspGowaDELMAkGA1UEBhMCVVMxJTAjBgNVBAoTHFN0 YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xMjAwBgNVBAsTKVN0YXJmaWVsZCBD bGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8w DQYJKoZIhvcNAQEFBQADggEBAAWdP4id0ckaVaGsafPzWdqbAYcaT1epoXkJKtv3 L7IezMdeatiDh6GX70k1PncGQVhiv45YuApnP+yz3SFmH8lU+nLMPUxA2IGvd56D eruix/U0F47ZEUD0/CwqTRV/p2JdLiXTAAsgGh1o+Re49L2L7ShZ3U0WixeDyLJl xy16paq8U4Zt3VekyvggQQto8PT7dL5WXXp59fkdheMtlb71cZBDzI0fmgAKhynp VSJYACPq4xJDKVtHCN2MQWplBqjlIapBtJUhlbl90TSrE9atvNziPTnNvT51cKEY WQPJIrSPnNVeKtelttQKbfi3QBFGmh95DmK/D5fs4C8fF5Q= -----END CERTIFICATE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzy_drawrings at protonmail.com Tue Jan 23 08:41:45 2018 From: fuzzy_drawrings at protonmail.com (FuzzyDrawrings) Date: Tue, 23 Jan 2018 02:41:45 -0500 Subject: Keys clean of all signatures except those made by others I trust Message-ID: Title says it all. Say I import Bob's key with "--recv-key" from some keyserver. Bob's public key has been signed by a lot of non-serious User ID's and spam. However Bob's key may have been signed by Alice (whose public-key I have in my keyring). I would like to clean the key of the spam signatures while preserving any signatures made by Alice (or anyone else I have trusted on my keyring). Does there exist a command/option to accomplish this in gpg2? -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Tue Jan 23 12:34:40 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 23 Jan 2018 12:34:40 +0100 Subject: Keys clean of all signatures except those made by others I trust In-Reply-To: References: Message-ID: <59e0072b-efbe-639d-8cf4-53991717f291@digitalbrains.com> On 23/01/18 08:41, FuzzyDrawrings via Gnupg-users wrote: > Title says it all. From the man page: > --edit-key > Present a menu which enables you to do most of the key manage? > ment related tasks. It expects the specification of a key on > the command line. > [...] > clean Compact (by removing all signatures except the selfsig) > any user ID that is no longer usable (e.g. revoked, or > expired). Then, remove any signatures that are not usable > by the trust calculations. Specifically, this removes > any signature that does not validate, any signature that > is superseded by a later signature, revoked signatures, > and signatures issued by keys that are not present on the > keyring. (Apparently you agree on the name for the concept, a "clean" key :-) 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 tlikonen at iki.fi Tue Jan 23 17:16:33 2018 From: tlikonen at iki.fi (Teemu Likonen) Date: Tue, 23 Jan 2018 18:16:33 +0200 Subject: Keys clean of all signatures except those made by others I trust In-Reply-To: (FuzzyDrawrings via Gnupg-users's message of "Tue, 23 Jan 2018 02:41:45 -0500") References: Message-ID: <87r2qg35zy.fsf@iki.fi> FuzzyDrawrings via Gnupg-users [2018-01-23 02:41:45-05] wrote: > Say I import Bob's key with "--recv-key" from some keyserver. Bob's > public key has been signed by a lot of non-serious User ID's and spam. > However Bob's key may have been signed by Alice (whose public-key I > have in my keyring). > > I would like to clean the key of the spam signatures while preserving > any signatures made by Alice (or anyone else I have trusted on my > keyring). Does there exist a command/option to accomplish this in > gpg2? For one key: "--edit-key" and "clean". To make it automatic for all import operations you can use options in gpg.conf file: import-options import-clean keyserver-options import-clean I like clean export too, so: import-options import-clean export-options export-clean keyserver-options import-clean,export-clean -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From doron.behar at gmail.com Tue Jan 23 16:35:12 2018 From: doron.behar at gmail.com (Doron Behar) Date: Tue, 23 Jan 2018 17:35:12 +0200 Subject: Why exactly does pinentry fails with gpg-agent and ssh support? In-Reply-To: <87o9lm2v9u.fsf@wheatstone.g10code.de> References: <20180121164154.toj5wok32y7i55rx@NUC.localdomain> <87o9lm2v9u.fsf@wheatstone.g10code.de> Message-ID: <20180123153512.vxu5hwc5zar6uxrs@NUC.localdomain> I'm glad to hear your comments guys. I've posted a bug report on ssh' bug tracker: https://bugzilla.mindrot.org/show_bug.cgi?id=2824 On Mon, Jan 22, 2018 at 08:43:41AM +0100, Werner Koch wrote: > On Sun, 21 Jan 2018 17:41, doron.behar at gmail.com said: > > > As far as I understand, because I use `systemd`'s user service, whenever > > I want to unlock an authentication key I need to run the command > > `gpg-connect-agent updatestartuptty /bye`. > > Although I have no experience with the peculiarities of the --supervised > mode, there is no need to run the updatestartuptty command. That command > is only used to switch gpg-agent's default $DISPLAY and tty to the one > active in the shell you run this command. This is required because the > ssh-agent protocol has no way to tell gpg-agent (or ssh-agent) the > DISPLAY/tty which shall be used to pop-up the Pinentry. > > Another problem with ssh is that ssh can't start gpg-agent on the the > fly. Thus you need to make sure that gpg-agent has already been started > when you use ssh. A way to ensure this is to run > > gpg -K > > which lists all your private keys and as a side-effects starts > gpg-agent. You can also do > > gpg-connect-agent /bye > > because it exhibits the same side-effect. The suggested way to start > gpg-agent for ssh is to use > > gpgconf --launch gpg-agent > > > Salam-Shalom, > > Werner > > > p.s. > And the best solution would be to extended the ssh-agent protocol > and openssh to allow starting of an arbitrary process and conveying some > environment variables. > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 691 bytes Desc: not available URL: From fuzzy_drawrings at protonmail.com Tue Jan 23 22:08:38 2018 From: fuzzy_drawrings at protonmail.com (FuzzyDrawrings) Date: Tue, 23 Jan 2018 16:08:38 -0500 Subject: Keys clean of all signatures except those made by others I trust Message-ID: I guess I had stopped reading about ' clean' after the first line: > clean Compact (by removing all signatures except the selfsig) ...however the rest of the description indicates it does exactly what I need. Doh! Many thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Tue Jan 23 22:55:20 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 23 Jan 2018 16:55:20 -0500 Subject: Keys clean of all signatures except those made by others I trust In-Reply-To: <59e0072b-efbe-639d-8cf4-53991717f291@digitalbrains.com> References: <59e0072b-efbe-639d-8cf4-53991717f291@digitalbrains.com> Message-ID: > From the man page: Note that this can be done in a bash one-liner: $ for x in `gpg --list-keys|grep "[A-F0-9]\{40\}"|sed 's/ //g'` ; do gpg --edit-key $x clean save ; done Or in Windows Powershell: > ForEach ($keymatch In &gpg --list-keys|Select-String -Pattern "[A-F0-9]{40}") { &gpg --edit-key $keymatch.ToString().Trim() clean save;} ... There are undoubtedly half a dozen ways to do this quickly. But if you're looking for one, these will do. From guilhem at fripost.org Wed Jan 24 00:10:12 2018 From: guilhem at fripost.org (Guilhem Moulin) Date: Wed, 24 Jan 2018 00:10:12 +0100 Subject: "best" ed25519/curve25519 setup? In-Reply-To: <87d121ovfu.fsf@latte.josefsson.org> References: <87a7xxso71.fsf@latte.josefsson.org> <20180101183331.GA7187__38237.3872948394$1514838024$gmane$org@localhost.localdomain> <87d121ovfu.fsf@latte.josefsson.org> Message-ID: <20180123231012.GA18383@localhost.localdomain> On Tue, 23 Jan 2018 at 09:01:25 +0100, Simon Josefsson wrote: > Guilhem Moulin writes: >> On Mon, 01 Jan 2018 at 14:28:34 +0100, Simon Josefsson wrote: >>> I want to use ed25519/curve25519, but right now I have an offline >>> master RSA key with three subkeys. Does it work well to add new >>> subkeys for Ed25519/Curve25519? What is the user experience in >>> various applications? I'm thinking MUAs, SSH, git, gpg itself, and >>> also more exotic approaches like K9Mail. >> >> AFAICT multiple Ed25519/Curve25519 subkeys work fine, with the following >> caveats: >> >> * You'll want to sign with both your Ed25519 and non-ECC (sub-)keys, >> otherwise non-ECC capable OpenPGP implementations won't be able to >> verify your data signatures. You can do this by adding >> >> local-user $FINGERPRINT! >> >> for each (sub)key to sign with (note the trailing exclamation mark >> to specify the subkey). > > Have you noticed any problem with this approach? I could imagine some > software might be equally confused by two signatures, or become confused > that GnuPG "under the hood" adds another signature. There are non RFC-compliant implementations for sure, but FWIW RFC 4880 allows multiple signatures on the same data. That's the last octet of One-Pass Signature Packets, cf. RFC 4880 Sec. 5.4: ?A one-octet number holding a flag showing whether the signature is nested. A zero value indicates that the next packet is another One-Pass Signature packet that describes another signature to be applied to the same message data.? ? https://tools.ietf.org/html/rfc4880#section-5.4 That's often used in OpenPGP key transition statements, for instance. That being said I didn't add a signing-capable Ed25519 subkey along with my RSA one, and the only OpenPGP implementation I use is GnuPG, so I don't know how well other implementations support nested signatures. > I wonder if I should re-use the RSA subkeys from my current key into the > new one... I suppose for SSH it would be useful, but for anything > OpenPGP-related it should be based on the master key id, right? I see no reason to do that for signing and decryption, indeed. -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gnupg-users at spodhuis.org Wed Jan 24 03:51:24 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Tue, 23 Jan 2018 21:51:24 -0500 Subject: GnuPG 2.2.4 on Windows - problems accessing some HKPS keyservers In-Reply-To: <00e901d393e7$4d94eb50$e8bec1f0$@yahoo.com> References: <00e901d393e7$4d94eb50$e8bec1f0$@yahoo.com> Message-ID: <20180124025124.GA46039@tower.spodhuis.org> On 2018-01-22 at 20:12 -0500, David Gray via Gnupg-users wrote: > I'm running GnuPG 2.2.4 on Windows. I'm able to successfully query the SKS > keyserver pool via HKPS (hkps://hkps.pool.sks-keyservers.net) with no > problems. I'm trying to query the hkps://keys.mailvelope.com keyserver, and > I'm not having any luck. Looks to me like a GnuPG bug. In fact, it looks very much like https://dev.gnupg.org/T1447 which has been marked resolved. The hostname there is a CNAME to Amazon DNS, and my dirmngr logfile records: 2018-01-23 21:28:10 dirmngr[70787.6] TLS verification of peer failed: hostname does not match 2018-01-23 21:28:10 dirmngr[70787.6] DBG: expected hostname: keyserver-prod.v3jierkpjv.eu-west-1.elasticbeanstalk.com The untrusted name retrieved from DNS resolution of the CNAME record is being used as the name for validation. The patches to address the issue seem to focus on SRV records, so repaired one way in which the problem manifested, but either didn't fix the underlying issue, or there's been a regression. I've opened a new ticket for the maintainers to track this. https://dev.gnupg.org/T3755 -Phil From dgray4656 at yahoo.com Wed Jan 24 14:17:39 2018 From: dgray4656 at yahoo.com (David Gray) Date: Wed, 24 Jan 2018 08:17:39 -0500 Subject: GnuPG 2.2.4 on Windows - problems accessing some HKPS keyservers In-Reply-To: <20180124025124.GA46039@tower.spodhuis.org> References: <00e901d393e7$4d94eb50$e8bec1f0$@yahoo.com> <20180124025124.GA46039@tower.spodhuis.org> Message-ID: <70824078-2820-4543-A333-2EEC168AFA9E@yahoo.com> Thanks, Phil - I appreciate your help and your response. Thanks, Dave Sent from my iPhone > On Jan 23, 2018, at 9:51 PM, Phil Pennock wrote: > > Looks to me like a GnuPG bug. In fact, it looks very much like > https://dev.gnupg.org/T1447 which has been marked resolved. > > The hostname there is a CNAME to Amazon DNS, and my dirmngr logfile > records: > > 2018-01-23 21:28:10 dirmngr[70787.6] TLS verification of peer failed: hostname does not match > 2018-01-23 21:28:10 dirmngr[70787.6] DBG: expected hostname: keyserver-prod.v3jierkpjv.eu-west-1.elasticbeanstalk.com > > The untrusted name retrieved from DNS resolution of the CNAME record is > being used as the name for validation. > > The patches to address the issue seem to focus on SRV records, so > repaired one way in which the problem manifested, but either didn't fix > the underlying issue, or there's been a regression. > > I've opened a new ticket for the maintainers to track this. > https://dev.gnupg.org/T3755 > > -Phil From andre at colomb.de Wed Jan 24 20:34:45 2018 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Wed, 24 Jan 2018 20:34:45 +0100 Subject: Why exactly does pinentry fails with gpg-agent and ssh support? In-Reply-To: <24226ee0-bf39-c35c-aef1-46d56f2d4d90@colomb.de> References: <20180121164154.toj5wok32y7i55rx@NUC.localdomain> <87o9lm2v9u.fsf@wheatstone.g10code.de> <507a6896-5941-547b-db7c-501acc679637@colomb.de> <1c90403a-8143-1d6d-57bb-de7664ba0502@digitalbrains.com> <87zi56hzxy.fsf@fifthhorseman.net> <24226ee0-bf39-c35c-aef1-46d56f2d4d90@colomb.de> Message-ID: <2b2ea62c-c8f2-c164-921a-f528d064856c@colomb.de> On 2018-01-22 18:06, Andr? Colomb wrote: >> the systemd user service takes care of automatically launching the >> gpg-agent when the user connects to it via the ssh-agent protocol, so >> this isn't required when using systemd. > > I can't see how it does that in my packaged Ubuntu version (2.1.15), > there is no gpg-agent.socket unit file anywhere? Seems like the relevant systemd unit file examples were added in commit 57e95f5413e21cfcb957af2346b292686a5647b7, shortly after 2.1.15 (included in Debian / Ubuntu) was released. As far as I can see, the new socket-activated user units should be installed with current packages in Debian testing and Ubuntu bionic. I might try manually upgrading to 2.2.4-1ubuntu1 and report any findings. Regards Andr? -- Greetings... From: Andr? Colomb From dkg at fifthhorseman.net Wed Jan 24 19:05:16 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 24 Jan 2018 13:05:16 -0500 Subject: Keys clean of all signatures except those made by others I trust In-Reply-To: References: <59e0072b-efbe-639d-8cf4-53991717f291@digitalbrains.com> Message-ID: <87zi53gmjn.fsf@fifthhorseman.net> On Tue 2018-01-23 16:55:20 -0500, Robert J. Hansen wrote: >> From the man page: > > Note that this can be done in a bash one-liner: > > $ for x in `gpg --list-keys|grep "[A-F0-9]\{40\}"|sed 's/ //g'` ; do gpg > --edit-key $x clean save ; done please don't script based on the output of gpg without using --with-colons. the "human-readable" form is subject to change, but --with-colons offers a stable API. so a stable bash script would look something like: for fpr in $(gpg --with-colons --list-keys | \ awk -F: '/^fpr:/{ print $10 }'); do \ gpg --edit-key "fpr" clean save; done hope this helps, --dkg From dkg at fifthhorseman.net Wed Jan 24 19:36:43 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 24 Jan 2018 13:36:43 -0500 Subject: failed to convert unprotected openpgp key: Checksum error In-Reply-To: <20180122203737.GA6255@tower.spodhuis.org> References: <20180122203737.GA6255@tower.spodhuis.org> Message-ID: <87r2qfgl38.fsf@fifthhorseman.net> On Mon 2018-01-22 15:37:37 -0500, Phil Pennock wrote: > So at this point, it looks to me like it really is an incorrect > checksum, exposing unfortunate edge-case handling in GnuPG. Thanks for the diagnosis, Phil and Simon. Please file a bug report about this at https://dev.gnupg.org/ so that this edge-case doesn't get lost! --dkg From rjh at sixdemonbag.org Thu Jan 25 00:01:25 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 24 Jan 2018 18:01:25 -0500 Subject: Keys clean of all signatures except those made by others I trust In-Reply-To: <87zi53gmjn.fsf@fifthhorseman.net> References: <59e0072b-efbe-639d-8cf4-53991717f291@digitalbrains.com> <87zi53gmjn.fsf@fifthhorseman.net> Message-ID: > please don't script based on the output of gpg without using > --with-colons. Correction noted, thank you. Have one in return. :) > for fpr in $(gpg --with-colons --list-keys | \ > awk -F: '/^fpr:/{ print $10 }'); do \ > gpg --edit-key "fpr" clean save; done "fpr" should be $fpr, I think. From fuzzy_drawrings at protonmail.com Thu Jan 25 03:26:58 2018 From: fuzzy_drawrings at protonmail.com (FuzzyDrawrings) Date: Wed, 24 Jan 2018 21:26:58 -0500 Subject: Subpacket 33 and GnuPG Specifics on RFC-4880 Tag ID's, algorithm identifiers, etc Message-ID: <-txjQqH6fiWtaDmap7J6NTEk11gHWVCCThGbeoeOeX54aiETpJJfHz1tGO3_PI-FIfg528XCuAqbGTD8DzD15iR78LHC6n0t0vzSRRwiB2w=@protonmail.com> ?Hello, I am working to better understand the OpenPGP standard and how it is handled by the current implementation of GnuPG. To this end I have created a Python program that reads ASCII-Armor and returns details about the encoded data within. This is purely for my own edification and understanding of how OpenPGP works and also learn Python in the process. I'm at the point where I can parse ascii armor to display almost all of the information I could otherwise get using "$ gpg --list-packets", including calculate the actual key fingerprint (which took a lot of re-reading the section of RFC-4880 that explains all the data that must be hashed to produce the fingerprint). Does anyone know what are the additions or changes there are, in terms of packet tags, signature types, subpacket types, and algorithm identifiers used in the current version of GnuPG but that are not defined in RFC4880? I've figured out a few on my own: additional public-key algorithm identifiers like 18 and 19 (ECDH and ECDSA, respectively, as defined in RFC-6637). And it seems that 22 is the identifier for Curve 25517 and/or EdDSA. One I haven't been able to figure out is signature subpacket type 33. The signature files for the downloads on gnupg.org contain this subpacket type, but it isn't defined in RFC-4880. Strangely, even my installation of GnuPG does not display anything but "(?)" for the meaning of this subpacket's content: $ gpg2 --list-packets gnupg-2.2.4.tar.bz2.sig # off=0 ctb=89 tag=2 hlen=3 plen=307 :signature packet: algo 1, keyid 249B39D24F25E3B6 version 4, created 1513760871, md5len 0, sigclass 0x00 digest algo 8, begin of digest 75 a5 hashed subpkt 33 len 21 (?) hashed subpkt 2 len 4 (sig created 2017-12-20) subpkt 16 len 8 (issuer key ID 249B39D24F25E3B6) data: [2046 bits] # off=310 ctb=89 tag=2 hlen=3 plen=307 :signature packet: algo 1, keyid 2071B08A33BD3F06 version 4, created 1513762863, md5len 0, sigclass 0x00 digest algo 8, begin of digest 95 36 hashed subpkt 33 len 21 (?) hashed subpkt 2 len 4 (sig created 2017-12-20) subpkt 16 len 8 (issuer key ID 2071B08A33BD3F06) data: [2046 bits] From fuzzy_drawrings at protonmail.com Thu Jan 25 05:43:03 2018 From: fuzzy_drawrings at protonmail.com (FuzzyDrawrings) Date: Wed, 24 Jan 2018 23:43:03 -0500 Subject: Subpacket 33 and GnuPG Specifics on RFC-4880 Tag ID's, algorithm identifiers, etc In-Reply-To: <-txjQqH6fiWtaDmap7J6NTEk11gHWVCCThGbeoeOeX54aiETpJJfHz1tGO3_PI-FIfg528XCuAqbGTD8DzD15iR78LHC6n0t0vzSRRwiB2w=@protonmail.com> References: <-txjQqH6fiWtaDmap7J6NTEk11gHWVCCThGbeoeOeX54aiETpJJfHz1tGO3_PI-FIfg528XCuAqbGTD8DzD15iR78LHC6n0t0vzSRRwiB2w=@protonmail.com> Message-ID: After looking at the content of subpacket 33, it appears to be the signing-key's fingerprint prepended by '0x04'. So I'm guessing subpacket 33 is to be a more robust version of subpacket 16 (Issuer)? From wk at gnupg.org Thu Jan 25 08:58:37 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jan 2018 08:58:37 +0100 Subject: Keys clean of all signatures except those made by others I trust In-Reply-To: (FuzzyDrawrings via Gnupg-users's message of "Tue, 23 Jan 2018 02:41:45 -0500") References: Message-ID: <87k1w6z7wy.fsf@wheatstone.g10code.de> On Tue, 23 Jan 2018 08:41, gnupg-users at gnupg.org said: > I would like to clean the key of the spam signatures while preserving > any signatures made by Alice (or anyone else I have trusted on my > keyring). Does there exist a command/option to accomplish this in > gpg2? I do blacklisting of certain signatures in my gpg.conf. A blacklist may look like this import-filter drop-sig= sig_created_d=2015-12-24 import-filter drop-sig=|| sig_created_d=2016-03-16 and a whitelist would be import-filter drop-sig= sig_created_d<>2015-12-24 import-filter drop-sig=&& sig_created_d<>2016-03-16 Unfortuntely a property for comparing the key-id or the fingerprint is not yet available. Shall I look into this? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Jan 25 09:13:28 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jan 2018 09:13:28 +0100 Subject: Subpacket 33 and GnuPG Specifics on RFC-4880 Tag ID's, algorithm identifiers, etc In-Reply-To: (FuzzyDrawrings via Gnupg-users's message of "Wed, 24 Jan 2018 23:43:03 -0500") References: <-txjQqH6fiWtaDmap7J6NTEk11gHWVCCThGbeoeOeX54aiETpJJfHz1tGO3_PI-FIfg528XCuAqbGTD8DzD15iR78LHC6n0t0vzSRRwiB2w=@protonmail.com> Message-ID: <87fu6uz787.fsf@wheatstone.g10code.de> On Thu, 25 Jan 2018 05:43, gnupg-users at gnupg.org said: > After looking at the content of subpacket 33, it appears to be the signing-key's fingerprint prepended by '0x04'. > > So I'm guessing subpacket 33 is to be a more robust version of subpacket 16 (Issuer)? Right. From RFC-4880bis (draft -03) | 5.2.3.5. {5.2.3.5} Issuer | | (8-octet Key ID) | | The OpenPGP Key ID of the key issuing the signature. If the version | of that key is greater than 4, this subpacket MUST NOT be included in | the signature. | | | 5.2.3.28. Issuer Fingerprint | | (1 octet key version number, N octets of fingerprint) | | The OpenPGP Key fingerprint of the key issuing the signature. This | subpacket SHOULD be included in all signatures. If the version of | the issuing key is 4 and an Issuer subpacket is also included in the | signature, the key ID of the Issuer subpacket MUST match the low 64 | bits of the fingerprint. | | Note that the length N of the fingerprint for a version 4 key is 20 | octets; for a version 5 key N is 32. Note that the OpenPGP WG page is not anymore updated automatically, thus you better watch https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc4880bis/ for updates. I use ssh://git at gitlab.com/openpgp-wg/rfc4880bis to prepare new draft versions. With gpg implementing some propose changes I guess I should do a -04 soonish. I will report also to gnupg-devel whne tehre is a new draft. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From guru at unixarea.de Thu Jan 25 09:39:24 2018 From: guru at unixarea.de (Matthias Apitz) Date: Thu, 25 Jan 2018 09:39:24 +0100 Subject: pinentry fails with gpg-agent for ssh, but works for gpg Message-ID: <20180125083924.GA3403@c720-r314251> Hello, A bit triggered by the last thread "Why exactly does pinentry fails with gpg-agent and ssh support?" I want to report a similar issue which I do not understand. I have the 'pinentry' in /usr/local/bin/pinentry as a sym-link to the qt5 version: $ ls -l /usr/local/bin/pinentry lrwxr-xr-x 1 root wheel 27 15 may. 2017 /usr/local/bin/pinentry -> /usr/local/bin/pinentry-qt5 Most of the time I work within the KDE desktop and when the PIN is required to unlock the keys on the OpenPGP card, it pops up a small Qt5 window asking for it. Sometimes I work in the alpha console where `tty` gives /dev/ttyv0 (and GPG_TTY env var is set to this). What I do not get to understand is: $ gpg2 -d file pops up some curses window asking for the PIN, i.e. /usr/local/bin/pinentry-qt5 falls back to this at the end because has no DISPLAY to connect to. $ ssh some-host fails to ask for the PIN. Why, or what could I do? matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wk at gnupg.org Thu Jan 25 12:03:59 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jan 2018 12:03:59 +0100 Subject: pinentry fails with gpg-agent for ssh, but works for gpg In-Reply-To: <20180125083924.GA3403@c720-r314251> (Matthias Apitz's message of "Thu, 25 Jan 2018 09:39:24 +0100") References: <20180125083924.GA3403@c720-r314251> Message-ID: <877es6yzc0.fsf@wheatstone.g10code.de> On Thu, 25 Jan 2018 09:39, guru at unixarea.de said: > $ ssh some-host > > fails to ask for the PIN. That is because ssh has no mechanism to tell the ssh-agent (in this case gpg-agent) the DISPLAY or tty to use for pinentry. This the pinentry pops up on the tty or X server gpg-agent was initially started. Running gpg-connect-agent updatestartuptty /bye on your current tty tells gpg-agent to updates its default tty and DISPLAY to the one where you run gpg-connect-agent. ssh will then work again. After you switch back to another terminal you need to do the same. I have to use it always when I move from my standalone laptop to the Xserver connected to that laptop. It is a bit annoying and the only clean solution would be to enance the the ssh-agent protocol and implement that in both, ssh and gpg-agent. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From fuzzy_drawrings at protonmail.com Fri Jan 26 05:44:51 2018 From: fuzzy_drawrings at protonmail.com (FuzzyDrawrings) Date: Thu, 25 Jan 2018 23:44:51 -0500 Subject: Keys clean of all signatures except those made by others I trust In-Reply-To: <87k1w6z7wy.fsf@wheatstone.g10code.de> References: <87k1w6z7wy.fsf@wheatstone.g10code.de> Message-ID: On January 24, 2018 11:58 PM, Werner Koch wrote: >On Tue, 23 Jan 2018 08:41, gnupg-users at gnupg.org said: > >>I would like to clean the key of the spam signatures while preserving >> any signatures made by Alice (or anyone else I have trusted on my >> keyring). Does there exist a command/option to accomplish this in >> gpg2? >> > I do blacklisting of certain signatures in my gpg.conf. A blacklist may > look like this > > import-filter drop-sig= sig_created_d=2015-12-24 > import-filter drop-sig=|| sig_created_d=2016-03-16 > > and a whitelist would be > > import-filter drop-sig= sig_created_d<>2015-12-24 >import-filter drop-sig=&& sig_created_d<>2016-03-16 > > Unfortuntely a property for comparing the key-id or the fingerprint is > not yet available. Shall I look into this? I was able to get the results I needed by using the 'clean' command under --edit-key, and also '--import-options import-clean'. 'import-filter' option is unavailable to me as I use the GnuPG versions in Ubuntu repository. If I put either the blacklist or whitelist in gpg.conf, GPG 2.1.11 hangs while GPG 1.4.20 declares it an 'invalid option' From 2017-r3sgs86x8e-lists-groups at riseup.net Sat Jan 27 17:04:40 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sat, 27 Jan 2018 16:04:40 +0000 Subject: Keys clean of all signatures except those made by others I trust In-Reply-To: References: <87k1w6z7wy.fsf@wheatstone.g10code.de> Message-ID: <708305860.20180127160440@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday 26 January 2018 at 4:44:51 AM, in , FuzzyDrawrings via Gnupg-users wrote:- > 'import-filter' option is unavailable to me as I use > the GnuPG > versions in Ubuntu repository. If I put either the > blacklist or > whitelist in gpg.conf, GPG 2.1.11 hangs while GPG > 1.4.20 declares it an 'invalid option' Declaring it an 'invalid option' and exiting gracefully would seem to be a preferable outcome to hanging. - -- Best regards MFPA No matter where you go, there you are. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWmyjGl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +vzBAQDpBFlq9X5haOCvKG06sr1Ufo/7MPGk6htIqqmwULr1egD/eFwHx2cDK3kU hulUwEjz2R4IDLEL+XErnDX/mHqJ/gqJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWmyjGl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/6eRD/9rNeBarAkkmBNOU8hNhM+kimyL rutolWaBmk/ZZnGGEGdnIfPeSPYDtQY5KDJ1D+siCFyPZjV4uJ657MjV26bVe5XP IJkSBFWlvR2aaxrUB6uIsdBR3BwXeY4b+7T8HV/ORbxMpIWw8PkUm2FkPveo2vMW tQzx1dfisYutngAQBtI9jJb1JHP6uGSEipKTq/0SJJ2IMEx5QXF7nlI14107Bdxw VrXsuKejLbRTFyV7y0wi9udySZcuEXZ6xR/8poc1eO/PKcQ2ut6YdPSRvek0eJRR Ty2B6u3S5L6hagwJ45Vfu2UPK99nCFSNK1uTWpGzriAmpSKYRG1DOqmP3/WWt1Jv Rq0FhtWdCWLg7snFNwT08cHRAhNLGNALaeYqnEwbeuTRkpVJc5kjWF0B+BFm12zZ FYKEPYIwhw5AcaZFmkJZ0fsXFzVigeYBCGNCu6B3ZJ+XGzHFlhuEb7+q5GRYfpim A7tDecyaE2/PV9kb39doTJouqdk9yjOcVnsd7Yr2+B1Bebr+ax+Ailyu1Lhi0w6d JMdGBrhFHxcqa46hX+9chJYGUhbKO1BT6BppSBu/razhUwX/m55RiD1wOwe0X9a6 f3OKFS/LlQCoBQLD4IxVtXzcdNmFfnHXzD+m7ochV9xLKkvIqUQsaTnsb1N3ENC6 /SITFLTEqTvVxkwFKA== =+ys4 -----END PGP SIGNATURE----- From mail at maciej.szmigiero.name Sun Jan 28 22:02:39 2018 From: mail at maciej.szmigiero.name (Maciej S. Szmigiero) Date: Sun, 28 Jan 2018 22:02:39 +0100 Subject: SCM SPR332 PIN entry doesn't work In-Reply-To: <21fbf99f-49a8-745e-8804-34266f546f54@maciej.szmigiero.name> References: <21fbf99f-49a8-745e-8804-34266f546f54@maciej.szmigiero.name> Message-ID: <2bcbd710-bb97-bd1c-a3c8-8ed26172758f@maciej.szmigiero.name> On 21.01.2018 00:16, Maciej S. Szmigiero wrote: > On 14.01.2018 01:01, Maciej S. Szmigiero wrote: >> Hi all, >> >> I've just received a SCM SPR332 from FLOSS-Shop (marked as "SPR332 V2" >> on its bottom side) and while its basic reader functionality seems to work >> just fine I can't get the secure PIN entry mode to work at all. >> >> I've tried two different OpenPGP cards, tried both GnuPG built-in CCID >> driver and the pcsc-lite one to no avail. >> >> I've even tried the latest vendor Windows driver (with OpenSC and a constant >> length PIN verify operation), but the behavior in each of these setups was >> always the same: >> Upon typing and accepting a PIN the "key" LED on the reader continues to >> blink for a few seconds, then the reader responds with "64 00" result at >> the USB interface level (which is probably the code for >> "SPE [Secure PIN Entry] operation timed out" error) and then it doesn't >> want to communicate with the card anymore. >> >> A relevant log snippet from GnuPG built-in CCID driver: >> DBG: prompting for pinpad entry '||Please unlock the card%0A%0A Number: 0005 00005B0E%0AHolder: ' >> DBG: ccid-driver: sending escape sequence to switch to a case 1 APDU >> DBG: ccid-driver: PC_to_RDR_Escape: >> DBG: ccid-driver: dwLength ..........: 3 >> DBG: ccid-driver: bSlot .............: 0 >> DBG: ccid-driver: bSeq ..............: 56 >> DBG: ccid-driver: [0007] 00 00 00 80 02 00 >> DBG: ccid-driver: RDR_to_PC_Escape: >> DBG: ccid-driver: dwLength ..........: 0 >> DBG: ccid-driver: bSlot .............: 0 >> DBG: ccid-driver: bSeq ..............: 56 >> DBG: ccid-driver: bStatus ...........: 0 >> DBG: ccid-driver: buffer[9] .........: 00 >> DBG: ccid-driver: PC_to_RDR_Secure: >> DBG: ccid-driver: dwLength ..........: 19 >> DBG: ccid-driver: bSlot .............: 0 >> DBG: ccid-driver: bSeq ..............: 57 >> DBG: ccid-driver: bBMI ..............: 0x00 >> DBG: ccid-driver: wLevelParameter ...: 0x0000 >> DBG: ccid-driver: [0010] 00 00 82 00 00 19 >> DBG: ccid-driver: [0016] 06 02 01 09 04 00 00 00 00 00 20 00 82 >> DBG: ccid-driver: RDR_to_PC_DataBlock: >> DBG: ccid-driver: dwLength ..........: 2 >> DBG: ccid-driver: bSlot .............: 0 >> DBG: ccid-driver: bSeq ..............: 57 >> DBG: ccid-driver: bStatus ...........: 0 >> DBG: ccid-driver: [0010] 64 00 >> DBG: dismiss pinpad entry prompt >> verify CHV2 failed: Operation cancelled >> app_check_pin failed: Operation cancelled >> DBG: ccid-driver: PC_to_RDR_XfrBlock: >> DBG: ccid-driver: dwLength ..........: 9 >> DBG: ccid-driver: bSlot .............: 0 >> DBG: ccid-driver: bSeq ..............: 58 >> DBG: ccid-driver: bBWI ..............: 0x04 >> DBG: ccid-driver: wLevelParameter ...: 0x0000 >> DBG: ccid-driver: [0010] 00 00 05 00 CA 00 >> DBG: ccid-driver: [0016] 6E 00 A1 >> DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT >> ccid_transceive failed: (0x1000a) >> apdu_send_simple(0) failed: card I/O error >> DBG: ccid-driver: PC_to_RDR_XfrBlock: >> DBG: ccid-driver: dwLength ..........: 9 >> DBG: ccid-driver: bSlot .............: 0 >> DBG: ccid-driver: bSeq ..............: 59 >> DBG: ccid-driver: bBWI ..............: 0x04 >> DBG: ccid-driver: wLevelParameter ...: 0x0000 >> DBG: ccid-driver: [0010] 00 00 05 00 CA 00 >> DBG: ccid-driver: [0016] C5 00 0A >> DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT >> ccid_transceive failed: (0x1000a) >> apdu_send_simple(0) failed: card I/O error >> >> I've tried also an EMV card with this reader, the behavior >> is slightly different in this case: the typed PIN is accepted >> immediately, but "00 82 00 82" T=1 protocol error is returned >> at the USB interface level. >> And the card communication still works after this. >> >> The same cards (two OpenPGP ones and one EMV) accept PIN input without >> problems using exactly the same software setup when driven by a >> different PIN pad reader (a HP smart card keyboard). >> >> What's interesting is that the reader reports firmware version 7.0 >> while all the references I could find talk about firmware version 6.01. >> >> The vendor Windows driver also has a firmware version check utility >> that explicitly checks for firmware version 6.01 (unfortunately, >> it is just a checking tool without up- or down-grade capability). >> >> Now, I wonder: did anybody earlier spotted a similar behavior with this >> or other SCM/Identiv readers? >> Or is it possible that this reader is loaded with some non-standard >> firmware? >> It reports as "SPRx32 USB Smart Card Reader", which suggests the firmware >> should be common with a well-tested SPR532 model. > > Has anybody used this reader as a PIN pad successfully or had similar > issues? > For posterity's sake: after contacting FLOSS-Shop the problem turned out to be caused by the reader firmware (version 7.0). If somebody encounters a similar problem in the future please contact your seller or Identive to get an updated firmware (the working one is marked version 7.01 build 1.53). Maciej From daniele at grinta.net Mon Jan 29 01:37:40 2018 From: daniele at grinta.net (Daniele Nicolodi) Date: Sun, 28 Jan 2018 17:37:40 -0700 Subject: --export-options export-reset-subkey-passwd In-Reply-To: <87mv6pqzdu.fsf@wheatstone.g10code.de> References: <6308661f-1769-3e76-84d4-b25168688cf6@grinta.net> <87mv6pqzdu.fsf@wheatstone.g10code.de> Message-ID: On 23/08/2017 23:59, Werner Koch wrote: > On Sun, 13 Aug 2017 08:17, daniele at grinta.net said: > >> Digging a bit more, it seems that the functionality got dropped because >> with GnuPG 2.x all key manipulations go through gpg-agent and it does >> not (yet?) support password reset on expert. > > Unfortunately this is still an open bug: > > https://dev.gnupg.org/T1753 > > we won't be able to fix it for 2.2.0 but given that it is marked as a > bug it can and should be fixed in the soon to be release 2.2 series. As a work around I come up with this simple script, which has the sole problem of asking the secret subkey passphrase a few times too much, and to require to explicitly enter an empty passphrase. Let me know if it is excessively dummy or if there is a better way. Cheers, Daniele #!/bin/sh set -e KEY="$1" shift # make sure to have a "!" at the end of the key fingerprint to export # exclusively the corresponding subkey and not the primary key if [ "$KEY" == "${KEY%\!}" ] then KEY="$KEY"\! fi umask 0077 TMPDIR=$(mktemp -d) trap "rm -r $TMPDIR; exit" 0 1 2 3 15 gpg --export-secret-subkey "$KEY" | gpg --home $TMPDIR --import gpg --home $TMPDIR --change-passphrase "$KEY" gpg --home $TMPDIR --armor "$@" --export-secret-subkey "$KEY" From dan.horne at redbone.co.nz Mon Jan 29 03:44:56 2018 From: dan.horne at redbone.co.nz (Dan Horne) Date: Mon, 29 Jan 2018 15:44:56 +1300 Subject: Using GnuPG when switching users Message-ID: Hi I'm using GnuPG 2.0.29 on Solaris. This specific version is being used because it's the only one we could get installed and working. I'm trying to generate keys from a user I have su'd to, but I get the following error: gpg-agent[23024]: command get_passphrase failed: Permission denied gpg: problem with the agent: Permission denied gpg: Key generation canceled. I believe that thus occurs because when pinentry-curses is invoked by gpg-agent, the tty is owned by the original user I logged into via SSH, not the user I switched to via su. I've seen various workarounds online, but most are relevant to GNU/Linux, not Solaris (e.g. run the "script" command with the -c option, which doesn't exist on Solaris). Others have suggested using the loopback pinentry-mode, which doesn't seem to exist in version 2.0.29 of gpg-agent , as far as I can tell. Has someone got a workaround? I need to be able to use "su" as we are not allowed to log into the user directly. I'm also stuck with Solaris and the specified version of GnuPG -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.horne at redbone.co.nz Mon Jan 29 03:44:15 2018 From: dan.horne at redbone.co.nz (Dan Horne) Date: Mon, 29 Jan 2018 15:44:15 +1300 Subject: No subject Message-ID: Hi I'm using GnuPG 2.0.29 on Solaris. This specific version is being used because it's the only one we could get installed and working. I'm trying to generate keys from a user I have su'd to, but I get the following error: gpg-agent[23024]: command get_passphrase failed: Permission denied gpg: problem with the agent: Permission denied gpg: Key generation canceled. I believe that thus occurs because when pinentry-curses is invoked by gpg-agent, the tty is owned by the original user I logged into via SSH, not the user I switched to via su. I've seen various workarounds online, but most are relevant to GNU/Linux, not Solaris (e.g. run the "script" command with the -c option, which doesn't exist on Solaris). Others have suggested using the loopback pinentry-mode, which doesn't seem to exist in version 2.0.29 of gpg-agent , as far as I can tell. Has someone got a workaround? I need to be able to use "su" as we are not allowed to log into the user directly. I'm also stuck with Solaris and the specified version of GnuPG Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Mon Jan 29 10:12:46 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 29 Jan 2018 10:12:46 +0100 Subject: SCM SPR332 PIN entry doesn't work In-Reply-To: <2bcbd710-bb97-bd1c-a3c8-8ed26172758f@maciej.szmigiero.name> References: <21fbf99f-49a8-745e-8804-34266f546f54@maciej.szmigiero.name> <2bcbd710-bb97-bd1c-a3c8-8ed26172758f@maciej.szmigiero.name> Message-ID: On 28/01/18 22:02, Maciej S. Szmigiero wrote: > For posterity's sake: after contacting FLOSS-Shop the problem turned out > to be caused by the reader firmware (version 7.0). Thank you for posting the solution to the mailing list! That's really helpful for others in the future. Cheers, 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 kippapa at yahoo.com Mon Jan 29 14:45:24 2018 From: kippapa at yahoo.com (kip papa) Date: Mon, 29 Jan 2018 13:45:24 +0000 (UTC) Subject: Etoken pro windows 10 References: <1835237504.2567117.1517233524308.ref@mail.yahoo.com> Message-ID: <1835237504.2567117.1517233524308@mail.yahoo.com> Hi, everybody has anyone been able to use etoken pro gpg with windows 10. Is there any guide about it;? gpg: selecting openpgp failed: No such device gpg: OpenPGP card not available: No such device thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guru at unixarea.de Mon Jan 29 20:17:13 2018 From: guru at unixarea.de (Matthias Apitz) Date: Mon, 29 Jan 2018 20:17:13 +0100 Subject: Etoken pro windows 10 In-Reply-To: <1835237504.2567117.1517233524308@mail.yahoo.com> References: <1835237504.2567117.1517233524308.ref@mail.yahoo.com> <1835237504.2567117.1517233524308@mail.yahoo.com> Message-ID: <20180129191713.GA2296@c720-r314251> El d?a lunes, enero 29, 2018 a las 01:45:24p. m. +0000, kip papa via Gnupg-users escribi?: > Hi, everybody has anyone been able to use etoken pro gpg with windows 10. Is there any guide about it;? > gpg: selecting openpgp failed: No such device > gpg: OpenPGP card not available: No such device > thank you. Hi, Check this thread 'Using the OpenPGP Card on Unix && Win7' in the list's archives. I have had a similar issue and have had to configure which of the devices should be used. HIH matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From brnsaia at ieee.org Mon Jan 29 20:19:41 2018 From: brnsaia at ieee.org (brian saia) Date: Mon, 29 Jan 2018 11:19:41 -0800 Subject: pinentry fails with gpg-agent for ssh, but works for gpg In-Reply-To: <877es6yzc0.fsf@wheatstone.g10code.de> References: <20180125083924.GA3403@c720-r314251> <877es6yzc0.fsf@wheatstone.g10code.de> Message-ID: On 01/25/2018 03:03 AM, Werner Koch wrote: >> $ ssh some-host >> >> fails to ask for the PIN. > That is because ssh has no mechanism to tell the ssh-agent (in this case > gpg-agent) the DISPLAY or tty to use for pinentry. This the pinentry > pops up on the tty or X server gpg-agent was initially started. > > Running > > gpg-connect-agent updatestartuptty /bye > > on your current tty tells gpg-agent to updates its default tty and > DISPLAY to the one where you run gpg-connect-agent. ssh will then work > again. After you switch back to another terminal you need to do the > same. > > I have to use it always when I move from my standalone laptop to the > Xserver connected to that laptop. It is a bit annoying and the only > clean solution would be to enance the the ssh-agent protocol and > implement that in both, ssh and gpg-agent. One option could be to add that snippet of code... gpg-connect-agent updatestartuptty /bye to your /.bashrc/ (or equivalent) file. At the very least it might reduce the number of times you would have to enter it manually. Another option could be to create a script which calls gpg-connect-agent first then calls SSH. Something like this: $cat ~/bin/ssh #!/usr/bin/env bash gpg-connect-agent updatestartuptty /bye &>/dev/null /usr/bin/ssh "$@" -- Thank you for your time. -Brian Saia -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From demian at theshadowcompany.org Tue Jan 30 01:31:51 2018 From: demian at theshadowcompany.org (Demian J. Haven) Date: Tue, 30 Jan 2018 01:31:51 +0100 Subject: Key Length Issue on Mac OS X Message-ID: <17683678-40BA-4D67-B037-063CAFBC434B@theshadowcompany.org> Hello, I am facing key length issues when generating new keys with GPGTools. All new keys, are quite short compared to what I was used to. I can reproduce this issue consistently on both my MacPro on OS X 10.11.6 and my MacBook Pro on OS X 10.13.2 (tested on this machine with the last 3 Mac OS, El Capitan, Sierra and High Sierra, and different versions of GPGTools since mid 2016). The issue remains the same with the last version of GPGTools, released December 22, 2017. While generating a new key, I generally have a large file downloading, two others copying from/to the HD, typing text in TextEdit, and mouse pointer moving around. As much as I used to obtain very decent key lengths, as much now, I systematically obtain a much shorter one, regardless the disk activity during the generation of the key(s). The key length is remains the same, without the disk activity mentioned above. To illustrate, here is a link to an image with a previous key generated in March 2016 and another generated recently: https://imgur.com/x2d0IFh I have contacted GPGTools support where Luke Le advised I should post my issue here. Any advice and help would be truly appreciated. Thank you. Demian ? Demian Haven e demian at theshadowcompany.org PGP Key ID 0xC3F77843 Fingerprint 7CBA 6054 1F05 6589 8906 7378 B0CB 4838 C3F7 7843 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rjh at sixdemonbag.org Tue Jan 30 06:36:09 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 30 Jan 2018 00:36:09 -0500 Subject: Key Length Issue on Mac OS X In-Reply-To: <17683678-40BA-4D67-B037-063CAFBC434B@theshadowcompany.org> References: <17683678-40BA-4D67-B037-063CAFBC434B@theshadowcompany.org> Message-ID: <26aa4636-5e91-6586-68ad-9b6ae3ca7a36@sixdemonbag.org> > I am facing key length issues when generating new keys with GPGTools. I don't see any issue there. Two certificates may be of vastly different lengths for many different reasons. So far there's no reason to believe they contain different lengths of asymmetric keys. A 4096-bit key takes up about 12 lines of text in a certificate. The rest is other, non-key-related stuff. Instead of posting a link to an image of two certificates, please share the two certificates themselves -- for instance, via Dropbox or Pastebin. Once we can see the actual certificates we'll be able to more fully explain what's going on. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From fuzzy_drawrings at protonmail.com Wed Jan 31 03:35:57 2018 From: fuzzy_drawrings at protonmail.com (FuzzyDrawrings) Date: Tue, 30 Jan 2018 21:35:57 -0500 Subject: Why do Key Fingerprints include Creation Timestamp? Message-ID: <3tFdIT2BPb3fq6j-6OJKkMRmelq_PemcFx6ZN0Cc_kpcBTw_Aav1E4C_-0dxr9yGVj3C17rOokVt6y8s-lc49S3UkIJZLUYfc1h-guw3dQI=@protonmail.com> Wouldn't it make more sense to hash only the public-key's MPI value(s)? That way if an implementation's code fails to generate a unique key-pair, it will be known because the fingerprint will be the same as some other key. But as it is, with the Fingerprint hash including the timestamp, any "colliding" keys will have different fingerprints and so will go undetected. Is there a good reason for it to be this way? From dkg at fifthhorseman.net Wed Jan 31 05:19:50 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 30 Jan 2018 23:19:50 -0500 Subject: Why do Key Fingerprints include Creation Timestamp? In-Reply-To: <3tFdIT2BPb3fq6j-6OJKkMRmelq_PemcFx6ZN0Cc_kpcBTw_Aav1E4C_-0dxr9yGVj3C17rOokVt6y8s-lc49S3UkIJZLUYfc1h-guw3dQI=@protonmail.com> References: <3tFdIT2BPb3fq6j-6OJKkMRmelq_PemcFx6ZN0Cc_kpcBTw_Aav1E4C_-0dxr9yGVj3C17rOokVt6y8s-lc49S3UkIJZLUYfc1h-guw3dQI=@protonmail.com> Message-ID: <878tceacd5.fsf@fifthhorseman.net> On Tue 2018-01-30 21:35:57 -0500, FuzzyDrawrings via Gnupg-users wrote: > Wouldn't it make more sense to hash only the public-key's MPI > value(s)? That way if an implementation's code fails to generate a > unique key-pair, it will be known because the fingerprint will be the > same as some other key. > > But as it is, with the Fingerprint hash including the timestamp, any > "colliding" keys will have different fingerprints and so will go > undetected. > > Is there a good reason for it to be this way? This is a great question, and one that i've struggled with over time. I currently think that including the creation time in the fingerprint is a *good* thing, but i have felt otherwise in the past. The first thing to realize is that an OpenPGP certificate (a "transferable public key" in the text of RFC 4880) is not an immutable object -- it consists of a series of packets, and that collection of packets can change over time (or some people can hold some packets of a cert and other people hold others, so they see slightly different certs), though the fingerprint remains constant. So, including the creation date in the fingerprint means that if you know the fingerprint and your tools depend on it (or it's included in things like the signer fingerprint subpacket as modern implementations do), you've locked down the key's creation date, and it cannot be modified or replaced in the future regardless of how the certificate changes. Also, it cannot seem to be created at one time to some people and another way to other people. knowing the cert creation date can useful because it provides a bound on what kind of signatures are sensible. (e.g. a signature made before your key was created is super fishy). If your goal is to detect colliding key material, *you can do that too*, just by looking at the MPIs themselves directly. But given that the fingerprint kind of "locks in" the data that it covers, and it can be handy to know that the creation date of an OpenPGP certificate is immutable. does that make sense? --dkg From kippapa at yahoo.com Wed Jan 31 08:55:01 2018 From: kippapa at yahoo.com (kip papa) Date: Wed, 31 Jan 2018 07:55:01 +0000 (UTC) Subject: =?UTF-8?Q?=CE=A3=CF=87=CE=B5=CF=84:_Etoken_pro_windows_10?= In-Reply-To: <20180129191713.GA2296@c720-r314251> References: <1835237504.2567117.1517233524308.ref@mail.yahoo.com> <1835237504.2567117.1517233524308@mail.yahoo.com> <20180129191713.GA2296@c720-r314251> Message-ID: <2053936050.193830.1517385301016@mail.yahoo.com> Unfortunately? safenet etoken pro doesn't seem to be compatible with gpg for windows. Maybe i have to find something like a?http://gnupg-pkcs11.sourceforge.net/?smart-card daemon to enable the use of PKCS#11 token with?GnuPG?for windows or use cygwin.? Thank you for your support. 2018-01-30 09:15:48 scdaemon[3936] detected reader 'AKS ifdh 0'2018-01-30 09:15:48 scdaemon[3936] detected reader 'AKS ifdh 1'2018-01-30 09:15:48 scdaemon[3936] detected reader 'AKS VR 0'2018-01-30 09:15:48 scdaemon[3936] detected reader 'Rainbow Technologies iKeyVirtualReader 0'2018-01-30 09:15:48 scdaemon[3936] detected reader 'Rainbow Technologies iKeyVirtualReader 1'2018-01-30 09:15:48 scdaemon[3936] detected reader ''2018-01-30 09:15:48 scdaemon[3936] reader slot 0: not connected2018-01-30 09:15:48 scdaemon[3936] DBG: leave: apdu_open_reader => slot=0 [pc/sc]2018-01-30 09:15:48 scdaemon[3936] DBG: enter: apdu_connect: slot=02018-01-30 09:15:48 scdaemon[3936] pcsc_control failed: invalid PC/SC error code (0x1)2018-01-30 09:15:48 scdaemon[3936] pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 655472018-01-30 09:15:48 scdaemon[3936] reader slot 0: active protocol: T12018-01-30 09:15:48 scdaemon[3936] slot 0: ATR=3B F2 18 00 02 C1 0A 31 FE 58 C8 09 752018-01-30 09:15:48 scdaemon[3936] DBG: leave: apdu_connect => sw=0x02018-01-30 09:15:48 scdaemon[3936] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=02018-01-30 09:15:48 scdaemon[3936] DBG:? ?PCSC_data: 00 A4 00 0C 02 3F 002018-01-30 09:15:48 scdaemon[3936] DBG:? response: sw=9000? datalen=02018-01-30 09:15:48 scdaemon[3936] DBG:? ? ?dump:??2018-01-30 09:15:48 scdaemon[3936] DBG: send apdu: c=00 i=A4 p1=02 p2=0C lc=2 le=-1 em=02018-01-30 09:15:48 scdaemon[3936] DBG:? ?PCSC_data: 00 A4 02 0C 02 2F 022018-01-30 09:15:48 scdaemon[3936] DBG:? response: sw=6A82? datalen=02018-01-30 09:15:48 scdaemon[3936] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=02018-01-30 09:15:48 scdaemon[3936] DBG:? ?PCSC_data: 00 A4 04 00 06 D2 76 00 01 24 012018-01-30 09:15:48 scdaemon[3936] DBG:? response: sw=6A82? datalen=02018-01-30 09:15:48 scdaemon[3936] can't select application 'openpgp': Not supported ???? 9:17 ?.?. ???????, 29 ?????????? 2018, ?/? Matthias Apitz ??????: El d?a lunes, enero 29, 2018 a las 01:45:24p. m. +0000, kip papa via Gnupg-users escribi?: > Hi, everybody has anyone been able to use etoken pro gpg with windows 10. Is there any guide about it;? > gpg: selecting openpgp failed: No such device > gpg: OpenPGP card not available: No such device > thank you. Hi, Check this thread 'Using the OpenPGP Card on Unix && Win7' in the list's archives. I have had a similar issue and have had to configure which of the devices should be used. HIH ??? matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Wed Jan 31 10:30:03 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 31 Jan 2018 10:30:03 +0100 Subject: Using GnuPG when switching users In-Reply-To: References: Message-ID: <201801311030.03485.bernhard@intevation.de> Am Montag 29 Januar 2018 03:44:56 schrieb Dan Horne: > I'm trying to generate keys ?from a user I have su'd to, but I get the > following error: > > gpg-agent[23024]: command get_passphrase failed: Permission denied Maybe you can work around the problem in a different way. Ideas: * Login as the user, e.g. try ssh. * Use no passphrase * Use a pinentry that uses X11 * temporarility change ownership of the tty (As you can see, I'm a bit guessing widely, but maybe there is a hint in there for you.) Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From aneesh at idspage.com Wed Jan 31 07:12:15 2018 From: aneesh at idspage.com (Aneesh Varghese) Date: Wed, 31 Jan 2018 06:12:15 +0000 Subject: How to avoid Passphrase prompt Message-ID: Hi, How to avoid the passphrase prompt while decrypting the file in the version gnupg-w32-2.2.3_20171120. Thanks & Regards Aneesh Varghese -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roman.Fiedler at ait.ac.at Wed Jan 31 10:37:54 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Wed, 31 Jan 2018 09:37:54 +0000 Subject: AW: Why do Key Fingerprints include Creation Timestamp? In-Reply-To: <878tceacd5.fsf@fifthhorseman.net> References: <3tFdIT2BPb3fq6j-6OJKkMRmelq_PemcFx6ZN0Cc_kpcBTw_Aav1E4C_-0dxr9yGVj3C17rOokVt6y8s-lc49S3UkIJZLUYfc1h-guw3dQI=@protonmail.com> <878tceacd5.fsf@fifthhorseman.net> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B4100A@S0MSMAIL112.arc.local> > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von > > On Tue 2018-01-30 21:35:57 -0500, FuzzyDrawrings via Gnupg-users wrote: > > Wouldn't it make more sense to hash only the public-key's MPI > > value(s)? That way if an implementation's code fails to generate a > > unique key-pair, it will be known because the fingerprint will be the > > same as some other key. > > > > But as it is, with the Fingerprint hash including the timestamp, any > > "colliding" keys will have different fingerprints and so will go > > undetected. > > > > Is there a good reason for it to be this way? > > This is a great question, and one that i've struggled with over time. I > currently think that including the creation time in the fingerprint is a > *good* thing, but i have felt otherwise in the past. Including it provides a fast way to generate keys without changing cryptographic material (slow), thus speeds up creating keys with given 32 key-ID, 64 key-id might also be possible. Thus making it easier to provoke human errors (fingerprints where first/last 16 bit are matching another key, identical key-ID) ... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4814 bytes Desc: not available URL: From peter at digitalbrains.com Wed Jan 31 12:34:34 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 31 Jan 2018 12:34:34 +0100 Subject: How to avoid Passphrase prompt In-Reply-To: References: Message-ID: <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com> On 31/01/18 07:12, Aneesh Varghese wrote: > How to avoid the passphrase prompt while decrypting the file in the > version?gnupg-w32-2.2.3_20171120. You can remove the passphrase from the private key by: gpg --edit-key KEYID passwd Just enter the old password but keep the "new" fields blank. GnuPG will prompt whether you're sure you want to remove the protection of the key. Choose "Yes, protection is not needed". It will prompt multiple times when you have subkeys. It would be possible to remove passphrase protection from just the encryption subkey, but leave it on the rest. But this appears to be a bit awkward as the prompt doesn't tell me which subkey I'm currently changing the passphrase for... There's also a way to supply the password up front, which would still keep the on-disk private key encrypted. But this is more cumbersome, and you don't say whether that is needed or not, so I'm just mentioning it, not working it out. More in general, it helps if you explain more about your situation and your goals. 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 peter at digitalbrains.com Wed Jan 31 13:11:07 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 31 Jan 2018 13:11:07 +0100 Subject: How to avoid Passphrase prompt In-Reply-To: References: <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com> Message-ID: <47037cbe-106d-5cfb-f76e-7cb5b403e5ae@digitalbrains.com> On 31/01/18 12:47, Aneesh Varghese wrote: > Thanks for your reply.. > How can we decrypt a file without passphrase prompt? I don't understand what you want me to explain. A file is decrypted by using the private key. If the private key is passphrase-protected, you will need to enter that passphrase. I explained how to remove the passphrase from the key. The private key is stored as a file on your hard disk. If there is no passphrase to protect it, anybody with access to the file can use the private key. They can also decrypt files, and use the key however they want. This is why it has passphrase protection normally. > Passphrase is entered via code. I don't understand what you mean. 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 peter at digitalbrains.com Wed Jan 31 14:12:45 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 31 Jan 2018 14:12:45 +0100 Subject: How to avoid Passphrase prompt In-Reply-To: <69cd8517e2c24e9593d8dc4a8fa87150@idspage.com> References: <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com> <47037cbe-106d-5cfb-f76e-7cb5b403e5ae@digitalbrains.com> <69cd8517e2c24e9593d8dc4a8fa87150@idspage.com> Message-ID: On 31/01/18 13:19, Aneesh Varghese wrote: > is it possible to avoid the windows popup for entering the passphrase? The simplest way to avoid the popup is to remove the passphrase from the private key. The private key is stored on your hard disk. If there is no passphrase on the private key, anybody with access to your hard disk can decrypt files. They can also do anything else with your key. So you need to make sure that only you have access to the hard disk. Is this acceptable? 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 dkg at fifthhorseman.net Wed Jan 31 17:00:05 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 31 Jan 2018 11:00:05 -0500 Subject: Using GnuPG when switching users In-Reply-To: References: Message-ID: <87wozy81dm.fsf@fifthhorseman.net> On Mon 2018-01-29 15:44:56 +1300, Dan Horne wrote: > Has someone got a workaround? I need to be able to use "su" as we are not > allowed to log into the user directly. I'm also stuck with Solaris and the > specified version of GnuPG the problem you're running into is that pinentry is unable to prompt you for a password. as a workaround, you could create your own pinentry that provides a password, or that can prompt you in some other way. You might be interested in some dummy pinentry implementations: https://dev.gnupg.org/source/gnupg/browse/master/tests/fake-pinentries/ For an actual fix, you've got quite a set of constraints here, and they might just mean that you cannot solve the problem without a workaround. Please note that the 2.0.x branch of GnuPG is no longer supported by the project. I *strongly* recommend that you try to get the 2.2.* branch installed and then you'll be able to use the loopback pinentry-mode. And you'll be running supported software. --dkg From dkg at fifthhorseman.net Wed Jan 31 16:54:45 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 31 Jan 2018 10:54:45 -0500 Subject: AW: Why do Key Fingerprints include Creation Timestamp? In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B4100A@S0MSMAIL112.arc.local> References: <3tFdIT2BPb3fq6j-6OJKkMRmelq_PemcFx6ZN0Cc_kpcBTw_Aav1E4C_-0dxr9yGVj3C17rOokVt6y8s-lc49S3UkIJZLUYfc1h-guw3dQI=@protonmail.com> <878tceacd5.fsf@fifthhorseman.net> <2ECE9D9EEF1F524185270138AE23265955B4100A@S0MSMAIL112.arc.local> Message-ID: <87zi4u81mi.fsf@fifthhorseman.net> On Wed 2018-01-31 09:37:54 +0000, Fiedler Roman wrote: > Including it provides a fast way to generate keys without changing > cryptographic material (slow), I think you mean "to generate fingerprints", not "to generate keys" -- right? in particular, i think you're talking about the computational expense of searching the fingerprint space for certain properties. fwiw, cryptographic material generation itself is also super cheap these days (in particular, ecc keys just need a small and predictable amount of entropy to find). And if you're trying to do something devious where you don't care about the security of the key, even key formats that require searching for primes don't have a large cost. > thus speeds up creating keys with given 32 key-ID, 64 key-id might > also be possible. Thus making it easier to provoke human errors > (fingerprints where first/last 16 bit are matching another key, > identical key-ID) ... These are great reasons to never use key IDs for any purpose [0]. They're not particularly compelling reasons to avoid including the creation date, given that the computational expense of fingerprint search is basically the same whether you include the creation timestamp or not. If the goal is to increase computational expense of fingerprint search, there are better ways to do that (though they require changing the spec for OpenPGP, and most proposals i've seen to do so incur additional costs at other places in an OpenPGP workflow, which may or may not be a cost worth paying). Regards, --dkg [0] i agree, and i've argued this more comprehensively here: https://debian-administration.org/users/dkg/weblog/105 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From aneesh at idspage.com Wed Jan 31 12:47:22 2018 From: aneesh at idspage.com (Aneesh Varghese) Date: Wed, 31 Jan 2018 11:47:22 +0000 Subject: How to avoid Passphrase prompt In-Reply-To: <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com> References: , <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com> Message-ID: Thanks for your reply.. How can we decrypt a file without passphrase prompt? Passphrase is entered via code. Thanks & Regards Aneesh Varghese ________________________________________ From: Peter Lebbing Sent: Wednesday, January 31, 2018 5:04 PM To: Aneesh Varghese; gnupg-users at gnupg.org Subject: Re: How to avoid Passphrase prompt On 31/01/18 07:12, Aneesh Varghese wrote: > How to avoid the passphrase prompt while decrypting the file in the > version gnupg-w32-2.2.3_20171120. You can remove the passphrase from the private key by: gpg --edit-key KEYID passwd Just enter the old password but keep the "new" fields blank. GnuPG will prompt whether you're sure you want to remove the protection of the key. Choose "Yes, protection is not needed". It will prompt multiple times when you have subkeys. It would be possible to remove passphrase protection from just the encryption subkey, but leave it on the rest. But this appears to be a bit awkward as the prompt doesn't tell me which subkey I'm currently changing the passphrase for... There's also a way to supply the password up front, which would still keep the on-disk private key encrypted. But this is more cumbersome, and you don't say whether that is needed or not, so I'm just mentioning it, not working it out. More in general, it helps if you explain more about your situation and your goals. 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 From aneesh at idspage.com Wed Jan 31 13:19:49 2018 From: aneesh at idspage.com (Aneesh Varghese) Date: Wed, 31 Jan 2018 12:19:49 +0000 Subject: How to avoid Passphrase prompt In-Reply-To: <47037cbe-106d-5cfb-f76e-7cb5b403e5ae@digitalbrains.com> References: <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com> , <47037cbe-106d-5cfb-f76e-7cb5b403e5ae@digitalbrains.com> Message-ID: <69cd8517e2c24e9593d8dc4a8fa87150@idspage.com> Hi Peter, Currently I am able to decrypt the file using passphrase (passphrase entered via windows popup), is it possible to avoid the windows popup for entering the passphrase? Thanks & Regards Aneesh Varghese ________________________________________ From: Peter Lebbing Sent: Wednesday, January 31, 2018 5:41 PM To: Aneesh Varghese; gnupg-users at gnupg.org Subject: Re: How to avoid Passphrase prompt On 31/01/18 12:47, Aneesh Varghese wrote: > Thanks for your reply.. > How can we decrypt a file without passphrase prompt? I don't understand what you want me to explain. A file is decrypted by using the private key. If the private key is passphrase-protected, you will need to enter that passphrase. I explained how to remove the passphrase from the key. The private key is stored as a file on your hard disk. If there is no passphrase to protect it, anybody with access to the file can use the private key. They can also decrypt files, and use the key however they want. This is why it has passphrase protection normally. > Passphrase is entered via code. I don't understand what you mean. 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 From dan.horne at redbone.co.nz Wed Jan 31 21:22:15 2018 From: dan.horne at redbone.co.nz (Dan Horne) Date: Thu, 1 Feb 2018 09:22:15 +1300 Subject: Using GnuPG when switching users In-Reply-To: <87wozy81dm.fsf@fifthhorseman.net> References: <87wozy81dm.fsf@fifthhorseman.net> Message-ID: I'd love to have gone to 2.2 but getting GnuPG to work on Solaris is extremely difficult. We tried compiling from source, but hit several roadblocks. Looking online, several others have reported the same issues, but have had no resolution. I messaged this group, but unfortunately, none of the suggestions worked. In the end, our admins found an old packaged version of v2 on an open source for Solaris repository. The workaround was to make the virtual device terminal of the original user accessible to the su user who was creating the keys. This is a security hole that we're not happy with, but it was only temporary as we don't require an interactive passphrase following key creation. On 1 February 2018 at 05:00, Daniel Kahn Gillmor wrote: > On Mon 2018-01-29 15:44:56 +1300, Dan Horne wrote: > > Has someone got a workaround? I need to be able to use "su" as we are not > > allowed to log into the user directly. I'm also stuck with Solaris and > the > > specified version of GnuPG > > the problem you're running into is that pinentry is unable to prompt you > for a password. > > as a workaround, you could create your own pinentry that provides a > password, or that can prompt you in some other way. You might be > interested in some dummy pinentry implementations: > > https://dev.gnupg.org/source/gnupg/browse/master/tests/fake-pinentries/ > > For an actual fix, you've got quite a set of constraints here, and they > might just mean that you cannot solve the problem without a workaround. > > Please note that the 2.0.x branch of GnuPG is no longer supported by the > project. > > I *strongly* recommend that you try to get the 2.2.* branch installed > and then you'll be able to use the loopback pinentry-mode. And you'll > be running supported software. > > --dkg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Jan 31 23:02:28 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 31 Jan 2018 17:02:28 -0500 Subject: Using GnuPG when switching users In-Reply-To: References: <87wozy81dm.fsf@fifthhorseman.net> Message-ID: <87607h8z63.fsf@fifthhorseman.net> On Thu 2018-02-01 09:22:15 +1300, Dan Horne wrote: > I'd love to have gone to 2.2 but getting GnuPG to work on Solaris is > extremely difficult. We tried compiling from source, but hit several > roadblocks. Looking online, several others have reported the same issues, > but have had no resolution. I messaged this group, but unfortunately, none > of the suggestions worked. the only message i see from you about getting gpg to work on solaris is from back in September: Subject: "Insecure memory" (yes setuid set) and "get_passphrase failed" I don't see any issues about compilation there, though -- sorry if your messages were missed. > In the end, our admins found an old packaged version of v2 on an open > source for Solaris repository. The workaround was to make the virtual > device terminal of the original user accessible to the su user who was > creating the keys. This is a security hole that we're not happy with, but > it was only temporary as we don't require an interactive passphrase > following key creation. sounds like a functional workaround for the moment, but it doesn't get you into the realm of running software with active support :( aiui, GnuPG *intends* to support platforms like Solaris. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mail at davidlasek.eu Wed Jan 31 22:25:50 2018 From: mail at davidlasek.eu (D) Date: Wed, 31 Jan 2018 22:25:50 +0100 Subject: initramfs - gpg decryption failed invalid IPC response Message-ID: <8c08b400-b2c6-9459-2dc2-a7e0c2dc9691@davidlasek.eu> Hi there, I've been using OpenPGP smartcard to decrypt a keyfile to my drive partition with gpg. This worked until it broke after system upgrade some time around November 2017 (I do not have the pacman pkg cache from that time). > uname -a ??? Linux username 4.14.15-1-ARCH #1 SMP PREEMPT Tue Jan 23 21:49:25 UTC 2018 x86_64 GNU/Linux > gpg --version ??? gpg (GnuPG) 2.2.4 ??? libgcrypt 1.8.2 _THE PROBLEM:_ > gpg --homedir "/etc/initcpio/gpg" -o "/keyfile.bin" --decrypt "${key_file}" The command above which is run inside custom initcpio hook fails with status code: 2 And prints: gpg: encrypted with RSA key, ID . created gpg: public key decryption failed: Invalid IPC response gpg: decryption failed: No secret key Interestingly enough, when I break into a shell with `break=premount` kernel parameter and attempt to decrypt the keyfile by manually invoking same set of commands, everything works. However the break=premount gets triggered after the hook is run which might be why it works by that point. The custom initcpio hook is available here: https://github.com/fogine/initramfs-scencrypt Particularly this line: https://github.com/fogine/initramfs-scencrypt/blob/master/scencrypt-hook#L49 Note that before the decryption command, I run `gpg --card-status` which successfully detects the smartcard and populates subkey secret stub. These are hooks run at boot time (/etc/mkinitcpio.conf): HOOKS="base udev autodetect modconf block filesystems keyboard fsck scencrypt" "scencrypt" being my custom hook. I do not load any MODULES="" (in /etc/mkinicpio.conf) before the hooks are run. I struggle with debuging this issue, does anybody have an idea how I could proceed further? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: