Hi all--- On Mon 2015-07-27 01:55:03 -0400, n...@enigmail.net wrote: > 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.
Sorry to take a while to respond to this thread. I think a proposal for an e-mail-validating keyserver/mail-loop can be evaluated in several different ways. unfortunately, none of them look to me like they'll solve the concerns of the c't editor automatically without introducing other problems. Some ways of looking at the problem: 0) is it OK to run an autonomous validating OpenPGP certification agent? I think the answer here is clearly "yes". OpenPGP keys make certifications based on their own policies, and if you set up something like this, you can set the policy to whatever you like. Some people might even use it, like people used their PGP Global Directory as a public attestation service. 1) What (if any) technical structure should there be for an autonomous validating OpenPGP certification agent? This thread discussed several options, including e-mail pingbacks, requirements of PoW, notation data, etc. I don't have a strong opinion on this, and i tend to think that a bit of experimentation with actually running such an agent would be more fruitful than abstract discussion. 2) Should existing OpenPGP clients be willing to rely on certifications made by such an autonomous validating OpenPGP certification agent? if so, which one(s) ? This is now asking the same question as "should browsers/OSes come with a built-in list of X.509 trust anchors?" From the perspective of the global network, where many people use the same tools but have different and non-aligned goals and interests, the answer is clearly "no" to me. But of course the practical answer to most deployed software installations is "yes", because even extremely technically-sophisticated people don't understand how to (or have a way to) configure their trust anchors to align with their own interests. Should OpenPGP implementations follow this model? I'm not convinced it should: it creates high-value targets (the widely-relied-upon certification agents), and provides little to no mechanisms for oversight/auditing of those targets. That said, the possibility of assigning marginal ownertrust to such an agent, coupled with the existence and common usage of the keyserver network makes it possible provide a bit more oversight on the use of these high-valued keys than we have in the (current CT-less) X.509 ecosystem. ------ In summary, i would not want the responsibility of running one of these agents myself. If one existed, i would be fine submitting my own OpenPGP certificate to it for its certification, assuming its certifications don't bloat my cert too much, and i'd be happy to give feedback about its workflow/security posture to whoever is operating it. I don't think that any special notations are necessary for such a use. Just treat it as a special certification-only OpenPGP cert, and document its certification policy clearly. I'd be disappointed if GnuPG or other OpenPGP tools were to decide that they "trusted" such an agent on behalf of all users. So, does this solve the problem that the c't folks had? Not without a lot of other tooling and incentives that don't exist yet. Could such an agent be a useful contribution to a larger certification ecosystem? Possibly, but we won't know that until someone is willing to step up to be responsible for such an agent, and to try it out. --dkg
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users