Re: [Sks-devel] pool.sks-keyservers.net issues

[Niels Laukens]

Thanks Phil for the very clear summary of the problem!

On 2013-02-28 00:50, Phil Pennock wrote:
> The best fix is to use gpg with a real cURL library.

I'm currently using a downloaded binary from gpgtools.org. I don't see
libcurl in the list of shared objects used by the binary (otool -L,
Mac's equivalent to ldd), so I assume gpg was build without libcurl
support and I need to build a gpg2 myself. Am I correct?


> So:
>  (1) there's a corner-case interaction of TCP/HTTP and half-closes
>  (2) there's a build work-around for end-sites of the client software
>  (3) there's a code change for the client software that avoids the issue
>  (4) we're working on server configuration fixes to avoid the issue too
> 
> (4) is the only thing that will help currently deployed software bases.
> (3) is the only thing that will keep the issue reliably fixed going
> forward.
> (2) means people encountering it can work around it now.
> (1) sucks, because I for one like the signalling done and the model used
> in TCP and used by the GnuPG developers.  It's very clear, "we're
> not going to send anything else".  Unfortunately, it's causing
> real-world interoperability issues.  :-(

I agree with your sentiment on (1). TCP clearly states that this is the
expected behavior (quote from RFC793 section 3.5):
> CLOSE is an operation meaning "I have no more data to send."  The
> notion of closing a full-duplex connection is subject to ambiguous
> interpretation, of course, since it may not be obvious how to treat
> the receiving side of the connection.  We have chosen to treat CLOSE
> in a simplex fashion.  The user who CLOSEs may continue to RECEIVE
> until he is told that the other side has CLOSED also.  Thus, a program
> could initiate several SENDs followed by a CLOSE, and then continue to
> RECEIVE until signaled that a RECEIVE failed because the other side
> has CLOSED.

(2) does require a recompile of the binary. I don't mind compiling from
source, but I think a lot of users won't go further than downloading
binaries.

(3) will solve thing in the future. Is someone already working on a
patch? Since my options are (a) live with the problem or (b) compile a
fixed version, I can just as well patch and compile the curl-shim-part.

(4) is obviously the best solution from a user perspective, and combined
with my (and Phil's) view on (1), also the "right" solution.

Niels



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

Re: [Sks-devel] pool.sks-keyservers.net issues

[Niels Laukens]

On 2013-02-28 09:36, Phil Pennock wrote:
> On 2013-02-28 at 09:12 +0100, Niels Laukens wrote:
>> On 2013-02-28 00:50, Phil Pennock wrote:
>>> The best fix is to use gpg with a real cURL library.
>>
>> I'm currently using a downloaded binary from gpgtools.org. I don't see
>> libcurl in the list of shared objects used by the binary (otool -L,
>> Mac's equivalent to ldd), so I assume gpg was build without libcurl
>> support and I need to build a gpg2 myself. Am I correct?
> 
> Or use gpg 1.

This is a workable workaround for me.

>> I agree with your sentiment on (1). TCP clearly states that this is the
>> expected behavior (quote from RFC793 section 3.5):
> 
> Standards say one thing, real world experience says another.

I agree.
(Just for completeness: I don't mind changing behavior from
"standard-compliant" to "real-world working" as long as the latter is
still standard-compliant. Which is the case for this discussion)

>> (3) will solve thing in the future. Is someone already working on a
>> patch? Since my options are (a) live with the problem or (b) compile a
>> fixed version, I can just as well patch and compile the curl-shim-part.
> 
> The GnuPG folks have a patch in tree, they just need to port it across
> from the 1.4 branch to the 2.0 branch.

I'll keep an eye on the mentioned bug report for progress


Thanks!
Niels

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

Re: [Sks-devel] pool.sks-keyservers.net issues (was: Questions about OpenPGP best practices)

[Phil Pennock]

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 sometimes see my server with
the same symptom, so it's timing-sensitive.

It is the half-close you saw: GnuPG with curl-shim is the only thing
doing this and it's the common factor.  nginx as a proxy will drop the
request if it sees the connection half-closed before it passes the
request onto the backend.

Half-closing an HTTP request connection is into a very grey area of the
HTTP specification, with some strong opinions all around based on "it's
classic TCP" to "it's not in HTTP", etc.  The nginx authors think it's a
problem to allow it.

There's a proxy_ignore_client_abort option for nginx, which is broken at
various times in the nginx source tree.

The best fix is to use gpg with a real cURL library.  Separately, for
maximum compatibility, gnupg's curl-shim should stop half-closing the
TCP connections used, and behave more like curl does.

Separately from that, we're trying to find ways to configure nginx and
establish a best-practice configuration which avoids exposing this
issue.

So:
 (1) there's a corner-case interaction of TCP/HTTP and half-closes
 (2) there's a build work-around for end-sites of the client software
 (3) there's a code change for the client software that avoids the issue
 (4) we're working on server configuration fixes to avoid the issue too

(4) is the only thing that will help currently deployed software bases.
(3) is the only thing that will keep the issue reliably fixed going
forward.
(2) means people encountering it can work around it now.
(1) sucks, because I for one like the signalling done and the model used
in TCP and used by the GnuPG developers.  It's very clear, "we're
not going to send anything else".  Unfortunately, it's causing
real-world interoperability issues.  :-(

-Phil


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

Re: [Sks-devel] pool.sks-keyservers.net issues

[Phil Pennock]

On 2013-02-28 at 09:12 +0100, Niels Laukens wrote:
> On 2013-02-28 00:50, Phil Pennock wrote:
> > The best fix is to use gpg with a real cURL library.
> 
> I'm currently using a downloaded binary from gpgtools.org. I don't see
> libcurl in the list of shared objects used by the binary (otool -L,
> Mac's equivalent to ldd), so I assume gpg was build without libcurl
> support and I need to build a gpg2 myself. Am I correct?

Or use gpg 1.  Discussion on gnupg-devel points out that my
https://bugs.g10code.com/gnupg/issue1479 bug is a dup of
https://bugs.g10code.com/gnupg/issue739 fixed in 2007.  The same issue
was fixed for GnuPG 1.4.x, but not fixed for GnuPG 2.x.

> I agree with your sentiment on (1). TCP clearly states that this is the
> expected behavior (quote from RFC793 section 3.5):

Standards say one thing, real world experience says another.  The nginx
folks note that they couldn't tell apart "closed for sending" from
"closed entirely", so they just treat the FIN as a sign of an aborted
connection.

> (2) does require a recompile of the binary. I don't mind compiling from
> source, but I think a lot of users won't go further than downloading
> binaries.

Download a gpg 1.4.x binary.

> (3) will solve thing in the future. Is someone already working on a
> patch? Since my options are (a) live with the problem or (b) compile a
> fixed version, I can just as well patch and compile the curl-shim-part.

The GnuPG folks have a patch in tree, they just need to port it across
from the 1.4 branch to the 2.0 branch.

> (4) is obviously the best solution from a user perspective, and combined
> with my (and Phil's) view on (1), also the "right" solution.

Unfortunately, it looks as though nginx has broken the
"proxy_ignore_client_abort on" directive: it doesn't work.

If it did work, I wouldn't now be able to reliably trigger the bug.  I
built gpg2 with the curl-shim on a friend's box in the same colo
network, so it's one unrouted ethernet hop away from my keyserver setup.
With this, I can now trigger it pretty consistently.

I've just bumped my nginx from 1.3.12 to 1.3.13 and the problem
persists.

-Phil

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

Re: key length for smart card key generation

[Anonymous]

On Wed, 27 Feb 2013 12:03:22 +0100
Josef Schneider  wrote:

> Hello,
> with the current version of GPG 2 you can import 4096bit keys to a
> OpenPGP smartcard version 2.0.
> There is a bug in GPG2 that prevents it from decrypting data with a
> key longer than 3072bit on a OpenPGP smartcard. This should be fixed
> in the GIT repository.
> AFAIK a version 1 card doesn't support keys longer than 1024bit! "gpg
> --card-status" should tell you which version you have.
> 
> 

Thanks for the information.

So I should be able to import the key...but not use it unless it is 
3072 bits or less?

I run gpg2 --card-status, and I get a lot of information, but I don't
see an entry "OpenPGP version."  What I do see is a field "Version:"
which says "11.11".


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

Re: [Sks-devel] pool.sks-keyservers.net issues

[Doug Barton]

Phil,

Could this curl issue be the cause of this error that I've been seeing 
the last few days:


gpg: sending key 1A1ABC84 to hkp server pool.sks-keyservers.net
gpgkeys: HTTP post error 22: The requested URL returned error: 417 
Expectation Failed

gpg: sending key D5B2F0FB to hkp server pool.sks-keyservers.net
gpgkeys: HTTP post error 22: The requested URL returned error: 417 
Expectation Failed

gpg: keyserver internal error
gpg: keyserver send failed: Keyserver error

Based on your post I tried GnuPG 1 with that same keyserver and it 
worked fine.


Doug

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

Re: [Sks-devel] pool.sks-keyservers.net issues

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/28/2013 09:44 AM, Kristian Fiskerstrand wrote:
| Hi Doug,
|
|
| On 02/28/2013 06:35 PM, Doug Barton wrote:
|> Phil,
|
|> Could this curl issue be the cause of this error that I've been
|> seeing the last few days:
|
|> gpg: sending key 1A1ABC84 to hkp server pool.sks-keyservers.net
|> gpgkeys: HTTP post error 22: The requested URL returned error:
|> 417 Expectation Failed
|
|
| The 417 return code is typically used by a reverse proxy if the
| backend (i.e. SKS) is non-responsive, so intuitively that is a
| separate matter. Please add --keyserver-options verbose,debug to
| see if you're talking to different servers.

Yes, I'm talking to different servers (as would be expected). Just
tried it a few times ...

2001:470:1f09:5e7::2worked
2001:470:1f0a:5d7::2failed

In any case thanks for clarifying the cause of the error ... it's just
hard to debug without putting those options in first obviously, and
with those options the output is very noisy.

GnuPG folks, would it be possible to add a keyserver-option to show
the IP address of the server connected to? I could live with that full
time, and it would make reporting errors a lot easier.

Doug
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iQEcBAEBCAAGBQJRL5t6AAoJEFzGhvEaGryEOhEIAM3M29gBHr2Y855kJxuw9b+F
j+kPmf+zTEBERWo7H4if+qBQ54jdubQ06G96ejYd7f+4kMlP7+KycB0kOWWBdRH0
J/w8VyYzaVVKLIi6QudzpuZ8g3SYz4auVoOjwSBYWUX3d9RUHgajpYgVaZIIEs9n
RqCUrf6PdBgR08bOYX/jXRiaBqTdTCgQkzRd06hgjY0i+jo3AfJJuqdwKnGerZyi
CE8AF8FfY2eIBxS1tmnA6S6tPiN080Xj+oWGA0t3B91hSGBLCJGFYe0OdJDlkM/1
A129MHfYqHVnzH1CCPITkb+v6r00RcqwkHOtt18ZH+CrUHBMz+ehTTsfqq5Tvpk=
=U6+f
-END PGP SIGNATURE-

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

Re: [Sks-devel] pool.sks-keyservers.net issues

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/28/2013 07:01 PM, Doug Barton wrote:
> On 02/28/2013 09:44 AM, Kristian Fiskerstrand wrote: | Hi Doug, |
> 

...

> Yes, I'm talking to different servers (as would be expected). Just 
> tried it a few times ...
> 

At least that explains it. For what it is worth both of those servers
are working for me now. I'd typically expect this response while the
server is running its statistics update. I notice that the last stats
update on the server you had issues with was at 19:03 CET, so just
about 20 minutes ago. Hopefully both are working for you as well now.

- -- 
- 
Kristian Fiskerstrand
Twitter: @krifisk
- 
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Veni vidi velcro
I came, I saw, I got stuck
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.0-beta145 (GNU/Linux)

iQIcBAEBCAAGBQJRL6CFAAoJEAt/i2Dj7frjfWYP/2z4ttKRH5eavUm4EKT91X8K
ABA6cIrpwkMABjN4GOY/W5pfBIz1GcCEBCyB+XnpljZ8xYrHFMVSk/iauEMRdBn/
98rRWVWpLS17EhR7pJzF+qBsn1SR5wY1CUqDnkhAN1L8gxLDgmZZOJTMw4QY0aSa
SDGu3sNHUBUrz2vca2zKwtknlZTSPSfYsmvvPAfpvCODuoWMqT9nSUE4hENUYisR
gvqf/0ALbzNpHmCJfbRWdcxmfoCASWBhXw9xhO2Fm9S3U2YyrJswUWmOZYmx/pph
BggPZDeii4TYUw+2LU6m8497biPAqY0zBEOzffw9ZX0ZpoTi3138D8d+5+KecSQr
QGf1xoBb565ywSfPK6wdVKlxXorR8Afaa8bSLHqnnyEkTU+Xe12YKQSrCP5zeMVo
flhQtv3mI+qT2NeQMscfED+tSFh8I0I1mY+/2wNoWsrh6rCFuG18sFJSBvMOI3qD
7140QhksM3gX2Z8484SHTbRkNyJkpgpmy7pZIV7eYGGrs9GOJW1FZQYlNhTtXYh5
pTXAu/cpmjWofEMywZ8zXkijwZnjmLqk0ItYSPfS2NlTSmvBtTq5ALIRpGcmN9qZ
i/rRJbM0fBU17Y0Qfzz/YYb68LF5wTlQQ1sAKu8ta8aeK2RoT5KU3Oj0ofzR1FJH
hTVUoeOWbbgi60fyfOFJ
=n8oh
-END PGP SIGNATURE-

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

Re: [Sks-devel] pool.sks-keyservers.net issues

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/28/2013 10:23 AM, Kristian Fiskerstrand wrote:
| On 02/28/2013 07:01 PM, Doug Barton wrote:
|> On 02/28/2013 09:44 AM, Kristian Fiskerstrand wrote: | Hi Doug,
|> |
|
|
| ...
|
|> Yes, I'm talking to different servers (as would be expected).
|> Just tried it a few times ...
|
|
| At least that explains it. For what it is worth both of those
| servers are working for me now. I'd typically expect this response
| while the server is running its statistics update. I notice that
| the last stats update on the server you had issues with was at
| 19:03 CET, so just about 20 minutes ago. Hopefully both are working
| for you as well now.

~From your description I suspected that it was probably load related,
so that's understandable. My concern is that I'm seeing that error way
more often than not when sending keys over the last few days, and I
don't remember ever seeing it before. OTOH, I recently attended a key
signing party with over 40 participants, so I have been busy pulling
down other people's keys, and uploading mine when new signatures come
in, so I've been hitting the servers harder than usual. Sounds like
I'm just getting unlucky?

Doug



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iQEcBAEBCAAGBQJRL6GjAAoJEFzGhvEaGryE77wIAKFYkkYbqJ1RzTi0KrC9Luzs
q8a2/gToWdR7+dDLWyd/rxeLT84YSCX71IPDYIaE4zUVh6sDQ2TqVf8dGdjL8mTS
ys0Oz1tXRbxi6W0s+6tsBgmAm37DxN0mROw81OI65OC0sc747/8++5tyRx48m2SC
WLy9PJ3/8Dt0qe3C2T/SiszllAS1cJFnKjqyNOs6ousObj12zSuqiFKkt1G6huzc
XbwVs9u/aZIBmUwGwcP8YpOPiHe+q05CQGIWfXLkdyGn3mnKMx8rgQEBZzdaXLMG
HMFMsBXF96q/PjvvYaDE59enMvOxbwlmycHTmHmnBDIRAYA3fNGntpeVBaOZtC4=
=2F5Y
-END PGP SIGNATURE-

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

Re: [Sks-devel] pool.sks-keyservers.net issues

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Doug,


On 02/28/2013 06:35 PM, Doug Barton wrote:
> Phil,
> 
> Could this curl issue be the cause of this error that I've been
> seeing the last few days:
> 
> gpg: sending key 1A1ABC84 to hkp server pool.sks-keyservers.net 
> gpgkeys: HTTP post error 22: The requested URL returned error: 417 
> Expectation Failed


The 417 return code is typically used by a reverse proxy if the
backend (i.e. SKS) is non-responsive, so intuitively that is a
separate matter. Please add --keyserver-options verbose,debug to see
if you're talking to different servers.

- -- 
- 
Kristian Fiskerstrand
Twitter: @krifisk
- 
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Aquila non capit muscas
The eagle does not hunt flies
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.0-beta145 (GNU/Linux)

iQIcBAEBCAAGBQJRL5dsAAoJEAt/i2Dj7frjcaQQAKeYkzTGh6h8X+iaIvTcCtz8
DK722PEgEH2l9nFpi0JAd8fp8FimmtJXQK0thW3NNW95Atf8LfV7Eeg67KFaqw0v
PCCsOVIifDsNYheJ4eJ59G2HWljVXmCBTTm+3/F6uPTOyKNf/Puyya7TrJiIGVOs
rtEiWJEoIP8y2N4Nh4Kgur64menvyErMaFQZOZrrR90IeOBQyAyJEB2tPspuM/qk
iEbyNnxF4CsAJJWhpPlth3u81Qu6Qx6iX97nnZyilGf53KFM02JSP246rvuw8Px1
tWEK5CeEe/Z60Uxpcvg1YKnsjvihmSXR3arNgCoqkV+HsoZIToQz8F/DbTxwNbvw
3moZhqr08xklAcXdjmT3fwy5n7PXmLRl5kppWQMV9fcuNhxMS2Ppxk32OvxBAx6W
eyc3ve4UvW6yFhBiELnOEqgVB1EiPA+lrW8Mv0P6hNO5eAxTRbmq0AGiMReRNkAd
Hu/fLcJ70/e2sia/QvmpfejZK+NflzKfFE1sZjiEE8+JdsiNvvvh/8NkepuOSABo
eolGwFsx4F67fOEO+tc090L3Xygy+Qd6Or7IemYEqttOWgp5vBVBVkKJD4oHePM1
S59N9V4IoN+OwZH8Q7jrIVQ8abRxXZEMr+n1wGUYpNqqpSoUUcaOCnV8CJBD5Tz3
bgFLLYOnzjKdgXuh13hh
=BRke
-END PGP SIGNATURE-

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

Re: Questions about OpenPGP best practices

[Kristian Fiskerstrand]

-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 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 issued by
>> an entity that is not trusted by your computer's operating
>> system."

... this part is already answered by Daniel, for a service that
specifically targets the OpenPGP community, I consider using the
OpenPGP WoT more appropriate than any CA Corporation.

>> 4. When I try to use hkps://sks-keyservers.net with GnuPG at the 
>> command line, I get these messages:

Note that you're trying to connect to my webserver, all the pools are
under the "pool" subdomain. HKPS defaults to port 443 and as such this
request correspond to the HTTPS enabled website.


>> And when I try the same with the domain name only
>> (sks-keyservers.net) I get these messages:

...

>> 
>> : can't connect to `sks-keyservers.net': No route to host 
>> gpgkeys: HTTP post error 7: couldn't connect: No route to host 
>> gpg: keyserver internal error gpg: keyserver send failed:
>> Keyserver error
> 
> The site doesn't want unencrypted connections, and they way they 
> enforce this is by returning "no route" to requests for connection
> to port 80.  I would have used "administratively prohibited", to
> give real users a clue, but they may be trying to be less visible
> to 'bots.
> 

See above, you're trying to talk to my webserver rather than any SKS
server, this time on port 11371.


- -- 
- 
Kristian Fiskerstrand
Twitter: @krifisk
- 
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Aquila non capit muscas
The eagle does not hunt flies
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.0-beta145 (GNU/Linux)

iQIcBAEBCAAGBQJRL5TKAAoJEAt/i2Dj7frjBUAP/191bZD/sPPBAlZWkrtrynS4
9UCYBDnayKNTJ+rKVIW6l29BPpfl0MoJNA1F8DIil6HkYiDilmqT5g77Zd/VZgmn
u0g7sdUUT1XNWzXfqhha/d3spoRRfORdIEX94c/pga35+f+emxNzD3mfYTJJaIHa
gJUG/zIYUmZZUNYJCEmw908qo9H6DYckx1vi6S6nDAk9AuXL2NeAqyazsWycwTQX
ebBRdfWOKs7KAs827MDmGNv1XmgRHmRaGf96l0x/4J/zdcd3dtWCafJ15yMcc3Mj
q+wP4IUEIahGJ9Vq/UyuQa4g4XA/g5bCN/p+2Tn/hxoEAz+8FN2WFh8+33JZ5TpL
AjGi1UqpwnF2clH6XqLnKv1QMpw2FeZTalaITxnB/gqHvSYLp4oc9L9YAsMsWrtm
Z9X8b2oo6DTROUUlSQMUehQmBL6Gs1mBNYs/vKacjYxyrTL0E0m/SpWi6+IUej2N
OxiXXbT5IWSRmAcJjgA81NUNOg4fPkYKZHzBw9okgm0GG9dT45cw36/ZGMK2uuaJ
cQZOIt3UsmlmDQvbxxQIBz2EWuoMpSDpjiQjZX2LEq3pdkKwr8l6wuBIWuYBzAzI
HNuv4pro6YEH61VpJ8rkjYz49ROmBb91gYI22r6Jl5jI0huO+w868dk7w1qoNqkO
vWFqzN3JTvF62N21jYz4
=EopU
-END PGP SIGNATURE-

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

Re: key length for smart card key generation

[Peter Lebbing]

On 27/02/13 22:58, Anonymous wrote:
> So I should be able to import the key...but not use it unless it is 
> 3072 bits or less?

If we're all talking about RSA here, I think so.

> I run gpg2 --card-status, and I get a lot of information, but I don't
> see an entry "OpenPGP version."  What I do see is a field "Version:"
> which says "11.11".

Second line of the output for me:

> Application ID ...: D2760001240102[snip]
> Version ..: 2.0
^^^
> Manufacturer .: ZeitControl
> Serial number : [snip]
> Name of cardholder: Peter Lebbing
> Language prefs ...: en
> Sex ..: yes, please
> URL of public key : [not set]
> Login data ...: [not set]
> Signature PIN : forced
> Key attributes ...: 2048R 2048R 2048R
> Max. PIN lengths .: 32 32 32
> PIN retry counter : 3 0 3
> Signature counter : [snip]
> Signature key : 6500 8DC2 20AA E2A2 574D  6CD5 969E 018F DE6C DCA1
>   created : [snip]
> Encryption key: 2E0F 8C51 BC77 58A3 3795  79D9 26F7 563E 73A3 3BEE
>   created : [snip]
> Authentication key: [none]

BTW, the Application ID includes the unique serial number.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: Questions about OpenPGP best practices

[Doug Barton]

-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 perspective, however I see a couple of
problems with it. First, there is a bootstrapping problem. People new
to PGP almost certainly do not possess the skills to verify the
signature file for the cert, even if they had an appropriate web of
trust to rely on (which obviously they would not).

Second, not using a cert signed by a recognized CA presents 2
problems, it increases the perception that the PGP community is a
closed circle, such that if you don't already have the skills, we
don't want to talk to you. For those new users that click through it
adds further damage to their security habits, since we try to teach
people NOT to do that, even though most people do it anyway.

In the previous era where free and/or low-cost SSL certs were not
available I would have had a lot more sympathy with your position.
However nowadays there are a non-zero number of good choices,
including https://www.startssl.com/ which offers free certs, and has a
good reputation in the community. I personally use them for my sites,
although I have no other affiliation other than "happy 'customer.'"

I hope you'll reconsider your decision.

Doug

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iQEcBAEBCAAGBQJRL+MxAAoJEFzGhvEaGryEmCgH/0d3sZ8fHcuaKKUexTXugSX7
C23zFnSihJZeU3CL4DgcbroRT5dstBOw69/rB1SVCCEukuhcZ/DVfksHj5iKfFxQ
3Jc2skvH8rsFzEnRjrnwcZVowljNQpN9s8hWRMDJGTs8xfIrRoXlgaI3eukOGpGv
DesttA2GKAMq9NJIm2tJ4GgW3CS1f3UQ7G+v301BVnKLfAncAAZ8g2zQCJpZL0UF
mw9JvBa8lP2+jGB8nn2zMGBHMgl2U1ydfcxgcSZejvfZQ+AkujA0PKgcSdo/bgY7
qgRIKwiNVijhu3v0K6m0nkUyLXVV/TsG56uQdeh3XCc1bg3fhg4yd9WGZbNZON8=
=nTWY
-END PGP SIGNATURE-

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

Re: key length for smart card key generation

[Josef Schneider]

On Thu, Feb 28, 2013 at 10:34 PM, Peter Lebbing  wrote:
> On 27/02/13 22:58, Anonymous wrote:
>> So I should be able to import the key...but not use it unless it is
>> 3072 bits or less?
>
> If we're all talking about RSA here, I think so.

Using an 4096 bit RSA key _should_ work if you compile the current
source from the git repository and then _should_ work with 2.0.20 once
that is out!
I didn't have the time to test that yet because I use Windows and
compiling GnuPG 2 for Windows seems to be quite a difficult task!

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

Re: key length for smart card key generation

[Marcos Aurelio Lenharo]

Hi,

if you compile from git repo as Josef said it will work 100% with 4096
bit RSA keys.

Regards,

Marcos A. Lenharo

On 28-02-2013 22:08, Josef Schneider wrote:
> On Thu, Feb 28, 2013 at 10:34 PM, Peter Lebbing  
> wrote:
>> On 27/02/13 22:58, Anonymous wrote:
>>> So I should be able to import the key...but not use it unless it is
>>> 3072 bits or less?
>> If we're all talking about RSA here, I think so.
> Using an 4096 bit RSA key _should_ work if you compile the current
> source from the git repository and then _should_ work with 2.0.20 once
> that is out!
> I didn't have the time to test that yet because I use Windows and
> compiling GnuPG 2 for Windows seems to be quite a difficult task!
>
> ___
> 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