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 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
