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

[Stephen J. Turnbull]

Daniel Kahn Gillmor writes:

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

Yes.

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

Yes.  Probably the primary key.

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

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

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

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

So this interpretation is useful only if a new UID is being assigned
to that key in this transaction.  It doesn't work if we are binding a
new key to an existing UID.

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.

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

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.

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

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