On Tue, May 29, 2012 at 10:03:57PM -0400, Robert J. Hansen wrote:
There may be a use case for contextualization in certificates, but if so
I haven't found it yet. :)
You may wnat to lookup up all certificates that signed a certificate.
Or just get all your certificates displayed.
Or all
On May 29, 2012, at 1:26 PM, Werner Koch wrote:
Hi,
I can't remember whether I announced it, but since some weeks
keys.gnupg.net is a CNAME to pool.sks-keyservers.net
and
http-keys.gnupg.net is a CNAME to ha.pool.sks-keyservers.net
The reason for this change is that it is
On 05/30/2012 09:40 AM, Mark H. Wood wrote:
Oh, how many times have I wondered why GPA has no search tool.
Taking a look at GPA, it seems that 0.9.0 no longer compiles on a modern
UNIX -- it expects libassuan-1.x, apparently, and libassuan's now in a
version 2.
I wasn't able to get the git
On Wed, 30 May 2012 16:16, r...@sixdemonbag.org said:
On 05/30/2012 09:40 AM, Mark H. Wood wrote:
Oh, how many times have I wondered why GPA has no search tool.
Taking a look at GPA, it seems that 0.9.0 no longer compiles on a modern
UNIX -- it expects libassuan-1.x, apparently, and
The new download site is
ftp://ftp.gnupg.org/gcrypt/gpa/
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
On 05/29/2012 11:35 AM, Werner Koch wrote:
Use
gpg --keyid-format long --decrypt sensitive_file.gpg
to see the non-abbreviated key ID as stored in the file. Use this to
find the key on a server, etc.
i've seen a lot of these mistakes where people seem to think that 32-bit
keyids are
Am Di 29.05.2012, 11:51:06 schrieb Daniel Kahn Gillmor:
I think switching the default to long would be on balance a Good Thing.
A smaller change which should solve most of these problems could be to
change the error message. If gpg is operating with the short format then a
respective hint
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2012-05-29 17:51, Daniel Kahn Gillmor wrote:
On 05/29/2012 11:35 AM, Werner Koch wrote:
...
I think switching the default to long would be on balance a Good
Thing.
I agree, and don't see much of a reason not to use a long KeyID rather
On 5/29/12 11:51 AM, Daniel Kahn Gillmor wrote:
Perhaps GnuPG should change the default of --keyid-format from short
to long?
Hurts interoperability. Once someone learns the process on PGP or
BouncyCastle or [insert OpenPGP implementation here], they're going to
want to take those same skills
On Tue, 29 May 2012 18:31, r...@sixdemonbag.org said:
Honestly, this seems like something to bring up to the IETF WG. The RFC
already has a plethora of implementation recommendations: adding an
implementation recommendation of use long key IDs when possible seems
I bet that this will
On 5/29/2012 10:18 AM, Werner Koch wrote:
Hiding the keyID from the user would even be better - the mail
address should be sufficient for 99% of all users.
I use the e-mail address for almost all of my command-line work, FWIW.
--
If you're never wrong, you're not trying hard enough
Hi,
I can't remember whether I announced it, but since some weeks
keys.gnupg.net is a CNAME to pool.sks-keyservers.net
and
http-keys.gnupg.net is a CNAME to ha.pool.sks-keyservers.net
The reason for this change is that it is useless to spend a lot of work
in maintaining such a second
On 5/29/12 1:18 PM, Werner Koch wrote:
Frontends should handle this problem.
The problem is that most people developing front ends are making them
pretty darn user-hostile.
A few years ago while taking some HCI courses, I did a usability study
on the most common certificate interface -- the
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
On 05/29/2012 11:35 AM, Werner Koch wrote:
Use
gpg --keyid-format long --decrypt sensitive_file.gpg
to see the non-abbreviated key ID as stored in the file. Use this to
find the key on a server, etc.
i've seen a lot of these
On May 29, 2012, at 1:18 PM, Werner Koch wrote:
On Tue, 29 May 2012 18:31, r...@sixdemonbag.org said:
Honestly, this seems like something to bring up to the IETF WG. The RFC
already has a plethora of implementation recommendations: adding an
implementation recommendation of use long key
On Tue, May 29, 2012 at 1:47 PM, David Shaw ds...@jabberwocky.com wrote:
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
What is your concern here, though - accidental or intentional collision?
Certainly both; while accidental collision isn't probable, 32-bit IDs
aren't exactly
On May 29, 2012, at 2:05 PM, Sam Whited wrote:
On Tue, May 29, 2012 at 1:47 PM, David Shaw ds...@jabberwocky.com wrote:
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
What is your concern here, though - accidental or intentional collision?
Certainly both; while accidental
On Tue, 29 May 2012 19:44, r...@sixdemonbag.org said:
Anyway. If people are interested in what I found out about effective
user-interface design with respect to certificate managers, say the
word. Otherwise I'll crawl back under my rock and leave the subject
GPA has many different ways to
On 05/29/2012 02:18 PM, David Shaw wrote:
The reason I bring it up is that using the v3 key attack, 64-bit key IDs have
no particular benefit over 32-bit IDs for intentional collisions (i.e. an
attacker generating a key with the same key ID as the victim in order to
confuse matters and/or
On 5/29/12 3:23 PM, Werner Koch wrote:
However, changing such a common UI might result in a
lot of negative comments - people love what they once learned.
Absolutely. The good news, though, is that (at least in the Free
Software world) the 'market' is fragmented. No one particular key
manager
On May 29, 2012, at 3:34 PM, Daniel Kahn Gillmor wrote:
On 05/29/2012 02:18 PM, David Shaw wrote:
The reason I bring it up is that using the v3 key attack, 64-bit key IDs
have no particular benefit over 32-bit IDs for intentional collisions (i.e.
an attacker generating a key with the same
On Tue, 29 May 2012, Robert J. Hansen wrote:
. . .
Tabular data is the Right Thing To Do in two major use cases.
The first is when you have a noninteractive display of identical
field(s) for multiple pieces of data. Consider a printed almanac: if it
wants to convey a list of countries and
On 5/29/12 9:57 PM, reynt0 wrote:
In general, being able to examine variation of content within
uniformity of structure is also a way to legitimate the
specific content of interest.
As I said, it's useful when data must be contextualized. For a
spreadsheet, the information in one row must be
23 matches
Mail list logo
