Re: certificate chain depth (technical)

[David Shaw]

On Apr 25, 2009, at 6:27 PM, Raimar Sandner wrote:


On Saturday 25 April 2009 18:27:44 Raimar Sandner wrote:

Hello,

when gnupg trusts a key as a result of trustdb calculations, I would
like to know what the chain depth for the given key is.

[snip]

As of now I can only think of gradually reducing max-cert-depth,
recalculating trustdb and see, if a given key stays fully trusted.
Is there a better way to determin the cert depth? If not, I think
this would be a nice feature to implement.


So as the discussion tends to drift a bit off-topic (no offense), I  
would like

to dedicate this sub-thread to the technical question asked.

Is there some way to determin the certificate depth? I regard it to  
be useful
information, maybe someone else does too. I suppose the value should  
be

present somewhere in the trustdb, just not accessible right now.


The trustdb actually doesn't store per-user ID depth values.  Rather,  
one of the many possible depths is stored for the key as a whole,  
which is fine for our purposes, but may not give you what you want  
here.  Take the case of A signs B(uid1), A signs C(uid1), and C signs  
B(uid2).  B is thus fully valid as per B(uid1) being signed.  But  
B(uid2) is also valid, and at one level of depth larger than B(uid1).   
B as a whole thus lives at both depth 0 and depth 1.  We store this as  
1, but I think you'd want it at 0.


You can see this in action, and perhaps give you the information you  
want, by doing:


  gpg -v -v --check-trustdb.

You will see (along with some other debug info), a bunch of records  
that look like this


0:1234567812345678:K::?
0:1234567812345678:U:::f:::u...@example.com:
0:1234567812345678:U:::m:::u...@example.net:

The first field is the depth.   0 means "signed by an ultimately  
trusted key", and 1 means one step beyond that, etc.

The second field is the key ID
The third field is K for keys and U for user IDs.  You're more  
interested in user IDs here.

The 6th field is the validity:

  q == undefined validity
  f == fully valid
  m == marginally valid

The 9th field is a piece of the user ID string.

You can see some keys appear at multiple depths if a particular user  
ID from that key becomes valid earlier than other user IDs on the key.


David


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

Re: certificate chain depth

[Raimar Sandner]

On Saturday 25 April 2009 22:00:05 John W. Moore III wrote:
> Raimar Sandner wrote:
> > In the end it is of course a people thing whether you trust a key or not,
> > no mathematical model ever can replace your final decision. So there is a
> > big difference in gpg saying "fully trusted" and you thinking "fully
> > trusted".
>
> This is why both Owner Trust & Calculated Trust exist.  One is a
> mathematical result and the other is a Personal evaluation.
>

Well, as I understand those two are quite different. The owner trust refers to 
my personal trust in the _owner_ of a key to correctyl sign other keys. The 
calculated trust refers to the validity of a _key_ (and is of course 
calculated  based on the ownertrust values belonging to the signatures 
attached to this key). So one is trust in a key (here gpg can give a hint) and 
one is trust in people (here gpg cannot say anything). But they are not trust 
values refering to the same thing, one being my opinion and one gpg's.

Greetings,
Raimar

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

Re: certificate chain depth

[David Shaw]

On Apr 25, 2009, at 6:18 PM, Raimar Sandner wrote:


On Saturday 25 April 2009 22:00:05 John W. Moore III wrote:

Raimar Sandner wrote:
In the end it is of course a people thing whether you trust a key  
or not,
no mathematical model ever can replace your final decision. So  
there is a

big difference in gpg saying "fully trusted" and you thinking "fully
trusted".


This is why both Owner Trust & Calculated Trust exist.  One is a
mathematical result and the other is a Personal evaluation.



Well, as I understand those two are quite different. The owner trust  
refers to
my personal trust in the _owner_ of a key to correctyl sign other  
keys.


Yes.


The
calculated trust refers to the validity of a _key_ (and is of course
calculated  based on the ownertrust values belonging to the signatures
attached to this key).


Almost.  The calculated trust actually refers to the validity of a  
given user ID on a given key.  It is possible to have a key with  
multiple user IDs, some of which are calculated to be valid, and some  
of which are not.



So one is trust in a key (here gpg can give a hint) and
one is trust in people (here gpg cannot say anything). But they are  
not trust

values refering to the same thing, one being my opinion and one gpg's.


