Re: Signing a key (meaning)
Sounds like some people could use a signature type which means: "I disclaim all signatures made by ". -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpp2yNFuADwp.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
keys not available for signed messages in this maillist
Hi, i wonder whether the keys from several members of this maillist should be available from the keyserver. e.g. Grant Olson signs all his messages here. evolution and gpg on ubuntu, however, fail to retrieve the public key from the server: the message always reads: signature exists, however, the public key is required. I have already tried to use the key ID to look for the public key, but, not too surprisingly, could not retrieve it. I have then seen, that the key used for signing is one of grants subkey. My question now is, why are those subkeys not retrieved? I do not at all want to blame Grant, John Clizbe's key and that of others can equally not be retrieved. Cheers bernhard 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: keys not available for signed messages in this maillist
On 4/8/11 10:25 AM, Bernhard Kleine wrote: > i wonder whether the keys from several members of this maillist should > be available from the keyserver. e.g. Grant Olson signs all his messages > here. evolution and gpg on ubuntu, however, fail to retrieve the public > key from the server: "Should" is maybe the wrong word to use. I've never seen "should" mean anything other than, "I want" or "I expect." The universe doesn't much care about what we want or expect, though. Justice should prevail and the sun should rise in the east: but I don't think for a second either of those "shoulds" means much. :) Still, let's try this instead: "why are so many certificates not available on the keyserver network?" One answer is, the certificate owners might not want their certificates on the keyserver network. Some people much prefer to give their certificates via biglumber, or person to person, or... etc. We may agree or disagree with their reasons, but the decision is theirs to make: we just have to respect it. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Set key to be default to sign/encrypt
On Thu, Apr 07, 2011 at 09:10:45PM +0200 Also sprach Csabi: Hi! Thx your reply. I tried the following: gpg -u 4096R/626D791C --detach-sign t.txt The error is the same: gpg: skipped "4096R/626D791C": secret key not available gpg: signing failed: secret key not available I tried it with the public key's key ID too but the result was the same. What am i doing wrong? I think you may just have a problem with your command line syntax. "gpg -u" expects only the Key ID or fingerprint, NOT the key type (i.e. drop the 4096R/). Try the following command line and see if you get better results: gpg -u 626D791C --detach-sign t.txt -- "Le hasard favorise l'esprit préparé." --Louis Pasteur ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys not available for signed messages in this maillist
Bernhard Kleine wrote: > Hi, > > i wonder whether the keys from several members of this maillist should > be available from the keyserver. e.g. Grant Olson signs all his messages > here. evolution and gpg on ubuntu, however, fail to retrieve the public > key from the server: > > the message always reads: signature exists, however, the public key is > required. I have already tried to use the key ID to look for the public > key, but, not too surprisingly, could not retrieve it. I have then seen, > that the key used for signing is one of Grant's subkey. > > My question now is, why are those subkeys not retrieved? Client configuration issue? The keys are out there on the servers. Which server(s) are you searching? Is that server online? Does gpg --search-keys work from the command line? Does gpg --recv-keys? http://pool.sks-keyservers.net:11371/pks/lookup?search=kgo%40grant-olson.net&fingerprint=on&op=index > I do not at all want to blame Grant, John Clizbe's key and that of > others can equally not be retrieved. Which keys of mine can you not retrieve? I normally sign with two. Currently they are 0xD6569825 and 0x435BD034. _ALL_ of the keys I use publicly are available on the SKS keyservers. I also know those of Grant's are also available as I recently updated them with gpg --refresh-key. http://pool.sks-keyservers.net:11371/pks/lookup?search=clizbe&fingerprint=on http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0xEB5E19F3D6569825 http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0x2313315C435BD034 You may wish^W^W need to check your keyserver configuration. It obviously has a problem. -- John P. Clizbe Inet: John (a) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 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: keys not available for signed messages in this maillist
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 8 Apr 2011, at 16:23, Robert J. Hansen wrote: > On 4/8/11 10:25 AM, Bernhard Kleine wrote: >> > "Should" is maybe the wrong word to use. I've never seen "should" mean > anything other than, "I want" or "I expect." 'Should' and 'Must' have specific meanings within most RFC's (I've been OD'ing on RFCs, recently) So, as many of us here are from a technical background, I think we might be ready to believe such a formalism may apply? Regards, Andy - -- Andrew Long andrew dot long at mac dot com -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAk2fO0gACgkQRL8D6wymVNYDZgD+OqBcWPsLxnRiTOF2hH/nHWqS OVRedrbj5jB95IpiSxABALwTna/K4jlmdkLCg2L2hhfieYnmbZvdh5XWrElQWHtg =G+N0 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys not available for signed messages in this maillist
On 4/8/11 12:43 PM, Andrew Long wrote: > 'Should' and 'Must' have specific meanings within most RFC's. SHOULD and MUST do. They're presented in all-caps in RFCs to make sure people know they're being used in a formal context as opposed to a conversational English context. If you want to say certificates SHOULD be uploaded to keyservers, we can have a good, healthy debate on that subject. If you want to say certificates should be uploaded to keyservers, my response to that is I should have a pony, too. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Do not conflate key+userID certification with "vouching" [was: Re: How to verify the e-mail address when certifying OpenPGP User IDs]
On 04/07/2011 09:37 PM, Grant Olson wrote:
> Keep in mind that the web-of-trust isn't the mafia. If you 'vouch' for
> someone and they turn out to be a rat, nobody's going to two bullets in
> your chest, and one in your head.
"Vouching" for someone usually means that you think you can rely on the
person, and that you think they're somehow "good", "on our side",
"trustworthy", etc.
Making an OpenPGP certification ("keysigning") is *not* the same as
"vouching" for them. An OpenPGP certification is a simple assertion of
two things: {identity (which may include an address), and ownership of a
key}.
An OpenPGP certification says nothing about whether you think the
keyholder is a good person, whether you would trust them with your
children, whether they are a good software engineer, whether you would
vote them into public office if you happen to live in a democracy, or
even whether you are willing to rely on the OpenPGP certifications they
produce. [0]
You are free to assert these other qualities in many other ways, of
course. For example, I could write, sign, and publish a document that
says "Alice has strong moral fiber". This sort of
"vouching" would be distinct from my certification of Alice's OpenPGP
key. Note that I am *not* saying that Alice's key has strong moral
fiber. My statement is vouching for *Alice*, not her key.
Keeping the semantics of keysigning restricted to a simple assertion of
identity and key ownership makes it possible to do reasoned inference
over a set of certifications, to establish (via intermediate parties,
such as "mutual acquaintances") a level of reliable identity and
key-ownership between people (and other entities!) who have never
physically met. It also makes OpenPGP certification less fraught with
doubt or confusion, and it reduces the amount deep social relationships
published on the public keyservers. This is good.
If you mix non-identity, non-key-ownership notions into your OpenPGP
certifications, making a certification becomes radically harder (because
the other notions are significantly less objective), and your ability to
do effective reasoned inference about identity and key-ownership drops
away as certifications themselves become rarer and more entangled with
subjective measurements of "vouch-worthiness".
Ironically, this means that mixing concepts of "vouching" into standard
OpenPGP certification makes it *harder* to effectively "vouch" for
someone, because it is harder for them to establish their identity in
the first place.
Vouching for people is great, and useful in many contexts. But it
should not be conflated with identity certification.
--dkg
[0] Yes, you can actually assert your willingness to rely on the
keyholders' own OpenPGP certifications, using so-called "trust
signatures". Currently, very few people issue trust signatures, and
those who use them responsibly issue them very rarely. If you aren't
confident on standard OpenPGP certifications, you should probably avoid
issuing trustsigs entirely. They are public declarations of social
relationships that most people prefer to keep private.
signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys not available for signed messages in this maillist
John Clizbe wrote: > Bernhard Kleine wrote: >> Hi, >> >> i wonder whether the keys from several members of this maillist should >> be available from the keyserver. e.g. Grant Olson signs all his messages >> here. evolution and gpg on ubuntu, however, fail to retrieve the public >> key from the server: >> >> My question now is, why are those subkeys not retrieved? > You may wish^W^W need to check your keyserver configuration. It obviously has > a > problem. You most likely need to configure gpg to automatically retrieve needed keys. It's not handled directly by Evolution. From http://live.gnome.org/Evolution/FAQ#How_can_import_GPG_keys_automatically_from_within_Evolution.3F > > How can import GPG keys automatically from within Evolution? > > If you receive a signed GPG/PGP message from someone and you do not yet > have his public key in your GPG/PGP keyring. You can make GPG automatically > download and add unknown GPG/PGP keys of received messages by adding the > following two lines to the file $HOME/.gnupg/gpg.conf: > > keyserver hkp://subkeys.pgp.net > > keyserver-options auto-key-retrieve > > The actual link (URI) to the keyserver is only one example and may be > different - you can also choose other servers. Many recommend pool.sks-keyservers.net. It's regularly updated to reflect up-to-date online servers and distributes the load of serving keys over more of the SKS network. There are several pools you may choose. See http://www.sks-keyservers.net/overview-of-pools.php for more information. There are additional options for the keyserver-options line. I recommend adding ' include-subkeys include-revoked import-clean'. See the gpg man page. -- John P. Clizbe Inet: John (a) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 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: Do not conflate key+userID certification with "vouching" [was: Re: How to verify the e-mail address when certifying OpenPGP User IDs]
On 4/8/11 2:00 PM, Daniel Kahn Gillmor wrote:
> On 04/07/2011 09:37 PM, Grant Olson wrote:
>> Keep in mind that the web-of-trust isn't the mafia. If you 'vouch' for
>> someone and they turn out to be a rat, nobody's going to two bullets in
>> your chest, and one in your head.
>
> "Vouching" for someone usually means that you think you can rely on the
> person, and that you think they're somehow "good", "on our side",
> "trustworthy", etc.
>
> Making an OpenPGP certification ("keysigning") is *not* the same as
> "vouching" for them. An OpenPGP certification is a simple assertion of
> two things: {identity (which may include an address), and ownership of a
> key}.
>
> An OpenPGP certification says nothing about whether you think the
> keyholder is a good person, whether you would trust them with your
> children, whether they are a good software engineer, whether you would
> vote them into public office if you happen to live in a democracy, or
> even whether you are willing to rely on the OpenPGP certifications they
> produce. [0]
>
We're on the same page here, although I probably made my point sloppily.
Two definitions of vouch:
1. Assert or confirm as a result of one's own experience that something
is true or accurately so described.
2. Confirm that someone is who they say they are or that they are of
good character: "someone could vouch for him".
A sig is the first definition. Organized crime is the second.
Jan seems to be worried that if he signs a key, and Eve is somehow
illegally using an email or whatever, that his signature would add some
sort of credibility or trust measurement to Eve when she initiates her
Nigerian 411 scam. I was (sloppily) saying that the signature implies
no such thing.
> You are free to assert these other qualities in many other ways, of
> course. For example, I could write, sign, and publish a document that
> says "Alice has strong moral fiber". This sort of
> "vouching" would be distinct from my certification of Alice's OpenPGP
> key. Note that I am *not* saying that Alice's key has strong moral
> fiber. My statement is vouching for *Alice*, not her key.
>
Like I said, if you want to do this, using certification levels and a
signing policy might be a less ad-hoc way of accomplishing this. (Not
that any clients currently do anything with that info.) And yes,
there's still a distinction between the acutal person and their key.
Like you say below, attaching various certification levels may actually
be undesirable and leak more personal info than some people want out there.
> Keeping the semantics of keysigning restricted to a simple assertion of
> identity and key ownership makes it possible to do reasoned inference
> over a set of certifications, to establish (via intermediate parties,
> such as "mutual acquaintances") a level of reliable identity and
> key-ownership between people (and other entities!) who have never
> physically met. It also makes OpenPGP certification less fraught with
> doubt or confusion, and it reduces the amount deep social relationships
> published on the public keyservers. This is good.
>
--
Grant
"I am gravely disappointed. Again you have made me unleash my dogs of war."
signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys not available for signed messages in this maillist
Am Freitag, den 08.04.2011, 11:29 -0500 schrieb John Clizbe: > Bernhard Kleine wrote: > > Hi, > > > > i wonder whether the keys from several members of this maillist should > > be available from the keyserver. e.g. Grant Olson signs all his messages > > here. evolution and gpg on ubuntu, however, fail to retrieve the public > > key from the server: > > > > the message always reads: signature exists, however, the public key is > > required. I have already tried to use the key ID to look for the public > > key, but, not too surprisingly, could not retrieve it. I have then seen, > > that the key used for signing is one of Grant's subkey. > > > > My question now is, why are those subkeys not retrieved? > > Client configuration issue? The keys are out there on the servers. Which > server(s) are you searching? Is that server online? > Does gpg --search-keys work from the command line? Does gpg --recv-keys? > > http://pool.sks-keyservers.net:11371/pks/lookup?search=kgo%40grant-olson.net&fingerprint=on&op=index > > > I do not at all want to blame Grant, John Clizbe's key and that of > > others can equally not be retrieved. > > Which keys of mine can you not retrieve? I normally sign with two. Currently > they are 0xD6569825 and 0x435BD034. > > _ALL_ of the keys I use publicly are available on the SKS keyservers. I also > know those of Grant's are also available as I recently updated them with gpg > --refresh-key. > > http://pool.sks-keyservers.net:11371/pks/lookup?search=clizbe&fingerprint=on > > http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0xEB5E19F3D6569825 > > http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0x2313315C435BD034 > > You may wish^W^W need to check your keyserver configuration. It obviously has > a > problem. Sorry for ambiguous wording with the "should". I am quite sure that Grant Olson's key is on the keyserver, thus there is no matter of hiding it, as robert j.hansen suggested. however, i wonder why i can't retrieve it. gpg --search-keys A18A54D gpg: Suche nach "A18A54D" von hkp Server pool.sks-keyservers.net gpg: Schlüssel "A18A54D" am Schlüsselserver nicht gefunden i.d. search for A18A54D on hkp server .. key A18A54D not found at the keyserver. on the command line! on the interaction page of sks-keyservers.net the key cannot found either. Any help appreciated. Bernhard 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: keys not available for signed messages in this maillist
Am Freitag, den 08.04.2011, 13:19 -0500 schrieb John Clizbe: > John Clizbe wrote: > > Bernhard Kleine wrote: > >> Hi, > >> > >> i wonder whether the keys from several members of this maillist should > >> be available from the keyserver. e.g. Grant Olson signs all his messages > >> here. evolution and gpg on ubuntu, however, fail to retrieve the public > >> key from the server: > > >> > >> My question now is, why are those subkeys not retrieved? > > > You may wish^W^W need to check your keyserver configuration. It obviously > > has a > > problem. > > You most likely need to configure gpg to automatically retrieve needed keys. > It's not handled directly by Evolution. From > http://live.gnome.org/Evolution/FAQ#How_can_import_GPG_keys_automatically_from_within_Evolution.3F > > > > How can import GPG keys automatically from within Evolution? > > > > If you receive a signed GPG/PGP message from someone and you do not yet > > have his public key in your GPG/PGP keyring. You can make GPG automatically > > download and add unknown GPG/PGP keys of received messages by adding the > > following two lines to the file $HOME/.gnupg/gpg.conf: > > > > keyserver hkp://subkeys.pgp.net > > > > keyserver-options auto-key-retrieve > > > > The actual link (URI) to the keyserver is only one example and may be > > different - you can also choose other servers. > > Many recommend pool.sks-keyservers.net. It's regularly updated to reflect > up-to-date online servers and distributes the load of serving keys over more > of > the SKS network. There are several pools you may choose. > See http://www.sks-keyservers.net/overview-of-pools.php for more information. > > There are additional options for the keyserver-options line. I recommend > adding > ' include-subkeys include-revoked import-clean'. See the gpg man page. > sorry for the noice: I happen to notice a typing error: sks-keyserver instead of keyservers. after that keys could be retrieved. thanks a lot for your patience. Greetings from the Black Forest Bernhard 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: keys not available for signed messages in this maillist
Bernhard Kleine wrote: > > I am quite sure that Grant Olson's key is on the keyserver, thus there > is no matter of hiding it, as robert j.hansen suggested. however, i > wonder why i can't retrieve it. > > gpg --search-keys A18A54D > gpg: Suche nach "A18A54D" von hkp Server pool.sks-keyservers.net > gpg: Schlüssel "A18A54D" am Schlüsselserver nicht gefunden > > i.d. search for A18A54D on hkp server .. > key A18A54D not found at the keyserver. > Key IDs are 8 hex digits. You have typed 7. Add the '6' at the end :-) sks@yogi:~$ gpg --keyserver yogi --search-keys 0xA18A54D6 gpg: searching for "0xA18A54D6" from hkp server yogi (1) Grant T. Olson (pikimal) Grant T. Olson (Personal email) Grant T. Olson (Grant - home email) 2048 bit RSA key E3B5806F, created: 2010-01-11 Keys 1-1 of 1 for "0xA18A54D6". Enter number(s), N)ext, or Q)uit > -- John P. Clizbe Inet: John (a) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 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: keys not available for signed messages in this maillist
Am Freitag, den 08.04.2011, 14:09 -0500 schrieb John Clizbe: > Key IDs are 8 hex digits. You have typed 7. Add the '6' at the end :-) > > sks@yogi:~$ gpg --keyserver yogi --search-keys 0xA18A54D6 > gpg: searching for "0xA18A54D6" from hkp server yogi > (1) Grant T. Olson (pikimal) > Grant T. Olson (Personal email) > Grant T. Olson (Grant - home email) > 2048 bit RSA key E3B5806F, created: 2010-01-11 > Keys 1-1 of 1 for "0xA18A54D6". Enter number(s), N)ext, or Q)uit > > > see also the other mail: this actually worked here, too. on the interactionpage of sks-keyservers.net 8 digits are not sufficient you have to prefix 0xA18AA54D6. Thus all the problems are solved. your other suggestion were already active here: sks-keyserver pool and the auto-retrieve-key option. Thanks again! bernhard 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: keys not available for signed messages in this maillist
On 4/8/11 2:50 PM, Bernhard Kleine wrote: > > I am quite sure that Grant Olson's key is on the keyserver, thus there > is no matter of hiding it, as robert j.hansen suggested. however, i > wonder why i can't retrieve it. > > gpg --search-keys A18A54D > gpg: Suche nach "A18A54D" von hkp Server pool.sks-keyservers.net > gpg: Schlüssel "A18A54D" am Schlüsselserver nicht gefunden > > i.d. search for A18A54D on hkp server .. > key A18A54D not found at the keyserver. > > on the command line! > > on the interaction page of sks-keyservers.net the key cannot found > either. > > Any help appreciated. > > Bernhard You missed the last digit of the key id: A18A54D6 You also need start that with 0x so it knows it's a hexadecimal key id. And you probably want to use my primary key. but either: gpg --search-keys 0xA18A54D6 or gpg --search-keys 0xE3B5806F Should work. -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Do not conflate key+userID certification with "vouching"
On 04/08/2011 02:38 PM, Grant Olson wrote: > Two definitions of vouch: > > 1. Assert or confirm as a result of one's own experience that something > is true or accurately so described. > 2. Confirm that someone is who they say they are or that they are of > good character: "someone could vouch for him". > > A sig is the first definition. Organized crime is the second. Or, more simply, An OpenPGP certification is "vouching for someone's identity"; it is not "vouching for someone". But given the easy confusion and the level of nuance required to tease the concepts apart, i think we're better off avoiding the term "vouch" entirely, and talking about "assertions of identity and key ownership" instead. Why use a term likely to sow more confusion in an already confused topic? > Like I said, if you want to do this, using certification levels and a > signing policy might be a less ad-hoc way of accomplishing this. Actually, i think using a signing policy and certification levels to refer to non-identity,non-key-ownership characteristics is *also* a mistake. Here are the descriptions of the conventionally-defined "certification levels" (from https://tools.ietf.org/html/rfc4880#page-20) : >>0x10: Generic certification of a User ID and Public-Key packet. >>The issuer of this certification does not make any particular >>assertion as to how well the certifier has checked that the owner >>of the key is in fact the person described by the User ID. >> >>0x11: Persona certification of a User ID and Public-Key packet. >>The issuer of this certification has not done any verification of >>the claim that the owner of this key is the User ID specified. >> >>0x12: Casual certification of a User ID and Public-Key packet. >>The issuer of this certification has done some casual >>verification of the claim of identity. >> >>0x13: Positive certification of a User ID and Public-Key packet. >>The issuer of this certification has done substantial >>verification of the claim of identity. >> >>Most OpenPGP implementations make their "key signatures" as 0x10 >>certifications. Some implementations can issue 0x11-0x13 >>certifications, but few differentiate between the types. > Note that none of these levels make any reference to anything other than identity and key ownership. They refer to levels of certainty (of the issuer) of identity and key ownership (of the subject). But not to any other statements like "has strong moral fiber" or "has been my best friend since birth" or "is trustworthy around dogs" or "loves sauerkraut as much as i do". [0] Again, if you want to assert these things publicly, you're free to do so. But regular public OpenPGP certifications are probably the wrong place to do it. OpenPGP certifications should be about identity and key-ownership. Regards, --dkg [0] Note that i *could* give a "positive" certification to my best friend since birth, since i certainly have done substantial verification of his identity, but that doesn't work bi-directionally: every "positive" certification doesn't have to mean "best friend since birth". Moreover, making that kind of assertion would leak some additional information about my perception of our relationship, and (since our tools don't make use of this information) it would not provide any additional benefit to either of us. So why would anyone make such a public certification? If someone can describe an actual benefit, i can decide whether it's worth the tradeoff that comes from the extra data in the social graph implied by the WoT. But as it stands, i don't think there's even a tradeoff to be made. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Do not conflate key+userID certification with "vouching"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Friday 8 April 2011 at 8:35:56 PM, in , Daniel Kahn Gillmor wrote: > Or, more simply, An OpenPGP certification is "vouching > for someone's identity"; it is not "vouching for > someone". The meaning and implications of "vouching for" somebody are massively dependent on context and circumstances. In the context of a discussion about openPGP certifications, in the abstract without any specific use for those certifications lurking in the shadows, I see no difference between "vouching for someone's identity" and "vouching for someone." > But given the easy confusion and the level of nuance > required to tease the concepts apart, i think we're > better off avoiding the term "vouch" entirely, and > talking about "assertions of identity and key > ownership" instead. Why use a term likely to sow more > confusion in an already confused topic? Whilst "vouch" is yet another term with the potential to confuse, is it really any more confusing than "certification" or "assertion of identity?" > OpenPGP certifications should be about identity and > key-ownership. As an aside, I've always found "control" to be more helpful than "ownership" in my thought processes about openPGP keys. Who "controls" the private key has an obvious meaning to me, who "owns" a key seems a little more abstract. - -- Best regards MFPAmailto:expires2...@ymail.com Never interrupt me when I'm trying to interrupt you. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNn3jWnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pdiAD+gMv jNDoqqqZ9cYUf39hBs2w3e8QoyjMIBVmk8Ghg/4F/L7yaXQCGR9OXrKAFl45zPAz B9Y2Cz8VLjBa7CjpeluZe0kkzF+0De4vd+BaNFBGF0jY13KXPfbWezC22SH4A16w jlOFLFWiEPk1mJaNjA7GHB1JVxM9nrHRYXT1iPX2 =WqbR -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signing a key (meaning)
>> I wonder how I can check whether the email >>address in the ID realy belongs to the keyowner. >You can only check whether the key owner "has access" >to the email address. You cannot check whether this >access is in any way exclusive, legit or whatever. I think so, but WHAT benefit (concerning the identity) do you have from knowing that the person who owns the private key *has access* to the email address mentioned in that key ID? Remember that we do the whole fingerprint checking, because we believe it might very well be there's a man in the middle or that an attacker has access to the email address. I think there's no benefit, because everybody who issueses a key (even an attacker) wants to receive information encrypted with that key, - otherwise he wouldn't issue it. Thus he will place an email address in the ID he has access to. So I think we can take this for granted. The reason why the email address is in the user ID is for convenience (so everybody knows where to send emails) and makes sure keys can be easily found on the keyserver. Apart from that it enables user to distinguished between keys of persons with the same name. Thanks for answers, Jan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signing a key (meaning)
On 04/08/2011 06:02 PM, Jan Janka wrote: > I think there's no benefit, because everybody who issueses a key (even an > attacker) wants to receive information encrypted with that key, - otherwise > he wouldn't issue it. Thus he will place an email address in the ID he has > access to. So I think we can take this for granted. But if an attacker puts his e-mail address on a key he claims to be mine, he won't get my mail sent to (or encrypted to) him. Many people already know Bob's e-mail address; if they're sending mail do b...@example.net, they're not going to encrypt that mail to a key that has "Bob " as the only User ID. OTOH, if Eve suspects she might at some point get access to a message that was sent to Bob, it's in her interest to put *Bob's* e-mail address on a key and try to get people to accept it as Bob's (rather than putting her own address on it). You're right that if Eve *already* has access to Bob's inbox, then the e-mail access check won't be a terribly useful test (though as soon as people start encrypting mail to Eve's key and mailing it to Bob, Bob ought to notice). But the e-mail access control check *does* protect against the attack scenario where at the time of keysigning, Eve does *not* have access to Bob's inbox. It protects the contents of the inbox (because people send messages encrypted to the correct key) when some of Bob's mail accidentally leaks to Eve later. > The reason why the email address is in the user ID is for convenience (so > everybody knows where to send emails) and makes sure keys can be easily found > on the keyserver. Apart from that it enables user to distinguished between > keys of persons with the same name. This is pretty critical in some contexts. E-mail is a (mostly) unique, global identifier. "John Smith" is not. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
default keyserver-options [was: Re: keys not available for signed messages in this maillist]
On 04/08/2011 02:19 PM, John Clizbe wrote: > There are additional options for the keyserver-options line. I recommend > adding > ' include-subkeys include-revoked import-clean'. See the gpg man page. Thanks for these pointers, John. If you think these are good options, maybe we should advocate for changing the defaults to include them? I support setting include-subkeys and include-revoked to on by default. The only reason these aren't more seriously problematic right now is that SKS (the dominant HKP implementation today) automatically searches subkeys and includes revoked keys. That is, these options have no effect when querying SKS keyservers. As a keyserver client, i think gpg should make it clear that it wants these options by default, in case any keyservers attempt to honor them. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signing a key (meaning)
> But if an attacker puts his e-mail address on a key he claims to be > mine, he won't get my mail sent to (or encrypted to) him. If someone somehow gets that key, reads your name in the ID and relies on that name he might sent mail intented for you to the attacker's email address, that might even pretty much look like yours email address. >But the e-mail access control check *does* protect >against the attack scenario where at the time of keysigning, Eve does >*not* have access to Bob's inbox. Yes, but the fingerprint check already protects against that, so why do we need another check? >> The reason why the email address is in the user ID is for convenience >>(so >> everybody knows where to send emails) and makes sure keys can be >>easily >> found on the keyserver. Apart from that it enables user to >>distinguished >> between keys of persons with the same name. >This is pretty critical in some contexts. E-mail is a (mostly) unique, >global identifier. "John Smith" is not. What do you mean with critical? "John Smith " is quite global and quite unique, although I don't check the email address before signing. 1. John tells me j...@hot.com. 2. I believe him he has access to j...@hot.com (see former email). 3. I find keys on the server by looking for j...@hot.com. 4. I choose "John Smith ", because I know his name. 5. I make a fingerprint check on the phone (I know his voice). 6. I sign the key. 7. I upload the signed key to the keyserver. If there is a clever attacker he might issue a key with the very same ID. People then looking for John's key will be presented the following list: "John Smith " (signed by me) "John Smith " If they don't know me they can simply do their own fingerprintcheck with John, otherwise they will take the signed key. Thanks for your answers, I know I'm asking unorthodox questions, but I pretty much feel I'm right and the conventional procedure is partly unnecessary and thus hard to understand and difficult to use. Best regards, Jan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
