Help setting gpgsm to do LDAP lookup

2020-05-16 Thread John Scott via Gnupg-users
Hi,

I'm stumped getting gpgsm to lookup S/MIME certificates in my organization. 
I've got a temporary working solution with ldapsearch after logging into my 
VPN with NetworkManager+OpenConnect:
ldapsearch -Wt -b OU=Accounts,DC=ads,DC=foo,DC=com -D 
CN=jscott,OU=Accounts,DC=ads,DC=foo,DC=com '(mailNickname=[recipient])' 
userSMIMECertificate

This saves the signed message to a temporary file which I do gpgsm --verify on, 
although the certs themselves are also stored in the userCertificate record 
IIRC. ldapsearch also works if I use only LDAPv2.

My dirmngr_ldapservers.conf reads
ads.foo.com:636:ads\jscott:PassPhrase:ou=Accounts,dc=ads,dc=foo,dc=com
 
and to be extra safe I've put an explicit no-use-tor and ldapserverlist-file 
dirmngr_ldapservers.conf in my dirmngr.conf. Reloading dirmngr and gpgsm after 
getting on the VPN doesn't help.

Looking up recipients with both dirmngr-client and
gpgsm --verbose --list-external-keys [recipient]
are fruitless whether I drop the ads\ from my username or not. I've bumped the 
ldaptimeout to 25. Still both commands finish instantaneously—not unlike 
ldapsearch however.

$ gpgsm --debug-level expert -v --list-external-keys anything
gpgsm: enabled debug flags: x509 crypto cache ipc
gpgsm: DBG: chan_3 <- # Home: /home/john/.gnupg
gpgsm: DBG: chan_3 <- # Config: /home/john/.gnupg/dirmngr.conf
gpgsm: DBG: chan_3 <- OK Dirmngr 2.2.20 at your service
gpgsm: DBG: connection to the dirmngr established
gpgsm: DBG: chan_3 -> GETINFO version
gpgsm: DBG: chan_3 <- D 2.2.20
gpgsm: DBG: chan_3 <- OK
gpgsm: DBG: chan_3 -> OPTION audit-events=1
gpgsm: DBG: chan_3 <- OK
gpgsm: DBG: chan_3 -> LOOKUP anything
gpgsm: DBG: chan_3 <- OK
secmem usage: 0/16384 bytes in 0 blocks

I'm using 2.2.20 on Debian Bullseye. Other options set are add-servers in 
dirmngr.conf and auto-issuer-key-retrieve in gpgsm.conf.

$ systemctl --user status dirmngr
● dirmngr.service - GnuPG network certificate management daemon
 Loaded: loaded (/usr/lib/systemd/user/dirmngr.service; static; vendor 
preset: enabled)
 Active: active (running) since Sat 2020-05-16 22:52:38 EDT; 23min ago
TriggeredBy: ● dirmngr.socket
   Docs: man:dirmngr(8)
   Main PID: 26309 (dirmngr)
 CGroup: /user.slice/user-1000.slice/user@1000.service/dirmngr.service
 └─26309 /usr/bin/dirmngr --supervised

I also use GnuPG's SSH agent emulation and have in my .bashrc
export GPG_TTY=$(tty)
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
gpg-connect-agent updatestartuptty /bye >/dev/null

signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-16 Thread Robert J. Hansen
> I’d like to point out that the options you are referring to are actually
> enabled by default nowadays (since 2.2.17).

Thank you, Damien.  :)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-16 Thread Damien Goutte-Gattat via Gnupg-users

On Sat, May 16, 2020 at 04:28:58PM -0400, Robert J. Hansen wrote:
With judicious use of the various -clean options, the key spamming bug 
is effectively dead...


I’d like to point out that the options you are referring to are actually 
enabled by default nowadays (since 2.2.17). So from an user’s point of 
view, the judicious thing to do is simply to use the latest GnuPG 
version available.


I am pointing that out because people could interpret your comment as 
meaning that GnuPG requires some tinkering of its options in order to be 
safely usable with regard to the SKS spamming issue. That’s not the 
case; the default configuration is fine.


- Damien


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Comparison of RSA vs elliptical keys

2020-05-16 Thread Stefan Claas
Stefan Claas wrote:
 
> MFPA wrote:
>  
> [...]
> 
> > -BEGIN PGP SIGNATURE-
> > 
> > iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl692adfFIAALgAo
> [...]
> 
> > RjfdBwsdZJrUrgtu7YTLAf0/v9mZZBAXfvO8CgNySZfWWZ5IP0BvHLgkUXI0r7Qt
> > kuQMuu7LJiMJFrPQKIL1cQ==
> > =XcGg
> > -END PGP SIGNATURE-
> 
> Hi,
> 
> out of curiosity, you signed the reply with two sub keys, but
> what makes the signature so large, the hash algo used? I must
> admit I have never seen such a large signature before.
> 
> And slightly OT, when not counting the two last short lines
> in the signature, 378 NaClbox public keys would fit in in
> the signature! :-)

Correction, a NaClbox key is 32 bytes but in an ASCII representation
64 ASCII chars long in the key ring, so it would 'only' be 189 public
keys.

Regards
Stefan



-- 
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas
   

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: keys require a user-id

2020-05-16 Thread Robert J. Hansen
> Have the bureaucrats who define standards have finally fixed the DOS
> issues about keys spammed with signatures or is it still being
> "discussed whether they are even needed."?

GnuPG had a bug in the key importation code which made it run in time
proportional to the square of the number of signatures.  Importing a
certificate with 100,000 signatures was literally a hundred million
times slower than importing a certificate with 10.

That bug has since been fixed.  With judicious use of the various -clean
options, the key spamming bug is effectively dead... on the GnuPG side:
on the SKS side, people are still filling up SKS keyservers with spam.

SKS is a completely separate project from GnuPG, and has no RFC guiding
it.  So the "bureaucratic" project has it resolved, and the "free to
innovate" project has been unable to innovate.

(Note: I'm not blaming SKS.  This is a hard problem.  I personally don't
think SKS can be saved.)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-16 Thread Johan Wevers
On 16-05-2020 17:56, Robert J. Hansen wrote:

> I tell them, "I will not be able to use OpenPGP with you until such time
> as you UID conforms to the standard.

You confuse "not being able to" with "not willing to".

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-16 Thread Johan Wevers
On 16-05-2020 15:57, Peter Pentchev wrote:

> But it is
> also fine for other people to say "okay, sure, you have your
> experimental features, but I'll wait until they're standardized until
> I do the work on implementing them myself; also, let's discuss whether
> they are even needed."

Have the bureaucrats who define standards have finally fixed the DOS
issues about keys spammed with signatures or is it still being
"discussed whether they are even needed."?

This strictly following standards removes all flexibility from
implementations. I am beginning to understand Moxie Marlinspike's ideas
about all these committees holding back progress better and better.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-16 Thread Stefan Claas
Robert J. Hansen wrote:

> > How does this work in general, let's say I am a dev and would add
> > this too, to my OpenPGP app. Is there an OpenPGP board where devs
> > can vote for or against a feature, so that Werner has then to
> > follow suite, or is he in the position to say no and every dev has
> > to follow his GnuPG specs?
> 
> The RFC is maintained under auspices of the Internet Engineering Task
> Force (IETF), just like every other RFC.  The IETF's motto is "rough
> consensus and running code".
> 
> Werner sits as secretary of the (largely dormant) group that guides
> OpenPGP development, but there are a lot of non-GnuPG people who are
> deeply involved in giving feedback on proposed changes.  He's the
> secretary, not the dictator.

Thanks for your reply, much appreciated!

Regards
Stefan

-- 
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas
   

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: keys require a user-id

2020-05-16 Thread Robert J. Hansen
> GnuPG users can interact perfectly well with people who use OpenPGP
> software :) As Robert J. Hansen said, if you (or somebody else) want to
> extend the standard, there is an IETF working group and mailing list for
> that.

Please, just "Rob".  :)

I share a name with Robert "rsnake" Hansen of SecTheory.  He and I have
both spoken at Black Hat and DEF CON (which has sometimes led to
hilarious results when journalists have tried to track us down to talk
about our research).

In order to reduce confusion I always use my middle initial
professionally.  But I go by Rob.  :)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-16 Thread Robert J. Hansen
> So, when you like to communicate with a person who uses such a new
> key how do you proceed then?

I tell them, "I will not be able to use OpenPGP with you until such time
as you UID conforms to the standard.  Would you like help in making your
user ID standards-conformant in a way that reveals nothing about your
real-world identity?"

This is, in fact, the preferred GNU way.  "I'd love to be able to work
with you on this document, but you're using a proprietary format I can't
read.  There's an open format we can both use, though, and I'd be happy
to help you get started with it."