Yes.  The terminology can get difficult if the term "trust" is used  
for both.  Many people use the words "trust" (aka owner trust or  
personal trust) and "validity" for these two concepts.


David


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

Re: certificate chain depth (technical)

[Raimar Sandner]

On Saturday 25 April 2009 18:27:44 Raimar Sandner wrote:
> Hello,
>
> when gnupg trusts a key as a result of trustdb calculations, I would
> like to know what the chain depth for the given key is.
[snip]
> As of now I can only think of gradually reducing max-cert-depth,
> recalculating trustdb and see, if a given key stays fully trusted.
> Is there a better way to determin the cert depth? If not, I think
> this would be a nice feature to implement.

So as the discussion tends to drift a bit off-topic (no offense), I would like 
to dedicate this sub-thread to the technical question asked. 

Is there some way to determin the certificate depth? I regard it to be useful 
information, maybe someone else does too. I suppose the value should be 
present somewhere in the trustdb, just not accessible right now.

Greetings,
   Raimar

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

Re: Just a thought

[John Clizbe]

Ingo Klöcker wrote:
> On Saturday 25 April 2009, John Clizbe wrote:
>>
>> The message will be encrypted once with a symmetric cipher and
>> session key. Then the session key is encrypted to each recipient's
>> public key and the encrypted session keys are attached to the
>> message.
>>
>> For each recipient the first valid key with matching email address is
>> the one selected. If this is not the preferred key, then Enigmail's
>> Per-recipient rules may be setup to specify the correct key to use.
> 
> How does Thunderbird/Enigmail handle bcc'd recipients? Does it create 
> several differently encrypted copies of the message in case of bcc'd 
> recipients, i.e. one copy of the message encrypted with the keys of all 
> public recipients and additional copies of the message (one per bcc'd 
> recipient) encrypted only with the key of the corresponding bcc 
> recipient (and probably with the sender's key)?

Enigmail passes GnuPG a list of recipients to encrypt to. It does not
generate separate messages, only the one.  This is a constraint of
Thunderbird's architecture.

BCCed recipients are treated as just another recipient. There is only
one copy of the message and one set of encrypted session keys.

If one is going to encrypt *and, at the same time*, use BCC, he should
seriously look at using GnuPG's throw-keyids option. From the man page:

--throw-keyids

--no-throw-keyids
 Do not put the recipient key  IDs  into  encrypted  messages.
 This helps to hide the receivers of the message and is a lim-
 ited countermeasure against traffic analysis.  On the receiv-
 ing side, it may slow down the decryption process because all
 available secret keys must be tried.  --no-throw-keyids  dis-
 ables  this  option.   This option is essentially the same as
 using --hidden-recipient for all recipients.

The other alternative is to manually manage BCC copies. Personally, I'm
not a big fan of BCC.

PS: Rob's comments about how TB's architecture forces Enigmail's
behavior and the suggestion that it should probably be moved are both
correct.
-- 
John P. Clizbe  Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
 mailto:pgp-public-k...@gingerbear.net?subject=help

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"



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

Re: Just a thought

[Robert J. Hansen]

Ingo Klöcker wrote:
> How does Thunderbird/Enigmail handle bcc'd recipients?

Someone else may have a more definitive answer, but I would not
recommend using bcc'd recipients with Enigmail.  Enigmail is constrained
by the Thunderbird architecture, which puts some severe limits on what
Enigmail is allowed to do.  As long as everything is done in one pass
and it's a simple transform of the data, Thunderbird is quite happy to
work with plugins; but as soon as plugins want to do complex things,
Thunderbird says "no."

E.g., with PGP/MIME messages, Enigmail has to go through some
contortions since it doesn't know before the message is composed which
hash algorithm will be used, meaning that it can't craft the PGP/MIME
headers.  So instead, a dummy message is sent (one which goes precisely
nowhere), which Enigmail then reads to see the algorithm used, which is
then used to construct a proper PGP/MIME header for the real message.
It's a pretty repulsive hack, but it's the only game in town.

Please note that I do not follow the Enigmail source tree, so any and/or
all of this may be incorrect.  It is correct as far as I know, though.

This discussion should probably be moved to the Enigmail list.


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

Re: Just a thought

[Ingo Klöcker]

On Saturday 25 April 2009, John Clizbe wrote:
> david wrote:
> > Hi all,
> >
> > Late here in Cyprus, in Thunderbird, OpenPGP I can sign and encrypt
> > - but say I cc'd to a few people - because if those people are in
> > my key ring will it encrypt for each?
>
> If a valid key can be located for each recipient, the message will be
> encrypted to all. If a single recipient cannot be matched with a key,
> the message will be sent in the clear.
>
> The message will be encrypted once with a symmetric cipher and
> session key. Then the session key is encrypted to each recipient's
> public key and the encrypted session keys are attached to the
> message.
>
> For each recipient the first valid key with matching email address is
> the one selected. If this is not the preferred key, then Enigmail's
> Per-recipient rules may be setup to specify the correct key to use.

How does Thunderbird/Enigmail handle bcc'd recipients? Does it create 
several differently encrypted copies of the message in case of bcc'd 
recipients, i.e. one copy of the message encrypted with the keys of all 
public recipients and additional copies of the message (one per bcc'd 
recipient) encrypted only with the key of the corresponding bcc 
recipient (and probably with the sender's key)?


Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Just a thought

[david]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi John,

I took a look at the per recipient rules - thanks for the direction

Regards,

David


John Clizbe wrote:
> david wrote:
>> Hi all,
>>
>> Late here in Cyprus, in Thunderbird, OpenPGP I can sign and encrypt -
>> but say I cc'd to a few people - because if those people are in my key
>> ring will it encrypt for each?
> 
> If a valid key can be located for each recipient, the message will be
> encrypted to all. If a single recipient cannot be matched with a key,
> the message will be sent in the clear.
> 
> The message will be encrypted once with a symmetric cipher and session
> key. Then the session key is encrypted to each recipient's public key
> and the encrypted session keys are attached to the message.
> 
> For each recipient the first valid key with matching email address is
> the one selected. If this is not the preferred key, then Enigmail's
> Per-recipient rules may be setup to specify the correct key to use.
> 

- --
Confidentiality Statement

Wisdom is knowing what to do with what you know. This message and any
attachments are solely for the intended recipient and may contain
confidential or privileged information. If you are not the intended
recipient, any disclosure, copying, use, or distribution of the
information included in this message and any attachments is prohibited.
If you have received this communication in error email
postmas...@gbenet.com. Thank you.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAknzhN4ACgkQYvuE3Ov+SsBOlgCgtjAJH7RVNhsSIXBUa7gcnFVF
DfYAnRIJpythFDUnqW4SqBMGBJ9eYGwt
=k7OR
-END PGP SIGNATURE-

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

Re: certificate chain depth

[Robert J. Hansen]

david wrote:
> it's a value judgement - that over time, changing conditions may not 
> reflect the "trust" one had in regard to the person.

This is why signatures can be revoked.

> I'm not likely to put trust into systems.

Really?  You already have.  For instance, do you have the capability,
right here, right now, to grow or obtain your own food?  If not, then
you're trusting in your local food distribution system.  If it goes out,
then you're in a world of hurt.  Do you have the capability to obtain
potable water?  If not, then you're trusting your water system.

The question is not _if_ you trust, but _who and what_ you trust, and
whether that trust will be a blind trust or an examined trust.  Blind
trust tends to get people in a lot of trouble; examined trust lets you
prepare for what happens if and when that trust is breached.

There's a reason why I have three days of MREs and ten liters of
drinking water in my pantry.  I trust food distribution and I trust my
water system.  And it's because of that trust that I have backups.

On balance, I think it is better to practice examined trust than
unexamined trust.  But that said... I am an advocate of trust.

> or (it just struck me) that I may want to compromise some one 
> (shudder)

Compromise means you have failed to uphold your publicly stated policy.
 If people are able to put you in a position where you have to
compromise your policy, that should be the cause for some soul-searching
about where you erred in your policy.

If your policy is, "I will divulge communications if required to by a
court, or if necessary to prevent lawless action, or to save human
life," and you go out and do just that -- that's not a compromise at all.

> where are we now then? a small group of people that's fairly secure

If by "secure" you mean "my system is not compromisable and my
communications cannot be intercepted," then none of us are secure.  None
of us are even fairly secure by that standard.

Generally speaking, GnuPG gives excellent protection against one
particular part of the communications security profile.  It is not a
comprehensive solution.

If my system is secure and my communications are uncompromised, it is
only because I have not yet risen to the notice of those who have the
power to change it, while I have simultaneously put myself beyond the
likely reach of amateurs.

To the extent there is a "fairly secure" worth talking about, that's it.
IMO, that's not "fairly secure" at all.  It's best to keep a sense of
proportion about these things, and not to fall into a false sense of
security.


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

Re: Just a thought

[david]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Robert J. Hansen wrote:
> david wrote:
>> Late here in Cyprus, in Thunderbird, OpenPGP I can sign and encrypt -
>> but say I cc'd to a few people - because if those people are in my key
>> ring will it encrypt for each?
> 
> Yes, although if you want Enigmail-specific answers you may want to ask
> on the Enigmail list.
> 

Thank you Robert

- --
Confidentiality Statement

Wisdom is knowing what to do with what you know. This message and any
attachments are solely for the intended recipient and may contain
confidential or privileged information. If you are not the intended
recipient, any disclosure, copying, use, or distribution of the
information included in this message and any attachments is prohibited.
If you have received this communication in error email
postmas...@gbenet.com. Thank you.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAknzgS8ACgkQYvuE3Ov+SsDlNgCeNFbd1x1R+wohuxH3X3F0BeJB
O2MAoOpHhQrgsXTq624f+p4CYo1XpFQJ
=Hq28
-END PGP SIGNATURE-

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

Re: Just a thought

[John Clizbe]

david wrote:
> Hi all,
> 
> Late here in Cyprus, in Thunderbird, OpenPGP I can sign and encrypt -
> but say I cc'd to a few people - because if those people are in my key
> ring will it encrypt for each?

If a valid key can be located for each recipient, the message will be
encrypted to all. If a single recipient cannot be matched with a key,
the message will be sent in the clear.

The message will be encrypted once with a symmetric cipher and session
key. Then the session key is encrypted to each recipient's public key
and the encrypted session keys are attached to the message.

For each recipient the first valid key with matching email address is
the one selected. If this is not the preferred key, then Enigmail's
Per-recipient rules may be setup to specify the correct key to use.

-- 
John P. Clizbe  Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
 mailto:pgp-public-k...@gingerbear.net?subject=help

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"



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

Re: Just a thought

[Robert J. Hansen]

david wrote:
> Late here in Cyprus, in Thunderbird, OpenPGP I can sign and encrypt -
> but say I cc'd to a few people - because if those people are in my key
> ring will it encrypt for each?

Yes, although if you want Enigmail-specific answers you may want to ask
on the Enigmail list.

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

Re: certificate chain depth

[david]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Robert J. Hansen wrote:
>> Hi, I don't wish to be over-simplistic, but I had thought that the web
>> of trust was a people thing rather than a mathematical model.
> 
> Honestly, it's a little of one and a lot of the other.  The questions of
> "whom do I trust and why?" is purely a human factor; the questions of
> "... and given I trust them, what can I deduce to be true?" is a
> mathematical question.
> 
>> What is trust anyway?
> 
> Generally, trust is the ability to break someone's security policy.
> 
> E.g., I've given a friend of mine from college, John Hawley, a trusted
> signature.  John can now screw over my local security policy.  If I see
> a key which John has signed, I'm going to assume that key is valid.  If
> John signs keys that aren't valid, he can break my security policy.
> 
> This is why most uses of the phrase "trusted system" give security geeks
> the heebie-jeebies.  A trusted system is, ironically, more dangerous
> than an untrusted system.  An untrusted system has no capability to
> break your security policy; a trusted system can.  That means trusted
> systems often need to be watched like hawks.
> 
> In a similar vein, many Wall Street brokers were trusted with billions
> of client money -- and they should have been watched closely as a result
> of that trust.
> 
I appreciate secure systems - being rigid are apt to get broken or
people break out of them :) just as equally friendships based on common
interests and concerns dissolve - may be there's no trust in keys at
all. it's a value judgement - that over time, changing conditions may
not reflect the "trust" one had in regard to the person. I'm not likely
to put trust into systems.

I appreciate the security of transmitted data and a requirement it's not
going to leak out the edges or that some one's going to compromise
oneself or others - or (it just struck me) that I may want to compromise
some one (shudder) but then we are still making value judgements about
people and who we trust and why we trust them.

It was philosophical - radical politics - enabling people to protect
their privacy - as a driving principle - where are we now then? a small
group of people that's fairly secure - but the principle is for public
world wide use of pgp to safeguard their privacy - with a fair few
intent on breaking it. It's still a people thing - conflicts of
interest, politics, philosophy the ethics or mores that govern how
people interact. What they share - are we to become closed and only open
if a key is trusted by so many? That in itself is a weakness.

Must be the Med sea and the coffee 

Happy Days

David

- --
Confidentiality Statement

Wisdom is knowing what to do with what you know. This message and any
attachments are solely for the intended recipient and may contain
confidential or privileged information. If you are not the intended
recipient, any disclosure, copying, use, or distribution of the
information included in this message and any attachments is prohibited.
If you have received this communication in error email
postmas...@gbenet.com. Thank you.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAknzcywACgkQYvuE3Ov+SsDvLwCgiAPXIx4jJ1qzvjEBm+NVQKtj
3yUAoNWbV6B6GAkK9NKDvVnwRBiJSSn9
=t+1X
-END PGP SIGNATURE-

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

Just a thought

[david]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

Late here in Cyprus, in Thunderbird, OpenPGP I can sign and encrypt -
but say I cc'd to a few people - because if those people are in my key
ring will it encrypt for each?

Some one must have tried it :)

