Re: Proposal of OpenPGP Email Validation

[Neal H. Walfield]

At Mon, 27 Jul 2015 17:51:56 +0200,
Patrick Brunschwig wrote:
> 
> On 27.07.15 14:15, Neal H. Walfield wrote:
> > Hi,
> > 
> > I guess you mean this:
> > 
> >   The idea I have in mind is roughly as follows: if you upload a key to
> >   a keyserver, the keyserver would send an encrypted email to every UID
> >   in the key. Each encrypted mail contains a unique link to confirm the
> >   email address. Once all email addresses are confirmed, the key is
> >   validated and the keyserver will allow access to it just like with any
> >   regular keyserver.
> > 
> > This approach is not going to stop a nation state.  A nation state can
> > intercept the mail, decrypt it and follow the link.
> 
> If the email can be decrypted, then any email can be decrypted, which
> would turn OpenPGP useless.

Sorry.  This was definately unclear.  What I meant is: a nation state
can create a "fake" key, upload it to the key server and intercept the
mail encrypted to the fake key thereby validating the fake key.

> In any case, the target users are not the Edward Snowdens of this world,
> but the 99% of people who just want to communicate easily with each
> other and don't want to be bothered too much with key complicated key
> lookup/verification scenarios.

This is a worthy goal :).

:) Neal

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

Re: Proposal of OpenPGP Email Validation

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Monday 27 July 2015 at 1:33:42 PM, in
, Daniel Baur wrote:


> What could be a problem: The state or the ISP could
> create a key-pair of its own and upload it, intercept
> the mail and verify it.

That certainly would be a problem. I've no idea how likely.


- --
Best regards

MFPA  

None are so fond of secrets as those who do not mean to keep them
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJVtrc7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwFO0H/AlkbVUjVPqi46W3sSaQjxR6
LmQrNbaUzHDdwWWNgBfUCciejRzkwgFUtxCwuMogzsGbObdBVtMsBk8XCkGYoG1O
5mPLyiKP1Mz5mburJZsphrrmwSsH3gjy7Fspa7GnmGkZk3EwdE8AHLEoazViTfQu
ELU0vtJMapqvccafMYLTFnzwm+eaJivtiLlPhL+kBX5opgK4BfB73uw1M3VW9OHl
XP1nKgEO7v8WUVIDkdnyP6fYILdSWAjqdYeQvaIjl8XkJntcnVR2LVZ5fTRNSnbW
imo+ihOskkjMT0Y5GEsgK8KtcG6MYaq1jb+ffbeZtoIy8f40hjF1890FgfEBPYWI
vgQBFgoAZgUCVba3Q18UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45CjfAQCwdabfoGT+SvHNxpQirKYVNF8+
j2lNxxAPC/QYCY+dAwEA7s2QOoHqmgyghBc//is7xFDt3Q0wAyUhE0cuYCKbAg4=
=qn4S
-END PGP SIGNATURE-


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

One Key, multiple Smartcards not working anymore

[Josef Schneider]

Hello,

I have a problem with my Key. I have a 4096bit RSA key since 2012 and it
is stored on a OpenPGP smartcard.
Recently I added three new 2048bit subkeys, because I bought a Yubikey
NEO device and want to use PGP on my phone/tablet with Android and NFC.
This worked as expected. I created the new subkeys on my PC, saved a
backup and then moved them to the card.
PGP showed me correctly that the first three keys are on card 1 and the
second three are on card 2. If the wrong card was inserted, it asked me
to insert the correct one.

I then wanted to create one key backup with all six private keys to
print using PaperBack and store in a safe place. I was able to merge all
the private keys with gpgsplit and moving/renaming files and created
that backup.

After that, I deleted the whole key, got my public key from the
keyservers and tried to use it with the card (after gpg2 --card-status).
Here is now my problem:
GPG adds the key stub for the smartcard keys only for the first card! If
I delete the key, import, use card-status, then I can usse the three
keys from that smartcard. If I insert the second smartcard and do a
card-status, nothing changes!

If I import the full key with all private keys, I can then replace the
keys on the card and move all keys to smartcards. Then I get a key
working with both smartcards again. But of course I don't want to touch
the key backup. It's printed on paper and stored in a safe location for
a reason.

Am I doing something wrong, or is that a bug?

Here are some gpg outputs:

At the moment, I have it here on my notebook working with the 4096bit keys:
sec>  4096R/9BE45ED0 2012-12-10 [verfällt: 2017-04-13]
  Kartenseriennr. = 0005 
uid  Josef Schneider 
uid  Josef Schneider 
ssb>  4096R/B641DD11 2012-12-10
ssb>  4096R/CA02F8EA 2012-12-10
ssb#  2048R/988E7DDD 2015-07-07
ssb#  2048R/03E021FE 2015-07-07
ssb#  2048R/8B406748 2015-07-07

I insert the other card and do a card-status:

C:\Users\Josef Schneider>gpg --card-status
Application ID ...: DXXX
Version ..: 2.0
Manufacturer .: Yubico
Serial number : 
Name of cardholder: Josef Schneider
Language prefs ...: de
Sex ..: männlich
URL of public key : https://j0s.at/gpg.asc
Login data ...: [nicht gesetzt]
Signature PIN : zwingend
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 39
Signature key : 50FD 3663 AB67 A8FD 64BD  C208 1272 58BE 988E 7DDD
  created : 2015-07-07 11:34:08
Encryption key: 88FA 7314 795F 5F19 F258  3B70 E18B C1D9 03E0 21FE
  created : 2015-07-07 11:38:08
Authentication key: E0E5 13F9 AA97 8C8E 1BF5  27FB B6BF D0F7 8B40 6748
  created : 2015-07-07 20:15:08
General key info..: pub  2048R/988E7DDD 2015-07-07 Josef Schneider

sec>  4096R/9BE45ED0  erzeugt: 2012-12-10  verfällt: 2017-04-13
  Kartennummer:0005 
ssb>  4096R/B641DD11  erzeugt: 2012-12-10  verfällt: niemals
  Kartennummer:0005 
ssb>  4096R/CA02F8EA  erzeugt: 2012-12-10  verfällt: niemals
  Kartennummer:0005 
ssb#  2048R/988E7DDD  erzeugt: 2015-07-07  verfällt: 2017-07-06
ssb#  2048R/03E021FE  erzeugt: 2015-07-07  verfällt: 2017-07-06
ssb#  2048R/8B406748  erzeugt: 2015-07-07  verfällt: 2017-10-24


