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

[Tzafrir Cohen]

Hi

On Sat, Jan 10, 2009 at 06:38:45AM -0600, 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.

Suggested modification)

X also signs the message with his public key.

(If X doesn't want to, this automated procedure will not apply)

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

The security alias processor has in its keyring the "approved" public
keys. If the signature passes, the mail can be simply forwarded as-is. 

If not, we need the extra verification ping-pong (step 4 below).

Rationale: I wouldn't want this delay for every message I send through
the alias.

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

A verified key will also be added to the alias processor's keyring. We
should see how to sync that keyring to A, B, C and D.

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



-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir