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

[Daniel Kahn Gillmor]

On 06/29/2013 12:49 AM, Stephen J. Turnbull wrote:
> Daniel Kahn Gillmor writes:
>  > 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

Maybe we're not talking about the same thing.  OpenPGP certification
should be identity certification, and nothing else.  trying to extend
OpenPGP certification to mean something other than identity
certification sounds like a bad idea to me -- it breaks all kinds of
other assumptions within the OpenPGP world.

I was thinking that the baseline is:

 0) each e-mail list has a set of "identity certifiers"

 1) each "identity certifier" is itself an OpenPGP primary key
fingerprint (or, the primary key itself).

 2) subscribers to an OpenPGP-enabled mailman mailing list subscribe,
unsubscribe, receive, and send mails as usual (though messages not
signed with valid keys will not be re-sent to the list).

 3) if a signed message comes in, the server checks to make sure that
the message is signed properly with a key that is certified (by one of
the list's "identity certifiers") to belong to the person in the
message's "From:" header, *and* that person is a known subscriber to the
list.

getting fancier, subscription and unsubscription messages,
preference-changing messages, etc, could need to be signed by a valid,
certified key as well.

so when you say "certified key" above, i think you're talking about what
is known as a "valid" key -- that is, the relevant user ID is bound to
its primary key by a certification made by one of my trusted identity
certifiers.

In this model, the only special policy that is conferred upon an OpenPGP
keyholder by the list administrator is "is this key one of the list's
trusted identity certifiers or not?"

>  > 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 hear you :)

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

certification expiry means "i am willing to claim that this key belongs
to this person for N months; if it's later than N months, and you don't
see a newer certification from me, please don't rely on my claim any
more".  I think it would be a mistake to interpret that any other way,
since that is the default interpretation of other pre-existing OpenPGP
clients that will be seeing these same certifications.

i hope this helps clarify my perspective -- i think i'm pushing for
something simpler, not more complex; i think simplicity is one of the
critical factors in making this stuff comprehensible to regular e-mail
list administrators.  Another (as you mention above) is clear, concise,
and clean reporting about what is going on!

	--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/20130630/b5cabda9/attachment.pgp>