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

[Daniel Kahn Gillmor]

On 07/01/2013 01:58 AM, Stephen J. Turnbull wrote:
>  >  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).
> 
> Not necessarily.  It may be necessary to sign admin messages as well
> (subscribe, unsubscribe, set vacation)....
> 
> Your phrasing presumes that the only role of Users (the internal
> representation of an identity) is to act as a subscriber who reads and
> posts.  The way I think of it is that Users may have several roles
> (read, post, moderate, admin) for each list.  Each of these roles may
> be certified by a different "agent" of the owner, where agents are
> represented by different keys.

It sounds to me like you're trying to use OpenPGP keys for authorization
here, rather than for authentication.  I think that's a mistake.

OpenPGP's so-called "web of trust" is a network of identity
certifications; it does not typically include authorization information.
 This is limited scope is actually a feature, for (at least) three reasons:

 0) OpenPGP certifications are typically public -- you do not always
want to publish your authorization decisions.

 1) because OpenPGP certifications are statements about identity, you
can perform some reasoned inference about them (e.g. following
reasonable chains of authenticated certifications) that would be much
harder to do if the semantics of any given certification could
potentially indicate authorization as well as authentication.

 2) because the certifications are just statements about identity, they
are easier for most users to make; this is because it is simpler to
consider identity on its own than to consider both identity and
authorization bundled together.  More certifications means a richer pool
to draw from when trying to calculate authentication.

> "Known subscriber" doesn't really make sense in the Mailman 3 world.
> There are Users, they can be "members" of a list (ie, known to the
> list) and they can have roles (reader, poster, etc).  It's not clear
> to me that requiring posters to have the reader role in this world is
> the right way to determine membership.

i'm just suggesting that those roles are authorization statements about
users and lists.  I apologize for not knowing the official mailman
terminology here, so if you can help me translate, i would be very
grateful :)   I think those authorization statements should *stay the
same* in mailman lists that use OpenPGP as they are in mailman lists
that do not use OpenPGP.

>  > 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.
> 
> That seems to be nonsense, though.  Key-to-UID binding is done by the
> user database; it's only meaningful inside of Mailman.


The key-to-uid binding is done by the OpenPGP keyring. this is the
entire point of an OpenPGP keyring: given a signed message and a from
address, can you confirm that this message really came from the stated
from address?

> A signature on
> a key is not a way of making an authenticated link to a UID in
> Mailman, AFAICS.  It's only a of certifying that the signer knows the
> keyholder and that this is that keyholder's key, and that the signer
> trusts the keyholder not to allow others to use her key.  That doesn't
> mean (in the absence of actually binding a UID to the key *in* the
> certification) that this keyholder corresponds to any given UID.

I don't think i understand what you're saying.  when Alice makes an
OpenPGP certification on Bob's key ("Alice signs Bob's key"), she is
explicitly binding Bob's User ID to his public key.  So saying "in the
absence of actually binding a UID to the key in the certification"
doesn't make sense to me.

> I also don't see why, in a web-of-trust model, you would want to use
> that definition of "valid".  (If the key is determined to be none of
> corrupt, expired, or revoked, I would call that "valid".)  A key not
> signed by a trusted certification key would be (completely) untrusted,
> but you can imagine various degrees of trust.  For example, in a
> member recommendation model, you might allow any member's key to
> certify the reader role but not the poster (or vice-versa for a list
> handling privacy issues!)  Having validity depend on trust makes the
> concept of validity quite ambiguous.

It's not surprising that these terms still confuse people; they were
muddled even in the GPG documentation up until a few years ago.  It's
worth clarifying them explicitly:

 * A literal key (nothing but a key, no UIDs, no self-sigs, etc -- not
an OpenPGP certificate) that is well-formed is "syntactically valid".

 * a syntactically-valid key whose certifications we are willing to rely
on when evaluating other keys and user IDs is a "trusted" key.  This is
the same thing as saying that the key has "full ownertrust".

 * a (key,userID) pair that has been certified by a trusted key is
"valid" -- that is, we believe that the person identified by the User ID
is the person who holds the specified key.

If the plan is to use GnuPG's OpenPGP keyring as a backend for this
project, it's probably worth adopting the same terminology.

> I don't interpret it any other way.  I'm assuming that once the key is
> registered, Mailman and the list owner take responsibility for
> trusting keys, and they no longer rely on the certification at all.

Why?  Why not keep relying on the keyring for that?  Who is going to be
responsible for checking for expiration, revocation, etc?  It seems like
continuing to use the keyring specifically for this relationship is the
simpler and cleaner.

> If the list owner wants to use the "certification" in authenticating
> the User, that would be OK.  But then the temptation to use an
> infinite expiry would be strong (unless a mechanism is provided to
> make re-signing convenient -- but not *too* convenient: sorry, no
> "re-sign all" button will be provided!).  With infinite expiry
> certification is meaningless in the long run (in the long run we're
> all dead, and a signed message from someone known to be dead should be
> a clue...).

if they're known to be dead, they should be unsusbcribed from the list :P

Most people currently make OpenPGP certifications that have no expiry --
because there is an assumption that people's identities and keys don't
change very often.  This is not a universal practice, but it's pretty
widespread.

>  > since that is the default interpretation of other pre-existing
>  > OpenPGP clients that will be seeing these same certifications.
> 
> Why are they delegating so much power to the certifications?  That
> seems very strange to me.  I certainly wouldn't stop trusting a
> key that had been used to sign messages to my list daily just because
> a third party certification from 6 months ago expired!

if that third party was the only trusted certifier for the list, the
list absolutely should stop believing that the given key belongs to the
given user when the certification expires.  why should the list believe
anything different?

Anyway, i hope this makes my perspective on this clear: i think you
should be relying on OpenPGP certifications for authentication, and you
should rely on your list's keyring to understand key-to-userID mappings.
 And keep the authentication associations (roles that relate users to
lists) as they currently are in mailman.

I realize that it sounds like these suggestions are not in line with
your current plans, so maybe i'm just causing noise; if you want me to
step back from the discussion, please let me know -- i certainly don't
want to get in the way of the project getting done.

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/20130701/5d8d3d80/attachment.pgp>