David

- --
Confidentiality Statement

Wisdom is knowing what to do with what you know. This message and any
attachments are solely for the intended recipient and may contain
confidential or privileged information. If you are not the intended
recipient, any disclosure, copying, use, or distribution of the
information included in this message and any attachments is prohibited.
If you have received this communication in error email
postmas...@gbenet.com. Thank you.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAknzeZoACgkQYvuE3Ov+SsBz/wCgvU/ujxYhNmb/qYEKlAHiyzyL
KWwAnAx9Q0XhXb+eed1waj0+bdGykTs4
=vgtz
-END PGP SIGNATURE-

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

Re: certificate chain depth

[John W. Moore III]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Raimar Sandner wrote:

> In the end it is of course a people thing whether you trust a key or not, no 
> mathematical model ever can replace your final decision. So there is a big 
> difference in gpg saying "fully trusted" and you thinking "fully trusted".

This is why both Owner Trust & Calculated Trust exist.  One is a
mathematical result and the other is a Personal evaluation.

JOHN ;)
Timestamp: Saturday 25 Apr 2009, 15:59  --400 (Eastern Daylight Time)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10-svn4987: (MingW32)
Comment: Public Key at:  http://tinyurl.com/8cpho
Comment: Gossamer Spider Web of Trust: https://www.gswot.org
Comment: Homepage:  http://tinyurl.com/yzhbhx

iQEcBAEBCgAGBQJJ82vEAAoJEBCGy9eAtCsPm5QH/RfSaHGZH+edqH37FByiwBJZ
cDLodzPtQZRAy2ylgmjtLoAC7tIllGiNtN21Gj8V398+Iu3xeOboQ0sTKHYa8psq
CarHkh2hrIqusTBgt5L7kUCy83wFwVeezlMiCCSNbQJ1bYTbRtJs7UPe5o4QUDkd
t+dnTauyUZJg5ZoYRkQtdlbDQb9VVA7ehgVsS3SQ7HDzR7Pkk/pPLyaeEQ+LRYv3
hugGcqONscRofURAVSLYuir2dZB8alvud2imI0dYwLlzPVTTNTuWbp/cXHiy0/UM
UZ1YxTDjeJsCElBZwT1/sb79KRUz5OEsOncnKIwCiPOLM3ZL5NVwEA7tDoLMIr8=
=PzT0
-END PGP SIGNATURE-

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

Re: certificate chain depth

[Raimar Sandner]

On Saturday 25 April 2009 20:58:44 david wrote:
> Raimar Sandner wrote:
> > Hello,
> >
> > when gnupg trusts a key as a result of trustdb calculations, I would
> > like to know what the chain depth for the given key is.
[snip]
>
> Hi, I don't wish to be over-simplistic, but I had thought that the web
> of trust was a people thing rather than a mathematical model.

> I can appreciate it's difficult to form a web of trust between people
> that you never meet - like me posting here - the idea I thought was to
> develop such networks through people that one knows - or gets to know
> via  shared contacts - shared experiences - common interests and concerns.

Not over-simplistic, you're definitely right about this. The best thing to do 
still is to go out, sign keys and thus establish trust. But as you say that is 
not always possible in a large community.

In the end it is of course a people thing whether you trust a key or not, no 
mathematical model ever can replace your final decision. So there is a big 
difference in gpg saying "fully trusted" and you thinking "fully trusted".

I think _because_ it's a people thing, feedback from gpg about the depth would 
be nice. Say over time I have added a lot of keys to my keyring, assigned 
ownertrust values, and now encounter a signature, gpg saying "Good signature, 
key fully trusted". I would appreciate an option to see at first glance whether 
gpg takes the key as fully trusted because I signed it or because a friend's 
friend signed it, to help me make a final decission.

The web of trust is a great way to establish some amount of trust into new 
keys when you cannot meet the owner. But I think that maybe gpg could help 
differentiate a bit more between keys introduced through the web of trust and 
keys that I have signed personally, for example by showing the depth level.

> What is trust anyway? Common shared values? How does one measure that
> with the depth of signed keys?

I'd rather say "give a hint about trust" than "measure trust" :)

Greetings
Raimar



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

Re: certificate chain depth

[Robert J. Hansen]

> Hi, I don't wish to be over-simplistic, but I had thought that the web
> of trust was a people thing rather than a mathematical model.

Honestly, it's a little of one and a lot of the other.  The questions of
"whom do I trust and why?" is purely a human factor; the questions of
"... and given I trust them, what can I deduce to be true?" is a
mathematical question.

> What is trust anyway?

Generally, trust is the ability to break someone's security policy.

E.g., I've given a friend of mine from college, John Hawley, a trusted
signature.  John can now screw over my local security policy.  If I see
a key which John has signed, I'm going to assume that key is valid.  If
John signs keys that aren't valid, he can break my security policy.

This is why most uses of the phrase "trusted system" give security geeks
the heebie-jeebies.  A trusted system is, ironically, more dangerous
than an untrusted system.  An untrusted system has no capability to
break your security policy; a trusted system can.  That means trusted
systems often need to be watched like hawks.

In a similar vein, many Wall Street brokers were trusted with billions
of client money -- and they should have been watched closely as a result
of that trust.

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

Re: certificate chain depth

[david]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Raimar Sandner wrote:
> Hello,
> 
> when gnupg trusts a key as a result of trustdb calculations, I would
> like to know what the chain depth for the given key is.
> 
> I know that I can control the maximal acceptable depth with the
> max-cert-depth configuration parameter. I would like to keep the
> default of 5, but it is still a difference regarding the
> trustworthiness of a key if it is frully trusted in, say, third or 
> fifth level.
> 
> Manually following the trust chains can be annoying, and could also
> lead to false conclusions as in the following small example:
> 
> Say we have marginals-needed=2, completes-needed=1 and the web of 
> trust is
> 
> #   me -> A -> E
> #   | \---> D /
> #   \-> B -> C /
> 
> with the ownertrust values
> A: marginal
> D: marginal
> C: marginal
> B: full
> 
> On a first glance one might think as we have the chains me->A->E and
> me->A->D->E, that E is fully trusted in third level. But because D
> only is trusted in third level (me->B->C->D), E is actually trusted
> in fourth level. This rapidly gets more complex with a growing web
> of trust.
> 
> As of now I can only think of gradually reducing max-cert-depth,
> recalculating trustdb and see, if a given key stays fully trusted.
> Is there a better way to determin the cert depth? If not, I think
> this would be a nice feature to implement.
> 
> Cheers, 
> Raimar
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

Hi, I don't wish to be over-simplistic, but I had thought that the web
of trust was a people thing rather than a mathematical model.

I can appreciate it's difficult to form a web of trust between people
that you never meet - like me posting here - the idea I thought was to
develop such networks through people that one knows - or gets to know
via  shared contacts - shared experiences - common interests and concerns.

What is trust anyway? Common shared values? How does one measure that
with the depth of signed keys?

Ok so I'm being a bit philosophical

Best Wishes :)

David
- --
Confidentiality Statement

Wisdom is knowing what to do with what you know. This message and any
attachments are solely for the intended recipient and may contain
confidential or privileged information. If you are not the intended
recipient, any disclosure, copying, use, or distribution of the
information included in this message and any attachments is prohibited.
If you have received this communication in error email
postmas...@gbenet.com. Thank you.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAknzXV4ACgkQYvuE3Ov+SsB4YgCg0aogBZ7fsuSw+Jyotn2PMofX
E1gAnAlaa+501bbdFVx8Lbvqat/kvIpW
=q/xg
-END PGP SIGNATURE-

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

certificate chain depth

[Raimar Sandner]

Hello,