I can't use this key.
After deleting it and import https://j0s.at/gpg.asc :
C:\Users\Josef Schneider>gpg --card-status
Application ID ...: DXXX
Version ..: 2.0
Manufacturer .: Yubico
Serial number : 
Name of cardholder: Josef Schneider
Language prefs ...: de
Sex ..: männlich
URL of public key : https://j0s.at/gpg.asc
Login data ...: [nicht gesetzt]
Signature PIN : zwingend
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 40
Signature key : 50FD 3663 AB67 A8FD 64BD  C208 1272 58BE 988E 7DDD
  created : 2015-07-07 11:34:08
Encryption key: 88FA 7314 795F 5F19 F258  3B70 E18B C1D9 03E0 21FE
  created : 2015-07-07 11:38:08
Authentication key: E0E5 13F9 AA97 8C8E 1BF5  27FB B6BF D0F7 8B40 6748
  created : 2015-07-07 20:15:08
General key info..: pub  2048R/988E7DDD 2015-07-07 Josef Schneider

sec#  4096R/9BE45ED0  erzeugt: 2012-12-10  verfällt: 2017-04-13
ssb#  4096R/B641DD11  erzeugt: 2012-12-10  verfällt: niemals
ssb#  4096R/CA02F8EA  erzeugt: 2012-12-10  verfällt: niemals
ssb>  2048R/988E7DDD  erzeugt: 2015-07-07  verfällt: 2017-07-06
  Kartennummer:0006 
ssb>  2048R/03E021FE  erzeugt: 2015-07-07  verfällt: 2017-07-06
  Kartennummer:0006 
ssb>  2048R/8B406748  erzeugt: 2015-07-07  verfällt: 2017-10-24
  Kartennummer:0006 

I can use the 2048bit keys, but not the 4096

After inserting the first card again:

C:\Users\Josef 

Re: Next Big Future on quantum computation

[Robert J. Hansen]

> Point blank: quantum computers cannot solve NP-Hard problems.  Period,
> end of sentence.  NP-Hard is where the ridiculously difficult problems
> live.

For those who like pedantry: NP-Hard is the name given to any problem
that is as hard, or harder, than any problem in NP.  The Traveling
Salesman Problem is NP, and is known to be as hard as any problem in NP,
therefore it's NP-Hard.

But it's also the *easiest* NP-Hard.

Because remember, NP-Hard is anything as hard *or harder* than anything
in NP.  Playing a perfect game of Go isn't in NP, ergo playing a perfect
game of Go is NP-Hard.  NP-Hard is a collective term that covers a truly
staggering amount of terrain, going from the "easy" problems like
traveling salesman all the way up to the "are you kidding me?" like
reversing entropy.

Few computer scientists like talking about NP-Hard.  It's simply too big
of a space.  And if anyone seriously talks about a general technique
that works on NP-Hard problems, they get laughed at.  Lots.  Because
there isn't one, and we've formally proven there isn't one.  This was
the proof that made Alan Turing famous.

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

Next Big Future on quantum computation

[Robert J. Hansen]

Some people have been all abuzz over this article lately:

http://nextbigfuture.com/2015/07/currently-quantum-computers-might-be.html

Rather than go through it point by point I'm just going to talk about
the author's closing paragraph, which one would expect to have been
pretty closely checked prior to publication.

"Getting 1.4 million times speedup over a single CPU
 is possible now with a Google data center. In ten to
 15 years it could be inside one rack of future
 conventional computers. If that rack of computers
 could not solve your NP-hard problem you could use
 it for many other revenue generating and useful
 applications."

The first "wait, what did you just say?" was his assertion that it's
possible to get a 1.4 millionfold speedup over a single CPU with the
money it would take to build a Google data center.  If it was possible,
don't you think Google, Microsoft, Apple, and Facebook would *already be
building them*?  Entrepreneurs who can afford to do this are
overwhelmingly choosing not to do this.  When the people who should be
doing it aren't, think hard and think twice.

His next claim is just ... it makes no sense to me.  "If that rack of
[quantum] computers could not solve your NP-hard problem..."

Point blank: quantum computers cannot solve NP-Hard problems.  Period,
end of sentence.  NP-Hard is where the ridiculously difficult problems
live.  If you had a computer that could break NP-Hard problems, you
could literally crack one-time pads, predict the future, solve the
Halting Problem, reverse entropy, and essentially become a god.

Okay, so maybe the author had a goof.  Maybe he meant NP-Complete.
That's better, right?  If that rack of computers couldn't solve your
NP-Complete problem you could use it for many other revenue generating
and useful applications.

Except that, by definition, if you're unable to solve *one* NP-Complete
problem, you're unable to solve *any* NP-Complete problem.  It's an
all-or-nothing deal.  You can either solve everything in NP-Complete, or
nothing.  No in-betweens.  So reading his sentence as "couldn't solve
your NP-Complete problem" doesn't improve it.  Can't solve one, can't
solve any.

Let's scale it back some more.  Maybe he meant "If that rack of
computers couldn't solve your NP problem you could...".  Okay.  Now
we're getting kind of close to reality, except that NP is a *big* class
of algorithms -- this is like asking someone to find your lost dog and
saying you're pretty sure you left him in Australia.  It's too vague to
really be meaningful.  NP is like that, but its Outback is bigger.

Take it back a step further: "If that rack of computers could not solve
your BQP problem you could..."  BQP is the set of all algorithms that
can be efficiently solved with a quantum computer.  If that rack of
computers can't solve a BQP problem, then maybe you should consider
whether you've been defrauded.

So that sentence there --

* Can't be true for NP-Hard: you're not a god.
* Is nonsense for NP-Complete: if you can't solve one, you
  can't solve any.
* Isn't particularly well-defined for NP.
* Is trivially true for BQP.


... I'm a thesis shy of a Ph.D. in computer science and I've got
absolutely no idea what the author meant by what he said in that
paragraph.  None.  Zero.  It sounds nice but I'm at a loss to explain
what it means.

I'm not an expert on rocketry, so I won't comment on those parts of the
essay.  But the computer science parts of the essay are all like this:
they're superficially glib but they're just plain *bad*.

Also, check out the author's bio/resume:

http://lifeboat.com/ex/bios.brian.l.wang

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

Re: Proposal of OpenPGP Email Validation

