Re: unsubscribe

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Wednesday 6 November 2013 at 7:46:50 AM, in
,
Griffin Cheng [CLIB] wrote:



> [nothing]



I thought "subscribe" and "unsubscribe" and "help" requests went to




- --
Best regards

MFPAmailto:expires2...@ymail.com

If you are afraid to speak against tyranny, then you are already a slave.
-BEGIN PGP SIGNATURE-

iPQEAQEKAF4FAlJ8KVVXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0
N0VDQTAzAAoJEKipC46tDG5p5dcD/2dPvtp9IU1WQfDKDIyjHk9G4yn3pj7dLglH
y9+oGbrBouymtRIA+sNiN67XobrZn3iFzsb3XdKYddTrda/T1ST+qZdR0TY8CGjo
lr0jnSvVgXqdobo2rOjfu7hg9BIa4pH85jtzyAuq1uy2yuUuiV0f+gKxkToA2Wxd
aJmk7s3y
=pY0R
-END PGP SIGNATURE-


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

Re: trust your corporation for keyowner identification?

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Thursday 7 November 2013 at 7:10:11 PM, in
, Leo Gaspard wrote:


> But I still wonder how one should deal with key
> duplication (ie. owner of K1 now has a second key
> K2)...

If the owner doesn't revoke one, you could always disable one.

One approach might be to contact the owner and ask which key to use.
Or use the newest available key. Or just pick at random. Or encrypt to
both. Or use whichever the owner seems to use themself.

But they might have multiple keys for a reason, such as purpose of
communication. Or one for their phone and another for their computer.


- --
Best regards

MFPAmailto:expires2...@ymail.com

Volvo, Video, Velcro. (I came, I saw, I stuck around.)
-BEGIN PGP SIGNATURE-

iPQEAQEKAF4FAlJ8KGhXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0
N0VDQTAzAAoJEKipC46tDG5pP6QEALCiKSGC/EnSauln6vySoDer3fua90MUrsGN
ymE70UZ/f7tpe2GfPt7pMiMoLxXubxKXWRK0soSDk77E+FoQlN98jMVt9pwrd+dZ
BFvlIXCJHyIQml4njLn9cOtlnAqY4MAMkPKVMEbTNQOChZRokQylQIFfby4M+D7v
J6nj6a8O
=vTwh
-END PGP SIGNATURE-


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

Re: gpgsm and expired certificates

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Thursday 7 November 2013 at 11:16:36 AM, in
, Uwe Brauer wrote:




> However it is not necessary I just export our signature
> as a pem file and import in under authorities. Still
> this is very uncomfortable...

I had to search for and import some more root certificates from the
Comodo website before I could encrypt to you using my mailer's
built-in s/mime.

Microsoft Crypto-API no use, even after your and comodo's certificates
imported into certmgr.msc. I'm probably doing something wrong there,
but it's not clear what to do.

For something that is supposed to be easier than OpenPGP, s/mime
doesn't seem easy to me.


- --
Best regards

MFPAmailto:expires2...@ymail.com

My mind works like lightning... one brilliant flash and it's gone
-BEGIN PGP SIGNATURE-

iPQEAQEKAF4FAlJ8IW9XFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0
N0VDQTAzAAoJEKipC46tDG5p2hIEAJuUrJYztL/8jLXZ525+nGHHzIkKtXDUOTDn
o1DtWyAYMd0UDhAaJsK4aZl5KeiyP+AwjPSAtQExFwz8pg4ywhMx0SUC/3PcmmEs
BlxHRXOhf31d71ndv0gTu1XFVi/2N1dfXZSlI4DO0iOICgnNqIWubwsxkuA8zzBd
3q/j95//
=V2Ln
-END PGP SIGNATURE-


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

Re: Signing keys on a low-entropy system

[Leo Gaspard]

(Failed again to answer to list. I really ought to replace this shortcut...)

On Fri, Nov 08, 2013 at 12:11:38AM +0100, Johannes Zarl wrote:
> Hi,
>
> I'm currently thinking about using a raspberry pi as a non-networked stand-
> alone system for signing keys. Since I haven't heard anything to the contrary,
> I'm pretty sure that entropy is relatively scarce on the pi.

I heard haveged is quite good at gathering entropy from anywhere it can
(processor cycles, etc.)