> How does this work in general, let's say I am a dev and would add this
> too, to my OpenPGP app. Is there an OpenPGP board where devs can vote
> for or against a feature, so that Werner has then to follow suite, or
> is he in the position to say no and every dev has to follow his GnuPG
> specs?

The RFC is maintained under auspices of the Internet Engineering Task
Force (IETF), just like every other RFC.  The IETF's motto is "rough
consensus and running code".

Werner sits as secretary of the (largely dormant) group that guides
OpenPGP development, but there are a lot of non-GnuPG people who are
deeply involved in giving feedback on proposed changes.  He's the
secretary, not the dictator.




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-16 Thread Stefan Claas
Peter Pentchev wrote:
 
> On Sat, May 16, 2020 at 04:55:11PM +0300, Peter Pentchev wrote:
> > On Sat, May 16, 2020 at 01:36:10AM +0200, Stefan Claas wrote:
> > > Peter Pentchev wrote:
> > >  
> > > > On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote:
> > > 
> > > > > You know what, the most interesting thing of this ML for me
> > > > > is that when people, do a request or suggestion the old guard
> > > > > is always there to defend some standard and are not accepting
> > > > > that a new product on the OpenPGP market, with a new feature
> > > > > included, add an enrichment to a given standard, which people
> > > > > may like to use and appreciate.
> > > > 
> > > > OK, but *how* is it an enrichment? What does a UID-less key
> > > > provide over a randomly-generated UID? Why go to the bother of
> > > > supporting a new special case when you can get the same result
> > > > in another way, with zero additional code in any of the
> > > > existing implementations and only a couple more lines of code
> > > > in the special client that will have to generate a random UID?
> > > 
> > > Fact is this function is available for users of OpenPGP software.
> > 
> > Is it though? It is not part of the OpenPGP standard, is it? It is
> > available for users of software that implements the OpenPGP standard
> > *with some local extensions*, which is a bit different.
> > 
> > > We should better think of how this will pan out in the future, if
> > > users start to use OpenPGP software with UID-less public
> > > keyblocks and how GnuPG users can interact with them, or not?
> > 
> > GnuPG users can interact perfectly well with people who use OpenPGP
> > software :) As Robert J. Hansen said, if you (or somebody else)
> > want to extend the standard, there is an IETF working group and
> > mailing list for that.
> > 
> > The way I see it, there are two types of standards:
> > 
> > - ones that are discussed and written before being implemented, so
> > that all the implementors have the same idea and nobody comes up
> > with, say, using the same magic numbers for completely different
> > purposes or having a function accept one more argument than anyone
> > else and break if it is called with fewer arguments
> > 
> > - ones that standardize existing behavior, like the POSIX standard
> > for operating systems, system calls, libraries, command shell, etc.
> > 
> > Now, I've been on the POSIX mailing list for well nigh 20 years
> > now, and let me tell you, trying to standardize something when
> > different implementors have come up with *all kinds* of slightly
> > different ways of doing *almost* the same thing can be... crazy.
> > Insane. Amazingly, astonishingly, horrifyingly weird, and very
> > time- and nerve-consuming.
> > 
> > It seems to me that the people involved in developing the OpenPGP
> > standard did, at one point, decide to go the other way: yes, sure,
> > start with the existing PGP and GnuPG and other implementations,
> > but then, when thinking about future work, decide to discuss things
> > before implementing them (recent threads on the OpenPGP mailing list
> > notwithstanding), so that it is sorta kinda expected that once
> > various implementations gain the new features, they *will* be able
> > to interoperate. That sounds... kind of reasonable to me.
> 
> Just one more point that I forgot to write: *of course* it's fine for
> people to implement experimental things to see if they'll work...
> within reasonable bounds, of course, like not implementing new
> algorithm identifiers outside the space reserved for experimental
> ones. But it is also fine for other people to say "okay, sure, you
> have your experimental features, but I'll wait until they're
> standardized until I do the work on implementing them myself; also,
> let's discuss whether they are even needed."

Thanks for the write up, this mostly anwsers my question I had for
Robert.

Regards
Stefan

-- 
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas
   

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: keys require a user-id