[Ludwig Hügelschäfer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Ingo,

On 27.07.15 16:31, Ingo Klöcker wrote:

> This whole concept of a whitelist of "trusted validation servers"
> included in the email clients sounds a lot like the CA certificate
> bundles included in browsers and/or OSes. Who is going to maintain
> this whitelist?

Whilelists: The OpenPGP-aware clients. There aren't so many of them,
so that's manageable.

> The email client developers? The OS manufactures? Who is going to
> certify "trusted validation servers", i.e. who is going to tell
> benign validation servers apart from malignant validation servers?

There is a community providing keyservers (such as
pool.sks-keyservers.net). My impression is that this network is well
maintained and has worked reliably the last years.

Why should there not be a similar community approach for setting up a
(smaller) network of validating key server proxies.

> I'd rather put my bets on a DANE-based approach like 
> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/

DANE requires write access to DNS. I don't see that the average
OpenPGP user has facilities and knowledge to achieve setting up the
required DNS records. If you can't convince the big mail providers
(e.g. Google, GMX here in Germany, ...) to provide a reasonable
interface for their users, I'm afraid that this will not be a success,

Ludwig

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVtoDzAAoJEDrb+m0Aoeb+/NcP/ioUVK5tlkZ7bXlkiKKtaB1f
7EpTqpkg2gIY0ev6xhAWwLoDsACLX/iCmVu+OHgJbRFYo/e5m6FHzxpWEMMxgsON
Dn7yuuHtxDxWQmX3LzPzG3GU3x2ynKuR7V5iyj4p1fbVYmijaIraOpbPaM5wKjP+
2m5+QZjAHrHzFIrj4LadiaJmCn5HVfGcttqxc3I8u/oQl3uXoB1XTIa+Xf5lt2vG
7FUchBZCWSZVzShLk2PYU9ZYHK1/oMYFBS0qMgYtZeGnuCMUUbKFsPjfaqEAq/I9
95dxk9GSssxdANGFjyT9Q1fMdrJOdi/rAENCzHHQ+Tmj6Aa2cn46DNxjiqEjA77V
YPvlLm9Sjec/UvpaJ3aYVhu+uHl7FwEsNe+ZA1W/y9HmdISCrmorpHi3SOCGJIWR
PbGmRthYjDPQ7wK0naQ5my5prum586Cs9dloHMFuW/1jd7K2rC8GkOhR2KDpsHr3
L1sGovfBtahy3uVOOvqILZzX61qen9ACd/7XJBXOYurytgzXFzz8FtRehdwf31Of
3VnprnXPIWwOQ6Xj0lcilw3Ff3t8T2PgJqLftBxF+64bqtlP63XzFMNWo87a0nbo
WfG13WHLdBEmWo2TiAA8EHFWCCW+HlGVclo+5mR/NBgFKlZhF4kAhgcaTwLvP6ke
TnJfQ7Ba8btK1vP/5nfq
=L7BF
-END PGP SIGNATURE-

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

Re: Proposal of OpenPGP Email Validation

[Juan Miguel Navarro Martínez]

On 2015/07/27 at 21:08, Neal H. Walfield wrote:
> If this is not right please point me to the proposal.  The above is
> just a quote from the single source in your original email.  After I
> read that I will respond to your other questions / comments.
> 
> :) Neal
> 

It's attached in the OP named "OpenPGP-Email-Validation-20150726.pdf"

-- 
Juan Miguel Navarro Martínez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF

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

Re: Proposal of OpenPGP Email Validation

[Neal H. Walfield]

Hi Nico,

At Mon, 27 Jul 2015 19:21:10 +0200,
n...@enigmail.net wrote:
> 
> Thanks, Neal for the feedback.
> I will try to answer.
> 
> Am 27.07.2015 um 14:15 schrieb Neal H. Walfield:
> > Hi,
> > 
> > I guess you mean this:
> > 
> >   The idea I have in mind is roughly as follows: if you upload a key to
> >   a keyserver, the keyserver would send an encrypted email to every UID
> >   in the key. Each encrypted mail contains a unique link to confirm the
> >   email address. Once all email addresses are confirmed, the key is
> >   validated and the keyserver will allow access to it just like with any
> >   regular keyserver.
> > 
> Hmm, not quite right, there are two major points where I think
> there is some misunderstanding:

If this is not right please point me to the proposal.  The above is
just a quote from the single source in your original email.  After I
read that I will respond to your other questions / comments.

:) Neal


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

Re: Proposal of OpenPGP Email Validation

[n...@enigmail.net]

Hi Ingo,
thanks a lot for the feedback.

Am 27.07.2015 um 16:31 schrieb Ingo Klöcker:
> On Monday 27 July 2015 07:55:03 n...@enigmail.net wrote:
>> Hi all,
>>
>> in March we discussed here
>> "German ct magazine postulates death of pgp encryption"
>> and Patrick Brunschwig proposed a way to validate email addresses
>>
>> I also had in mind:
>>> http://lists.gnupg.org/pipermail/gnupg-users/2015-March/052882.html
>>
>> In the past months I tried to come up with a concrete proposal.
>> I discussed it already with some people and
>> this is what I/we propose so far.
>> The proposal is not perfect and not completely worked out
>> but IMO it is ready for a broader discussion and review.
> 
> This whole concept of a whitelist of "trusted validation servers" included in 
> the email clients sounds a lot like the CA certificate bundles included in 
> browsers and/or OSes. Who is going to maintain this whitelist? The email 
> client developers? The OS manufactures? Who is going to certify "trusted 
> validation servers", i.e. who is going to tell benign validation servers 
> apart 
> from malignant validation servers?
> 
I agree that this is a key issue/problem of the approach.
And indeed, I suggest to initially or by default give some trust
to some signatures.

Note that I propose different things, though:
1) A standard format for such validations.
   This simply would help to be able to deal with any
   validation approach.
2) A way to establish such validations
   by using a validating key server proxy.
3) A whitelist.

I am happy to only have 1) and 2) and to teach people
to trust e.g. specific servers (and to mistrust others).

I only want to have a way to manage email validations
(a common technique where everybody wonders why this
 is not supported).
This is the best I could come up with after discussing this
with several people.
And so far it would be a lot more than we have now.
It it might fix a problem which otherwise is a show stopper.

If this is not appropriate, what do YOU propose instead
for email validation?
So many processes in this world are today based on email validation.
Do you think that in general email validation is not the right approach
or do you propose something different?

> Your proposal seems to repeat a lot of the (failed) concepts of the 
> centralized CA approach. For this reason I think the approach is doomed to 
> fail the same way the centralized CA approach has failed (even if everybody 
> seems to ignore its failure).
> 
I TRIED to avoid some of them:
- avoiding to many signatures
- providing no central solution
It's the best I could come up with.
I don't see any other form but may be you know better.
Tell me!

> I'd rather put my bets on a DANE-based approach like 
> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/
> 
I am happy with ANY solution here.
I don't know all the details about DANE, but as far as I know
it is promising but well not established yet.
If we don#t need my proposal, great!
But if establishing DANE will take more time or if there are
some flaws with it), I would like to have this solution
because IMO it would help.
But I might be wrong.

Thanks and all the best
  Nico

BTW, the name sounds German and I am happy to discuss this whole issue
with you in person.

> 
> Regards,
> Ingo

-- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5


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

Re: Proposal of OpenPGP Email Validation

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/27/2015 07:55 PM, n...@enigmail.net wrote:
> Hi MFPA, Thanks a lot for your feedback.

..

