-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/01/2013 12:07 AM, Doug Barton wrote:
On 02/28/2013 09:33 AM, Kristian Fiskerstrand wrote: | for a
service that specifically targets the OpenPGP community, I |
consider using the OpenPGP WoT more appropriate than any CA |
Corporation.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/01/2013 06:06 PM, Kristian Fiskerstrand wrote:
On 03/01/2013 12:07 AM, Doug Barton wrote:
..
I hope you'll reconsider your decision.
I certainly continuously consider constructive feedback on the
setup, so will give it some more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
El 25-02-2013 19:54, Peter Loshin escribió:
...
2. On keeping an encrypted backup of my secret key material, what
method is recommended for doing that? (Presumably something like
gpg --export-secret-keys | gpg --output secretkeymatter.gpg
On 2013-02-27 at 10:57 +0100, Niels Laukens wrote:
Apologies for cross-posting to both mailing lists, but since I got
replies via both ways I feel this is the easiest way to sync them.
Current status: Kristian and I have debugged and he found the core
issue. If I load down my server, we can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Mark,
A belated answer to this email, as I'm reading through the backlog of
emails.
On 02/26/2013 03:43 PM, Mark H. Wood wrote:
On Mon, Feb 25, 2013 at 05:54:34PM -0500, Peter Loshin wrote:
3. On using a keyserver with HKPS support: when I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/28/2013 09:33 AM, Kristian Fiskerstrand wrote:
| for a service that specifically targets the OpenPGP community, I
| consider using the OpenPGP WoT more appropriate than any CA
| Corporation.
Kristian,
I certainly understand that
On 02/25/2013 11:52 PM, Niels Laukens wrote:
I find *.sks-keyservers.net unusable (unfortunately).
More often than not, I get this:
gpgkeys: HTTP fetch error 7: couldn't connect: End of file
tcpdump shows me that the server just closes the connection without an
answer.
It does work from
On Tue, 26 Feb 2013 08:52, ni...@dest-unreach.be said:
It does work from time to time, so when doing a manual --recv-key, I
usually get the key within a few tries. But when using e.g. caff (which
The problem is that this is a pool of servers and you don't know which
one you are currently
On 2013-02-26 09:14, Daniel Kahn Gillmor wrote:
On 02/25/2013 11:52 PM, Niels Laukens wrote:
I find *.sks-keyservers.net unusable (unfortunately).
More often than not, I get this:
gpgkeys: HTTP fetch error 7: couldn't connect: End of file
tcpdump shows me that the server just closes the
On 26/02/13 07:43, Doug Barton wrote:
That worked for me, although I was a bit disappointed that placing the cert at
/etc/ssl/certs/ca.hkps.pool.sks-keyservers.net.cert didn't work like all the
docs said it should.
Please realise that if it would have worked, you would have installed that
...@fifthhorseman.net
Sender: gnupg-users-boun...@gnupg.org
Date: Tue, 26 Feb 2013 00:14:13
To: GnuPG Usersgnupg-users@gnupg.org
Subject: Re: Questions about OpenPGP best practices
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org
On Tue, 26 Feb 2013 11:19, pe...@digitalbrains.com said:
In other words, trusting a certificate authority is currently an
all-or-nothing
thing where you now trust them to certify any SSL-protected service
you connec
Right, they are all implicitly cross-signed. In reality there is no
On 26/02/13 11:56, Werner Koch wrote:
Thus, it won't harm you to add such a kind of Salvation Army CA.
Okay, you made me laugh out loud, thanks :).
It probably won't hurt to add the sks-keyservers CA, although I don't know how
well they guard their private key. Probably fairly well, these are
On Mon, Feb 25, 2013 at 05:54:34PM -0500, Peter Loshin wrote:
3. On using a keyserver with HKPS support: when I attempt to connect
(via Chrome) to https://sks-keyservers.net/, I get an error headlined
The site's security certificate is not trusted!, stating the
server presented a certificate
On 02/26/2013 02:19 AM, Peter Lebbing wrote:
On 26/02/13 07:43, Doug Barton wrote:
That worked for me, although I was a bit disappointed that placing the cert at
/etc/ssl/certs/ca.hkps.pool.sks-keyservers.net.cert didn't work like all the
docs said it should.
Please realise that if it would
I got a new error today:
gpg: sending key 1A1ABC84 to hkp server pool.sks-keyservers.net
gpgkeys: HTTP post error 22: The requested URL returned error: 417
Expectation Failed
Never seen that one before. :)
Overall the performance of the sks-keyservers pool has been great for me
though.
On 02/26/2013 06:43 AM, Mark H. Wood wrote:
That service presents a self-signed certificate (I checked), which
means that if you do not already have a copy of that cert. installed in
your browser and marked trusted, then it cannot be verified.
This is not correct. As noted on the web site
Many thanks to Daniel Kahn Gillmor for pointing to the best practices
page (https://we.riseup.net/riseuplabs+paow/openpgp-best-practices);
this information is very helpful.
Some questions about the information on this page:
1. Don't use pgp.mit.edu. Which keyserver *should* be used? I assume
On 2/25/13 5:54 PM, Peter Loshin wrote:
1. Don't use pgp.mit.edu. Which keyserver *should* be used? I assume
that a pool is better than a particular server; is there one
particular pool that is preferred? What about
http://pool.sks-keyservers.net/?
Yep, that's the one you want.
2. On
On 02/25/2013 02:54 PM, Peter Loshin wrote:
Many thanks to Daniel Kahn Gillmor for pointing to the best practices
page (https://we.riseup.net/riseuplabs+paow/openpgp-best-practices);
this information is very helpful.
Some questions about the information on this page:
1. Don't use pgp.mit.edu.
On 02/25/2013 02:54 PM, Peter Loshin wrote:
1. Don't use pgp.mit.edu. Which keyserver *should* be used? I assume
that a pool is better than a particular server; is there one
particular pool that is preferred? What about
http://pool.sks-keyservers.net/?
You should use hkp:// instead of
On 02/25/2013 10:43 PM, Doug Barton wrote:
The Best Practices page you posted above actually suggests:
keyserver hkps://hkps.pool.sks-keyservers.net
keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem
That worked for me, although I was a bit disappointed that placing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2013 11:10 PM, Daniel Kahn Gillmor wrote:
| On 02/25/2013 10:43 PM, Doug Barton wrote:
| The Best Practices page you posted above actually suggests:
|
|keyserver hkps://hkps.pool.sks-keyservers.net
|keyserver-options
On 02/25/2013 11:28 PM, Doug Barton wrote:
lots, this one for example:
https://help.ubuntu.com/community/GnuTLS
hmm, i don't use ubuntu myself, but i believe that documentation is
wrong, particularly this section:
https://help.ubuntu.com/community/GnuTLS#Deploying_the_Certificates
That
On 2013-02-26 07:51, Daniel Kahn Gillmor wrote:
On 02/25/2013 02:54 PM, Peter Loshin wrote:
1. Don't use pgp.mit.edu. Which keyserver *should* be used? I assume
that a pool is better than a particular server; is there one
particular pool that is preferred? What about
25 matches
Mail list logo
