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

[Stephen J. Turnbull]

Daniel Kahn Gillmor writes:

 > ok, of course you have priority here, but i don't think we're actually
 > disagreeing :)

Good!

 > The "simple, generic mechanism" you describe *is* key
 > manangement as far as i'm concerned, and i think it's an excellent
 > step.

OK.  I remember the context as being one of actually implementing
(automated) policy decisions.  That's where I really don't want him to
go until the more limited GSoC project is done.

 > 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".

So you're suggesting that the *only* policies that should be
automatically implementable via certified key are

(0) let this guy upload this key (and implicitly create a User if
    needed), but he can't do *anything* else (not even subscribe)
    until the list owner explicitly adds authorizations,

(0.5) this guy gets the intersection of sets of privileges I ever want
    to grant to anybody, and

(1) this guy is co-owner of this list

?

 > 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 agree it's fiddly, I agree it's not in scope for Abhilash's GSoC
project, but for Mark's[1] sake I think we need to notify users whose
status changes from valid to invalid of the reason for the change.

 > 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.

I would interpret a certification expiry differently: as the period of
time for which permission to register the key is valid.  If we want an
expiry for User authentication, probably a generic tool for managing
that in Mailman itself would be sufficient for this purpose and useful
elsewhere.


Footnotes: 
[1]  He's the guy who does the most work on fielding problem reports
from users.