> 
>> Why would the notation value be base64 encoded? What is the
>> rationale for preventing users from reading the notation values
>> in a key listing?
> 
> Hmm, it was a recommendation by Kristina Fiskerstrand: "the value
> should be base64 encoded to avoid some issues" @Kristian: Can you
> elaborate on that?

It makes the information more compact and will make hkp vindex lists
look cleaner. Presuming this information contains data objects in json
format it will be interpreted by a parser, and raw data from
keyservers anyways shouldn't be trusted directly before validating the
signature (including its subpackets/notations) since no crypto has
been performed at that point.

- -- 
- 
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
"Knowing is not enough; we must apply. Willing is not enough; we must do
."
(Johann Wolfgang von Goethe)
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVtnGkAAoJECULev7WN52FyFAIAKgXWzCuH8/k96sw+Bgw4Y5O
fuAzTVTFk4D4UO9F0T1YIinfWNiDXV37sOGdGdgR5BGNGSyeXNU3R0GgyeM4NTaT
K8UGnY2xwpY2wndi8rKpLVj5uoLofCrvhnrqJ1juuNHOXy0xuQarYwB5/5TWYfgT
rBBMeIrEUgBita8Eh+7/0H4AkmRioTJIcHZDNqySqA5UF9ai6skcvVIoyh/zAmtH
230shQfx4XG4wJpWTRE7W0oCyEMBl38Pdno0c2GfJ7rHszpnk3DnOViyf9JHFzvI
rjWP0DTP7CCsJ3N0YomphnDGxtpZyKJw3R8znk1CU3Q8quZ/R1dlkvF8alwGfxI=
=XKeM
-END PGP SIGNATURE-

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

Re: Proposal of OpenPGP Email Validation

[n...@enigmail.net]

Thanks, Neal for the feedback.
I will try to answer.

Am 27.07.2015 um 14:15 schrieb Neal H. Walfield:
> Hi,
> 
> I guess you mean this:
> 
>   The idea I have in mind is roughly as follows: if you upload a key to
>   a keyserver, the keyserver would send an encrypted email to every UID
>   in the key. Each encrypted mail contains a unique link to confirm the
>   email address. Once all email addresses are confirmed, the key is
>   validated and the keyserver will allow access to it just like with any
>   regular keyserver.
> 
Hmm, not quite right, there are two major points where I think
there is some misunderstanding:

First, I DON'T propose to use key servers here.
In agreement with Kristian Fiskerstrand we propose to give
other servers the task.
As written, these "validation servers" should ideally operate as key
server proxies, though, passing all requests to keyservers and responses
back to email clients, while in addition doing/triggering email validations.
But for ordinary keyservers validations servers "only" provide
validation signatures as any other email client can do.

Second, because the signatures sign UIDs (not keys),
each UID is individually signed.
A validation server could wait to upload the key to a key server
until the FIRST email address is signed.
But in principle, uploading a key or a new UID for the key
is different from triggering its validation (and as a result uploading
the corresponding validation signature to the UID(s)).

> This approach is not going to stop a nation state.  A nation state can
> intercept the mail, decrypt it and follow the link.
> 
Sorry, don't know what a nation state is.

> For the same reason, it is not going to stop a user's ISP.  Given
> Microsoft's et al.'s willingness to cooperate with the NSA, these are
> not very good starting conditions.
> 
Although, Daniel answered, I didn't quite get the problem here
and would be happy if you prefer to explain the problem a bit in detail
(yes, sorry, I am not an expert).

> The approach also has another problem: which key servers are going to
> do this?  There are 100s of key servers.  I'm not going to reply to
> mails from each one, sorry.
> 
Hmm, I though I discussed that but may be my wording was bad.
Indeed, there should only by one validation request per email address
each year.
For this, we'd trust multiple validation signatures. But yes,
as I wrote, we have to maintain white- and/or black lists then
(in email clients or where ever).
And yes, THIS can be(come) a problem.

> This also seems like a nice way to spam someone.  Generate a key,
> upload it to a key server and they have a bunch of mails from the key
> server.  Based on this, I suspect that it won't take long for the key
> servers to be blacklisted?
> 
We though about that, but right I didn't write anything about it.
We might follow the following rule:
- Once validated, no re-validations can be triggered
  within the 12 months the signature is valid
  (may be unless the owner of the key itself troggers the re-validation)
- But yes, then we have the problem of others uploading
  faked keys (the problem we want to solve).
  First: May be it's fine that people get informed that
 faked keys are uploaded.
 At least I personally would like to know that.
  Then: I could trigger my own validation and as written
in the first bullet disable any other validations
unless triggered by me.
  Thus, once there is a successful validation
this is no loner a problem.

> Have you considered these issues?  Do you have any thoughts about how
> to avoid these problems or do you think they are not real problems?
> 
At least a part of them, I hope.
But I would not be surprised having overlooked some stuff.
You are the experts.
I only want to solve the problem.

And indeed , the question, how to avoid to many validation requests
while at the same time having multiple validation servers
is something I am pretty unsure about details.
I am happy for any help here.

> Regarding the design: personally, I wouldn't have the user follow a
> link that includes a swiss number, but have the user reply to the
> mail, include the swiss number and sign it.
> 
OK, that's of course also possible.
Any reason why this is something you prefer?

> I'd also consider having the key servers publish the validations.  If
> you chain the validations (include the hash of the previous validation
> in the current validation) you can detect if the key servers serve a
> fake key to a specific user.
> 
OK, interesting idea.

Thanks a lot
  Nico

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

-- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5


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

Re: Proposal of OpenPGP Email Validation

[Kristian Fiskerstrand]

On 07/27/2015 07:46 PM, Werner Koch wrote:
> On Mon, 27 Jul 2015 14:15, n...@walfield.org said:
> 


> 
> You can't do that due to the decentralized approach with no
> requirement for the user to always upload to the same keyserver.
> Thus a server may miss validation signatures not yet received from
> other servers.

The way I read this proposal isn't about keyservers per se, but the
individual validation servers publishing a chained list (like a
blockchain) of its validations. There is merit to that proposal for
auditing purposes, although I'm not entirely sure how it'd work in
practice unless the blockchain itself was decentralized (it can't
function securely if completely local to validation server). iirc this
is what Google is doing with its approach as well[0].

References:
[0] http://www.certificate-transparency.org/

-- 

Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"Knowing is not enough; we must apply. Willing is not enough; we must do."
(Johann Wolfgang von Goethe)



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

Re: Proposal of OpenPGP Email Validation

[n...@enigmail.net]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi MFPA,
Thanks a lot for your feedback.

