On Monday 14 April 2008 at 23:42:43 Herbert Furting wrote:
If the new UID just contains a new email address, you should really
check if the keyholder controlls that email address.
You can do so, by sending him an encrypted challenge.
Ah, thanks, that makes sense. And then I can sign his new
Robert J. Hansen (15.04.2008 06:06):
... Rijndael is AES, incidentally. Rijndael was the name it was
submitted under to the AES competition. Once it was chosen as the
winner, it became AES. And yes, I have seen people passionately
advocating for the inclusion of Rijndael in OpenPGP, despite
On Tue, Apr 15, 2008 at 3:43 AM, Robert J. Hansen [EMAIL PROTECTED] wrote:
While this doesn't make sense (nothing is bound to the key) it
wouldn't hurt either.
It violates a de-facto standard. That hurts.
Don't see why,.. but... however.
I just think, that an implementation should not
2008/4/15 Peter Lewis [EMAIL PROTECTED]:
Ah, thanks, that makes sense. And then I can sign his new UIDs too? Or just
change their trust level?
You'll have to sign his new UIDs, too.
What you could to is do issue a so called non-exportable (gpg uses the
term local, iirc) signature.
That means
Hi,
On Tue, Apr 15, 2008 at 12:42:43AM +0200, Herbert Furting wrote:
On Mon, 2008-04-14 at 23:20 +0100, Peter Lewis wrote:
Ah yes, thanks. So I have now set the owner-trust for his key to full,
but
still it says unknown for the other UIDs. So, I should manually set the
trust for keys
On Tuesday 15 April 2008 at 12:39:43 Herbert Furting wrote:
gpg uses a so called trust modell (there ary actually several
different), where you can each UID/key an specific amount of trust.
You can give:
n Never trust this key.
m Marginally
Herbert Furting schrieb:
Ah you think cryptography is engineering? Always thought it would be math.
Implementing crypto is purest engineering.
Not even algorithm design is pure math if you think of timing or power
consumption attacks that might have to be considered.
Anyway if we always
Herbert Furting schrieb:
But imagine the following:
Yours: 3DES, AES256
Mine: AES256, 3DES
Which one is chosen now? But when I only include AES256 I can at least
somewhat control it.
If *you* send, it is AES; if RJH sent, it would be 3DES.
It doesn't matter if your key indicates a
Herbert Furting wrote:
If the new UID just contains a new email address, you should really
check if the keyholder controlls that email address.
You can do so, by sending him an encrypted challenge.
[another newbie here]
I don't understand this. If a public key has a UID1, which I already
Herbert Furting wrote:
The standard allows for terabit RSA keys. Should GnuPG allow them?
Yes why not,... but only in an expert mode.
You may want to consider re-reading your answer a few times and asking
yourself, why do I feel this way, and why do other people feel the way
they do? It
First of all,... unfortunately Chris forgot to CC the list (at least
it seems so). So I post his answer again:
On Tue, Apr 15, 2008 at 12:21 PM, Michael Kesper [EMAIL PROTECTED] wrote:
I remember Werner saying that this was just nonsense.
Werner, can you correct me if I'm wrong?
Well this is
Stan Tobias schrieb:
If a public key has a UID1, which I already
trust, and a new UID2 is added, why can't I infer trust for the new uid?
(...)
So the
only person that could have added UID2 is the one that is in control of
UID1 (supposedly, it's the same person). Why is there a need to check
On Tue, Apr 15, 2008 at 3:03 PM, Robert J. Hansen [EMAIL PROTECTED] wrote:
One of the best techniques available to us for controlling complexity in
software--and definitely the simplest--is to take a chainsaw to the
feature list. Go through the specification and copy down every single
On Tuesday 15 April 2008 at 14:11:48 Sven Radde wrote:
Stan Tobias schrieb:
If a public key has a UID1, which I already
trust, and a new UID2 is added, why can't I infer trust for the new uid?
(...)
So the
only person that could have added UID2 is the one that is in control of
UID1
Why? Just because new (perhaps incompatible) features are added in
newer versions,... nobody has to use that newer versions, right?
If you put GnuPG 3.0 available for download, everyone who's looking for
the latest release will grab it. The people who are quite happy with
1.2, 1.4 or 2.0
Peter Lewis schrieb:
Because you do not know whether the owner of UID1 is also the owner of
UID2.
Let's say, someone trusts my key and my user-id on that key.
Now, I add another ID: Stan Tobias [EMAIL PROTECTED]...
No good idea to trust that without checking, is it?
But isn't that the
Hi All,
Currently we are using GnuPG 1.4.7 which is under GPL V2 on HP-UX ,but we came
to know that there is a security vulnerability on GnuPG 1.4.8 earlier
version.Since Gnupg 1.4.9 is under GPL V3 we don't want to move to product
under GPL v3.Can you please tell us if it is permissible
Herbert Furting wrote the following on 4/15/08 9:38 AM:
Well but if Peter Lewis [EMAIL PROTECTED] adds a new UID Stan
Tobias [EMAIL PROTECTED] you obviously can't sign it, because the
keyholder is Peter Lewis and not Stan Tobias.
hf
To add a new UID, whichever it is, wouldn't Peter Lewis
On Tue, 15 Apr 2008 15:03, [EMAIL PROTECTED] said:
This is how GnuPG was developed, by and large. In the very early days,
GnuPG supported only the bare minimum necessary to conform to the RFC.
Features like Twofish support were not added until the MUSTs were well
Actually GnuPG predates
Hi!
Am Dienstag, den 15.04.2008, 11:03 -0500 schrieb John Clizbe:
There is nothing to backport. David Shaw answered this exact same post last
Friday on both GnuPG-Users and GnuPG-Devel.
I felt already last Friday that this was only a partial answer to the
question.
Although it might not be
On Tue, 2008-04-15 at 17:09 -0400, David Shaw wrote:
Change your preferences and GPG will make a new selfsig for you. No
source hacking needed.
Yes but ok let me explain what I want or would like to have ;-)
My current key has the following layout:
***[Pub key packet]***
***[UID]***
On Tue, Apr 15, 2008 at 02:31:07AM +0200, Herbert Furting wrote:
On Mon, 2008-04-14 at 18:06 -0500, Robert J. Hansen wrote:
1. You didn't ask for the option to allow zero-length UIDs. If you'd
asked for that option, I would have given it. You asked why does
GnuPG have a minimum
On Mon, Apr 14, 2008 at 11:22:59PM +0200, Herbert Furting wrote:
While the standard seems to allow this,.. gpg does not (it won't sign a
UID
when the a self-sig has been revoked before).
How can I solve this?
GPG allows this. Add --expert to your command line when you want to
On Mon, Apr 14, 2008 at 08:43:14PM -0500, Robert J. Hansen wrote:
Herbert Furting wrote:
gpg is probably THE main implementation of OpenPGP (sorry to the
commercial PGP folks ;) ),... as such I think it should support most
of the stuff from OpenPGP, or not?
Depends on who you ask. A
On Tue, Apr 15, 2008 at 08:40:17AM -0500, Robert J. Hansen wrote:
Why? Just because new (perhaps incompatible) features are added in
newer versions,... nobody has to use that newer versions, right?
If you put GnuPG 3.0 available for download, everyone who's looking for the
latest release
On Tue, 2008-04-15 at 18:04 -0400, David Shaw wrote:
It will work with GPG. I can't speak for other programs, but it's
legal by the spec, so it should work everywhere.
Mind you, you're going to hurt yourself, but it's legal by the spec.
Ok this I've already asked everything in my previous
Sven Radde wrote:
Am Dienstag, den 15.04.2008, 11:03 -0500 schrieb John Clizbe:
There is nothing to backport. David Shaw answered this exact same post last
Friday on both GnuPG-Users and GnuPG-Devel.
I felt already last Friday that this was only a partial answer to the
question.
Although
27 matches
Mail list logo