How to deal with a 2nd OpenPGP Summit?
Hi all, in April 2015 we had a first OpenPGP summit. It was a meeting where the technical experts of projects and tools dealing with OpenPGP with a focus on email encryption met to getting to know each other personally and discuss several issues. For details, see e.g. - https://www.gnupg.org/blog/20150426-openpgp-summit.html - https://www.mailpile.is/blog/2015-04-20_OpenPGP_Email_Summit.html The meting initially was organized by me to bring together a few guys/projects working in that area, but it became pretty big (about 30 people). This caused some problems, because we had a host with limited space (so I finally even had to reject some people wanting to attend). We also discussed there how to continue. On one hand we wanted to have the meeting open so that anybody wanting to attend could do that and to give trust by transparency. On the other hand we want to be able to continue to focus on technical issues (having a well signal to noise ratio) in a not-too-large group of "experts". We didn't find an appropriate way yet to deal with both interests. Now, I am about to organize a second meeting at the end of this year. And I want to take the "wisdom" of this crowd to discuss this issue. What I currently have in mind is a meeting open to the public but with some limitations (one reason is to focus the work, another is simply limited space although I don't know where we can meet this time). For example: - Some priority for those who did attend the first meeting - Some priority for "other experts", which didn't join the first meeting (but how do we handle that?) - Some limitations that a person plays a "significant role" in the community - Some limitation so that a tool/project should normally send only 1 or 2 guys The obvious other option is to open the meeting to everybody willing to come, which raises a couple of risks (simply too many people, too many non-experts or people who want to change the focus, ...). So, my questions are: = Is it OK for the public/community, if we meet in a way that is limited as describe above (just for practical reasons)? Is it OK even if we can't promise full transparency (e.g. by video taping sessions)? Would it even be OK, if we meet and constraint what is spoken there to the Chatham House Rule (see https://en.wikipedia.org/wiki/Chatham_House_Rule). Some people requested that because if anything they say might become public, they might or even have to be careful what they say. Any general thoughts or proposals about how to deal with this? Note that I don't want to have it too complicated. I organize this meeting in my free time to bring the issues of this community forward. And just having too many people is already a problem. I need an approach I can handle. Or is it better to have no meeting at all instead of a meeting with some limitations? Best Nico -- 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
Indeed, as written in the proposal key 8B5A ABB1 A033 21CE C2FF C35F 3BA0 E844 EDEB DFE9 > https://hkps.pool.sks-keyservers.net/pks/lookup?op=vindex&search=0x3BA0E844EDEBDFE9 is a faked key which is signed by a faked CA. THAT's exactly the problem I want to fix! And note that for ordinary users it is not that easy to find out Yes, people could in this case double check with the web site of the magazine. But they simply don't do that (including me and a couple of other people here in this forum!). As a result Jürgen aganin and again gets emails with the wrong key. And I dind't get an answer from Jürgen ... And ... I want to avoid this unnessecary burdon. BTW, as another example, several keys of t...@gpgtools.org are faked (search for these keys and the the interesting result). Am 30.07.2015 um 12:23 schrieb MFPA: > Hi > > > On Thursday 30 July 2015 at 9:27:37 AM, in > , Viktor Dick wrote: > > >> On 2015-07-30 10:17, Ingo Klöcker wrote: >>> I'm sorry to tell you that you have fallen into the trap. There is only one >>> genuine pg...@ct.heise.de key the fingerprint of which is printed in each >>> issue of the c't magazine. The other one is a fake. And the fact that the >>> fake >>> key with the author's email address is signed by different keys only means >>> that a lot of people have signed this fake key without following the proper >>> procedure of key validation (or that the trolls created even more fake keys >>> to >>> sign the author's fake key to make it look more credible). > >> Not according to >> http://www.heise.de/security/dienste/PGP-Schluessel-der-c-t-CA-473386.html >> where three different keys are listed (two DSS and one >> RSA). > > > I concur that the keys 38EA4970 and E1374764 both look likely to be > genuine. One has signatures from B3B2A12C, the other from DAFFB000. > The link above lists as "ct magazine CERTIFICATE " > keys B3B2A12C and DAFFB000, as well as a third key BB1D9F6D. > > > As for the other non-revoked keys I found by searching for "schmidt > juergen heise de":- > > all four are signed by a "ct magazine CERTIFICATE > " key F6ADD6C2 that is not listed on the > magazine's page. > > all four are also signed by a "ct magazine CERTIFICATE magazine CERTIFICATE>" key FB4DFDC6. > > one of the four has a UID claiming itself to be another "ct > magazine CERTIFICATE " as well as being > Juergen Schmidt's key. > > Also all four have the same creation date. > > I guess anybody being fooled didn't look at the page linked above, or > they would have used key 2C26A309 "ct magazine pgpCA CommunicationKey > 2015 " when contacting the magazine. (-; > > > > > > ___ > 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/mailman/listinfo/gnupg-users
Re: Proposal of OpenPGP Email Validation
Am 29.07.2015 um 15:41 schrieb MFPA:
>> Well, I don't like the CA model and that's what Nico is
>> basically proposing (with less rigorous checks).
>> Another huge disadvantage is that user's have to
>> actively participate by replying to emails / visiting a
>> link.
>
> Yes, PoW has none of that.
>
> If you went for a per-UID PoW and a common validation signature
> notation with Nico's scheme ("type": "ProofOfWork" instead of
> "enc-email"), the schemes could operate together as compatible
> alternatives.
I am happy to propose other way of validation.
Unfortunately I didn't understand the PoW approach yet.
So, could somebody explain in a bit more detail how a PoW approach works?
In my scenario a user only has to do 2 easy and understandable things:
a) change the keyserver configuration:
I.e. replace a keyserver by a validating keyserver proxy
b) From time to time process an email asking for
email confirmation by clicking the appropriate link
IMO, that's easy,
that's something people are used to do
(when they register to other services),
that's rare enough to get accepted..
And it works with each existing email client
(where I can configure the keyserver).
So, how does the PoW approach works in practice?
How does this validate an email?
What has the user to do?
Does it work for each existing email client?
IMO anything more complicated makes acceptance more problematic.
E.g. using two servers (asking for validation at another server
than the keyserver) is IMO for most people simply a show stopper.
Even replying with a signed email IMO instead of
clicking a link sounds more complicated to me.
IMO, we should avoid any step that makes the scenario
more complex than necessary (without a significant win).
But as written, I didn't understand the PoW scenario yet.
may be the effective interaction (based on the UIs of existing
email clients) is not worse.
Sorry that I am not an expert in this area.
Nico
--
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
Hmmm, first i talked to him/them a couple of times personally (there are multiple editors at that magazine) about the issue in detail and tried to convince them following the WoT without success. Note that they just behave as ordinary users, having not much time to deal with the problems of OpenPGP. They get hundreds of emails per day and each email they can't read is a significant problem because the 2 seconds they have for reading emails turn out to become minutes. There should simply be no overhead in using OpenPGP in the ordinary case for the ordinary user. And I agree with that. Usability is key for a broad acceptance. I don't want to have the same problem. And other tools also don't want to have it anymore (e.g. the GPGTools.org guys have the same problem). I see no reason NOT to solve this problem, but I see many reasons to solve it. Just saying "deal with it" simply means that we place unneccesary burden on OpenPGP users. IMO, that's a really bad approach. Am 29.07.2015 um 12:38 schrieb Ingo Klöcker: > On Wednesday 29 July 2015 01:48:54 MFPA wrote: >> On Tuesday 28 July 2015 at 8:17:28 PM, in >> , n...@enigmail.net wrote: >>> AFAIK, there are not THAT many faked keys, but the >>> problem exists especially for key parties of our >>> internet world (a famous German magazine, at least one >>> GPG tool, ...). The problem is that the German magazine >>> takes this as a show stopper (both personally and >>> publicly). I really want to have them back on our road >>> for more encryption with OpenPGP. And the "publicity" >>> we get from not validating email addresses is really a >>> big problem (especially as fixing that problems sounds >>> so easy and obvious). Thus, without fixing this, IMO >>> the whole OpenPGP movement has a reputation problem. >> >> I understand what you are saying. I cannot help but think they are >> making a mountain out of a molehill by characterising this minor >> irritation as a "show stopper". > > Yes, he (not they!), the author of the article is doing exactly this. > > >> Putting something in place to >> counteract the issue is one approach. Would it not be an equally-valid >> approach to educate them as to why it is a non-issue, which they could >> then disseminate through their magazine? > > I think that the author of the article knows that it's mostly a non-issue. He > still decided to write the article "Forged PGP Keys in the Wild" [1] and even > an accompanying editorial titled "Let PGP Die!" [2]. I guess he simply got > pissed because he received so many messages that were undecryptable with his > real key. > > Luckily, there are also more sensible authors working for this magazine who > write good articles about OpenPGP. > > I personally chose to ignore the stupid editorial. IMHO it does not deserve > more attention than any other rant written by a random troll. OTOH, the > article actually isn't that bad. It points out the issue with the missing > validation of email addresses in UIDs making a bit of a fuss about it, but > IIRC it also explains how to avoid falling into the trap of using a fake key. > > > Regards, > Ingo > > > [1] http://www.heise.de/artikel-archiv/ct/2015/06/160_Die-Schluessel-Falle > (German; needs to be bought) > [2] https://www.heise.de/artikel-archiv/ct/2015/06/3_Editorial (German; free) > > > > ___ > 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/mailman/listinfo/gnupg-users
Re: Proposal of OpenPGP Email Validation
>> b. The validation server does not need to manage a "stack" of keys >>awaiting feedback from the validation emails. >> > indeed, that's an argument > Hmm, but IMO we anyway need a state in validation servers to deal with different spam schemes (i.e. avoiding that any request to a v-server sends an email). -- 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
Am 29.07.2015 um 03:30 schrieb MFPA: > > Hi > > > On Monday 27 July 2015 at 1:15:57 PM, in > , Neal H. Walfield wrote: > > >> 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. > > > Why not simplify the workflow:- > > 1. key reaches validation server. > > 2. for each UID containing an email address, validation server creates >a copy of the key stripped of all other UIDs. > > 3. validation server signs that copy of the key. > > 4. validation server pastes the signed key into an email, encrypts the >email to that key, and sends it to the email address in the UID. > > 5. user receives each email, decrypts it, and updates their local copy of >their key. > > 6. user uploads key now bearing the validation server's signatures to >a keyserver. > > Interesting. What comes into my mind is the following: - This requires special email clients. The benefit of the proposed workflow is that any existing client can use it just by switching its keyserver to the validating keyserver proxy. IMO, that's a huge drawback, because any solution that requires email client updates is a lot harder to establish. - How to deal with existing keys? Well probably the same (upload a key for the first time and uploading it for updates would run the saem workflow), right? > There is still the same level of assurance that the email address and > private key are controlled by the same entity. Advantages are:- > > a. Nobody is asked to click links or reply to emails. > Hmm, isn't step 5 is kind of that? In any case some confirmation email handling is required. If this is done by the email client silently, this also can be done by the email client in my proposal. But again this requires supporting clients. > b. The validation server does not need to manage a "stack" of keys >awaiting feedback from the validation emails. > indeed, that's an argument > c. Changes to the user's key are uploaded to the keyserver by the >user, not by the validation server. > Is this a real benefit? Thanks Nico -- 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
Hi, thanks again for the great feedback. Am 28.07.2015 um 19:26 schrieb MFPA: > > Hi > > On Monday 27 July 2015 at 6:55:24 PM, in > , n...@enigmail.net wrote: > >> 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? > > I just think if I was to receive revalidation requests all at the same > time I would be less likely to overlook those for little-used email > addresses I do not often check. It also keeps it neat. > OK, I will add this as an argument. Does anybody disagree? >> It only says that the email did >> one day work for a validation of any kind, which is >> more than what we have now. > > We have the Web of Trust to demonstrate that. But those are generally > one-off signatures on a key, and may be quite a few years old. Some > email providers recycle addresses, so an address Bob used a few months > or years ago could now be under Alice's, or even Mallory's, control. > > As far as I see it, your scheme adds two things: periodic > revalidation, and an easy way to get a signature on your key without > having to meet anybody. > Yep, sounds good to me. May be an additional value is the goal to establish some "common" validation signatures, which would allow to use/trust these signatures by default. Thus, we also introduce an easy way to benefit from a validation (signature). >> 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. > > Indeed. I think an annual revalidation period strikes a reasonable > balance, although maybe there are email services that recycle > addresses more quickly than that. > Finding the right balance is probably something we have to find out over time. I would start very very conservatively, just not to annoy people. >> But that might be enough to solve the faked key issue. > > Are there really many "faked" keys, rather than keys that are no > longer used, forgotten passphrase, lost private key, etc.? > AFAIK, there are not THAT many faked keys, but the problem exists especially for key parties of our internet world (a famous German magazine, at least one GPG tool, ...). The problem is that the German magazine takes this as a show stopper (both personally and publicly). I really want to have them back on our road for more encryption with OpenPGP. And the "publicity" we get from not validating email addresses is really a big problem (especially as fixing that problems sounds so easy and obvious). Thus, without fixing this, IMO the whole OpenPGP movement has a reputation problem. >> this solution does NOT solve the >> problem of interception of emails. But it helps to >> detect them > > How does this help to detect interception of emails? > Today, people with faked keys simply get unreadable emails, but don't know whether there were trolls or spies at work. After validating their own key, only one of two things can happen: a) The faked key problem is solved, because people now know, which of the available keys to prefer (provided people trust the validation signature) b) The faked key problem still exists, because a validation signature to the faked key was also added. In this case we know that something more severe happened: - either the confirmation email was intercepted - or the validation server was corrupted That is, either the problem is solved or we know that the problem is more severe than just a work of trolls only uploading a faked key for fun. >> 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, >> ... > > Company email servers, I would expect companies as a matter of course > to have a means to decrypt their employees' emails. > > I'm shocked to read [0] that Riseup once had a webmail option that > stored the user's public and private keys. Riseup now tells [1] users > who want to use encrypted email to utilize an email client to send and > receive email, while keeping their pr
Re: Proposal of OpenPGP Email Validation
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
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
-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 ra
Guys please all see
Guys please all see >> http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_poitras.html#video to understand the important role, GPG plays. Support us, please! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