Am 27.07.2015 um 15:16 schrieb MFPA:
> Hi
> 
> 
> On Monday 27 July 2015 at 6:55:03 AM, in
> , n...@enigmail.net wrote:
> 
> 
> 
>> Thus, I am happy for any feedback (details and general
>> remarks) both here and directly as email to me.
> 
> 
> Comments in no particular order, just as they occurred to me when
> looking through your paper:-
> 
> 
> 
> If a key is validated by the proxy, then subsequently uploaded again
> with a new UID, does the new UID get a validation expiry date that
> matches the rest of the key? Or does it get a standard 12-month
> validation period, but still get re-validated the next time one of the
> other UIDs needs it, so that all UIDs' validation expiry dates are
> brought back into sync? And what if the upload with an extra UID hits
> a different validation server?
> 
Hmm, I didn't think about that in detail.
But I would assume that because each validation validates a specific
email address, a validation once each year is enough.
I see no problem with both attempts:
- - If the goal is to keep validations in sync,
  key owners might have to confirm emails added over the year
  earlier, which shouldn't be too bad.
- - If the goal is to reduce validation requests, I see no
  problem to have different expiration dates.
I think, because each email should be validated from time to time anyway
(and this is an isolated process), each validation should give
the 12 month period for the specific email when it is validated.
Or do you see any problems?


> If a third party has uploaded my key, or if the validation server is
> automatically validating existing keys in response to certain events,
> the validation emails are unsolicited by me. Most people will not
> click a link in such an email.
> 
OK, I agree (unless this feature is widely accepted ;-) ).
So may be, for the beginning, validations can only be triggered
when keys are uploaded (not when they are downloaded).

> If a third party who can intercept my emails has generated a key
> containing my email address in a UID, all bets are off.
> 
This whole approach is NOT to make a perfect prove that the email
is correct.
It only says that the email did one day work for a validation
of any kind, which is more than what we have now.
That is, such a validation does not give full trust, it
would only give slightly more trust over emails that
do not have the validation.
But that might be enough to solve the faked key issue.
This is BTW no different than for any other validation email
in common systems. They also don't give more guarantee.
Thus this solution does NOT solve the problem of
interception of emails.
But it helps to detect them (if this happens the ct guys
know that the problem is a lot worse than they thought)
and helps in case this is the result of internet trolls.

> If an email provider provides public keys for their customers,
> presumably those keys are unsuitable for mail encryption because the
> provider may have access to the private key.
> 
It depends on whether and how far you trust the provider.
Reality looks different (see startmail, posteo, riseup, and many company
email servers).
I don't claim to solve any problem in that area.
User/clients might have to decide whether to trust
a validation notation given by posteo, riseup, google, ...

> The configuration changes for email clients that you mention, things
> like which keyserver to use and which keys to trust, need to be set in
> GnuPG.conf (or maybe some form of GnuPG wrapper or plugin) so that
> they are used by an email client that simply calls GnuPG and therefore
> honours GnuPG's own settings. Same for trust models; maybe you should
> consider suggesting a modified trust model for GnuPG that includes
> options for handling validation signatures.
> 
THAT's a bigger step, but if Gnu wants to support it
(which would mean that they think that this approach is fine),
I am happy if this happens.
For the moment I try to minimize additional requirements
to be able to support this approach pretty fast
(for people who want it).
And I really try to got at least some solution for this problem,
which I consider to be one show stopper to establish email encryption.

> Blacklists should not be used *anywhere* as they are a form of
> censorship and can be used for DOS attacks.
> 
OK, don't we even have some blacklists in key servers? ;-)
But I agree, that's something we have to discuss or find out in detail.

> In your proposal for listing validation signatures in GnuPG:
> "‘!’ after sig signals successful validation" - why is this needed?
> Surely the mere presence of a validation signature signals successful
> validation.
> 
Hmm, Wener recommended to use
 --check-sigs
rather than
 --list.sigs
which then results in printing the '!'.
Isn't it necessary in your opinion?

> Why would the notation value be base64 encoded? What is the rationale
> for preventing users from reading the notation 

Re: Proposal of OpenPGP Email Validation

[Werner Koch]

On Mon, 27 Jul 2015 14:15, n...@walfield.org said:

> The approach also has another problem: which key servers are going to
> do this?  There are 100s of key servers.  I'm not going to reply to
> mails from each one, sorry.

As Nico described, PGP used a very simlar system to validate keys and
expire them based on the date of the last validation.  However, that
system worked with because they control the central server and the
server did not sync with the other keyserver automatically.  The
validation signature you find on some the keys are due to faulty manual
syncing (download from pgp.com upload to pgp.net).  A solid approach for
central crypto server.