when gnupg trusts a key as a result of trustdb calculations, I would
like to know what the chain depth for the given key is.

I know that I can control the maximal acceptable depth with the
max-cert-depth configuration parameter. I would like to keep the
default of 5, but it is still a difference regarding the
trustworthiness of a key if it is frully trusted in, say, third or 
fifth level.

Manually following the trust chains can be annoying, and could also
lead to false conclusions as in the following small example:

Say we have marginals-needed=2, completes-needed=1 and the web of 
trust is

#   me -> A -> E
#   | \---> D /
#   \-> B -> C /

with the ownertrust values
A: marginal
D: marginal
C: marginal
B: full

On a first glance one might think as we have the chains me->A->E and
me->A->D->E, that E is fully trusted in third level. But because D
only is trusted in third level (me->B->C->D), E is actually trusted
in fourth level. This rapidly gets more complex with a growing web
of trust.

As of now I can only think of gradually reducing max-cert-depth,
recalculating trustdb and see, if a given key stays fully trusted.
Is there a better way to determin the cert depth? If not, I think
this would be a nice feature to implement.

Cheers, 
Raimar

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

Re: Help with encrypting using my PGP Public key

[David Shaw]

On Apr 24, 2009, at 3:07 PM, David Shaw wrote:


On Apr 24, 2009, at 12:40 PM, bkumfer wrote:



Thanks for your help.  To create the key, I followed the

--gpg -gen-key command - used key length of 1024 bits.


I examined this key and there is nothing particularly unusual about  
it.   The only thing that jumps out (and this is a reach) is that  
the Elgamal encryption subkey is rather small.  It's possible  
(though odd) that the bank is configured to disallow keys of that  
size.  If it is easy for you to try different keys with the bank,  
try making and submiting one with a 2048 bit subkey (i.e. gpg --gen- 
key, select option 1, then enter 2048).


I'll check it against the PGP command line product later (the  
virtual machine it runs on is not powered on right now).


I've checked it and it works just fine.  I'm able to encrypt to it  
without any problems.


I'm afraid that doesn't leave you with a good answer, though.  I don't  
think it will help, but it's worth trying making a larger key, as I  
suggest above.  Aside from that, your bank or whoever you are  
communicating with needs to give you some more information about why  
this is failing.


David


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

Re: Libgcrypt on gpg 2.0.11 under Linux Ubuntu Jaunty 9.04_64bits

[Charly Avital]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Werner Koch wrote:
[...]

>   LD_LIBRARY_PATH=/usr/loca/bin gpg2

I did LD_LIBRARY_PATH=/usr/local/bin/gpg2 [assuming some mistypes ;)]

And I have now:

$ gpg2 --version
gpg (GnuPG) 2.0.11
libgcrypt 1.4.4
[.]


Thank you Werner.
Charly
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: GnuPG for Privacy
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBCAAGBQJJ8yT3AAoJEM3GMi2FW4PvX9IH/R+ZJMe5lWvGJ1kGfxMBg+/T
TncKAaCxLseJOyRm0VQ6jQj4pUHD+Mzw/DbdMIKvPsN2TELwISqI49PJHQ2I0Mdl
EOI8iP7JjMQdWkWR4772Se9DZi00B8YmiBzhsIV0p1hcS02H6w9CaScXl+fIa0ZJ
um8GPeKC7DLEg3mJ/LTRF47exxys8adkMPpkiFhUEgcyuTMPKjWG4HdeqEwxXSwf
m6K8i00Y9XbLoxfrrakGc0orN/80+D/1ptc0WvlOE+1aYuddGx5pQ8/Zu14X0oxd
7i+ZvhkJup+RleDXyguQjxgJYYQpn9VP//g0S8ZoyazdDC6L6DsV1T9ehGjqazU=
=0deX
-END PGP SIGNATURE-

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

Re: Troubleshooting signatures

[Robert J. Hansen]

allen.schu...@gmail.com wrote:
> First. Does the trust warning screw up FireGPG's signature validity or
> am I missing something else? Second, is this the normal reaction from
> GnuPG v1.4.9?

Can't answer re: FireGPG.  However, this is _a_ normal reaction, but not
_the_ normal reaction.

If you got a signature that purported to be from ob...@whitehouse.gov,
and it was signed with a key that purported to be from
ob...@whitehouse.gov, would you actually believe it was from President
Obama?  Or would you say, "wait a minute, /anyone/ can pretend to be
/anyone/ on the internet, I need some confirmation before I'll actually
believe the President is sending me an email"?

