Please test :)

[David Shaw]

Hi everyone,

I'd appreciate it if people could test two particular things in the  
keyserver support:

1) LDAP now works with DNS service discovery.  So, if you have keys in  
a ldap keyserver, you can put something like

_pgpkey-ldap._tcp       SRV     0 0 389 my-ldap-keyserver.example.com.

in your DNS and GPG will know that for addresses@..., it can  
query ldap://my-ldap-keyserver.example.com for keys.

This is very similar to the current support for ldap where GPG will  
look for a ldap keyserver named "keys" (i.e. for address@...,  
it looks for ldap://keys.example.com), but is no longer required to be  
named "keys".  If the SRV record does not exist, GPG will still look  
for the "keys" name for backwards (and PGP) compatibility.

Setting "auto-key-locate ldap" turns this feature on.  If you use an  
email address as a recipient, and do not have a key for that  
recipient, the key location feature will kick in and try to find the  
key for you.

Incidentally, it is legal to do this:

_pgpkey-ldap._tcp.example.com.       SRV     0 0 389 keyserver.pgp.com.

That is, point to a non-local (but public) keyserver.  It just means  
"to find keys for addresses @example.com, consult the keyserver at  
ldap://keyserver.pgp.com".

2) HKPS - in other words regular old HKP over SSL (i.e. https).  So  
far as I know, the only hkps server in existence right now is hkps://
zimmermann.mayfirst.org.

David


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Jeroen Schot]

Hi,

On Thu, Aug 13, 2009 at 10:21:46PM -0400, David Shaw wrote:
> 2) HKPS - in other words regular old HKP over SSL (i.e. https). So far as I
> know, the only hkps server in existence right now is hkps://
> zimmermann.mayfirst.org.

I successfully tested HKPS, but encountered a lack of documentation. So here a
short howto specifically for the zimmermann.mayfirst.org keyserver:

Download the 'May First/People Link CA' certificate from
<https://support.mayfirst.org/wiki/mfpl_certificate_authority> and store it in
~/.gnupg/ca.crt.

Add the following two lines to your gpg.conf (or add them to the commandline):
  keyserver hkps://zimmermann.mayfirst.org
  keyserver-options ca-cert-file ~/.gnupg/ca.crt

Test the keyserver with a '--search-keys' or '--recv-keys'.

Note: The ca-cert-file option is not documented?

Regards,
--
Jeroen Schot <schot@...>


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Daniel Leidert]

Am Freitag, den 14.08.2009, 11:46 +0200 schrieb Jeroen Schot:

> On Thu, Aug 13, 2009 at 10:21:46PM -0400, David Shaw wrote:
> > 2) HKPS - in other words regular old HKP over SSL (i.e. https). So far as I
> > know, the only hkps server in existence right now is hkps://
> > zimmermann.mayfirst.org.
>
> I successfully tested HKPS, but encountered a lack of documentation. So here a
> short howto specifically for the zimmermann.mayfirst.org keyserver:
>
> Download the 'May First/People Link CA' certificate from
> <https://support.mayfirst.org/wiki/mfpl_certificate_authority> and store it in
> ~/.gnupg/ca.crt.
>
> Add the following two lines to your gpg.conf (or add them to the commandline):
>   keyserver hkps://zimmermann.mayfirst.org
>   keyserver-options ca-cert-file ~/.gnupg/ca.crt
>
> Test the keyserver with a '--search-keys' or '--recv-keys'.

I tried to follow your short howto (got mfpl.crt as .gnupg/ca.crt and
added the options), but I always get an error:

gpgkeys: HTTP search error 60: server certificate verification failed.
CAfile: none CRLfile: none
gpg: key "Leidert" not found on keyserver
gpg: keyserver internal error
gpg: keyserver search failed: keyserver error

Following the webform, the keys exist. Any idea?

Regards, Daniel


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[David Shaw]

On Aug 14, 2009, at 5:46 AM, Jeroen Schot wrote:

> Hi,
>
> On Thu, Aug 13, 2009 at 10:21:46PM -0400, David Shaw wrote:
>> 2) HKPS - in other words regular old HKP over SSL (i.e. https). So  
>> far as I
>> know, the only hkps server in existence right now is hkps://
>> zimmermann.mayfirst.org.
>
> I successfully tested HKPS, but encountered a lack of documentation.  
> So here a
> short howto specifically for the zimmermann.mayfirst.org keyserver:
>
> Download the 'May First/People Link CA' certificate from
> <https://support.mayfirst.org/wiki/mfpl_certificate_authority> and  
> store it in
> ~/.gnupg/ca.crt.
>
> Add the following two lines to your gpg.conf (or add them to the  
> commandline):
>  keyserver hkps://zimmermann.mayfirst.org
>  keyserver-options ca-cert-file ~/.gnupg/ca.crt
>
> Test the keyserver with a '--search-keys' or '--recv-keys'.
>
> Note: The ca-cert-file option is not documented?

