From andrewg at andrewg.com  Wed Feb  1 10:01:15 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 1 Feb 2023 09:01:15 +0000
Subject: Unable to sign public key
In-Reply-To: <BF4A9431-E76B-4C5B-949F-FDDFCE390294@gmail.com>
References: <BF4A9431-E76B-4C5B-949F-FDDFCE390294@gmail.com>
Message-ID: <B44999AA-D8F0-4E01-948F-794E3335B593@andrewg.com>

On 31 Jan 2023, at 19:52, Joel via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> Hello!
> 
> I am trying to sign a public key, but I get an error saying, `gpg: signing failed: No secret key`. However, a normal signing on a file works perfectly fine. I suspect it could be something because I have a yubikey and it might not work as I initially expected. Have anyone had similar problems and know how to fix it when you use a yubikey?

Yes, this is expected behaviour with a yubikey. The confusion arises with an unfortunate clash of terminology. When you ?sign? someone else?s public key, you are technically ?certifying? it - even though signing and certification use the same cryptographic operation (also called ?signing?, hence the confusion), they are two different modes of operation and PGP treats them as entirely separate things.

The normal structure of a key is to have a primary key which is allowed to certify and sign, and an encryption subkey that is only allowed to (de)crypt. When using a yubikey, standard practice is to also create a signing subkey and store that and the encryption subkey (and optionally an authentication subkey) on the yubikey, but leave the primary on disk. The advantage is that if your yubikey is stolen, you can generate new subkeys and revoke the old ones, without having to revoke the primary. The disadvantage is that certification subkeys are not supported by the standard, so yubikeys (and other forms of smartcard) cannot normally certify other people?s keys.

You may be able to get around this by ensuring that your primary key is signing-capable (it is by default) and storing it instead of a signing subkey in the signing slot of your yubikey (caveat: I have not tested this!). But then you lose the main advantage of a yubikey (sacrificial subkeys). Otherwise, you can only certify other keys using the original computer that has your primary key on disk.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230201/a657c47a/attachment.sig>

From joellidin at gmail.com  Wed Feb  1 12:12:08 2023
From: joellidin at gmail.com (Joel)
Date: Wed, 1 Feb 2023 12:12:08 +0100
Subject: Unable to sign public key
In-Reply-To: <B44999AA-D8F0-4E01-948F-794E3335B593@andrewg.com>
References: <B44999AA-D8F0-4E01-948F-794E3335B593@andrewg.com>
Message-ID: <207A6959-FC86-4FA2-A1F1-3587D72D6F9C@gmail.com>

Thank you for the response. I suspected it was something to do with the fact that my master certification key is on a USB stick because it worked when I used another non-yubikey PGP key. I will try to certify it via the master certification key. Thanks for the help. I appreciate it!

Best regards,

Joel

Sent from my iPhone

> On 1 Feb 2023, at 10:01, Andrew Gallagher <andrewg at andrewg.com> wrote:
> 
> ?On 31 Jan 2023, at 19:52, Joel via Gnupg-users <gnupg-users at gnupg.org> wrote:
>> 
>> Hello!
>> 
>> I am trying to sign a public key, but I get an error saying, `gpg: signing failed: No secret key`. However, a normal signing on a file works perfectly fine. I suspect it could be something because I have a yubikey and it might not work as I initially expected. Have anyone had similar problems and know how to fix it when you use a yubikey?
> 
> Yes, this is expected behaviour with a yubikey. The confusion arises with an unfortunate clash of terminology. When you ?sign? someone else?s public key, you are technically ?certifying? it - even though signing and certification use the same cryptographic operation (also called ?signing?, hence the confusion), they are two different modes of operation and PGP treats them as entirely separate things.
> 
> The normal structure of a key is to have a primary key which is allowed to certify and sign, and an encryption subkey that is only allowed to (de)crypt. When using a yubikey, standard practice is to also create a signing subkey and store that and the encryption subkey (and optionally an authentication subkey) on the yubikey, but leave the primary on disk. The advantage is that if your yubikey is stolen, you can generate new subkeys and revoke the old ones, without having to revoke the primary. The disadvantage is that certification subkeys are not supported by the standard, so yubikeys (and other forms of smartcard) cannot normally certify other people?s keys.
> 
> You may be able to get around this by ensuring that your primary key is signing-capable (it is by default) and storing it instead of a signing subkey in the signing slot of your yubikey (caveat: I have not tested this!). But then you lose the main advantage of a yubikey (sacrificial subkeys). Otherwise, you can only certify other keys using the original computer that has your primary key on disk.
> 
> A
> 


From martin at postzone.org  Wed Feb  1 10:32:41 2023
From: martin at postzone.org (Martin)
Date: Wed, 1 Feb 2023 10:32:41 +0100
Subject: Public keys stored on different server
Message-ID: <1186983974.20230201103218@postzone.org>

Hello

Perhaps my question is strange an silly ;-)

More and more I see messages which are signed - but the author didn't
store his public key on a keyserver (eg. hkps://keys.openpgp.org) -
sometimes a footnote in the massages gives a link where the key could
be downloaded. Sometimes this link has a bad or strange https 
certificate...

What are the reasons for such a procedure and what is the advantage?

-- 
Best regards,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230201/fb807241/attachment.sig>

From alex at blueselene.com  Wed Feb  1 13:01:21 2023
From: alex at blueselene.com (Alex)
Date: Wed, 1 Feb 2023 13:01:21 +0100
Subject: Public keys stored on different server
In-Reply-To: <1186983974.20230201103218@postzone.org>
References: <1186983974.20230201103218@postzone.org>
Message-ID: <20230201130121.7082cbe7@blueselene.com>

On Wed, 1 Feb 2023 10:32:41 +0100
Martin <martin at postzone.org> wrote:

> Hello
> 
> Perhaps my question is strange an silly ;-)
> 
> More and more I see messages which are signed - but the author didn't
> store his public key on a keyserver (eg. hkps://keys.openpgp.org) -
> sometimes a footnote in the massages gives a link where the key could
> be downloaded. Sometimes this link has a bad or strange https 
> certificate...
> 
> What are the reasons for such a procedure and what is the advantage?
> 

That sometimes happen to me, my key is available at my domain but
sometimes codeberg pages freaks out a bit, fails to recognize my custom
domain and serves the *.codeberg.pages certificate, sorry about that, in
case you're talking about my key it is also at the Ubuntu keyserver:
keyserver.ubuntu.com (I used to have that on my sig).

There's not much you can do in those situations. There's not
really much in the way of an advantage compared to downloading from a
keyserver when searching by the key ID.

-- 
Current PGP KeyID: 11ADE4393600C1BDFFCBC0A598DE15942B08CA00

https://blueselene.com/pgp-archive/11ADE4393600C1BDFFCBC0A598DE15942B08CA00/key.pub

For up-to-date information on my crypto keys see
https://blueselene.com/crypto.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230201/2af3dc60/attachment.sig>

From alex at blueselene.com  Wed Feb  1 13:06:45 2023
From: alex at blueselene.com (Alex)
Date: Wed, 1 Feb 2023 13:06:45 +0100
Subject: Public keys stored on different server
In-Reply-To: <20230201130121.7082cbe7@blueselene.com>
References: <1186983974.20230201103218@postzone.org>
 <20230201130121.7082cbe7@blueselene.com>
Message-ID: <20230201130645.0f7fb1a6@blueselene.com>

On Wed, 1 Feb 2023 13:01:21 +0100
Alex <alex at blueselene.com> wrote:

> There's not much you can do in those situations. There's not
> really much in the way of an advantage compared to downloading from a
> keyserver when searching by the key ID.

Correction: It can help if there are collisions, software should not
assume that Key IDs are unique
(https://www.rfc-editor.org/rfc/rfc4880#section-3.3).

-- 
Current PGP KeyID: 11ADE4393600C1BDFFCBC0A598DE15942B08CA00

https://blueselene.com/pgp-archive/11ADE4393600C1BDFFCBC0A598DE15942B08CA00/key.pub

For up-to-date information on my crypto keys see
https://blueselene.com/crypto.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230201/2578b521/attachment.sig>

From fa-ml at ariis.it  Wed Feb  1 12:57:30 2023
From: fa-ml at ariis.it (Francesco Ariis)
Date: Wed, 1 Feb 2023 12:57:30 +0100
Subject: Public keys stored on different server
In-Reply-To: <1186983974.20230201103218@postzone.org>
References: <1186983974.20230201103218@postzone.org>
Message-ID: <Y9pTqtlCOls5l2QR@mkiii.casa>

Hello Martin,

Il 01 febbraio 2023 alle 10:32 Martin ha scritto:
> More and more I see messages which are signed - but the author didn't
> store his public key on a keyserver (eg. hkps://keys.openpgp.org) -
> sometimes a footnote in the massages gives a link where the key could
> be downloaded. Sometimes this link has a bad or strange https 
> certificate...
> 
> What are the reasons for such a procedure and what is the advantage?

Keyserver records are public and spammers can scan those (although:
a) in 2022 I wonder if there is still much value in email spamming and
b) some servers are taking countermeasures).

This could be a reason why some people prefer not to upload their public
key to keyservers.


From juergen at bruckner.email  Wed Feb  1 15:07:14 2023
From: juergen at bruckner.email (Juergen M. Bruckner)
Date: Wed, 1 Feb 2023 15:07:14 +0100
Subject: Public keys stored on different server
In-Reply-To: <1186983974.20230201103218@postzone.org>
References: <1186983974.20230201103218@postzone.org>
Message-ID: <171a808a-ce0d-d1af-1356-0c63935eef46@bruckner.email>

Hello,

Apart from the use of keyserver, it is relatively easy and highly 
recommended to use WKD (Web Key Directory) for PGP-Keys.
Another alternative is DNS OPENPGPKEY Record.

regards
Juergen

Am 01.02.23 um 10:32 schrieb Martin:
> Hello
> 
> Perhaps my question is strange an silly ;-)
> 
> More and more I see messages which are signed - but the author didn't
> store his public key on a keyserver (eg. hkps://keys.openpgp.org) -
> sometimes a footnote in the massages gives a link where the key could
> be downloaded. Sometimes this link has a bad or strange https
> certificate...
> 
> What are the reasons for such a procedure and what is the advantage?
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users

-- 
/?\   No  |
\ /  HTML |    Juergen Bruckner
  X    in  |    juergen at bruckner.email
/ \  Mail |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3482 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230201/e5cc2643/attachment.bin>

From martin at postzone.org  Wed Feb  1 16:51:14 2023
From: martin at postzone.org (Martin)
Date: Wed, 1 Feb 2023 16:51:14 +0100
Subject: Public keys stored on different server
In-Reply-To: <20230201130121.7082cbe7@blueselene.com>
References: <1186983974.20230201103218@postzone.org>
 <20230201130121.7082cbe7@blueselene.com>
Message-ID: <1474509388.20230201165114@postzone.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Alex,

Wednesday, February 1, 2023, 1:01:21 PM, you wrote:

> There's not much you can do in those situations. There's not
> really much in the way of an advantage compared to downloading from a
> keyserver when searching by the key ID.

It just seemed like a contradiction to me if a key for security
reasons should be downloaded from a website with an insufficient
certificate ;-)

- --
Best regards,
Martin
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE92uV/w2x7WB1p4XLsdyR185C444FAmPaiooACgkQsdyR185C
444E1Af9Eb7h9Kmqalk27WwprTx/fW/GK/m5HXdKLKLXtNbKbkGKu1f2lXEj3R6p
zlLC3npYgAr1ZPNT0H1G/1fHo8E4s8XeJRN8Lli216conbqX0KoY3OhC7vIMMpl7
3OgQXbEqPLBDZaFTmITHA6xCq5BN0jB+JGXKgWKBLEJUvyEfzgIY6jYqw1U7ng2a
55xSm2HQPCjhkoZnkZvj4fjuOzgSlID/v5g/yT9xZgMDUKBFuaejkg1NJ4OJXehb
OCTlC13O1dcbK+4Qe/aTBbnkjz7wLyUk7rdLN+uSW8MBA5wX22L4PERblVWYVTeT
/Gdu6xoPWfMwK4RNsmzQxRIpzy4ZCg==
=v7z2
-----END PGP SIGNATURE-----



From ming at imkuang.com  Wed Feb  1 17:40:54 2023
From: ming at imkuang.com (Ming Kuang)
Date: Thu, 2 Feb 2023 00:40:54 +0800
Subject: Public keys stored on different server
In-Reply-To: <1186983974.20230201103218@postzone.org>
References: <1186983974.20230201103218@postzone.org>
Message-ID: <006e01d9365b$f525cf80$df716e80$@imkuang.com>


On Wednesday, February 1, 2023 5:33 PM, Martin wrote:
> Hello
> 
> Perhaps my question is strange an silly ;-)
> 
> More and more I see messages which are signed - but the author didn't
> store his public key on a keyserver (eg. hkps://keys.openpgp.org) -
> sometimes a footnote in the massages gives a link where the key could
> be downloaded. Sometimes this link has a bad or strange https
> certificate...
> 
> What are the reasons for such a procedure and what is the advantage?

Even if the key is uploaded to a keyserver, we are faced with the new
problem of which server we can get it from (it is well known that
keys.openpgp.org is not synchronized with other keyservers, and I think
there are more such cases).

For users with custom domain email addresses, it may be a good idea to
publish PGP public keys using WKD (Web Key Directory), which solves the
problem of where to find the keys (find from your email address domain).
But for the average user, I think providing a key download link is probably
the easiest and most feasible solution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230202/22bc4c95/attachment-0001.sig>

From wk at gnupg.org  Wed Feb  1 17:45:04 2023
From: wk at gnupg.org (Werner Koch)
Date: Wed, 01 Feb 2023 17:45:04 +0100
Subject: Public keys stored on different server
In-Reply-To: <1474509388.20230201165114@postzone.org> (Martin's message of
 "Wed, 1 Feb 2023 16:51:14 +0100")
References: <1186983974.20230201103218@postzone.org>
 <20230201130121.7082cbe7@blueselene.com>
 <1474509388.20230201165114@postzone.org>
Message-ID: <871qn91gj3.fsf@wheatstone.g10code.de>

On Wed,  1 Feb 2023 16:51, Martin said:

> It just seemed like a contradiction to me if a key for security
> reasons should be downloaded from a website with an insufficient
> certificate ;-)

That is not really a matter.  X.509 certificates as well as PGP keys are
self-contained.  All OpenPGP applications check the integrity of newly
imported keys.

However, only the integrity can be checked but not whether the key
actually belongs to the entity it claims it belongs to (validity or
trust).  Thus you either need to verify the fingerprint of the key or
use signature on the key issued by keys you already validated (cf. Web
of Trust, trusted introducer).


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230201/2f6fa2d6/attachment.sig>

From look at my.amazin.horse  Thu Feb  2 12:41:48 2023
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Thu, 2 Feb 2023 12:41:48 +0100
Subject: Public keys stored on different server
In-Reply-To: <Y9pTqtlCOls5l2QR@mkiii.casa>
References: <1186983974.20230201103218@postzone.org>
 <Y9pTqtlCOls5l2QR@mkiii.casa>
Message-ID: <7e32f4d8-f4e3-3f60-5d7f-759814d4d104@my.amazin.horse>

Hey list,
> Keyserver records are public and spammers can scan those

Just quickly noting, since keys.openpgp.org was mentioned at the
beginning of the thread:

For traditional (sks-style) keyservers, it is true that the list of all 
certificates
and email addresses is public, and must be by design. For keys.openpgp.org
specifically, this full list is not public and never will be in 
accordance with
our privacy policy.

Cheers

 ?- V



From martin at postzone.org  Thu Feb  2 14:59:47 2023
From: martin at postzone.org (Martin)
Date: Thu, 2 Feb 2023 14:59:47 +0100
Subject: Public keys stored on different server
In-Reply-To: <7e32f4d8-f4e3-3f60-5d7f-759814d4d104@my.amazin.horse>
References: <1186983974.20230201103218@postzone.org>
 <Y9pTqtlCOls5l2QR@mkiii.casa> 
 <7e32f4d8-f4e3-3f60-5d7f-759814d4d104@my.amazin.horse>
Message-ID: <246482286.20230202145934@postzone.org>

Hello Vincent,

Thursday, February 2, 2023, 12:41:48 PM, you wrote:

> For traditional (sks-style) keyservers, it is true that the list of all certificates
> and email addresses is public, and must be by design. For keys.openpgp.org
> specifically, this full list is not public and never will be in accordance with
> our privacy policy.