> How is GnuPG affected by such a low-entropy system? Will operations just take
> a bit longer, or can this affect the quality/security of generated keys or
> signatures?
>
> I heard that low entropy or a bad entropy source is generall less of a problem
> for RSA. Is this true? Does this affect me in practice?

In theory, if /dev/random is configured to allow only random enough data to
pass, it should just mean operations would just take longer. However, I am not
absolutely sure of this -- but I know in theory /dev/random ensures some minimum
entropy, thus sometimes blocking reads.

Cheers & HTH,

Leo

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

Signing keys on a low-entropy system

[Johannes Zarl]

Hi,

I'm currently thinking about using a raspberry pi as a non-networked stand-
alone system for signing keys. Since I haven't heard anything to the contrary, 
I'm pretty sure that entropy is relatively scarce on the pi.

How is GnuPG affected by such a low-entropy system? Will operations just take 
a bit longer, or can this affect the quality/security of generated keys or 
signatures?

I heard that low entropy or a bad entropy source is generall less of a problem 
for RSA. Is this true? Does this affect me in practice?

Cheers,
  Johannes

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

Re: question about public key usage

[Doug Barton]

On 11/07/2013 01:02 PM, Smith, Cathy wrote:

Thank you

The earlier answer got caught at the firewall.  I apologize for posting twice.


Np, it happens. :)


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

Re: gpgsm and expired certificates

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Thursday 7 November 2013 at 11:16:36 AM, in
, Uwe Brauer wrote:



> BTW, I see you switched back to pgp, but why do you use
> old inline mode and not pgpmine?

Because I prefer it. I like to see the pgp signature in the message
body instead of hidden away.




- --
Best regards

MFPAmailto:expires2...@ymail.com

Those who do not read are no better off than those who cannot.
-BEGIN PGP SIGNATURE-

iPQEAQEKAF4FAlJ8BO5XFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0
N0VDQTAzAAoJEKipC46tDG5psUsD/iQhZWfXfzbDmVs/8vNg4nFRIZ5IXTb3LRU9
MbiKAdH6V6p55PMQ8/z/qJHBXHbnhacnKUMXPvyK71w5kKAnWb2gZfJivJj36axI
h0btBJjCA3d2899fuODBdON1y+q/VgZLfMA5Uj1ILN9AC8SnDrUHUqGDHzeH1xZm
OMbGJVaC
=5KUo
-END PGP SIGNATURE-


smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

RE: question about public key usage

[Smith, Cathy]

Thank you

The earlier answer got caught at the firewall.  I apologize for posting twice.

Best regards,

Cathy
---
Cathy L. Smith
IT Engineer

Pacific Northwest National Laboratory
Operated by Battelle for the
U.S. Department of Energy

Phone:  509.375.2687
Fax:    509.375.2330
Email:  cathy.sm...@pnnl.gov


-Original Message-
From: Doug Barton [mailto:do...@dougbarton.us] 
Sent: Thursday, November 07, 2013 12:57 PM
To: Smith, Cathy; 'gnupg-users@gnupg.org'
Subject: Re: question about public key usage

On 11/07/2013 12:52 PM, Smith, Cathy wrote:
> Hi
> Is it possible to have 2 public keys with different expiration dates 
> for the same user?  I created a public key a couple of years ago to be 
> used to exchange documents with vendors for a batch processing 
> account.  That is working just fine.  A new vendor wants our public 
> key but requires the key to have a shorter expiration date.  I don't 
> want to distribute a new public key to existing customers.

Someone else already answered this question for you, but the answer effectively 
is "yes," however you don't need to do that.

Edit the expiration date on the existing key to match the requirement for the 
new vendor, and then give them that version of the key. There is no reason to 
have multiple keys in this situation.

hope this helps,

Doug


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

Re: question about public key usage

[Doug Barton]

On 11/07/2013 12:52 PM, Smith, Cathy wrote:

Hi
Is it possible to have 2 public keys with different expiration dates for
the same user?  I created a public key a couple of years ago to be used
to exchange documents with vendors for a batch processing account.  That
is working just fine.  A new vendor wants our public key but requires
the key to have a shorter expiration date.  I don’t want to distribute a
new public key to existing customers.


Someone else already answered this question for you, but the answer 
effectively is "yes," however you don't need to do that.


Edit the expiration date on the existing key to match the requirement 
for the new vendor, and then give them that version of the key. There is 
no reason to have multiple keys in this situation.


hope this helps,

Doug


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

question about public key usage

[Smith, Cathy]

Hi

