[asterisk-users] Security communication dilemma: your help needed

[Jeff LaCoursiere]

On Sat, 10 Jan 2009, Kevin P. Fleming wrote:

> John Todd wrote:
>
>> Desired procedure:  A public key signature method would be publicly
>> available via an SSL web page or various keyservers.  Individuals
>> could sign messages with the public key.  Signed messages sent to
>> "security@" would then be decrypted, and re-encrypted with the
>> security@ key and sent to the small list of end recipients.  Any
>> recipients who replied back to the message would have the process
>> happen in reverse, and also have copies if the reply sent (encrypted)
>> to the other members of this email "exploder" as well as the external
>> author.
>
> Actually, a slight clarification is in order.
>
> Let's assume for the moment that the security@ role is actually serviced
> by developers A, B, C and D (not necessarily all Digium employees, but
> Asterisk developers). Let's also assume that third-party X wants to send
> a secure vulnerability report.
>
> 1) X retrieves the security@ public key from a reliable source; this key
> would be countersigned by a large number of Asterisk developers to
> ensure its authenticity.
>
> 2) X would compose their message, attach their GPG public key, digitally
> sign the message using their GPG private key, then encrypt the entire
> message using the security@ public key.
>
> 3) The message would be received by this super-duper email alias
> processor, which would then (because it has the security@ private key),
> decrypt the message, verify the signature from X, then store X's public
> key in a local database along with some sort of thread ID for this
> conversation.
>
> 4) The processor would then re-send the message to A, B, C and D, in
> each case signing the message using the security@ public key and
> encrypting it using the recipient's public key, so each copy of the
> message leaving the processor can only be read by the recipient.
>
> 5) If A, B, C or D responds to the message (back to the security@
> processor), they would also sign/encrypt their response, and the same
> process would occur. However, since the processor would have the thread
> ID (presumably in a References or In-Reply-To header in the reply), it
> would also include X in the distribution of the reply, encrypting the
> message using X's stored public key.
>

This sounds perfect.  So what is missing?  Just the "super list 
processor"?

j