You're right.  I'll fix that.

There is also a check-cert / no-check-cert option to enable checking  
or not.  It's actually a bit of a question whether the default should  
be to check or not to check (it's currently defaulting to check).  
Usually, you'd want to check by default, but in the case of OpenPGP  
keys, the keys are not validated by the keyserver anyway.

David


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[David Shaw]

On Aug 14, 2009, at 10:15 AM, Daniel Leidert wrote:

> Am Freitag, den 14.08.2009, 11:46 +0200 schrieb Jeroen Schot:
>
>> On Thu, Aug 13, 2009 at 10:21:46PM -0400, David Shaw wrote:
>>> 2) HKPS - in other words regular old HKP over SSL (i.e. https). So  
>>> far as I
>>> know, the only hkps server in existence right now is hkps://
>>> zimmermann.mayfirst.org.
>>
>> I successfully tested HKPS, but encountered a lack of  
>> documentation. So here a
>> short howto specifically for the zimmermann.mayfirst.org keyserver:
>>
>> Download the 'May First/People Link CA' certificate from
>> <https://support.mayfirst.org/wiki/mfpl_certificate_authority> and  
>> store it in
>> ~/.gnupg/ca.crt.
>>
>> Add the following two lines to your gpg.conf (or add them to the  
>> commandline):
>>  keyserver hkps://zimmermann.mayfirst.org
>>  keyserver-options ca-cert-file ~/.gnupg/ca.crt
>>
>> Test the keyserver with a '--search-keys' or '--recv-keys'.
>
> I tried to follow your short howto (got mfpl.crt as .gnupg/ca.crt and
> added the options), but I always get an error:
>
> gpgkeys: HTTP search error 60: server certificate verification failed.
> CAfile: none CRLfile: none
> gpg: key "Leidert" not found on keyserver
> gpg: keyserver internal error
> gpg: keyserver search failed: keyserver error
>
> Following the webform, the keys exist. Any idea?

Try not using the ~ in the file path. Rather, spell out the complete  
path.  Different distros sometimes build curl with different backend  
SSL libraries, and not all understand ~.

David


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Todd Zullinger]

David Shaw wrote:
> Try not using the ~ in the file path. Rather, spell out the complete
> path.  Different distros sometimes build curl with different backend
> SSL libraries, and not all understand ~.

On fedora, where curl is built with nss, this seems to be the case.

--
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The United States is a nation of laws, badly written and randomly
enforced.
    -- Frank Zappa



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Todd Zullinger]

David Shaw wrote:
> There is also a check-cert / no-check-cert option to enable checking
> or not.  It's actually a bit of a question whether the default
> should be to check or not to check (it's currently defaulting to
> check).  Usually, you'd want to check by default, but in the case of
> OpenPGP keys, the keys are not validated by the keyserver anyway.

This is one of those potential bike shed topics. :)

While the keyserver doesn't validate the keys, if someone is using
hkps:// it may well be to provide privacy and security for which keys
they are looking up.  If the cert is not checked the user cannot be
sure the keyserver they are connecting to is the legitimate site which
they trust.  To me, it seems like checking is the more reasonable
default.

--
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I visualize a time when we will be to robots what dogs are to humans,
and I'm rooting for the machines.
    -- Claude Shannon



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[David Shaw]

On Aug 14, 2009, at 2:46 PM, Todd Zullinger wrote:

> David Shaw wrote:
>> There is also a check-cert / no-check-cert option to enable checking
>> or not.  It's actually a bit of a question whether the default
>> should be to check or not to check (it's currently defaulting to
>> check).  Usually, you'd want to check by default, but in the case of
>> OpenPGP keys, the keys are not validated by the keyserver anyway.
>
> This is one of those potential bike shed topics. :)
>
> While the keyserver doesn't validate the keys, if someone is using
> hkps:// it may well be to provide privacy and security for which keys
> they are looking up.  If the cert is not checked the user cannot be
> sure the keyserver they are connecting to is the legitimate site which
> they trust.  To me, it seems like checking is the more reasonable
> default.

I agree (note that the default is to check, for both hkps and ldaps).  
While we cannot know the reason why someone is using hkps (rather than  
hkp), it is generally healthy to default to the more secure setting  
unless there is a clear reason not to.  Those who don't want cert  
checking can always turn it off.

