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

[Stephen J. Turnbull]

Daniel Kahn Gillmor writes:
 > On 07/01/2013 01:58 AM, Stephen J. Turnbull wrote:

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

A certification is a statement that "*I* know *this* key to be
associated with *that* person, and only that person".  Depending on
the value of "I", "you" may extend different levels of trust to "that
person".  You're already down the rabbit hole, my dear Alice.  The
question is whether to eat the red mushroom. ;-)

 > OpenPGP's so-called "web of trust" is a network of identity
 > certifications; it does not typically include authorization
 > information.

There's no authorization information in the web of trust.  The
authorization decision is made on the basis of being presented a
signed key; that's all Mailman has to go on.  Depending on the
identity of the signer *Mailman* may grant additional authorizations.

Consider the example I gave of subscription by member recommendation.

 >  This is limited scope is actually a feature, for (at least) three
 > reasons:
 > 
 >  0) OpenPGP certifications are typically public

If you don't want to expose different "roles" as OpenPGP identities,
don't.  Nevertheless, the capability is available in OpenPGP: the
identity-to-key mapping is not one-to-one.

 >  1) because OpenPGP certifications are statements about identity, you
 > can perform some reasoned inference about them

The whole point of the suggestion is based on this fact.  There's no
authorization in the signatures.  Mailman makes decisions about the
authorization to grant based on the identity(s) of the signer(s).

 >  2) because the certifications are just statements about identity, they
 > are easier for most users to make;

Sure, but some users are smarter than the average bear, or have
requirements beyond those of a typical panda.

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

They are.  We're just confused about "user".  I mean Mailman User, you
mean PGP userID.  They're not equivalent, at least not at the stage of
adding a key to a User in Mailman.

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

No, in Mailman 3 it is not, and cannot be, internal to OpenPGP because
addresses are *not* Users.  There is a many-to-one (address-to-User)
mapping (I hope; if it's many-to-many, we can probably dodge that
bullet by allowing sets of Users in many places we'd normally expect a
User).  However, binding an email address to a User is a Mailman
operation, and at the point of adding an email to a User, in the
scenario I'm thinking of the only thing Mailman has to go on is the
association of a key to an email.  If this is the initial email for
that User, there's no problem.

But for additional emails, there *is* a problem.  The identification
of existing emails with the email to be added is not necessarily
guaranteed by the key presented.  We need to think carefully about how
this works (or can be subverted).

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

Mailman UID != GPG UID, at least not at present, and probably not for
the foreseeable future.

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

Not so fast.  The official position of the GNU Project is that
standards are optional in GNU software.  We should adopt the standard
terminology as used in the OpenPGP RFCs and any other non-vendor-
specific documentation.  If GPG pretty reliably conforms, we can use
the GPG documentation as a reference since it's free and easily
available.

 > > 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 said anything about not relying on the keyring?  I'm saying that
Mailman should not rely on the *certification* that supported adding
this key, once the key is added.  Unless it wants to.

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

In security applications, we don't rely on "shoulds," now do we?

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

Sure, but we're specifically discussing the case where the
certification *does* expire.

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

Because it's the truth that the given key still does belong to the
given user?  And this truth is known to all subscribers of the list
because each has separately authenticated that user in their personal
keyrings, without expiry?

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

All three are fine by me, but they're not enough by themselves.  One
problem is associating OpenPGP userIDs with Mailman Users.  They are
not and cannot be the same.  Another problem is associating
authorizations with Users in the complex trust environment of OpenPGP.

 > I realize that it sounds like these suggestions are not in line with
 > your current plans,

I don't have any plans.  I'm trying to figure out what the
requirements are here.  The model of OpenPGP as a network of
individuals, each represented by a single userID-email pair, is not a
priori appropriate for mailing lists, and especially not for Mailman 3
which has many features designed for handling one User's memberships
in multiple lists possibly using various email addresses across
different domains typically representing different organizations.

 > so maybe i'm just causing noise;

No, not at all.  I'm a professional in the field of drawing inferences
about beliefs, but I don't know very much about OpenPGP specifically.
Obviously we need to have Mailman semantics and terminology correspond
to OpenPGP semantics and terminology where they are supposed to be
equivalent.