> I'd also consider having the key servers publish the validations.  If
> you chain the validations (include the hash of the previous validation

You can't do that due to the decentralized approach with no requirement
for the user to always upload to the same keyserver.  Thus a server may
miss validation signatures not yet received from other servers.


Salam-Shalom,

   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

Re: Proposal of OpenPGP Email Validation

[Patrick Brunschwig]

On 27.07.15 14:15, Neal H. Walfield wrote:
> Hi,
> 
> I guess you mean this:
> 
>   The idea I have in mind is roughly as follows: if you upload a key to
>   a keyserver, the keyserver would send an encrypted email to every UID
>   in the key. Each encrypted mail contains a unique link to confirm the
>   email address. Once all email addresses are confirmed, the key is
>   validated and the keyserver will allow access to it just like with any
>   regular keyserver.
> 
> This approach is not going to stop a nation state.  A nation state can
> intercept the mail, decrypt it and follow the link.

If the email can be decrypted, then any email can be decrypted, which
would turn OpenPGP useless.

> For the same reason, it is not going to stop a user's ISP.  Given
> Microsoft's et al.'s willingness to cooperate with the NSA, these are
> not very good starting conditions.

If (and only if) the user stores his private key on his computer, and
the connection to the validating key server is HTTPS with PFS, I don't
really agree.

In any case, the target users are not the Edward Snowdens of this world,
but the 99% of people who just want to communicate easily with each
other and don't want to be bothered too much with key complicated key
lookup/verification scenarios.

> The approach also has another problem: which key servers are going to
> do this?  There are 100s of key servers.  I'm not going to reply to
> mails from each one, sorry.

The idea is that these servers are separate from the keyserver network.
That is, a relatively small set of servers that would only do validation
of email addresses. Validated keys would then be uploaded to normal key
servers.

> This also seems like a nice way to spam someone.  Generate a key,
> upload it to a key server and they have a bunch of mails from the key
> server.  Based on this, I suspect that it won't take long for the key
> servers to be blacklisted?

True, but this only serves the purpose of spamming someone without any
further action. You cannot send specific text to those who get spammed,
that's thus not very interesting. But in general, that's certainly
something to consider (such as only accepting one key at a time and only
accepting N keys per hour from some IP address).

> Have you considered these issues?  Do you have any thoughts about how
> to avoid these problems or do you think they are not real problems?
> 
> 
> Regarding the design: personally, I wouldn't have the user follow a
> link that includes a swiss number, but have the user reply to the
> mail, include the swiss number and sign it.

That's a good idea indeed.

> I'd also consider having the key servers publish the validations.  If
> you chain the validations (include the hash of the previous validation
> in the current validation) you can detect if the key servers serve a
> fake key to a specific user.

Sounds like a good idea.

-Patrick



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

Re: Archaic PGP usage

[Werner Koch]

On Fri, 24 Jul 2015 17:49, ved...@nym.hush.com said:

> PGP 2.x can be used as a uuencode, and automatically split a signed
> and encrypted armored file into 100 smaller files ready to be emailed
> and reconstitued by the receiver.

OpenPGP also defines such an armor option but it is not implemented by
GnuPG because:

 - It is better to use the standard MIME feature for splitting messages.

 - Mail has replaced BBSs and we have other constraints now than the
   small maximum message size of 30 years ago.

 - Remailers need to employ their own system to send data in fixed size
   charges and can't use the PGP format.


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

Re: Proposal of OpenPGP Email Validation

[Ingo Klöcker]

On Monday 27 July 2015 07:55:03 n...@enigmail.net wrote:
> Hi all,
> 
> in March we discussed here
> "German ct magazine postulates death of pgp encryption"
> and Patrick Brunschwig proposed a way to validate email addresses
> 
> I also had in mind:
> > http://lists.gnupg.org/pipermail/gnupg-users/2015-March/052882.html
> 
> In the past months I tried to come up with a concrete proposal.
> I discussed it already with some people and
> this is what I/we propose so far.
> The proposal is not perfect and not completely worked out
> but IMO it is ready for a broader discussion and review.

This whole concept of a whitelist of "trusted validation servers" included in 
the email clients sounds a lot like the CA certificate bundles included in 
browsers and/or OSes. Who is going to maintain this whitelist? The email 
client developers? The OS manufactures? Who is going to certify "trusted 
validation servers", i.e. who is going to tell benign validation servers apart 
from malignant validation servers?

Your proposal seems to repeat a lot of the (failed) concepts of the 
centralized CA approach. For this reason I think the approach is doomed to 
fail the same way the centralized CA approach has failed (even if everybody 
seems to ignore its failure).

I'd rather put my bets on a DANE-based approach like 
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/


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: Proposal of OpenPGP Email Validation

[Werner Koch]

On Mon, 27 Jul 2015 07:55, n...@enigmail.net said:

> Thus, I am happy for any feedback
> (details and general remarks)

Plain text would be appreciated.  I accidentally accepted that 280k PDF
but sending such files to 2600 subscribes should be the exception.


Salam-Shalom,

   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

Re: gpg 2.1.6 toggle doesn't

[Marko Božiković]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 27/07/2015 14:31, MFPA wrote:
> Hi
> 
> 
> On Monday 27 July 2015 at 11:46:09 AM, in 
> , Marko Božikovic wrote:
> 
> 
>> I know that, and I'm using 2.1 exclusively... Still, it would be nice
>> to be able to see the state of private keys (e.g. primary key not
>> present in the keyring, private keys are on the card, etc) while
>> editing keys. It seems that the only way to see private key info is 
>> running gpg(2) -K (or am I missing something?)
> 
> When I run gpg -K, or gpg --list-secret-keys, the listing for each key 
> starts with the location of pubring.kbx and not the location of 
> private-keys-v1.d.
> 

Hi,

I'm not sure we're talking about the same thing...

When I run gpg -K (2.1), I get a listing of my private keys' info from my
pubring.kbx. In the listing, there are indicators for missing/deleted
private keys (sec#) and private key "placeholders" (not sure if that's the
term) for keys that are stored on the card (ssb>).

This is what the output looks like (notice # and >'s)

sec#  rsa4096/ 2015-05-11 [expires: 2018-05-10]
uid   [ultimate] 
uid   [ultimate] 
...
ssb>  rsa2048/ 2015-05-11 [expires: 2016-05-10]
ssb>  rsa2048/ 2015-05-11 [expires: 2016-05-10]
ssb>  rsa2048/ 2015-05-11 [expires: 2016-05-10]

Previously, using toggle, you could see that info while running gpg --edit-key

Cheers,
- -- 
Marko
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVtjr4AAoJEE8XQV0qn4BvSGEH/25G8HLCdrVmXgs9YRXfpWqp
Y62qTVfj/4YSpm0MHcQAn07f0GUoJparduX2Lh/hAd92ujb6Slg73AJWewza1oqd
m59J4+KWN22oFOBqaqBTK1eYXmSLSj9U9DwDXVxAvancGodME2krwsyLHgHUTeVU
yDaqoe+GK+eaX+K7v4yJ99rK8yUC26CGCcjj5Ygy0dAYIpYLNVS+8ATfaCgxlLx2
/0/DiaGog4cKWol3pJm2881RFyyE9JhgepzW+4cXuKBx0lDSJxt5DUg67VK2yJpX
XVmM1IrkKMXZkxoBQDulRrRh73YwJ5pY124sad9bzz714uAWKhiEBa+Z+YUf6mk=
=k8ug
-END PGP SIGNATURE-

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

Re: Proposal of OpenPGP Email Validation

[Daniel Baur]

Hello,
Am 27.07.2015 um 14:15 schrieb Neal H. Walfield:
> This approach is not going to stop a nation state.  A nation state can
> intercept the mail, decrypt it and follow the link.
> 
> For the same reason, it is not going to stop a user's ISP.  Given
> Microsoft's et al.'s willingness to cooperate with the NSA, these are
> not very good starting conditions.

As far as I understand, the email is encrypted with the public key of
the owner – so as long as we think that GPG is safe, Nico’s
verification-emails should be also safe.

What could be a problem: The state or the ISP could create a key-pair of
its own and upload it, intercept the mail and verify it.

Sincerely,
DaB.





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

Re: gpg 2.1.6 toggle doesn't

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Monday 27 July 2015 at 11:46:09 AM, in
, Marko Božikovic wrote:


> I know that, and I'm using 2.1 exclusively... Still, it
> would be nice to be able to see the state of private
> keys (e.g. primary key not present in the keyring,
> private keys are on the card, etc) while editing keys.
> It seems that the only way to see private key info is
> running gpg(2) -K (or am I missing something?)

When I run gpg -K, or gpg --list-secret-keys, the listing for each key
starts with the location of pubring.kbx and not the location of
private-keys-v1.d.




- --
Best regards

MFPA  

When it comes to humility, I'm the greatest.
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJVtjLMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw1ngIALjT1LY1U8g1sMIlRN409dn/
c4AKgkByMKjUKd3uL+fYRn6akpBNgO7JDz7PmRN48CtddhSgnTGqGMOEq44fldy+
XK22HMgP8tXMyZ/JK3VH12TndDY4EbcXlfQt3/NkqussQo0t8ZYETLZ6waAIOrhQ
0/0OgQ+jY4SYHsYrd9+1qkIdGioEXJKUjgpncDw23YlvtvxqJXw8qgnAa6tM/JYV
N0vVTjdmqjiLWcE2scoWdhzdVkFsfP5ZUZplGYRS1qmsGfnqw1gdQei6IdC8Ix2p
OzBoVqglFaVWhsyIZUeYKYspH/z4uZXNDs9HQV9jAMbvIzJqPR/gf6f1aBmGXeiI
vgQBFgoAZgUCVbYyzV8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45IfJAQDr1dvBpa8gkBAj+7wso3UoFAv4
tCe7nvS5djPAwuTN4AEA9OeeoQcRqN1aJkD8QjwzqyD69dclfPQPVsI+sYw8bAo=
=QJbV
-END PGP SIGNATURE-


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

Re: Proposal of OpenPGP Email Validation

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Monday 27 July 2015 at 6:55:03 AM, in
, n...@enigmail.net wrote:



> Thus, I am happy for any feedback (details and general
> remarks) both here and directly as email to me.


Comments in no particular order, just as they occurred to me when
looking through your paper:-



If a key is validated by the proxy, then subsequently uploaded again
with a new UID, does the new UID get a validation expiry date that
matches the rest of the key? Or does it get a standard 12-month
validation period, but still get re-validated the next time one of the
other UIDs needs it, so that all UIDs' validation expiry dates are
brought back into sync? And what if the upload with an extra UID hits
a different validation server?

If a third party has uploaded my key, or if the validation server is
automatically validating existing keys in response to certain events,
the validation emails are unsolicited by me. Most people will not
click a link in such an email.

If a third party who can intercept my emails has generated a key
containing my email address in a UID, all bets are off.

If an email provider provides public keys for their customers,
presumably those keys are unsuitable for mail encryption because the
provider may have access to the private key.

The configuration changes for email clients that you mention, things
like which keyserver to use and which keys to trust, need to be set in
GnuPG.conf (or maybe some form of GnuPG wrapper or plugin) so that
they are used by an email client that simply calls GnuPG and therefore
honours GnuPG's own settings. Same for trust models; maybe you should
consider suggesting a modified trust model for GnuPG that includes
options for handling validation signatures.

Blacklists should not be used *anywhere* as they are a form of
censorship and can be used for DOS attacks.

In your proposal for listing validation signatures in GnuPG:
"‘!’ after sig signals successful validation" - why is this needed?
Surely the mere presence of a validation signature signals successful
validation.

Why would the notation value be base64 encoded? What is the rationale
for preventing users from reading the notation values in a key
listing?

Notation version numbers. Rather than using different notation names
such as validation...@enigmail.net, I would think it better to keep
the notation name standard and put the version number at the start of
the value string.



- --
Best regards

MFPA  

Of course it's a good idea - it's mine!
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJVti9OXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwomYIAKOZABvgm+ThrS8fEVBss0ZC
YGum47Mu1j72FAAVZWw2q/w34sOOpZmBU4SdqFYVtvy+g3+KpdBviybU3pZCjUx9
220pOHjLzyWOA1Kg4yl3N9NDRRzN70IvTf3S1jEwiJAedr4dH1Wq25SlS8vICj6r
JYohh9Cp4fEBXQTA7IJVvHUE6AbVRfeN4HqyaDCfLN3Om0m37fws2J9p6w9u7CnI
Pkuku+BwMMzJX2bqJo4rEQ9f777FGpyicAfj0xVEZuwfa5zZ6Uc5sWaxc9RXyjw7
zKHpwllefD3xhV7SavEjea5cmU2GpNuPDHwYB2tzMq3PR/zZxMdK8qF2tgTqpDmI
vgQBFgoAZgUCVbYvU18UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45HYGAQCMDqnx5p5GssdlNRjamhGLZ722
jSiKwhEuScsRNcg2dAEA5QtVWIzazuuC8KJB9kERVyXCnoWUu9QD7Rlatzh6wAU=
=0XZS
-END PGP SIGNATURE-


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

Re: Proposal of OpenPGP Email Validation

[Neal H. Walfield]

Hi,

I guess you mean this:

  The idea I have in mind is roughly as follows: if you upload a key to
  a keyserver, the keyserver would send an encrypted email to every UID
  in the key. Each encrypted mail contains a unique link to confirm the
  email address. Once all email addresses are confirmed, the key is
  validated and the keyserver will allow access to it just like with any
  regular keyserver.

This approach is not going to stop a nation state.  A nation state can
intercept the mail, decrypt it and follow the link.

For the same reason, it is not going to stop a user's ISP.  Given
Microsoft's et al.'s willingness to cooperate with the NSA, these are
not very good starting conditions.

The approach also has another problem: which key servers are going to
do this?  There are 100s of key servers.  I'm not going to reply to
mails from each one, sorry.

This also seems like a nice way to spam someone.  Generate a key,
upload it to a key server and they have a bunch of mails from the key
server.  Based on this, I suspect that it won't take long for the key
servers to be blacklisted?

Have you considered these issues?  Do you have any thoughts about how
to avoid these problems or do you think they are not real problems?


Regarding the design: personally, I wouldn't have the user follow a
link that includes a swiss number, but have the user reply to the
mail, include the swiss number and sign it.

I'd also consider having the key servers publish the validations.  If
you chain the validations (include the hash of the previous validation
in the current validation) you can detect if the key servers serve a
fake key to a specific user.

Neal


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

Re: gpg 2.1.6 toggle doesn't

[Marko Božiković]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 27/07/2015 10:14, Kristian Fiskerstrand wrote:
> On 07/27/2015 11:03 AM, Kristian Fiskerstrand wrote:
>> On 07/27/2015 10:48 AM, Marko Božiković wrote:
>>> On 25/07/2015 13:26, MFPA wrote:
 Hi
> 
> 
>> ..
> 
>>> Ok, but why doesn't it make much sense anymore? Is there another way
>>> to get private key info while in --edit-key mode? (e.g. key location,
>>> like the bug submitter mentions)
> 
> 
>> 1.4 and 2.0 have separate keyrings for public keys (pubring.gpg) and
>> private keys (secring.gpg). In 2.1 everything is handled in agent and
>> keys stored in platform agnostic format on per-key basis based on
>> keygrip. I.e. there is no more toggling between keyrings.
> 
> 
> 
> Was a bit quick there, so to clarify that a bit, all secret-key 
> operations are handled in the agent, and based on keygrip calculated in
> the single-store public keyring.

I know that, and I'm using 2.1 exclusively... Still, it would be nice to be
able to see the state of private keys (e.g. primary key not present in the
keyring, private keys are on the card, etc) while editing keys. It seems
that the only way to see private key info is running gpg(2) -K (or am I
missing something?)


- -- 
Marko
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVtgvqAAoJEE8XQV0qn4Bv4dEIAKSOxfmrbgXZHK+0lzYMgSeB
5Mm3MWHBKx7mq6ffMm/MBsCoxjjLGf/boTTrG0t0DYjhKw0svZjEAkYegSYI5wqG
nt53+RtUTIbhcoSn1Fca+zoR5ppzTHMu+cKA1r2E6H/UgBovTcu+dpCa6he0Lqef
VQIf5ESJUi53Av9Wphjozt/RE2MSueijMG067fRyy8pfrw63nPvoo0u3toxxO0r1
mzwLKdVeM+3O1mhtJOzBrB4YWPoFT6kzvjHLGyxiMlcjTPQMCfW0jH5h6j65FFa9
m+f+s7f0x7FbXWpQAl/IjIfgpiL5mHCh0jAWvZWQxCS6dbe0lR7CB58PIgmBAE0=
=rgVw
-END PGP SIGNATURE-

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

Re: gpg 2.1.6 toggle doesn't

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/27/2015 11:03 AM, Kristian Fiskerstrand wrote:
> On 07/27/2015 10:48 AM, Marko Božiković wrote:
>> On 25/07/2015 13:26, MFPA wrote:
>>> Hi
> 
> 
> ..
> 
>> Ok, but why doesn't it make much sense anymore? Is there another 
>> way to get private key info while in --edit-key mode? (e.g. key 
>> location, like the bug submitter mentions)
> 
> 
> 1.4 and 2.0 have separate keyrings for public keys (pubring.gpg)
> and private keys (secring.gpg). In 2.1 everything is handled in
> agent and keys stored in platform agnostic format on per-key basis
> based on keygrip. I.e. there is no more toggling between keyrings.
> 
> 

Was a bit quick there, so to clarify that a bit, all secret-key
operations are handled in the agent, and based on keygrip calculated
in the single-store public keyring.

- -- 
- 
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Aquila non capit muscas
The eagle does not hunt flies
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVtfZ6AAoJECULev7WN52F/ucH/0TiasUsLalQsJsgjTuSG3Ee
ZBX90BOZOoxGvitIuLqY61+78Bwz0nSZe91Ar+UTPxZM+PnJIkL/tFwobJ5r6Oci
fopEU8OZzWxSafLlPEr4CZkzy9lOqfra+jFyYnNXPVsbR/hQhFyi5bfnRA1gy0Jg
NEEhUbWVHBt/V4ee79pVJMd9X5mRDDnknuQPLEvr8TdAYf+nK0AUKl0vHAF9JzCq
bMIywD0RzzdVALucuWknu/qJIqS4VEA3ON1Y3Ipx52+PSqAo4LkHY9BDUmQuRUd5
GV6024G3e5Laj4PVz8eulKlMUIGInJX9CvJxDxggFWSZpnTpT+XlOdtWnVO1fr0=
=ZaSY
-END PGP SIGNATURE-

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

Re: gpg 2.1.6 toggle doesn't

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/27/2015 10:48 AM, Marko Božiković wrote:
> On 25/07/2015 13:26, MFPA wrote:
>> Hi


..

> Ok, but why doesn't it make much sense anymore? Is there another
> way to get private key info while in --edit-key mode? (e.g. key
> location, like the bug submitter mentions)
> 

1.4 and 2.0 have separate keyrings for public keys (pubring.gpg) and
private keys (secring.gpg). In 2.1 everything is handled in agent and
keys stored in platform agnostic format on per-key basis based on
keygrip. I.e. there is no more toggling between keyrings.


- -- 
- 
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
"History doesn't repeat itself, but it does rhyme."
(Mark Twain)
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVtfPyAAoJECULev7WN52F2vcH/A2yB6w0XG6XjHw0+YBMna1y
A5FcA4c2W9CcQX/U2S8jhpAKP9e0yA4Z2dELKIyZoQhOEy5P9MHMKyQPC7z/dSP5
TW8G0/0gU1DyVTO+QtL4UvfSySjJXL8sXiEtq33aOIwdlhqB6+ev9Q8H3JHOqnLj
d/TmC8YeYGs2eKCnhQT9UEvuTzCzWSAbuiFFOOplCqvMraLHchECxrB7MxDsy9AV
1Jk/pACiaaiPDmJASufwL+WmLN96EJqEX5UM475Da3CsKmxuS+OV7pHUI0TDxvnM
/edCHHMr1jq3KqqsFWAoo79rQc1RZnXX7A0TryT8BgEy7VX8gfaTWEagcDP83vk=
=6DnW
-END PGP SIGNATURE-

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

Re: gpg 2.1.6 toggle doesn't

[Marko Božiković]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 25/07/2015 13:26, MFPA wrote:
> Hi
> 
> 
> On Thursday 23 July 2015 at 3:30:27 PM, in ,
> Marko Božikovic wrote:
> 
> 
>> Hi all,
> 
>> I've just noticed that the 'toggle' command in gpg 2.1.5/6 on Windows
>> doesn't switch key display. It still seems to switch the keys, since I
>> moved my authentication private key to a smartcard successfully.
> 
> Yes, it does not toggle the display in GnuPG 2.1.x. If you "toggle" 
> nothing seems to happen. But if you then, for example, try to "adduid" 
> you are told you need to "toggle" first.
> 
> In , Werner says the [toggle]
> command should be removed because it does not make much sense anymore.

Ok, but why doesn't it make much sense anymore? Is there another way to get
private key info while in --edit-key mode? (e.g. key location, like the bug
submitter mentions)

- -- 
Marko

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVtfBEAAoJEE8XQV0qn4Bv6fIIAIF35b38atadrKRuQ3Rralo7
g3Z3YklS9nn7/WF8j3Hp4SMzX/bvNwNxqgk+IOMH9Lrk9J4mZ7d06RF7n8sF5KZO
/fpo3EEuKyKPo6Uo9QD4X58HfjRwdGjCtWgrh415Mi8jNczU9txLdl5Lt0spsG8Z
/CIzd/JDSSrzyOl/ZnkFKHrXy85yCbY6jjx290NnULOlMOKZaRef+JLyj52fYbva
cNwAWS09jkM/ZxxDaSqEdWDVe8PzgALfvpvJpT2W1i+tnI7aZFvmoUVvWcIIGLM8
PHz1flJi3/PBlzCNwIlMphMsn0zm9ZkmO4v2E9kwfprZSg3jnUE0zWB3XwxfxeU=
=rBjh
-END PGP SIGNATURE-

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