That's what GnuPG is warning you about.  There is no evidence the key
really belongs to the person it claims to whom it claims to belong.
Maybe it does, maybe it doesn't, there's no evidence either way.


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

Re: Libgcrypt on gpg 2.0.11 under Linux Ubuntu Jaunty 9.04_64bits

[Werner Koch]

On Sat, 25 Apr 2009 11:36, shavi...@mac.com said:

> In spite of compiling and installing twice libgcrypt 1.4.4, compiling
> and installing again 2.0.11, and logging out/in, I still get 
>
> libgcrypt 1.4.1 in:

You probably installed libgcrypt under /usr/local and thus you need to
tell your system wfrom where to take it. Either

  LD_LIBRARY_PATH=/usr/loca/bin gpg2

or modify your /etc/ld.so.conf

I assume that you build against 1.4.4; if you did not install the
libgcrypr11-dev package from Ubuntu that should be the case.  It should
not matter anyway.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.


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

Troubleshooting signatures

[allen . schultz]

Ok. I'm getting a wierd signature verification message in two programs and I 
have a few questions. First the situation.

Inline signatures received from more than one person. Recently checked Godwin Stewart's 
signature (0xD769AF76) first with FireGPG. It is giving me a flat out "Wrong 
signature". When I copy to clipboard and tried with WinPT (Using Windows 7), it gave 
me the following status below.

Signature is good. Warning: This key is not certified with a trusted signature! 
There is no indication that the signature belongs to the owner.

First. Does the trust warning screw up FireGPG's signature validity or am I 
missing something else? Second, is this the normal reaction from GnuPG v1.4.9?

Any help in understanding this would be helpful.

--
Allen Schultz 



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

Re: Bad signatures on Gmail messages

[Werner Koch]

On Fri, 24 Apr 2009 17:55, jbr...@me.com said:

> Any estimation of when GPGOL will be compatible with Outlook 2007? I noticed 
> on your web site that it's in progress.

I have nor checked the last versions but the new GpgOL usually works on
OL 2007.  The ribbon bar or whatever it is called puts the buttons into
a another area but aside from that I never had problems.  My testbox is
Vista with OL2007 but Marcus runs his tests with XP and OL2007.

There is on reported problem which Vista which is probably due to the
symlink like feature.  That is related to GnuPG in general but I was not
able to duplicate the problem.

There are two main drawbacks: The user interface, based on KDE, has some
minor problems and the alternative interface based on GPA is probably
lacking some features.  The second problem is that sending mails with
Exchange does not anymore/yet work.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.


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

Re: --encrypt-to usage

[Robert J. Hansen]

Matthew Krotzer wrote:
>   I've recently started using Gnupg and public key encryption
>   in general. In my research I believe I've read that the
>   --encrypt-to option is a bad idea because it creates another
>   option for an attacker. If the attacker has either key,
>   then they can decode what was sent to the recipient.

There is a lot of very bad advice out there.  This idea is an example of it.

The more people who know a secret, the more likely it is that secret
will get out.  That's a weakness in human beings, not a weakness in the
cryptosystem.

So long as you trust that your correspondents are using GnuPG safely and
correctly, and you trust they're not working with your enemies, use
--encrypt-to with confidence.

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

--encrypt-to usage

[Matthew Krotzer]

Hello,

I've recently started using Gnupg and public key encryption
in general. In my research I believe I've read that the
--encrypt-to option is a bad idea because it creates another
option for an attacker. If the attacker has either key,
then they can decode what was sent to the recipient.

Is the usage of this common and acceptable or should I avoid
it like the plague? 

Matthew Krotzer



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

Libgcrypt on gpg 2.0.11 under Linux Ubuntu Jaunty 9.04_64bits

[Charly Avital]

Hi,

compiled 2.0.11 from source, on a freshly installed and updated copy of
Ubuntu 9.04_64 bits.

All required libraries were also compiled and installed, including
libgcrypt 1.4.4, before compiling 2.0.11.

In spite of compiling and installing twice libgcrypt 1.4.4, compiling
and installing again 2.0.11, and logging out/in, I still get 

libgcrypt 1.4.1 in:

$ gpg2 --version
gpg (GnuPG) 2.0.11
libgcrypt 1.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB


TIA for suggestions.
Charly





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