[Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration

[Daniel Kahn Gillmor]

On 06/28/2013 12:03 AM, Stephen J. Turnbull wrote:
> Daniel Kahn Gillmor writes:
> 
>  > I think Abhilash's question above is a really important question,
> 
> It is.
> 
>  > and one that really should be addressed by this GSoC project.
> 
> Vetoed (I'm the mentor).  Abhilash is welcome to work on key
> management if he wants to, but he will not be evaluated on it (subject
> to satisying the need discussed below for a simple, generic mechanism
> to allow the list owner to conveniently authorize keys without
> uploading them himself), and he will be warned if it appears that
> mission creep is endangering the mission.

ok, of course you have priority here, but i don't think we're actually
disagreeing :)  The "simple, generic mechanism" you describe *is* key
manangement as far as i'm concerned, and i think it's an excellent step.
 I wouldn't want the list to do much more than this, actually; we don't
want to encourage the list admin to do a lot of fiddly, error-prone,
list-specific work; normal public OpenPGP certifications should be able
to cover that.

> You're welcome to continue to
> lobby him to work on key management though (in public, please :-).

:)

> Yes.  As implied above, I envision there being a specific key used to
> sign for permission to do X FVO X such as subscribe, post, get member
> list, sign other people's keys (Web of Trust!), etc, so there could be
> several keys in that sense.  For paranoid folks who regularly expire
> their keys, I would expect that keys might overlap in time, so there
> probably should be a list of keys for each function.  In some cases
> one key will fit all, of course: "I only sign for people I trust to do
> everything a signature gives authorization to do".

I think this is too fine-grained, actually -- OpenPGP certifications
should attest to people's identities; those identities should have
permissions in mailman the same way that
non-cryptographically-verifiable identities have permissions in mailman.

The semantics are simple and graspable if we say "for list X, rely on
OpenPGP certifications from the following keys to prove cryptographic
identity".

>  >  A) if refreshing keys from the keyserver network is something we want
>  >     mailman to do, when should it happen?  how often?
> 
> Good questions, both the implicit one (do we want?) and the explict
> ones.  Beyond my technical knowledge at the moment, though.

As someone who has worked on this sort of key management in other
contexts (e.g. monkeysphere), the simplest mechanism is a scheduled
cronjob update from the keyservers.

One step up (fancier) is to couple the cronjob (which is still necessary
to check for revocations) with a key expiry script, that knows when the
next key or certification will expire and check from the keyservers at
that point in time.

If the cronjob is frequent enough, i don't think the fancier approach
has a great cost/benefit analysis, so i would just start with the cronjob.

Consider also that a cronjob that just does "gpg --refresh" should be
sufficient to pull in revocations and modifications to expiration dates,
but it won't pull in new keys that might be valid.  I think that's fine
for starters, and the new keys can be handled by:

>  >  B) if mailman can't find a valid key+userid for a known subscriber,
>  >     when should it query the public keyservers to try to find one?
> 
> Immediately, subject to the caveat that this would possibly be a
> separate queue.
> 
> Oh, I suppose you mean "should Mailman automatically add a key
> that the user may not really have intended to use?"  That's an
> extremely complex question.  If "signed by list owner" is the only
> criterion and it's necessary and sufficient, I'd go with "always".
> Otherwise you have a complex policy, and I'd have to see the policy to
> know when querying is appropriate.

I also think "always" is a reasonable default policy, though some list
managers may want to be able to set it to "never" if they don't want
arbitrary messages sent to the list to be able to force the list
software to interact with the public keyservers directly.

>  >  C) how should mailman accept uploads of key material that *don't* go
>  >     through the keyservers?
> 
> Please expand.  A signed key is a signed key, or isn't it?

ok, there are two approaches i can see:

 0) no key upload happens manually; all keys and OpenPGP certifications
are fetched from the public keyservers.  If a user's key isn't in the
public keyservers, or the certification by the list admin hasn't been
uploaded to the public keyservers are ignored.

 1) in addition to the use of the public keyservers, direct key upload
is allowed -- e.g. people can e-mail OpenPGP certificates to a special
address, or can upload them to a web form.  In this case, a user who
doesn't want their key on the public keyservers (or an admin who doesn't
want to distribute their certifications to the public keyservers) can
participate; also, a mailman installation which is (for whatever reason)
unable to access any of the public keyservers can still access it.

>  >  D) if mailman notices that a subscriber's key has expired or been
>  >     revoked or somehow become invalid in some other way, is it expected
>  >     to notify that subscriber of the change in status?  if so, how? (i
>  >     recommend that the answer is "no notification", at least in this
>  >     initial implementation.
> 
> I would expect that "noticing" would happen during the process of
> authenticating a request.  If key status *changes* (a key that was
> never valid for the list should cause silent denial of the request to
> reduce backscatter), then the user should be notified that key status
> has changed *and* how that was determined.  Anything else is going to
> leave the list owner in the dock.  Also, the key owner may wish to
> prosecute somebody for misuse of her key, and should be informed of
> the misuse.

i can see how this would be useful, but it means that there is more
fiddly tracking of the validity state of each (key,userid) pairing that
needs to be done to make this possible.  I suspect that the most common
change from valid to not-valid will be an expired key or an expired
certification (e.g. if the list owner's certification of the key
expires).  for the latter case, i can imagine that the certifier (the
list admin) might want to be notified as well.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130628/2d65d9b4/attachment.pgp>