Is it possible to have 2 public keys with different expiration dates for the 
same user?  I created a public key a couple of years ago to be used to exchange 
documents with vendors for a batch processing account.  That is working just 
fine.  A new vendor wants our public key but requires the key to have a shorter 
expiration date.  I don't want to distribute a new public key to existing 
customers.

Thank you.

Cathy
---
Cathy L. Smith
IT Engineer

Pacific Northwest National Laboratory
Operated by Battelle for the
U.S. Department of Energy

Phone:  509.375.2687
Fax:509.375.2330
Email:  cathy.sm...@pnnl.gov



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

Re: gpgsm and expired certificates

[Uwe Brauer]

>> "MFPA" == MFPA   writes:

Hello

[snip]


   > But all the hordes who use webmail are pretty-much still out of luck,
   > though. (With certain exceptions, such as hushmail.)

Yep, there is penango fore firefox+gmail.


   >> Public
   >> keys are automatically embedded in the signatures.

   > That is simpler and avoids the web-bug-like effect you have if you
   > choose to auto-retrieve OpenPGP keys from keyservers for new contacts.
   > But must waste a lot of bandwidth between regular correspondents.

Well given that a lot of users write emails with html markup, this
really does not bother me.


   >> However thunderbird refuses to use yoru public key
   >> claiming it cannot be trusted.


   > I just searched and found [1] about Thunderbird, which says you can
   > import a copy of other people's self-signed S/MIME certificate from a
   > ".cer" file into your "Authorities" tab. So much for "being easier
   > because keys are automatically embedded in the signatures."

Well I was referring to the following 10 years old bug
https://bugzilla.mozilla.org/show_bug.cgi?id=209182