Could you please explain this, I don't understand really. So there are
public and no public keys on the this key-server? Who decides that a
key is public or non-public? Who or how can I request a non-public
key?

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230202/d4bc31e3/attachment.sig>

From look at my.amazin.horse  Thu Feb  2 21:45:53 2023
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Thu, 2 Feb 2023 21:45:53 +0100
Subject: Public keys stored on different server
In-Reply-To: <246482286.20230202145934@postzone.org>
References: <1186983974.20230201103218@postzone.org>
 <Y9pTqtlCOls5l2QR@mkiii.casa>
 <7e32f4d8-f4e3-3f60-5d7f-759814d4d104@my.amazin.horse>
 <246482286.20230202145934@postzone.org>
Message-ID: <4c9ac34d-90fa-0fb1-4d0a-f2122c1c38ae@my.amazin.horse>

Hi Martin,

> Could you please explain this, I don't understand really. So there are
> public and no public keys on the this key-server? Who decides that a
> key is public or non-public? Who or how can I request a non-public
> key?
Sorry, that wasn't as clear as it could have been. There are no
non-public keys, all keys are still publicly available, and can be
retrieved by fingerprint or email address. You just can't retrieve
all keys or email addresses as a full list, which makes it a far
less interesting target for spammers.

Cheers

 ?- V




From bernhard at intevation.de  Fri Feb  3 09:27:04 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 3 Feb 2023 09:27:04 +0100
Subject: Technical Terms/Website TheBat!: OpenPGP, GnuPG
Message-ID: <202302030927.04799.bernhard@intevation.de>

Dear TheBat!-Team,

it is good that you are offering support for email cryptography
in your email client products. And it is fine and cool that you
are using GnuPG (on Windows via Gpg4win).

Just noticed that some of your technical terms on the web-site can be 
improved:

 
 https://www.ritlabs.com/de/products/thebat/
 "Unterst?tzung f?r PGP, GnuPGP, und S/MIME"

There is the typo "GnuPGP" where you mean "GnuPG".

Also note that "PGP" is a proprietary product (owned by Broadcom these days, 
last time I've looked). You are probably not really supporting it, I 
guess. :) And the crypto format is called "OpenPGP". So using "OpenPGP"
or "OpenPGP/MIME" would give your users a better understanding of what TheBat! 
is supporting.

  https://www.ritlabs.com/en/products/thebat/
  "PGP"

If you have any questions about GnuPG or Gpg4win, you can either
mail the mailinglist (gnupg-users@) or the Gpg4win forum.

Best Regards
Bernhard

-- 
https://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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230203/291e268b/attachment.sig>

From martin at postzone.org  Fri Feb  3 11:16:42 2023
From: martin at postzone.org (Martin)
Date: Fri, 3 Feb 2023 11:16:42 +0100
Subject: Public keys stored on different server
In-Reply-To: <4c9ac34d-90fa-0fb1-4d0a-f2122c1c38ae@my.amazin.horse>
References: <1186983974.20230201103218@postzone.org>
 <Y9pTqtlCOls5l2QR@mkiii.casa> 
 <7e32f4d8-f4e3-3f60-5d7f-759814d4d104@my.amazin.horse>
 <246482286.20230202145934@postzone.org>
 <4c9ac34d-90fa-0fb1-4d0a-f2122c1c38ae@my.amazin.horse>
Message-ID: <1483500981.20230203111642@postzone.org>

Hello Vincent,

Ok - that is clear now. I never had the idea to get a "whole list" 
from a key server but I didn't understand why people let access their 
key only on their own website.

Martin

Thursday, February 2, 2023, 9:45:53 PM, you wrote:


>> Could you please explain this, I don't understand really. So there are
>> public and no public keys on the this key-server? Who decides that a
>> key is public or non-public? Who or how can I request a non-public
>> key?
> Sorry, that wasn't as clear as it could have been. There are no
> non-public keys, all keys are still publicly available, and can be
> retrieved by fingerprint or email address. You just can't retrieve
> all keys or email addresses as a full list, which makes it a far
> less interesting target for spammers.



From juergen at bruckner.email  Fri Feb  3 12:06:23 2023
From: juergen at bruckner.email (Juergen M. Bruckner)
Date: Fri, 3 Feb 2023 12:06:23 +0100
Subject: Public keys stored on different server
In-Reply-To: <1483500981.20230203111642@postzone.org>
References: <1186983974.20230201103218@postzone.org>
 <Y9pTqtlCOls5l2QR@mkiii.casa>
 <7e32f4d8-f4e3-3f60-5d7f-759814d4d104@my.amazin.horse>
 <246482286.20230202145934@postzone.org>
 <4c9ac34d-90fa-0fb1-4d0a-f2122c1c38ae@my.amazin.horse>
 <1483500981.20230203111642@postzone.org>
Message-ID: <839729d2-4809-4dac-eef7-dc13fca3c539@bruckner.email>

Hello Martin,

so I think these people want to make it as easy as possible for others 
to get the public key. I also make my keys available on my website and 
via WKD and DNS.
 From my point of view it is also a kind of security for people who want 
to write to me that they have my real key - and not a fake one.

regards
Juergen

Am 03.02.23 um 11:16 schrieb Martin:
> Hello Vincent,
> 
> Ok - that is clear now. I never had the idea to get a "whole list"
> from a key server but I didn't understand why people let access their
> key only on their own website.
> 
> Martin
> 
> Thursday, February 2, 2023, 9:45:53 PM, you wrote:
> 
> 
>>> Could you please explain this, I don't understand really. So there are
>>> public and no public keys on the this key-server? Who decides that a
>>> key is public or non-public? Who or how can I request a non-public
>>> key?
>> Sorry, that wasn't as clear as it could have been. There are no
>> non-public keys, all keys are still publicly available, and can be
>> retrieved by fingerprint or email address. You just can't retrieve
>> all keys or email addresses as a full list, which makes it a far
>> less interesting target for spammers.
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users

-- 
/?\   No  |
\ /  HTML |    Juergen Bruckner
  X    in  |    juergen at bruckner.email
/ \  Mail |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3482 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230203/1cfae94c/attachment-0001.bin>

From bernhard at intevation.de  Fri Feb  3 16:09:28 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 3 Feb 2023 16:09:28 +0100
Subject: Technical Terms/Website TheBat!: OpenPGP, GnuPG
In-Reply-To: <202302030927.04799.bernhard@intevation.de>
References: <202302030927.04799.bernhard@intevation.de>
Message-ID: <202302031609.28711.bernhard@intevation.de>

Am Freitag 03 Februar 2023 09:27:04 schrieb Bernhard Reiter:
> Just noticed that some of your technical terms on the web-site can be
> improved:

Got a friendly response:

----------  Weitergeleitete Nachricht  ----------
[..]
Thank you very much for the detailed explanation.

We have updated the respective web-pages and it will take a couple of days for 
the cache to update too.

If you would like to, you can access these links avoiding the old caches 
pages:
https://www.ritlabs.com/de/products/thebat/?a
https://www.ritlabs.com/en/products/thebat/?a

Alexander Petrari
Ritlabs, SRL
------------------

-- 
https://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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230203/d781500a/attachment.sig>

From bozho at kset.org  Fri Feb 10 11:03:06 2023
From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=)
Date: Fri, 10 Feb 2023 11:03:06 +0100
Subject: Yubikeys and GnuPG 2.2/2.3
In-Reply-To: <877db6p1t1.fsf@wheatstone.g10code.de>
References: <1b3ae727-ee8b-865b-ea6a-7ba6ab3dfae4@kset.org>
 <87leznspv5.fsf@wheatstone.g10code.de>
 <e13774e5-3a48-1035-3750-d4bb9f25356a@kset.org>
 <877db6p1t1.fsf@wheatstone.g10code.de>
Message-ID: <756427e8-cc34-36e4-cb16-d30880b4f472@kset.org>

On 11/01/2022 19:25, Werner Koch wrote:
> 
>> Just to confirm, my scdaemon.conf file should look like this:
>>
>> debug-level ipc,app,cardio
> 
> Replace that by
> 
>    debug ipc,app,cardio
> 
> and remove debug-level lines.  (The debug-leve thing is IMHO not very
> useful since we got those dedicated selectors.  We should eventually
> remove the debug level thing and provide a GUI to select them.)

