As i about this, i wonder if the OpenPGP integration project shouldn't be broken into two phases, so that the tricky nuances could be handled more simply.
I'm imagining a first phase ("message authentication") would not expect
or handle encrypted messages, but would just use cryptographic
signatures to verify the authenticity of origin of the incoming message,
enhancing (and/or replacing) some of the current checks mailman uses to
decide if a message should be passed on to the list.
Then the second phase ("encrypted messages") would address the
possibility of having encrypted message content.
If you can get the "message authentication" phase done properly, you'll
have a good argument that your keyring management is effective, without
getting sidetracked into issues of exactly where the content of the
message might leak (since the messages aren't encrypted at all).
When the first phase is done, you could focus on the "encrypted
messages" phase, based on the assumption that you have decent keyring
management, and handle the peculiarities and concerns there separately.
I'm not a mailman developer; but I'd be curious to hear what mailman
devs think of this breakdown.
More comments and questions below, based on the workflow you've outlined
that mixes "message authentication" with "encrypted messages" and tries
to solve them all at once:
On 05/09/2013 01:31 AM, Abhilash Raj wrote:
> Consider this flow of message from one user to all list-subscribers:
>
> * A user sends a message( signed as well as encrypted )which as soon as
> received by mailman is first queued in "IN" queue.
who does the sender encrypt the message to? are we talking about a
public key associated with the list? how does the sender learn of that
public key?
> * When the incoming runner wakes up the message is checked if it is for
> owners, posting or encrypted.An encrypted chain is created for
> encrypted messages.
what if it is an encrypted message sent to "owners"? how does that get
handled?
> * Now according to the use case there can be two encrypted chain:
>
> 1) Where the posters are fully trusted and thus this rules only checks
> the signature of a message. If a message signed by a member is received
> it is sent to pipeline queue in a encrypted form for further processing.
when you say "fully trusted" it might be worth saying what they are
trusted for. I think here you mean "fully trusted to post messages
without moderation".
What happens if the message cannot be decrypted by the mailing list and
the signature is inside the encryption? does the message bounce?
what if the decryption succeeds but there is no message signature inside it?
what if the signature appears to be valid, but was made 3 years ago (or
in the future)?
what if the signature appears to be valid, and recent, but is the same
signature that was used on a previous e-mail to the list?
what if the signature is cryptographically valid, but the list member's
key has expired?
what if only part of the message is signed?
> 2) Where the posters are not fully trusted. In this case there needs to
> be various checks on decrypted message like current default-posting-chain.
One common thing that might happen here is that the message is being
held for moderation. if the message is encrypted, how is a moderator
supposed to review it and make a decision?
> * The messaged is moved in between queues in the encrypted form
> encrypted by a symmetric key algorithm which uses list's secret key to
> encrypt the message.
this doesn't make sense to me. when i hear "list's secret key" i tend
to think people are talking about asymmetric encryption, but it seems
here that you're talking about symmetric encryption. Maybe it would
help to enumerate exactly what secrets each entity holds (and maybe what
public data is associated with those secrets, in the case of the
public/private keypairs used by asymmetric crypto). If you give those
secrets names, you can refer to them more concisely and precisely.
> * When the pipeline handler wakes up it decides which pipeline the
> message is to passed through. In this case an encrypted_posting_pipeline
> is created to process an encrypted message.
which case is "this case" are we talking here about every encrypted
message or just a subset of them?
> * This encrypted_posting_pipeline is used to keep the message in
> plain-text for a minimal time. The message is decrypted, headers and
> footers are added and the message is signed by list's pub-key. It is
> then again (symmetrically) encrypted and stored in the outgoing queue.
public keys don't sign messages; secret keys can sign messages, and
public keys are used to verify those signatures.
what happens to the original sender's signature? is it stripped? or
does it remain, nested within the list's signature? How are list
members expected to verify these signatures?
i'm again confused by the symmetrical encryption proposal here.
> * The outgoing runner personalizes each message by encrypting it with
> each user's pub key and forwards it to MTA using VERP(Variable Envelop
> Return Path).
What happens if a user's public key is found to be expired or revoked?
How does mailman become aware of revocations, of extensions of the
expiration date, or of new keys or certificates for any given user?
i hope these questions are useful,
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