I have the feeling this is a design decision by  "philosophy":
thunderbird/semonkey don't encourage the use of self-signed certificates
(BTW I just learn that there is a add-on, key-manager which generates
self-signed certificates, similar as it seems to me to the BAT.

At first I thought that I need to use openssl in order to extract your
cert and import in under authorities 
like
openssl pkcs7 -in MFPA.p7 -inform DER -print_certs > out.cert

(Which would be bad, because command line openssl is not what the
average user would call, comfortable and windows users have to install
openssl a part)

However it is not necessary I just export our signature as a pem file
and import in under authorities. Still this is very uncomfortable...

regards

Uwe Brauer 

BTW, I see you switched back to pgp, but why do you use old inline mode
and not pgpmine?


smime.p7s
Description: S/MIME cryptographic signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: trust your corporation for keyowner identification?

[Leo Gaspard]

On Thu, Nov 07, 2013 at 08:10:11PM +0100, Leo Gaspard wrote:
> I'm sorry, I think I gave too much importance to your earlier statement
> ("Signing is to be an attestation to the validity of the key.") [...]

Sorry again, just noticed it actually wasn't you statement, but Paul's !

So, double mistake...

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

Re: trust your corporation for keyowner identification?

[Leo Gaspard]

On Thu, Nov 07, 2013 at 01:40:22PM -0500, Daniel Kahn Gillmor wrote:
> On 11/07/2013 11:09 AM, Leo Gaspard wrote:
> >Except they do not have to know X, nor that he makes perfectly reasonable
> >decisions in signing keys.
> >
> >And I believe it's not noise. Let's make an example in the real world :
> >  * I would entrust X with my life
> >  * X would entrust Y with his life, without my knowing it
> >  * Thus, if I actually entrusted X with my life, why should I be frightened 
> > if X
> >asked Y to take care of me ? Provided, of course, X told me he was 
> > letting Y
> >take care of me. After all, I would entrust X with my life, so I should 
> > just
> >agree to any act he believes is good for me.
> >(That's what I called blind trust. Somewhat more than full trust, I believe.)
> 
> if we're talking about gpg's concept of "ownertrust", please do not muddy
> the waters with "entrust X with my life"?  gpg's "ownertrust" is much more
> narrow than that: it says "I am willing to rely on OpenPGP certifications
> made by the holder of this key".
> 
> "entrust with my life" is not simply a superset of all other trust.  I have
> friends who would take care of me if i was deathly ill.  I would place my
> life in their hands.  But they have never thought about how to do rigorous
> cryptographic identity certification, and I would not rely on their OpenPGP
> certifications.

Indeed, I thought of this case after having sent my email. Anyway, by "blind
trust", I did mean a superset of all trusts related to keysigning.

> >>Let's get back to ownertrust: in the Web of Trust, ownertrust is an 
> >>expression
> >>of how well you think other people verify identities before they sign a 
> >>key. If
> >>you sign key K2 based on X's signature, you haven't verified Y's identity.
> >>You've probably verified X's identity, but not Y's. So you shouldn't sign 
> >>K2.
> >
> >So, is a signature a matter of belief in the validity of the key or of actual
> >work to verify the key ?
> 
> An OpenPGP certification says "I believe that Key X belongs to the person
> identified by User ID U".  Most people would not want to make that statement
> publicly without having thought about it and convinced themselves somehow
> that it is true.  What it takes to convince each person may well vary, which
> is why we assign different ownertrust to different people.  When making a
> public assertion like an OpenPGP certification, it is also probably
> reasonable to ask what the parties involved (or the rest of the world) gains
> from making that statement. Just because you believe a statement to be true
> doesn't mean you need to make it publicly, with strong cryptographic
> assurances, and it may have bad consequences.
> 
> Also, consider that certifications are not necessarily forever.   If Alice
> relies solely on Carol's certification to believe that key X belongs to Bob,
> and Alice then certifies (Bob,X), what does Alice do if Carol revokes her
> certification?  If Alice doesn't pay attention and revoke her own
> certification, then she is announcing as fact to the world something that
> she should no longer believe to be true (assuming that she was relying only
> on Carol's certification for that belief). This sounds like an untenable
> maintenance situation I personally would rather avoid, which is why i do not
> make public certifications based solely on other people's certifications.

Indeed. I just backed off in my answer to Peter, by understanding why it was not
needed. However, I believe that for the initial problem (ie. key change),
information provided by a signed message accompanied from a UID on the other key
is significant enough, and moreover definite, so I would not be bothered signing
such a new key (of course, also revoking the signature on the old key).

> >If I understood correctly, the depth parameter you are talking about is 
> >useless,
> >except in case there are trust signature. And you agreed with me for them to 
> >be
> >taken out of the equation.
> 
> The depth parameter is useful even without trust signatures.  Peter Lebbings
> response upthread describes the scenario.

Indeed. Thanks for your answer, clarifying once again what signatures mean ! (I
know, I'm slow to understand, but I think I'm OK no.)

Cheers,

Leo

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

Re: trust your corporation for keyowner identification?

[Leo Gaspard]

On Thu, Nov 07, 2013 at 07:21:28PM +0100, Peter Lebbing wrote:
> On 2013-11-07 17:09, Leo Gaspard wrote:
> >If I understood correctly, the depth parameter you are talking about
> >is useless, except in case there are trust signature. And you agreed with
> >me for
> >them to be taken out of the equation.
> 
> Of course it's not useless. You seem to misunderstand the Web of Trust.
> 
> I'll give an example.
> 
> I know and trust the people A, B, C, D and E. A has signed B, B has signed
> C, C has signed D, D has signed E, and E has signed F. I meet up with A,
> verify their identity, and sign their key. I assign ownertrust to A, B, C, D
> and E. Et voilà, the keys A, B, C, D and E are all valid, without me needing
> to meet up with my other friends to verify their key details. A is at level
> 1, B at 2, C at 3, D at 4, and E at 5. Unfortunately, F won't get valid
> because it is at level 6.

Indeed, I never thought someone would assign ownertrust without verifying the
key. Please accept my apologies.

However, I still believe that, under the condition any ownertrusted key has been
verified (which, I assumed, was commonplace, but I was apparently wrong), the
depth parameter is useless.

> Now suppose C signs F as well. F is now at level 4, so it becomes valid.
> However, I don't trust F, so even if F now signs G, G won't become valid.
> 
> Signatures indicate verification, not trust or belief. Trust is in your
> trust database or in trust signatures, but the latter are not commonly used.
> Belief is expressed in validity calculated from your trust database and
> signatures. I don't know if you can choose to disagree with GnuPG, that is,
> if you don't believe a key is valid even though GnuPG calculated that it is.

I'm sorry, I think I gave too much importance to your earlier statement
("Signing is to be an attestation to the validity of the key."), incorrectly
deducing from it that signatures indicates that you should sign whenever you
believe a key is correct as much as if you met in person

> I could get back to all the other points you raise, but I think it's a waste
> of time when you have reasoned from the standpoint that to get a key to be
> valid, you need to sign it, and that is how it looks to me.
> 
> It's not much of a Web when you don't have any depth... it's more of two
> intertwined strands then ;).

I think this time, you gave too much importance to some of my sentences. Or
maybe was I too bad at making myself understood.

Anyway, I meant I should sign a key whenever I believe a key to be valid as much
as if I met with the keyowner. Which, of course, does not equates with merely
believing a key is valid. Indeed, on the WoT, one is rarely sure of the quality
of signatures. (Indeed, I believe(d) full ownertrust must be quite rare., for
that same reason ; but I am probably wrong.)

And, now I know assigning ownertrust to not-personnally-checked keys is
relatively common, I know I should not sign keys based on other people's
verification.

However, to come back to the initial problem, I still believe the key change
problem (ie. owner of K1 switchs to K2) does not require re-verifying ownership
etc. (BTW, isn't this also why transition statements, like
https://we.riseup.net/assets/77263/key%20transition were written ?)

But I still wonder how one should deal with key duplication (ie. owner of K1 now
has a second key K2)...

> HTH,
> 
> Peter.
> 
> PS: My ownertrust for E is useless for now, because he/she is at level 5.
> However, if I get a shorter path to him or her later, it will become useful
> then.

Anyway, thanks for you detailed explanations about the WoT !

Cheers,

Leo

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

Re: trust your corporation for keyowner identification?

[Daniel Kahn Gillmor]

On 11/07/2013 11:09 AM, Leo Gaspard wrote:

Except they do not have to know X, nor that he makes perfectly reasonable
decisions in signing keys.

And I believe it's not noise. Let's make an example in the real world :
  * I would entrust X with my life
  * X would entrust Y with his life, without my knowing it
  * Thus, if I actually entrusted X with my life, why should I be frightened if 
X
asked Y to take care of me ? Provided, of course, X told me he was letting Y
take care of me. After all, I would entrust X with my life, so I should just
agree to any act he believes is good for me.
(That's what I called blind trust. Somewhat more than full trust, I believe.)


if we're talking about gpg's concept of "ownertrust", please do not 
muddy the waters with "entrust X with my life"?  gpg's "ownertrust" is 
much more narrow than that: it says "I am willing to rely on OpenPGP 
certifications made by the holder of this key".


"entrust with my life" is not simply a superset of all other trust.  I 
have friends who would take care of me if i was deathly ill.  I would 
place my life in their hands.  But they have never thought about how to 
do rigorous cryptographic identity certification, and I would not rely 
on their OpenPGP certifications.



Let's get back to ownertrust: in the Web of Trust, ownertrust is an expression
of how well you think other people verify identities before they sign a key. If
you sign key K2 based on X's signature, you haven't verified Y's identity.
You've probably verified X's identity, but not Y's. So you shouldn't sign K2.


So, is a signature a matter of belief in the validity of the key or of actual
work to verify the key ?


An OpenPGP certification says "I believe that Key X belongs to the 
person identified by User ID U".  Most people would not want to make 
that statement publicly without having thought about it and convinced 
themselves somehow that it is true.  What it takes to convince each 
person may well vary, which is why we assign different ownertrust to 
different people.  When making a public assertion like an OpenPGP 
certification, it is also probably reasonable to ask what the parties 
involved (or the rest of the world) gains from making that statement. 
Just because you believe a statement to be true doesn't mean you need to 
make it publicly, with strong cryptographic assurances, and it may have 
bad consequences.


Also, consider that certifications are not necessarily forever.   If 
Alice relies solely on Carol's certification to believe that key X 
belongs to Bob, and Alice then certifies (Bob,X), what does Alice do if 
Carol revokes her certification?  If Alice doesn't pay attention and 
revoke her own certification, then she is announcing as fact to the 
world something that she should no longer believe to be true (assuming 
that she was relying only on Carol's certification for that belief). 
This sounds like an untenable maintenance situation I personally would 
rather avoid, which is why i do not make public certifications based 
solely on other people's certifications.



If I understood correctly, the depth parameter you are talking about is useless,
except in case there are trust signature. And you agreed with me for them to be
taken out of the equation.


The depth parameter is useful even without trust signatures.  Peter 
Lebbings response upthread describes the scenario.


Regards,

--dkg

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

Re: trust your corporation for keyowner identification?

[Peter Lebbing]

On 2013-11-07 17:09, Leo Gaspard wrote:

If I understood correctly, the depth parameter you are talking about
is useless, except in case there are trust signature. And you agreed 
with me for

them to be taken out of the equation.


Of course it's not useless. You seem to misunderstand the Web of Trust.

I'll give an example.

I know and trust the people A, B, C, D and E. A has signed B, B has 
signed C, C has signed D, D has signed E, and E has signed F. I meet up 
with A, verify their identity, and sign their key. I assign ownertrust 
to A, B, C, D and E. Et voilà, the keys A, B, C, D and E are all valid, 
without me needing to meet up with my other friends to verify their key 
details. A is at level 1, B at 2, C at 3, D at 4, and E at 5. 
Unfortunately, F won't get valid because it is at level 6.


Now suppose C signs F as well. F is now at level 4, so it becomes 
valid. However, I don't trust F, so even if F now signs G, G won't 
become valid.


Signatures indicate verification, not trust or belief. Trust is in your 
trust database or in trust signatures, but the latter are not commonly 
used. Belief is expressed in validity calculated from your trust 
database and signatures. I don't know if you can choose to disagree with 
GnuPG, that is, if you don't believe a key is valid even though GnuPG 
calculated that it is.


I could get back to all the other points you raise, but I think it's a 
waste of time when you have reasoned from the standpoint that to get a 
key to be valid, you need to sign it, and that is how it looks to me.


It's not much of a Web when you don't have any depth... it's more of 
two intertwined strands then ;).


HTH,

Peter.

PS: My ownertrust for E is useless for now, because he/she is at level 
5. However, if I get a shorter path to him or her later, it will become 
useful then.


--
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: trust your corporation for keyowner identification?

[Leo Gaspard]

On Thu, Nov 07, 2013 at 11:48:07AM +0100, Peter Lebbing wrote:
> On 06/11/13 23:28, Leo Gaspard wrote:
> > But mostly because signing is an attestion of your belief someone is who 
> > (s)he is. Thus, if you believe someone is who the UID states (s)he is as
> > much as if you met him/her in person and followed the whole verification
> > process, I would not mind your exporting signatures of the key.
> 
> I get the feeling you're partly responding to my adamant statements earlier, 
> but
> you're confusing the situation I was responding to.

Well... The answer to your previous message was in my first two paragraphs. The
rest of my answer, to which you answered, was mostly thinking over some debate
that aroused earlier, and whose authors I do not remember. Anyway, I think you
answered the most important part of my last message.

> I think you're saying: Person X tells me their key is K1. I blindly trust 
> person
> X, and I know for a fact that person X was the one who told me K1 is his key.
> That is, you were in the same room, or you recognised their voice on the
> telephone, or something similar. This is acceptable to many people as a
> verification.
> 
> But this is not the situation I was talking about. It's this:
> 
> Person X (having key K1) has signed key K2, asserting that it is held by Y.
> Since you blindly trust X, you can assign him full (or hell, ultimate if you
> prefer) ownertrust, and key K2 is valid for you. You don't need to sign K2
> anymore, because it is already valid since you expressed your trust to GnuPG,
> and GnuPG uses it to validate that it belongs to Y.
> 
> Now, what Stan Tobias appeared to want, is sign key K2 himself, probably to
> express to others in the Web of Trust that he believes K2 to be valid. But 
> this
> doesn't add any additional verification of key validity to the Web of Trust,
> it's noise. Because anyone else can look at the signature made by X, and 
> decide:
> I trust X fully as well. They assign full trust to X, and K2 becomes valid.

Except they do not have to know X, nor that he makes perfectly reasonable
decisions in signing keys.

And I believe it's not noise. Let's make an example in the real world :
 * I would entrust X with my life
 * X would entrust Y with his life, without my knowing it
 * Thus, if I actually entrusted X with my life, why should I be frightened if X
   asked Y to take care of me ? Provided, of course, X told me he was letting Y
   take care of me. After all, I would entrust X with my life, so I should just
   agree to any act he believes is good for me.
(That's what I called blind trust. Somewhat more than full trust, I believe.)

> Let's get back to ownertrust: in the Web of Trust, ownertrust is an expression
> of how well you think other people verify identities before they sign a key. 
> If
> you sign key K2 based on X's signature, you haven't verified Y's identity.
> You've probably verified X's identity, but not Y's. So you shouldn't sign K2.

So, is a signature a matter of belief in the validity of the key or of actual
work to verify the key ?

> You might believe Y when he or she walks up to you and says: my name is Y and 
> K2
> is my key. But that is not what happened; X said: K2 is Y's key. Y didn't say
> anything to you, let alone that you verified it was actually Y talking. That's
> the absolutely necessary part of verification: you believe that it was 
> actually
> Y that told you K2 is theirs. Just believing K2 is Y's key is not 
> verification;
> it's key validity.
> 
> I'll give an example.
> 
> In the Web of Trust, key validity is a thing that can gradually build up until
> it passes a certain point where we say: I have so much proof that it appears 
> to
> be valid, that I conclude it's, within reason, valid. This is why you have
> "completes needed", "marginals needed", and "max cert depth". The latter says:
> once we pass a certain depth, my proof of identity becomes so indirect I don't
> wish to trust that information anymore. I will paint a picture with the 
> default
> settings, completes 1, marginals 3, max depth 5.

If I understood correctly, the depth parameter you are talking about is useless,
except in case there are trust signature. And you agreed with me for them to be
taken out of the equation.

> Suppose A has signed B. There are three people C, D and E, who have full trust
> in A. They do what I'm arguing against: they sign key B as well, based on 
> their
> trust of A.
> 
> Now I come along. I actually have key A valid as well, but quite indirectly: 
> it
> is at level 4. I know A, but ownertrust is very personal. I think A does an 
> okay
> job of verifying identities, but not to the rigorous level I personally 
> demand.
> I work with pretty sensitive stuff, and my standards are high (I'm painting a
> picture here, not describing reality). So I assign him marginal ownertrust. 
> Now
> what I would expect, is that I need some more signatures, and B will become
> valid at level 5, the level where I 

Re: question about public keys

[David Smith]

On 11/06/13 23:57, Smith, Cathy wrote:
> Hi
> 
> A couple of years ago I created a gpg key for an account that is use to 
> transfer documents with vendors.  It's worked fine.  We now have a new vendor 
> that won't accept the public key because of the expiration date.  I don't see 
> a way to create another public key for this account with the shorter 
> expiration date.  Replacing the current public key will disrupt business with 
> existing customers.  Is there a solution other than creating another account 
> with its own gpg key?

You have a number of options:

1. Edit the expiration date of the existing key, and then re-circulate
it.  Vendors with the old key will be able to carry on working, the new
one can use the key with the shorter expiration date.  As it comes close
to expiration, you can re-edit the expiration date to extend it.
However, this might not suit your new client's requirements.

2. Generate a new keypair with the same email address as the old one,
and only send it to the new client.  However, if it gets circulated to
other clients, it might cause confusion over which key to use.  You can
generate a new keypair with "gpg --gen-key".

3. Depending on what your new client's objections are, it might be
sufficient to generate a new encryption subkey within your existing
master key.  The new subkey can have a different expiration date to the
master key.  Most of your existing clients will continue using the
existing encryption subkey with a long expiration date; the new client
can specifically choose to use the new subkey with a shorter expiration
date.  When the new subkey expires, you can simply create another one
with a new expiration date.  You can add a subkey by running "gpg
--edit-key " and then running the command "addkey".

HTH...

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

Re: trust your corporation for keyowner identification?

[Peter Lebbing]

On 06/11/13 23:28, Leo Gaspard wrote:
> The fact that others could get just the same effect by twisting their WoT 
> parameters is not an issue to me. Firstly, because there are few trust 
> signatures (according to best practices I read, that said trust signatures 
> are mainly made for closed-system environments), so WoT rarely expands 
> outwards of one signature by someone you know.

Let's leave trust signatures out of the equation, it makes it a lot more
complicated and they are rarely used. I also don't see the relation between the
statements in this quote here.

> But mostly because signing is an attestion of your belief someone is who 
> (s)he is. Thus, if you believe someone is who the UID states (s)he is as
> much as if you met him/her in person and followed the whole verification
> process, I would not mind your exporting signatures of the key.

I get the feeling you're partly responding to my adamant statements earlier, but
you're confusing the situation I was responding to.

I think you're saying: Person X tells me their key is K1. I blindly trust person
X, and I know for a fact that person X was the one who told me K1 is his key.
That is, you were in the same room, or you recognised their voice on the
telephone, or something similar. This is acceptable to many people as a
verification.

But this is not the situation I was talking about. It's this:

Person X (having key K1) has signed key K2, asserting that it is held by Y.
Since you blindly trust X, you can assign him full (or hell, ultimate if you
prefer) ownertrust, and key K2 is valid for you. You don't need to sign K2
anymore, because it is already valid since you expressed your trust to GnuPG,
and GnuPG uses it to validate that it belongs to Y.

Now, what Stan Tobias appeared to want, is sign key K2 himself, probably to
express to others in the Web of Trust that he believes K2 to be valid. But this
doesn't add any additional verification of key validity to the Web of Trust,
it's noise. Because anyone else can look at the signature made by X, and decide:
I trust X fully as well. They assign full trust to X, and K2 becomes valid.

Let's get back to ownertrust: in the Web of Trust, ownertrust is an expression
of how well you think other people verify identities before they sign a key. If
you sign key K2 based on X's signature, you haven't verified Y's identity.
You've probably verified X's identity, but not Y's. So you shouldn't sign K2.

You might believe Y when he or she walks up to you and says: my name is Y and K2
is my key. But that is not what happened; X said: K2 is Y's key. Y didn't say
anything to you, let alone that you verified it was actually Y talking. That's
the absolutely necessary part of verification: you believe that it was actually
Y that told you K2 is theirs. Just believing K2 is Y's key is not verification;
it's key validity.

I'll give an example.

In the Web of Trust, key validity is a thing that can gradually build up until
it passes a certain point where we say: I have so much proof that it appears to
be valid, that I conclude it's, within reason, valid. This is why you have
"completes needed", "marginals needed", and "max cert depth". The latter says:
once we pass a certain depth, my proof of identity becomes so indirect I don't
wish to trust that information anymore. I will paint a picture with the default
settings, completes 1, marginals 3, max depth 5.

Suppose A has signed B. There are three people C, D and E, who have full trust
in A. They do what I'm arguing against: they sign key B as well, based on their
trust of A.

Now I come along. I actually have key A valid as well, but quite indirectly: it
is at level 4. I know A, but ownertrust is very personal. I think A does an okay
job of verifying identities, but not to the rigorous level I personally demand.
I work with pretty sensitive stuff, and my standards are high (I'm painting a
picture here, not describing reality). So I assign him marginal ownertrust. Now
what I would expect, is that I need some more signatures, and B will become
valid at level 5, the level where I have configured GnuPG to say: okay, this is
deep enough, I will not take into account B's signatures on other keys because
the proof becomes too indirect.

However, I also know C, D and E, signed their keys and assigned them marginal
ownertrust because I was under the impression they also verify identities pretty
well. I don't know that they go around signing keys based on other people's
signatures.

C, D and E are thus at level 1 in my web. They all signed B's key, so I think:
that's reasonable proof that B is valid. Not only do I think that, so does
GnuPG. It leads to B's key being valid at level 2. B can have another few levels
of indirection before I consider the path too long. In fact, for signature paths
through B, it effectively just changed my "max cert depth". B belongs at level
5, because the proof of validity is very indirect in my *own* web, but he's at
level 2, so my "max cert de

question about public keys

[Smith, Cathy]

Hi

A couple of years ago I created a gpg key for an account that is use to 
transfer documents with vendors.  It's worked fine.  We now have a new vendor 
that won't accept the public key because of the expiration date.  I don't see a 
way to create another public key for this account with the shorter expiration 
date.  Replacing the current public key will disrupt business with existing 
customers.  Is there a solution other than creating another account with its 
own gpg key?

Thanks


Cathy

---
Cathy L. Smith
IT Engineer

Pacific Northwest National Laboratory
Operated by Battelle for the
U.S. Department of Energy

Phone:  509.375.2687
Fax:    509.375.2330
Email:  cathy.sm...@pnnl.gov



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

Re: bug-like: strange behaviour of addrevoker

[Werner Koch]

On Tue,  5 Nov 2013 23:13, mailinglis...@hauke-laging.de said:

> revokers. But that didn't work as expected. After entering the command 
> "addrevoker" I was asked to enter the user ID of the respective key. Why the 
> user ID and not the key ID or fingerprint? Does that make any sense?

You may use any way to specify a user id.  It is the same code as used
when you fire up "gpg --key-edit USERID" with the only restriction that
the key must have certify capability which is always the case for a
primary key.

> nor 0x1a571df5 works. Even worse: The email address doesn't work either (both 
> ha...@laging.de and ).

If you have the two user IDs, gpg can't decide which to use.  Thus you
need to use the keyid or the fingerprint.  Please check again and if you
can't make it work, please create a test case for us.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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