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