David


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Daniel Leidert]

Am Freitag, den 14.08.2009, 14:27 -0400 schrieb David Shaw:
> On Aug 14, 2009, at 10:15 AM, Daniel Leidert wrote:

[test hkps support]

> > I tried to follow your short howto (got mfpl.crt as .gnupg/ca.crt and
> > added the options), but I always get an error:
> >
> > gpgkeys: HTTP search error 60: server certificate verification failed.
> > CAfile: none CRLfile: none
> > gpg: key "Leidert" not found on keyserver
> > gpg: keyserver internal error
> > gpg: keyserver search failed: keyserver error
> >
> > Following the webform, the keys exist. Any idea?
>
> Try not using the ~ in the file path. Rather, spell out the complete  
> path.  Different distros sometimes build curl with different backend  
> SSL libraries, and not all understand ~.

I used the full path too with the same result. But I tried the whole
thing in a chroot environment and I'll try to examine this further. Not
sure, what's happening.

Regards, Daniel


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Jeroen Schot]

Hi,

On Sat, Aug 15, 2009 at 07:12:20PM +0200, Daniel Leidert wrote:
> I used the full path too with the same result. But I tried the whole
> thing in a chroot environment and I'll try to examine this further. Not
> sure, what's happening.

Could you try to change the line
  keyserver-options ca-cert-file ~/.gnupg/ca.crt
to
  keyserver-options ca-cert-file=/path/to/.gnupg/ca.crt

Note the '=' sign.

Regards,
--
Jeroen Schot <schot@...>


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Daniel Leidert]

Am Samstag, den 15.08.2009, 21:17 +0200 schrieb Jeroen Schot:

> On Sat, Aug 15, 2009 at 07:12:20PM +0200, Daniel Leidert wrote:
> > I used the full path too with the same result. But I tried the whole
> > thing in a chroot environment and I'll try to examine this further. Not
> > sure, what's happening.
>
> Could you try to change the line
>   keyserver-options ca-cert-file ~/.gnupg/ca.crt
> to
>   keyserver-options ca-cert-file=/path/to/.gnupg/ca.crt
>
> Note the '=' sign.

Many thanks. That's it. JFTR: The tilde sign doesn't work under Debian
too. So the full path is necessary.

Regards, Daniel


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Werner Koch]

On Fri, 14 Aug 2009 20:27, dshaw@... said:

> Try not using the ~ in the file path. Rather, spell out the complete

We should process the tilde.  We do this at all other places and it is a
bit surprising that it does not work here.

While looking at the code I figured that 1.4. and 2.0 are not anymore
identical.  1.4. does complete tilde expansion since 2005 whereas 2.0
still looks only at $HOME.  I'll put this on my list for 2.0.13.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Marcus Brinkmann]