Hi Werner,

I've tested this again with GnuPG 2.4.0 (Windows build) and still get the same 
error with Yubikey NEO (scdaemon reports "no supported card application found: 
Card error") when running 'gpg --card-status'.

Yubikey 5 works fine.

Both Yubikey NEO and 5 work with GnuPG 2.2.27.

It looks like this (https://dev.gnupg.org/T5487) bug report mentions the 
same/similar problem, but that bug was supposedly fixed in 2.2.29.

I see that gniibe mentions that Yubikey NEO returns 6A86  on the first 
response, but my 2.4 log shows only 6D00 responses (as did 2.3 logs).

Kind regards,
-- 
Marko Bo?ikovi?
-------------- next part --------------
2023-02-10 10:50:41 scdaemon[4580] listening on socket 'F:\\Users\\bozho\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon'
2023-02-10 10:50:41 scdaemon[4580] handler for fd -1 started
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> OK GNU Privacy Guard's Smartcard server ready
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 <- GETINFO socket_name
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> D F:\Users\bozho\AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> OK
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 <- OPTION event-signal=28c
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> OK
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 <- GETINFO version
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> D 2.4.0
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> OK
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 <- SERIALNO
2023-02-10 10:50:41 scdaemon[4580] detected reader 'Yubico YubiKey OTP+FIDO+CCID 0'
2023-02-10 10:50:41 scdaemon[4580] reader slot 0: not connected
2023-02-10 10:50:41 scdaemon[4580] reader slot 0: active protocol: T1
2023-02-10 10:50:41 scdaemon[4580] slot 0: ATR=3bfd1300008131fe158073c021c057597562694b657940
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00a4000c023f00
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=6D00  datalen=0
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=8 le=-1 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00a4040008a000000527471117
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=30
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 5669727475616c206d6772202d2046572076657273696f6e20352e312e32
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 001d000000
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=44
2023-02-10 10:50:41 scdaemon[4580] DBG:       dump:  2b0102023f0302023f020400a6a3b704010105030501020602000007010f0801 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  000d02023b0e02023b0a01009000
2023-02-10 10:50:41 scdaemon[4580] Yubico: config=2b0102023f0302023f020400a6a3b704010105030501020602000007010f0801000d02023b0e02023b0a0100
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00a4040006d27600012401
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=0
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: [all zero]
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=00 p2=4F lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca004f00
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=16
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: d2760001240102010006109208870000
2023-02-10 10:50:41 scdaemon[4580] AID: d2760001240102010006109208870000
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca5f5200
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=8
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 0073000080059000
2023-02-10 10:50:41 scdaemon[4580] Historical Bytes: 0073000080059000
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca00c400
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=7
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: ff7f7f7f030003
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca006e00
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=224
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 6e81dd4f10d27600012401020100061092088700005f52080073000080059000 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  7f74038101207381b7c00a3c00000004c000ff00ffc106010800001100c20601 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  0800001100c306010800001100c407ff7f7f7f030003c53cdd16d08d4f6500c6 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  f497dd1b4f17415d2a9f806fd8f830bdada0ea87a54769bf8fd959c4e4d217d0 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  3aeca53c784d35debd0fd2d278b4b9f160ef5e9ec63c00000000000000000000 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  0000000000000000000000000000000000000000000000000000000000000000 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  000000000000000000000000000000000000cd0c55b1577555b157cb55b157ea
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca005e00
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=0
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: [all zero]
2023-02-10 10:50:41 scdaemon[4580] Version-2+ .....: yes
2023-02-10 10:50:41 scdaemon[4580] Version-3+ .....: no
2023-02-10 10:50:41 scdaemon[4580] Button .........: yes
2023-02-10 10:50:41 scdaemon[4580] SM-Support .....: no
2023-02-10 10:50:41 scdaemon[4580] Get-Challenge ..: no
2023-02-10 10:50:41 scdaemon[4580] Key-Import .....: yes
2023-02-10 10:50:41 scdaemon[4580] Change-Force-PW1: yes
2023-02-10 10:50:41 scdaemon[4580] Private-DOs ....: yes
2023-02-10 10:50:41 scdaemon[4580] Algo-Attr-Change: yes
2023-02-10 10:50:41 scdaemon[4580] Symmetric Crypto: no
2023-02-10 10:50:41 scdaemon[4580] KDF-Support ....: no
2023-02-10 10:50:41 scdaemon[4580] Max-Cert-Len ...: 1216
2023-02-10 10:50:41 scdaemon[4580] Cmd-Chaining ...: yes
2023-02-10 10:50:41 scdaemon[4580] Ext-Lc-Le ......: no
2023-02-10 10:50:41 scdaemon[4580] Status-Indicator: 05
2023-02-10 10:50:41 scdaemon[4580] GnuPG-No-Sync ..: no
2023-02-10 10:50:41 scdaemon[4580] GnuPG-Def-PW2 ..: no
2023-02-10 10:50:41 scdaemon[4580] Key-Attr-sign ..: RSA, n=2048, e=17, fmt=std
2023-02-10 10:50:41 scdaemon[4580] Key-Algo-sign ..: rsa2048
2023-02-10 10:50:41 scdaemon[4580] Key-Attr-encr ..: RSA, n=2048, e=17, fmt=std
2023-02-10 10:50:41 scdaemon[4580] Key-Algo-encr ..: rsa2048
2023-02-10 10:50:41 scdaemon[4580] Key-Attr-auth ..: RSA, n=2048, e=17, fmt=std
2023-02-10 10:50:41 scdaemon[4580] Key-Algo-auth ..: rsa2048
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S SERIALNO D2760001240100000006109208870000
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> OK
2023-02-10 10:50:41 scdaemon[4580] triggering event 0x0000028c (0x0000028c) for client -1
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 <- LEARN --force
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S READER Yubico YubiKey OTP+FIDO+CCID 0
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S SERIALNO D2760001240100000006109208870000
2023-02-10 10:50:41 scdaemon[4580] DBG: slot 0: have=openpgp want=openpgp keyref=[none]
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S CARDTYPE yubikey
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S CARDVERSION 50102
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S APPTYPE openpgp
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S APPVERSION 201
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S EXTCAP gc=0+ki=1+fc=1+pd=1+mcl3=1216+aac=1+sm=0+si=5+dec=0+bt=1+kdf=0
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S MANUFACTURER 6 Yubico
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=00 p2=65 lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca006500
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=27
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 65195b10426f7a696b6f7669633c3c4d61726b6f5f2d005f350139
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S DISP-NAME Bozikovic<<Marko
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S DISP-LANG
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S DISP-SEX 9
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=5F p2=50 lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca5f5000
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=0
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: [all zero]
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca006e00
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=224
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 6e81dd4f10d27600012401020100061092088700005f52080073000080059000 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  7f74038101207381b7c00a3c00000004c000ff00ffc106010800001100c20601 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  0800001100c306010800001100c407ff7f7f7f030003c53cdd16d08d4f6500c6 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  f497dd1b4f17415d2a9f806fd8f830bdada0ea87a54769bf8fd959c4e4d217d0 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  3aeca53c784d35debd0fd2d278b4b9f160ef5e9ec63c00000000000000000000 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  0000000000000000000000000000000000000000000000000000000000000000 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  000000000000000000000000000000000000cd0c55b1577555b157cb55b157ea
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEY-FPR 1 DD16D08D4F6500C6F497DD1B4F17415D2A9F806F
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEY-FPR 2 D8F830BDADA0EA87A54769BF8FD959C4E4D217D0
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEY-FPR 3 3AECA53C784D35DEBD0FD2D278B4B9F160EF5E9E
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEY-TIME 1 1437685621
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEY-TIME 2 1437685707
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEY-TIME 3 1437685738
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca00c400
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=7
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: ff7f7f7f030003
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S CHV-STATUS +255+127+127+127+3+0+3
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=00 p2=7A lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca007a00
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=7
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 7a059303000000
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S SIG-COUNTER 0
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=00 p2=D6 lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca00d600
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=2
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 0020
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S UIF-1 %00+
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=00 p2=D7 lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca00d700
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=2
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 0020
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S UIF-2 %00+
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=00 p2=D8 lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca00d800
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=2
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 0020
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S UIF-3 %00+
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=01 p2=01 lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca010100
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=0
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: [all zero]
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=CA p1=01 p2=02 lc=-1 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00ca010200
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=9000  datalen=0
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: [all zero]
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 0047810002b60000
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=610E  datalen=256
2023-02-10 10:50:41 scdaemon[4580] DBG: apdu_send_simple(0): 14 more bytes available
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00c000000e
2023-02-10 10:50:41 scdaemon[4580] DBG:      more: sw=9000  datalen=14
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 7f4982010981820100c409815f0535a93e8595473e83da1922ecf4e344401061 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  a3762a80db8e7e670cd3335b43633836bb872352c94bafe6ac49306318042579 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  fd3674787068f36e172c306070511cf3a855765f955e565a5dc381e693dbce16 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  c54c3ea67cf92e26fb08c2fc6863609cf09c9c2bbf0f9a51ca30ab0e3134c6f5 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  763fb9b7c39b7b244a773f08436d30c1283d0acf6109a142921b667d7560a1cb \
2023-02-10 10:50:41 scdaemon[4580] DBG:  168c0800d723dadc0d4e3e0c46855aaf13071e20bcb667a220c77ace3ac6be25 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  c5ee552d3053baac4a43e7398ea3edd75d04855818f342fb30370731a122eb07 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  7919b4df90603695d136c74aaf27669e3284e2b54f58aeb6ba813dc0bc4712f6 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  9b4ffe38a99152a05d8203010001
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEYPAIRINFO 2A854BE2CB2D97C3E441573B126519E96CAD2C4A OPENPGP.1 sc 1437685621 rsa2048
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 0047810002b80000
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=610E  datalen=256
2023-02-10 10:50:41 scdaemon[4580] DBG: apdu_send_simple(0): 14 more bytes available
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00c000000e
2023-02-10 10:50:41 scdaemon[4580] DBG:      more: sw=9000  datalen=14
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 7f4982010981820100b99e032cb3f12eaf31a6049aac0e96e9f46e8370f4fbbf \
2023-02-10 10:50:41 scdaemon[4580] DBG:  7e2c270c43551233945863a0d4b03527d046f8f6d8cfb71c61140213766fa66a \
2023-02-10 10:50:41 scdaemon[4580] DBG:  d2037ee30bf4a283613a3dbd873c4980dc6a377874f0e097bab40b7f73a413e5 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  a1df75b0f47a1dbcf02c898cab533427eae93333d08f35100efa10b28fd29e13 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  67e67e5e47d7021ef9cb14321b58a63b8c5f0030d113002ec260570849382995 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  b8786399a4128f63eb94e32537e749bc44a1176efcb8ee3080e94c956761a108 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  1d190291cdd0f83a1897a97745b4a229f36f58765749345b86a9d68512fe0603 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  fc16fe2e42ef6c3b9cb2720e05a97e40ce5c2be7cd27453b119a0a7ce69693c0 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  b860658cf2d697df158203010001
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEYPAIRINFO 737DF2CB8F7E7BB88D14679EF3ACBCDF4637870D OPENPGP.2 e 1437685707 rsa2048
2023-02-10 10:50:41 scdaemon[4580] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=256 em=0
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 0047810002a40000
2023-02-10 10:50:41 scdaemon[4580] DBG:  response: sw=610E  datalen=256
2023-02-10 10:50:41 scdaemon[4580] DBG: apdu_send_simple(0): 14 more bytes available
2023-02-10 10:50:41 scdaemon[4580] DBG: PCSC_data: 00c000000e
2023-02-10 10:50:41 scdaemon[4580] DBG:      more: sw=9000  datalen=14
2023-02-10 10:50:41 scdaemon[4580] DBG:      dump: 7f4982010981820100c9548d979247d3ce2ee467e1a7691fbea3e31a6850c3a4 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  bdf057877309c3ad98c8a385678c2e095d7c9350f43e3a52725efac8b1a1a295 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  0290862b6080c2ac58ede317a6412eb9796e5c4e051022fcd7abc4715d513430 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  05cbebbcb6f4cf9837bbaf73f1a15deaa7d83eb99ffc2a5cadbb33fa7d994b5c \
2023-02-10 10:50:41 scdaemon[4580] DBG:  f90a2c262be4e56f0bdadcef93989093f713beb3fb61bc5138fa8dd08e253d38 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  3f7fbaa07f7e2161c2b53677641e6b2b1b2b32135026d8381c7ab8f6b1dff460 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  b6371bdb2ecfaf826c839d14b439d5bc6c520e4c09d1e367f4262068966cf216 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  86bf3fe584419825f2a086963fcadfecbfdd98cf58a54b84a61ccd8494e19935 \
2023-02-10 10:50:41 scdaemon[4580] DBG:  7cbb70210c4ede322f8203010001
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEYPAIRINFO 4BA287F50A48091B6920FB4A63BE226ED3D7FA7E OPENPGP.3 sa 1437685738 rsa2048
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> OK
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 <- GETATTR KEY-ATTR
2023-02-10 10:50:41 scdaemon[4580] DBG: slot 0: have=openpgp want=openpgp keyref=[none]
2023-02-10 10:50:41 scdaemon[4580] DBG: slot 0 app openpgp: calling getattr(KEY-ATTR)
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEY-ATTR 1 1 rsa2048 17 1
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEY-ATTR 2 1 rsa2048 17 1
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEY-ATTR 3 1 rsa2048 17 1
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> OK
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 <- KEYINFO --list
2023-02-10 10:50:41 scdaemon[4580] DBG: slot 0, app openpgp: calling with_keygrip(status)
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEYINFO 2A854BE2CB2D97C3E441573B126519E96CAD2C4A T D2760001240100000006109208870000 OPENPGP.1 sc
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEYINFO 737DF2CB8F7E7BB88D14679EF3ACBCDF4637870D T D2760001240100000006109208870000 OPENPGP.2 e
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> S KEYINFO 4BA287F50A48091B6920FB4A63BE226ED3D7FA7E T D2760001240100000006109208870000 OPENPGP.3 sa
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> OK
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 <- RESTART
2023-02-10 10:50:41 scdaemon[4580] DBG: chan_0x000002e8 -> OK
-------------- next part --------------
2023-02-10 10:51:04 scdaemon[36288] listening on socket 'F:\\Users\\bozho\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon'
2023-02-10 10:51:04 scdaemon[36288] handler for fd -1 started
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 -> OK GNU Privacy Guard's Smartcard server ready
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 <- GETINFO socket_name
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 -> D F:\Users\bozho\AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 -> OK
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 <- OPTION event-signal=28c
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 -> OK
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 <- GETINFO version
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 -> D 2.4.0
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 -> OK
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 <- SERIALNO
2023-02-10 10:51:04 scdaemon[36288] detected reader 'Yubico Yubikey NEO OTP+U2F+CCID 0'
2023-02-10 10:51:04 scdaemon[36288] reader slot 0: not connected
2023-02-10 10:51:04 scdaemon[36288] reader slot 0: active protocol: T1
2023-02-10 10:51:04 scdaemon[36288] slot 0: ATR=3bfc1300008131fe15597562696b65794e454f7233e1
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a4000c023f00
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6D00  datalen=0
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=8 le=-1 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a4040008a000000527471117
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=9000  datalen=30
2023-02-10 10:51:04 scdaemon[36288] DBG:      dump: 44465520656e61626c6564202d2046572076657273696f6e20332e342e33
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 001d000000
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6D00  datalen=0
2023-02-10 10:51:04 scdaemon[36288] DBG:       dump:  6d00
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a4040006d27600012401
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6D00  datalen=0
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=9 le=256 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a4040009a0000003080000100000
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6700  datalen=0
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=7 le=-1 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a4040c07d2760000030102
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6D00  datalen=0
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=7 le=-1 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a4040c07d2760000030c01
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6D00  datalen=0
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=12 le=256 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a404000ca000000063504b43532d313500
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6700  datalen=0
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=08 p2=0C lc=2 le=-1 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a4080c022f00
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6D00  datalen=0
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=01 p2=0C lc=2 le=-1 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a4010c025015
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6D00  datalen=0
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=9 le=-1 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a4040c09d27600002545500200
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6D00  datalen=0
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=6 le=-1 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a4040c06d27600006601
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6D00  datalen=0
2023-02-10 10:51:04 scdaemon[36288] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=11 le=-1 em=0
2023-02-10 10:51:04 scdaemon[36288] DBG: PCSC_data: 00a4040c0be82b0601040181c31f0201
2023-02-10 10:51:04 scdaemon[36288] DBG:  response: sw=6D00  datalen=0
2023-02-10 10:51:04 scdaemon[36288] no supported card application found: Card error
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 -> S PINCACHE_PUT 0// 
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 -> ERR 100696144 No such device <SCD>
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 <- RESTART
2023-02-10 10:51:04 scdaemon[36288] DBG: chan_0x000002d8 -> OK

From liste at secarica.ro  Fri Feb 10 14:07:19 2023
From: liste at secarica.ro (Cristian =?UTF-8?Q?Secar=C4=83?=)
Date: Fri, 10 Feb 2023 15:07:19 +0200
Subject: Public keys stored on different server
In-Reply-To: <20230210144648.00002877@secarica.ro>
References: <1186983974.20230201103218@postzone.org>
 <Y9pTqtlCOls5l2QR@mkiii.casa>
 <7e32f4d8-f4e3-3f60-5d7f-759814d4d104@my.amazin.horse>
 <246482286.20230202145934@postzone.org>
 <4c9ac34d-90fa-0fb1-4d0a-f2122c1c38ae@my.amazin.horse>
 <1483500981.20230203111642@postzone.org>
 <839729d2-4809-4dac-eef7-dc13fca3c539@bruckner.email>
 <20230210144648.00002877@secarica.ro>
Message-ID: <20230210150719.000078d8@secarica.ro>

?n data de Fri, 10 Feb 2023 14:46:48 +0200, Cristian Secar? a scris:

> (your message below)

There was also a signature, that only contains an e-mail address:

/?\   No  |
\ /  HTML |    Juergen Bruckner
  X    in  |    juergen at bruckner.email
/ \  Mail |

Or, should one copy the e-mail domain part and check to see if the e-mail domain correspond to a web page ? This domain extension even sounds a bit strange for a *web* page.

(my question is just a curiosity)

Cristi

-- 
Cristian Secar?
https://www.secarica.ro


From liste at secarica.ro  Fri Feb 10 13:46:48 2023
From: liste at secarica.ro (Cristian =?UTF-8?Q?Secar=C4=83?=)
Date: Fri, 10 Feb 2023 14:46:48 +0200
Subject: Public keys stored on different server
In-Reply-To: <839729d2-4809-4dac-eef7-dc13fca3c539@bruckner.email>
References: <1186983974.20230201103218@postzone.org>
 <Y9pTqtlCOls5l2QR@mkiii.casa>
 <7e32f4d8-f4e3-3f60-5d7f-759814d4d104@my.amazin.horse>
 <246482286.20230202145934@postzone.org>
 <4c9ac34d-90fa-0fb1-4d0a-f2122c1c38ae@my.amazin.horse>
 <1483500981.20230203111642@postzone.org>
 <839729d2-4809-4dac-eef7-dc13fca3c539@bruckner.email>
Message-ID: <20230210144648.00002877@secarica.ro>

(top posting on purpose)

While reading your message and assuming, just as a principle, that I (= whatever user) would like to get your public key, how do I know your website so that "people who want to write to me that they have my real key - and not a fake one" ?

(your message below)

Cristi


?n data de Fri, 3 Feb 2023 12:06:23 +0100, Juergen M. Bruckner via Gnupg-users a scris:

> Hello Martin,
> 
> so I think these people want to make it as easy as possible for
> others to get the public key. I also make my keys available on my
> website and via WKD and DNS.
>  From my point of view it is also a kind of security for people who
> want to write to me that they have my real key - and not a fake one.
> 
> regards
> Juergen
> 
> Am 03.02.23 um 11:16 schrieb Martin:
> > Hello Vincent,
> > 
> > Ok - that is clear now. I never had the idea to get a "whole list"
> > from a key server but I didn't understand why people let access
> > their key only on their own website.
> > 
> > Martin
> > 
> > Thursday, February 2, 2023, 9:45:53 PM, you wrote:
> > 
> >   
> >>> Could you please explain this, I don't understand really. So
> >>> there are public and no public keys on the this key-server? Who
> >>> decides that a key is public or non-public? Who or how can I
> >>> request a non-public key?  
> >> Sorry, that wasn't as clear as it could have been. There are no
> >> non-public keys, all keys are still publicly available, and can be
> >> retrieved by fingerprint or email address. You just can't retrieve
> >> all keys or email addresses as a full list, which makes it a far
> >> less interesting target for spammers.  
> > 
> > 
> > _______________________________________________
> > Gnupg-users mailing list
> > Gnupg-users at gnupg.org
> > https://lists.gnupg.org/mailman/listinfo/gnupg-users  
> 


-- 
Cristian Secar?
https://www.secarica.ro


From bernhard at intevation.de  Wed Feb 22 09:16:49 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 22 Feb 2023 09:16:49 +0100
Subject: WKD: another company supports it: univention
Message-ID: <202302220917.03114.bernhard@intevation.de>

Hi,
the German company Univention has announced its support of WKD:

  https://www.univention.de/wkd/ (in German so far)

And yes, it can be seen:

gpg-wks-client --verbose --supported univention.de
gpg-wks-client: provider for 'foo at univention.de' does NOT support WKS
(which means it support WKD, but not the mail managing service WKS).

gpg -v --locate-keys --auto-key-locate clear,nodefault,wkd info at univention.de
gpg: key 2D3B68C377EE285B: public key "Univention Security Updates 
<info at univention.de>" imported

(used gpg-wks-client (GnuPG) 2.2.34 to do the testing)

Also noticable at https://www.univention.com/security-policy/
where Univention lists a gpg command.

Noticed it as someone entered it into the wiki, scroll down from
   https://wiki.gnupg.org/WKD?#Implementations
Thanks :)

This is cool, because Univention's product have an identity managing service 
at the core. It may mean that we get more WKD services in the future.

Regards,
Bernhard
-- 
https://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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230222/bd2b45a0/attachment.sig>

From a.grahn at web.de  Wed Feb 22 16:35:34 2023
From: a.grahn at web.de (Alexander Grahn)
Date: Wed, 22 Feb 2023 16:35:34 +0100
Subject: S/MIME certificates with LDAP-only CRL uri
Message-ID: <20230222153534.k7lqyov2e25uaale@dell>

Hello,

recently I obtained a free certificate from DGN (German Health Net) for signing
e-mails. I imported the p12 file  with gpgsm into my keybox and added the
complete certificate chain to ~/.gnupg/trustlist.txt

When I try to sign or encrypt, I get the following error:

  $ gpgsm --armor --sign testfile.txt
  gpgsm: certificate not found: No public key
  gpgsm: certificate #410FE63506C68DDF/CN=dgnservice CA 2 Type E:PN,O=DGN Deutsches Gesundheitsnetz Service GmbH,C=DE
  gpgsm: checking the CRL failed: Not found
  gpgsm: error creating signature: Not found <GpgSM>

It only works if I disable CRL checking with option
--disable-crl-checks, which is not such a good idea, I guess.

The CA provides only an LDAP URI for getting the revocation list. Root and
intermediate certificates can be downloaded here:

  https://www.dgn.de/dgncert/downloads.html

`gpgsm --dump-chain' presents me the following URI:

crlDP: ldap://ldap.dgnservice.de:389/CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certificateRevocationList?base?objectClass=cRLDistributionPoint

Now my question is whether the LDAP server is down, the URI incomplete
or wrong, or whether the problem is on the GPG end. On the other hand,
I cannot imagine that a wrong LDAP URI remains unnoticed by non-GPG
users. I know nothing about ldap and how to test such an URI. What can I do?

I am using gnupg-2.4.0 and I double checked that it was compiled with
ldap support.

Alex


From wk at gnupg.org  Thu Feb 23 10:14:40 2023
From: wk at gnupg.org (Werner Koch)
Date: Thu, 23 Feb 2023 10:14:40 +0100
Subject: WKD: another company supports it: univention
In-Reply-To: <202302220917.03114.bernhard@intevation.de> (Bernhard Reiter's
 message of "Wed, 22 Feb 2023 09:16:49 +0100")
References: <202302220917.03114.bernhard@intevation.de>
Message-ID: <87v8jspwu7.fsf@wheatstone.g10code.de>

On Wed, 22 Feb 2023 09:16, Bernhard Reiter said:

> gpg -v --locate-keys --auto-key-locate clear,nodefault,wkd info at univention.de

BTW, using

  gpg -v --locate-external-keys info at univention.de

is easier to remember.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230223/cd92a6d7/attachment.sig>

From kloecker at kde.org  Thu Feb 23 10:35:38 2023
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Thu, 23 Feb 2023 10:35:38 +0100
Subject: S/MIME certificates with LDAP-only CRL uri
In-Reply-To: <20230222153534.k7lqyov2e25uaale@dell>
References: <20230222153534.k7lqyov2e25uaale@dell>
Message-ID: <5913488.lOV4Wx5bFT@daneel>

On Mittwoch, 22. Februar 2023 16:35:34 CET Alexander Grahn via Gnupg-users 
wrote:
> recently I obtained a free certificate from DGN (German Health Net) for
> signing e-mails. I imported the p12 file  with gpgsm into my keybox and
> added the complete certificate chain to ~/.gnupg/trustlist.txt

You should only add root certificates to the trustlist. It probably doesn't 
harm to add non-root certificates, but it doesn't make much sense and it makes 
the trustlist longer (and thus less easy to manage) than necessary.

> When I try to sign or encrypt, I get the following error:
> 
>   $ gpgsm --armor --sign testfile.txt
>   gpgsm: certificate not found: No public key
>   gpgsm: certificate #410FE63506C68DDF/CN=dgnservice CA 2 Type E:PN,O=DGN
> Deutsches Gesundheitsnetz Service GmbH,C=DE gpgsm: checking the CRL failed:
> Not found
>   gpgsm: error creating signature: Not found <GpgSM>
[...]
> `gpgsm --dump-chain' presents me the following URI:
> 
> crlDP:
> ldap://ldap.dgnservice.de:389/CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certific
> ateRevocationList?base?objectClass=cRLDistributionPoint
> 
> Now my question is whether the LDAP server is down, the URI incomplete
> or wrong, or whether the problem is on the GPG end.

The ldapurl tool can parse the URI:
```
$ ldapurl -H 'ldap://ldap.dgnservice.de:389/
CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certificateRevocationList?base?
objectClass=cRLDistributionPoint'
scheme: ldap
host: ldap.dgnservice.de
port: 389
dn: CN=CRL-1,O=DGN Service GmbH,C=DE
selector: certificateRevocationList
scope: base
filter: objectClass=cRLDistributionPoint
```

I failed to use the ldapsearch tool to actually query the URI. It always tells 
me "Could not parse LDAP URI(s)=[...]", but I guess I'm just using it wrong.

> On the other hand,
> I cannot imagine that a wrong LDAP URI remains unnoticed by non-GPG
> users. I know nothing about ldap and how to test such an URI. What can I do?
> 
> I am using gnupg-2.4.0 and I double checked that it was compiled with
> ldap support.

Submit a bug report at https://dev.gnupg.org so that this can be tracked 
properly.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230223/36468f2f/attachment.sig>

From a.grahn at web.de  Thu Feb 23 11:22:58 2023
From: a.grahn at web.de (Alexander Grahn)
Date: Thu, 23 Feb 2023 11:22:58 +0100
Subject: S/MIME certificates with LDAP-only CRL uri
In-Reply-To: <5913488.lOV4Wx5bFT@daneel>
References: <20230222153534.k7lqyov2e25uaale@dell> <5913488.lOV4Wx5bFT@daneel>
Message-ID: <20230223102258.hxdoo3zf7s3wcg53@rpi>

On Thu, Feb 23, 2023 at 10:35:38AM +0100, Ingo Kl?cker wrote:
> On Mittwoch, 22. Februar 2023 16:35:34 CET Alexander Grahn via Gnupg-users
> wrote:
> > recently I obtained a free certificate from DGN (German Health Net) for
> > signing e-mails. I imported the p12 file  with gpgsm into my keybox and
> > added the complete certificate chain to ~/.gnupg/trustlist.txt
>
> You should only add root certificates to the trustlist. It probably doesn't
> harm to add non-root certificates, but it doesn't make much sense and it makes
> the trustlist longer (and thus less easy to manage) than necessary.

Thanks a lot for this, I learned something new.

>
> > When I try to sign or encrypt, I get the following error:
> >
> >   $ gpgsm --armor --sign testfile.txt
> >   gpgsm: certificate not found: No public key
> >   gpgsm: certificate #410FE63506C68DDF/CN=dgnservice CA 2 Type E:PN,O=DGN
> > Deutsches Gesundheitsnetz Service GmbH,C=DE gpgsm: checking the CRL failed:
> > Not found
> >   gpgsm: error creating signature: Not found <GpgSM>
> [...]
> > `gpgsm --dump-chain' presents me the following URI:
> >
> > crlDP:
> > ldap://ldap.dgnservice.de:389/CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certific
> > ateRevocationList?base?objectClass=cRLDistributionPoint
> >
> > Now my question is whether the LDAP server is down, the URI incomplete
> > or wrong, or whether the problem is on the GPG end.
>
> The ldapurl tool can parse the URI:
> ```
> $ ldapurl -H 'ldap://ldap.dgnservice.de:389/
> CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certificateRevocationList?base?
> objectClass=cRLDistributionPoint'
> scheme: ldap
> host: ldap.dgnservice.de
> port: 389
> dn: CN=CRL-1,O=DGN Service GmbH,C=DE
> selector: certificateRevocationList
> scope: base
> filter: objectClass=cRLDistributionPoint
> ```
>
> I failed to use the ldapsearch tool to actually query the URI. It always tells
> me "Could not parse LDAP URI(s)=[...]", but I guess I'm just using it wrong.

Should an ldap host answer on ping requests in general? Because the one in
question, ldap.dgnservice.de, remains silent. I tried with other hosts picked
at random from a simple web search, and they all answered on ping. Maybe
ldap.dgnservice.de is simply down. Meanwhile I doubt that DGN is a reliable CA
at all.

> > On the other hand,
> > I cannot imagine that a wrong LDAP URI remains unnoticed by non-GPG
> > users. I know nothing about ldap and how to test such an URI. What can I do?
> >
> > I am using gnupg-2.4.0 and I double checked that it was compiled with
> > ldap support.
>
> Submit a bug report at https://dev.gnupg.org so that this can be tracked
> properly.

At first, the basic availability of the ldap server should be verified, I think.

Thank you again for your help and kind regards


From wk at gnupg.org  Thu Feb 23 16:09:31 2023
From: wk at gnupg.org (Werner Koch)
Date: Thu, 23 Feb 2023 16:09:31 +0100
Subject: S/MIME certificates with LDAP-only CRL uri
In-Reply-To: <20230223102258.hxdoo3zf7s3wcg53@rpi> (Alexander Grahn via
 Gnupg-users's message of "Thu, 23 Feb 2023 11:22:58 +0100")
References: <20230222153534.k7lqyov2e25uaale@dell> <5913488.lOV4Wx5bFT@daneel>
 <20230223102258.hxdoo3zf7s3wcg53@rpi>
Message-ID: <87mt54pges.fsf@wheatstone.g10code.de>

On Thu, 23 Feb 2023 11:22, Alexander Grahn said:
> Should an ldap host answer on ping requests in general? Because the one in

Pinging arbitrary servers does often work because too many admins tend
to block ICMP echo.  An LDAP server is commonly behind some load
balancer and thus a ping won't help you anyway.

> question, ldap.dgnservice.de, remains silent. I tried with other hosts picked

Works for me.

$ dirmngr --debug network --fetch-crl  'ldap://ldap.dgnservice.de:389/CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certificateRevocationList?base?objectClass=cRLDistributionPoint'

dirmngr[27784.0]: dirmngr_ldap[27786]: found attribute 'certificateRevocationList;binary'
dirmngr[27784.0]: update times of this CRL: this=20230222T230000 next=20230324T230000
dirmngr[27784.0]: locating CRL issuer certificate by authorityKeyIdentifier
dirmngr[27784.0]: DBG: find_cert_bysubject: certificate not in cache
dirmngr[27784.0]: DBG: get_cert_local_ski called w/o context

Thus it could read the CRL (see the update times) but for verification a
certificate is missing.  That is a problem with the fetch-crl command of
dirmngr.  I will closer at the problem and thus I need to improve the
error reporting.


Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230223/c971ebe7/attachment.sig>

From a.grahn at web.de  Thu Feb 23 18:37:30 2023
From: a.grahn at web.de (Alexander Grahn)
Date: Thu, 23 Feb 2023 18:37:30 +0100
Subject: S/MIME certificates with LDAP-only CRL uri
In-Reply-To: <87mt54pges.fsf@wheatstone.g10code.de>
References: <20230222153534.k7lqyov2e25uaale@dell> <5913488.lOV4Wx5bFT@daneel>
 <20230223102258.hxdoo3zf7s3wcg53@rpi>
 <87mt54pges.fsf@wheatstone.g10code.de>
Message-ID: <20230223173730.3b47zlrr53kkpqm2@rpi>

On Thu, Feb 23, 2023 at 04:09:31PM +0100, Werner Koch wrote:
> On Thu, 23 Feb 2023 11:22, Alexander Grahn said:
> > Should an ldap host answer on ping requests in general? Because the one in
>
> Pinging arbitrary servers does often work because too many admins tend
> to block ICMP echo.  An LDAP server is commonly behind some load
> balancer and thus a ping won't help you anyway.
>
> > question, ldap.dgnservice.de, remains silent. I tried with other hosts picked
>
> Works for me.
>
> $ dirmngr --debug network --fetch-crl  'ldap://ldap.dgnservice.de:389/CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certificateRevocationList?base?objectClass=cRLDistributionPoint'
>
> dirmngr[27784.0]: dirmngr_ldap[27786]: found attribute 'certificateRevocationList;binary'
> dirmngr[27784.0]: update times of this CRL: this=20230222T230000 next=20230324T230000
> dirmngr[27784.0]: locating CRL issuer certificate by authorityKeyIdentifier
> dirmngr[27784.0]: DBG: find_cert_bysubject: certificate not in cache
> dirmngr[27784.0]: DBG: get_cert_local_ski called w/o context
>
> Thus it could read the CRL (see the update times) but for verification a
> certificate is missing.  That is a problem with the fetch-crl command of
> dirmngr.  I will closer at the problem and thus I need to improve the
> error reporting.

Thank your for your reply. Does it mean that the problem is to be solved on the
GnuPG end?

Alexander


From wk at gnupg.org  Fri Feb 24 11:21:32 2023
From: wk at gnupg.org (Werner Koch)
Date: Fri, 24 Feb 2023 11:21:32 +0100
Subject: S/MIME certificates with LDAP-only CRL uri
In-Reply-To: <20230223173730.3b47zlrr53kkpqm2@rpi> (Alexander Grahn via
 Gnupg-users's message of "Thu, 23 Feb 2023 18:37:30 +0100")
References: <20230222153534.k7lqyov2e25uaale@dell> <5913488.lOV4Wx5bFT@daneel>
 <20230223102258.hxdoo3zf7s3wcg53@rpi>
 <87mt54pges.fsf@wheatstone.g10code.de>
 <20230223173730.3b47zlrr53kkpqm2@rpi>
Message-ID: <87wn47nz2r.fsf@wheatstone.g10code.de>

On Thu, 23 Feb 2023 18:37, Alexander Grahn said:

> Thank your for your reply. Does it mean that the problem is to be solved on the
> GnuPG end?

I can't tell because I do not have a valid DGN certificate anymore.
Feel free so send me yours by PM - makes debugging easier.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230224/5ccc1c86/attachment.sig>

From bostrom.richardh at proton.me  Sun Feb 26 15:09:43 2023
From: bostrom.richardh at proton.me (Richard Bostrom)
Date: Sun, 26 Feb 2023 14:09:43 +0000
Subject: Public Key
Message-ID: <I-Soxizh3LAK-mC71gaZpMAxka3CDI8QYUHJtJrawuNhdBh3MsEqIzgGBCmlKBGL8y3blUo59h0Pz2xkb1pO2gGNqDED76xpUFcca_iO6zY=@proton.me>

Dear sirs and ladies!

May I please ask why some 4096 bit keys are longer then others?

Richard Stallmans key is much longer then my 4096 bit key.

Thank you.

Best regards

Richardh Bostrom

Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230226/2e96aaf9/attachment.html>

From fa-ml at ariis.it  Sun Feb 26 20:53:41 2023
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sun, 26 Feb 2023 20:53:41 +0100
Subject: Public Key
In-Reply-To: <I-Soxizh3LAK-mC71gaZpMAxka3CDI8QYUHJtJrawuNhdBh3MsEqIzgGBCmlKBGL8y3blUo59h0Pz2xkb1pO2gGNqDED76xpUFcca_iO6zY=@proton.me>
References: <I-Soxizh3LAK-mC71gaZpMAxka3CDI8QYUHJtJrawuNhdBh3MsEqIzgGBCmlKBGL8y3blUo59h0Pz2xkb1pO2gGNqDED76xpUFcca_iO6zY=@proton.me>
Message-ID: <Y/u4xWrketNC3xIE@mkiii.casa>

Hello Richard,

Il 26 febbraio 2023 alle 14:09 Richard Bostrom via Gnupg-users ha scritto:
> May I please ask why some 4096 bit keys are longer then others?
> 
> Richard Stallmans key is much longer then my 4096 bit key.

I suspect: signatures. They make keys longer
?F



From vollkorn at cryptobitch.de  Sun Feb 26 23:57:53 2023
From: vollkorn at cryptobitch.de (Jan Girlich)
Date: Sun, 26 Feb 2023 23:57:53 +0100
Subject: Public Key
In-Reply-To: <Y/u4xWrketNC3xIE@mkiii.casa>
References: <I-Soxizh3LAK-mC71gaZpMAxka3CDI8QYUHJtJrawuNhdBh3MsEqIzgGBCmlKBGL8y3blUo59h0Pz2xkb1pO2gGNqDED76xpUFcca_iO6zY=@proton.me>
 <Y/u4xWrketNC3xIE@mkiii.casa>
Message-ID: <5f8fbec7fd6fe9d7e165c0f2c7d89d2a5dc2447b.camel@cryptobitch.de>

Hi,

On Sun, 2023-02-26 at 20:53 +0100, Francesco Ariis wrote:
> Il 26 febbraio 2023 alle 14:09 Richard Bostrom via Gnupg-users ha
> scritto:
> > May I please ask why some 4096 bit keys are longer then others?
> > 
> > Richard Stallmans key is much longer then my 4096 bit key.
> 
> I suspect: signatures. They make keys longer

each identity makes your key larger. Multiple Subkeys for different
purposes. You can also add additional data like an image. My key is
667KB large, when exported with ASCII armor.

Cheers,
Jan


From wk at gnupg.org  Mon Feb 27 17:42:02 2023
From: wk at gnupg.org (Werner Koch)
Date: Mon, 27 Feb 2023 17:42:02 +0100
Subject: S/MIME certificates with LDAP-only CRL uri
In-Reply-To: <87wn47nz2r.fsf@wheatstone.g10code.de> (Werner Koch via
 Gnupg-users's message of "Fri, 24 Feb 2023 11:21:32 +0100")
References: <20230222153534.k7lqyov2e25uaale@dell> <5913488.lOV4Wx5bFT@daneel>
 <20230223102258.hxdoo3zf7s3wcg53@rpi>
 <87mt54pges.fsf@wheatstone.g10code.de>
 <20230223173730.3b47zlrr53kkpqm2@rpi>
 <87wn47nz2r.fsf@wheatstone.g10code.de>
Message-ID: <87a60zjc11.fsf@wheatstone.g10code.de>

Hi!

I spent some time looking into this.  The CRL is issued by a certificate

  CN=dgnservice CRL2101 13:PN,O=DGN Deutsches Gesundheitsnetz Service GmbH,C=DE

However that certificate is not available:  I only found the previous one:

  ldapsearch -H ldap://ldap.dgnservice.de:389 -b 'O=DGN Deutsches Gesundheitsnetz Service GmbH,C=DE' -x -v -LLL "CN=dgnservice CRL2101 12:PN"

without the certificate we can't verify the CRL.  Switching to OCSP does
also not work due to a missing certificate.

We have seen this problem already last year; see
https://dev.gnupg.org/rG90caa7ad598be123707f4d4651f9a64a74347626

Alexander: Maybe you can to ask DGN why they don't distribute that cert
but announce it in the CRL.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230227/bd205e67/attachment.sig>