2020-05-16 Thread Peter Pentchev
On Sat, May 16, 2020 at 04:55:11PM +0300, Peter Pentchev wrote:
> On Sat, May 16, 2020 at 01:36:10AM +0200, Stefan Claas wrote:
> > Peter Pentchev wrote:
> >  
> > > On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote:
> > 
> > > > You know what, the most interesting thing of this ML for me is that
> > > > when people, do a request or suggestion the old guard is always
> > > > there to defend some standard and are not accepting that a new
> > > > product on the OpenPGP market, with a new feature included, add an
> > > > enrichment to a given standard, which people may like to use and
> > > > appreciate.
> > > 
> > > OK, but *how* is it an enrichment? What does a UID-less key provide
> > > over a randomly-generated UID? Why go to the bother of supporting a
> > > new special case when you can get the same result in another way,
> > > with zero additional code in any of the existing implementations and
> > > only a couple more lines of code in the special client that will have
> > > to generate a random UID?
> > 
> > Fact is this function is available for users of OpenPGP software.
> 
> Is it though? It is not part of the OpenPGP standard, is it? It is
> available for users of software that implements the OpenPGP standard
> *with some local extensions*, which is a bit different.
> 
> > We should better think of how this will pan out in the future, if users
> > start to use OpenPGP software with UID-less public keyblocks and how
> > GnuPG users can interact with them, or not?
> 
> GnuPG users can interact perfectly well with people who use OpenPGP
> software :) As Robert J. Hansen said, if you (or somebody else) want to
> extend the standard, there is an IETF working group and mailing list for
> that.
> 
> The way I see it, there are two types of standards:
> 
> - ones that are discussed and written before being implemented, so that
>   all the implementors have the same idea and nobody comes up with, say,
>   using the same magic numbers for completely different purposes or
>   having a function accept one more argument than anyone else and break
>   if it is called with fewer arguments
> 
> - ones that standardize existing behavior, like the POSIX standard for
>   operating systems, system calls, libraries, command shell, etc.
> 
> Now, I've been on the POSIX mailing list for well nigh 20 years now, and
> let me tell you, trying to standardize something when different
> implementors have come up with *all kinds* of slightly different ways of
> doing *almost* the same thing can be... crazy. Insane. Amazingly,
> astonishingly, horrifyingly weird, and very time- and nerve-consuming.
> 
> It seems to me that the people involved in developing the OpenPGP
> standard did, at one point, decide to go the other way: yes, sure, start
> with the existing PGP and GnuPG and other implementations, but then,
> when thinking about future work, decide to discuss things before
> implementing them (recent threads on the OpenPGP mailing list
> notwithstanding), so that it is sorta kinda expected that once various
> implementations gain the new features, they *will* be able to
> interoperate. That sounds... kind of reasonable to me.

Just one more point that I forgot to write: *of course* it's fine for
people to implement experimental things to see if they'll work... within
reasonable bounds, of course, like not implementing new algorithm
identifiers outside the space reserved for experimental ones. But it is
also fine for other people to say "okay, sure, you have your
experimental features, but I'll wait until they're standardized until
I do the work on implementing them myself; also, let's discuss whether
they are even needed."

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-16 Thread Peter Pentchev
On Sat, May 16, 2020 at 01:36:10AM +0200, Stefan Claas wrote:
> Peter Pentchev wrote:
>  
> > On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote:
> 
> > > You know what, the most interesting thing of this ML for me is that
> > > when people, do a request or suggestion the old guard is always
> > > there to defend some standard and are not accepting that a new
> > > product on the OpenPGP market, with a new feature included, add an
> > > enrichment to a given standard, which people may like to use and
> > > appreciate.
> > 
> > OK, but *how* is it an enrichment? What does a UID-less key provide
> > over a randomly-generated UID? Why go to the bother of supporting a
> > new special case when you can get the same result in another way,
> > with zero additional code in any of the existing implementations and
> > only a couple more lines of code in the special client that will have
> > to generate a random UID?
> 
> Fact is this function is available for users of OpenPGP software.

Is it though? It is not part of the OpenPGP standard, is it? It is
available for users of software that implements the OpenPGP standard
*with some local extensions*, which is a bit different.

> We should better think of how this will pan out in the future, if users
> start to use OpenPGP software with UID-less public keyblocks and how
> GnuPG users can interact with them, or not?

GnuPG users can interact perfectly well with people who use OpenPGP
software :) As Robert J. Hansen said, if you (or somebody else) want to
extend the standard, there is an IETF working group and mailing list for
that.

The way I see it, there are two types of standards:

- ones that are discussed and written before being implemented, so that
  all the implementors have the same idea and nobody comes up with, say,
  using the same magic numbers for completely different purposes or
  having a function accept one more argument than anyone else and break
  if it is called with fewer arguments

- ones that standardize existing behavior, like the POSIX standard for
  operating systems, system calls, libraries, command shell, etc.

Now, I've been on the POSIX mailing list for well nigh 20 years now, and
let me tell you, trying to standardize something when different
implementors have come up with *all kinds* of slightly different ways of
doing *almost* the same thing can be... crazy. Insane. Amazingly,
astonishingly, horrifyingly weird, and very time- and nerve-consuming.

It seems to me that the people involved in developing the OpenPGP
standard did, at one point, decide to go the other way: yes, sure, start
with the existing PGP and GnuPG and other implementations, but then,
when thinking about future work, decide to discuss things before
implementing them (recent threads on the OpenPGP mailing list
notwithstanding), so that it is sorta kinda expected that once various
implementations gain the new features, they *will* be able to
interoperate. That sounds... kind of reasonable to me.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-16 Thread Stefan Claas
r...@sixdemonbag.org wrote:
 
> (Sent from my phone)
> 
> If and when people insisting on UID-less keys want to communicate
> with me, I'll tell them the same thing I told users of Imad Faiad's
> PGP 6.5.8ckt builds, Disastry's PGP builds, and many more:
> 
> "I'm sorry, but you're not confirming to the specification. If you
> wish for me to make sense of your messages, please resend in a
> conformant message."
> 
> The community has literally been dealing with devs breaking the
> standard for 25 years. We have learned from bitter experience how
> important standards conformance is.
> 
> UIDless certs will get the same response as people using TIGER192 as
> a hash.

So, when you like to communicate with a person who uses such a new
key how do you proceed then?

And you bring up also one interesting point, I like to ask, for the
interested ML reader here.

How does this work in general, let's say I am a dev and would add this
too, to my OpenPGP app. Is there an OpenPGP board where devs can vote
for or against a feature, so that Werner has then to follow suite, or
is he in the position to say no and every dev has to follow his GnuPG
specs?

P.S. Really to bad that Mr. Zimmermann, Bruce Schneier, Prof. Bernstein,
Prof. Green and other crypto experts are not on this ML. I would really
like to hear what they would say to such an OpenPGP feature in 2020.

Regards
Stefan

-- 
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas
   

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: keys require a user-id

2020-05-16 Thread rjh
(Sent from my phone)If and when people insisting on UID-less keys want to communicate with me, I'll tell them the same thing I told users of Imad Faiad's PGP 6.5.8ckt builds, Disastry's PGP builds, and many more:"I'm sorry, but you're not confirming to the specification. If you wish for me to make sense of your messages, please resend in a conformant message."The community has literally been dealing with devs breaking the standard for 25 years. We have learned from bitter experience how important standards conformance is.UIDless certs will get the same response as people using TIGER192 as a hash.On May 15, 2020 7:36 PM, Stefan Claas  wrote:Peter Pentchev wrote:

 

> On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote:



> > You know what, the most interesting thing of this ML for me is that

> > when people, do a request or suggestion the old guard is always

> > there to defend some standard and are not accepting that a new

> > product on the OpenPGP market, with a new feature included, add an

> > enrichment to a given standard, which people may like to use and

> > appreciate.

> 

> OK, but *how* is it an enrichment? What does a UID-less key provide

> over a randomly-generated UID? Why go to the bother of supporting a

> new special case when you can get the same result in another way,

> with zero additional code in any of the existing implementations and

> only a couple more lines of code in the special client that will have

> to generate a random UID?



Fact is this function is available for users of OpenPGP software. We

should better think of how this will pan out in the future, if users

start to use OpenPGP software with UID-less public keyblocks and how

GnuPG users can interact with them, or not?



Regards

Stefan



-- 

Signal (Desktop) +4915172173279

https://keybase.io/stefan_claas

   



___

Gnupg-users mailing list

Gnupg-users@gnupg.org

http://lists.gnupg.org/mailman/listinfo/gnupg-users




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Keyserver

2020-05-16 Thread Michał Górny via Gnupg-users
On Fri, 2020-05-15 at 16:52 -0700, Mark wrote:
> I know this may be a subjective question but what is the best keyserver
> to use?  I use GPG4Win with the Enigmail plugin for Thunderbird.  The
> keyservers listed in Enigmail are:
> 
> vks://keys.openpgp.org, hkps://hkps.pool.sks-keyservers.net,
> hkps://pgp.mit.edu
> 
> The keyserver that is used in Kelopatra (GPG4Win) is:
> 
> hkp://keys.gnupg.net

$ host keys.gnupg.net
keys.gnupg.net is an alias for hkps.pool.sks-keyservers.net.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users