David Shaw wrote:
> There is also a check-cert / no-check-cert option to enable checking or
> not.  It's actually a bit of a question whether the default should be to
> check or not to check (it's currently defaulting to check).  Usually,
> you'd want to check by default, but in the case of OpenPGP keys, the
> keys are not validated by the keyserver anyway.

Protecting the channel is important if for example replay attacks are a
concern, and you want to avoid a man in the middle providing out of date keys
and suppressing revoke certificates.

Thanks,
Marcus


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[David Shaw]

On Aug 17, 2009, at 2:17 PM, Marcus Brinkmann wrote:

> David Shaw wrote:
>> There is also a check-cert / no-check-cert option to enable  
>> checking or
>> not.  It's actually a bit of a question whether the default should  
>> be to
>> check or not to check (it's currently defaulting to check).  Usually,
>> you'd want to check by default, but in the case of OpenPGP keys, the
>> keys are not validated by the keyserver anyway.
>
> Protecting the channel is important if for example replay attacks  
> are a
> concern, and you want to avoid a man in the middle providing out of  
> date keys
> and suppressing revoke certificates.

Yes, and so the default for cert checking is on to be extra safe, but  
I don't think that case is very common.  Most people just talk to a  
public keyserver that they do not have any particular relationship to.

David


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[David Shaw]

On Aug 17, 2009, at 6:24 AM, Werner Koch wrote:

> On Fri, 14 Aug 2009 20:27, dshaw@... said:
>
>> Try not using the ~ in the file path. Rather, spell out the complete
>
> We should process the tilde.  We do this at all other places and it  
> is a
> bit surprising that it does not work here.

I agree.

How should we handle this?  This raises a different question, as the  
current tilde expansion code is in libutil, rather than libcompat,  
which is what is linked with the keyserver helpers.  My notes say we  
split libcompat and libutil in 2006 for licensing reasons, as the  
keyserver helpers might be linked with OpenSSL, which is not GPL  
compatible (hence the special exception in the keyserver helper  
license).

Now, it would be possible to move the tilde expanding code to  
libcompat (or even just implement things slightly differently), but I  
notice that GnuPG 2.x doesn't do any of this stuff with a different  
library, and just uses libcommon everywhere, including in the  
keyserver helpers.

Is libcompat really necessary for GPL compliance?  If not, this is an  
easier problem.  If it is necessary, we need to fix GnuPG 2.x.

David


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Werner Koch]

On Mon, 24 Aug 2009 03:46, dshaw@... said:

> which is what is linked with the keyserver helpers.  My notes say we
> split libcompat and libutil in 2006 for licensing reasons, as the
> keyserver helpers might be linked with OpenSSL, which is not GPL

Right, I forgot about this.  

> Now, it would be possible to move the tilde expanding code to
> libcompat (or even just implement things slightly differently), but I

Yeah we should do that:  Add the exception to gnupg14/util/fileutil.c
and make sure that it does not need other stuff from util/ .

BTW, srv.c, which is used in libcompat, is also missing the OpenSSL
exception.  Easy to fix.

> notice that GnuPG 2.x doesn't do any of this stuff with a different
> library, and just uses libcommon everywhere, including in the
> keyserver helpers.

Right.

Actually, I forgot about this problem while porting the keyserver code
to GnuPG-2, or assumed that OpenSSL is not used.  Those who distribute
GnuPG-2, need to take care of the license, meaning to use gnutls, yaSSL
or another GPL compatible SSL library.  In particular gnutls is a good
choice because gnutls uses libgcrypt which is a requirement for GnupG
anyway.

> Is libcompat really necessary for GPL compliance?  If not, this is an
> easier problem.  If it is necessary, we need to fix GnuPG 2.x.

We should allow the (indirect) use of OpenSSL with GnuPG 1.4, thus we
need to extend libcompat.  No need to care about it for GnuPG-2.

Shall I take care of the tilde code?


Shalom-Salam,

   Werner


--
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Werner Koch]

On Tue, 25 Aug 2009 21:03, dshaw@... said:

> Alas, it does.  It pulls in the memory allocation code (xmalloc and
> friends).  We could fairly easily make a ~ expander that doesn't use

No problem anymore.  I just added a small memory allocation stub.

> means that if a distribution builds Curl with OpenSSL, that
> distribution must build GnuPG without Curl.  Since Curl defaults to
> building with OpenSSL, and GnuPG-2 defaults to building with Curl,

Most GPL software is bugged by this problem.  This was discussed a few
years ago and all distros should by now know about it.  The problems are
sometimes even deeper hidden than gpl_application->openldap->openssl.

> I don't know how many distros fall into this category (I do know that
> Fedora is okay here), but any distro that follows the defaults will.

Debian and thus Ubunto gets this right.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[David Shaw]

On Aug 25, 2009, at 3:17 PM, Werner Koch wrote:

> On Tue, 25 Aug 2009 21:03, dshaw@... said:
>
>> Alas, it does.  It pulls in the memory allocation code (xmalloc and
>> friends).  We could fairly easily make a ~ expander that doesn't use
>
> No problem anymore.  I just added a small memory allocation stub.

Great!

>> means that if a distribution builds Curl with OpenSSL, that
>> distribution must build GnuPG without Curl.  Since Curl defaults to
>> building with OpenSSL, and GnuPG-2 defaults to building with Curl,
>
> Most GPL software is bugged by this problem.  This was discussed a few
> years ago and all distros should by now know about it.  The problems  
> are
> sometimes even deeper hidden than gpl_application->openldap->openssl.
>
>> I don't know how many distros fall into this category (I do know that
>> Fedora is okay here), but any distro that follows the defaults will.
>
> Debian and thus Ubunto gets this right.

Sounds good to me.  I just don't want any distribution to get any  
grief for distributing GnuPG.

David


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Bernd Eckenfels-4]

On Wed, Aug 26, 2009 at 11:33:39AM -0400, David Shaw wrote:
> Sounds good to me.  I just don't want any distribution to get any  
> grief for distributing GnuPG.

In that case it would help to get rid of GPL :)

Gruss
Bernd
--
  (OO)     -- Bernd_Eckenfels@Mörscher_Strasse_8.76185Karlsruhe.de --
 ( .. )    ecki@{inka.de,linux.de,debian.org}  http://www.eckes.org/
  o--o   1024D/E383CD7E  eckes@IRCNet  v:[phone]  f:[phone]
(O____O)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel