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 ne
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, desp
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 sho
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 me
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
> > tru
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 Marginall
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 say
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 preference
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 m
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 i
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
a
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
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 won'
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
1) This is the cost of advance...
2) btw: I've never said that one mustn't provide backward compatibility.
Of course there are things that would break that (e.g. use something
else than SHA1 for fingerprints) but my ideas about how to interpret
the standard, and where to put some subpacktes wouldn'
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
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.
Mark H. Wood schrieb:
The safest thing for gpg to assume
is that I assign no trust at all until I have instructed it
otherwise.
AFAIK this is the default behaviour, isn't it?
You have the option of specifying "trusted introducers" (i.e. keys
signed by those are automatically considered valid by
On Tue, Apr 15, 2008 at 01:23:01PM +0100, Peter Lewis wrote:
> So I guess my question is: is this a guide for me, and then I should manually
> set the trust level on key F myself (if I am satisfied that the chains
> exist), or should gpg do this automatically for me based on the parameters in
>
On Tue, Apr 15, 2008 at 4:56 PM, Sven Radde <[EMAIL PROTECTED]> wrote:
>[snip snap]
Well said :)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 P
On Tuesday 15 April 2008 at 15:05:45 Sven Radde wrote:
> Signing a new UID with the same key that was used to sign another UID
> proves that the same person that created the first UID created the
> second one.
> It does not prove that the person controls (or, is identified by) the
> second UID.
>
>
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 Op
Debabrata Das wrote:
> 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
On Tue, Apr 15, 2008 at 04:09:51PM +0100, Peter Lewis wrote:
> Please excuse one final question: I have signed keys with one person (A),
> whom
> I trust fully, and he has signed keys with another person (B), whom I know,
> but with whom I have not signed keys. B's key is (correctly) showing as
On Tue, Apr 15, 2008 at 09:37:45AM -0400, Mark H. Wood wrote:
> On Tue, Apr 15, 2008 at 01:23:01PM +0100, Peter Lewis wrote:
> > So I guess my question is: is this a guide for me, and then I should
> > manually
> > set the trust level on key F myself (if I am satisfied that the chains
> > exist)
On Tue, Apr 15, 2008 at 02:13:51PM +0200, Stan Tobias wrote:
> 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 her
On Tue, Apr 15, 2008 at 02:33:08PM +0100, Peter Lewis wrote:
> 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
>
On Tue, Apr 15, 2008 at 12:21:43PM +0200, Michael Kesper wrote:
> 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
> > > stil
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, Apr 15, 2008 at 03:10:47PM +0200, Herbert Furting wrote:
> To say it short: In my opinion every information that you sign/certify
> should be actually validaded.
> It probably makes even sense to check if a keyholder specified all of
> his given names,... and perhaps one shouldn't sign UIDs
On Tue, 2008-04-15 at 14:09 -0400, David Shaw wrote:
> On Tue, Apr 15, 2008 at 03:10:47PM +0200, Herbert Furting wrote:
> > To say it short: In my opinion every information that you sign/certify
> > should be actually validaded.
> > It probably makes even sense to check if a keyholder specified all
On Tue, 2008-04-15 at 13:45 -0400, David Shaw wrote:
> If someone wants to sign your key, you then end up with:
>
> KEY + UID + SELFSIG + SIG
>
Nicely illustrated,.. but let me please add (I know of course that _you_
know this) that the SIG is made only over the KEY+UID data,... thus the
keyhol
On Tue, Apr 15, 2008 at 09:27:26PM +0200, Christoph Anton Mitterer wrote:
> On Tue, 2008-04-15 at 13:45 -0400, David Shaw wrote:
> > If someone wants to sign your key, you then end up with:
> >
> > KEY + UID + SELFSIG + SIG
> >
> Nicely illustrated,.. but let me please add (I know of course tha
On Tue, 2008-04-15 at 16:43 -0400, David Shaw wrote:
> Yes indeed. OpenPGP even expects users to change their SELFSIGs
> occasionally - the preferences and other UID-specific information is
> stored there, so a change to preferences means a change in SELFSIG.
Yeah,.. I just try to browse to the so
On Tue, Apr 15, 2008 at 11:03:43PM +0200, Herbert Furting wrote:
> On Tue, 2008-04-15 at 16:43 -0400, David Shaw wrote:
> > Yes indeed. OpenPGP even expects users to change their SELFSIGs
> > occasionally - the preferences and other UID-specific information is
> > stored there, so a change to pref
Dear David.
On Tue, 2008-04-15 at 16:41 -0400, David Shaw wrote:
> It is irrelevant to this. There are a lot of "David Shaw"s in the
> world, and it's pointless to try and prevent collisions in a set that
> large. The disambiguation in OpenPGP keys is really the email
> address, not the name.
H
On Tue, Apr 15, 2008 at 09:36:04PM +0200, Herbert Furting wrote:
> On Tue, 2008-04-15 at 14:09 -0400, David Shaw wrote:
> > On Tue, Apr 15, 2008 at 03:10:47PM +0200, Herbert Furting wrote:
> > > To say it short: In my opinion every information that you sign/certify
> > > should be actually validade
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]***
***[0x
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 m
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 y
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 as
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 relea
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
Dear David.
On Tue, 2008-04-15 at 17:54 -0400, David Shaw wrote:
> > > A specification does not set a high-water mark for implementations. It
> > > sets a low-water mark. Implementations are free to restrict keys in any
> > > way they want, so long as the low-water mark is met. If you want to
>
Christoph Anton Mitterer wrote:
> But it does not say that it has to contain the must-have algos.
As has been mentioned here at least twice now, see section 13.2, where
it explicitly says if the MUSTs are not listed, they are tacitly listed.
I do not understand how much clearer I can make this.
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.
> A
Hi!
Am Dienstag, den 15.04.2008, 20:35 -0500 schrieb Robert J. Hansen:
> > Even if those subpacktes would be used in my suggested way, each
> > implementation would know "Nanana, 3DES is a fallback, so in each case I
> > can find my algorithm match", but in addition to that a user could force
> >
50 matches
Mail list logo
