project:secure_remailer:start
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
project:secure_remailer:start [2017/06/05 19:12] – [Motivation] ruza | project:secure_remailer:start [2017/06/05 19:54] – ruza | ||
---|---|---|---|
Line 7: | Line 7: | ||
hw=-| | hw=-| | ||
founder=[[user: | founder=[[user: | ||
- | interested=| | + | interested=[[user: |
status=active | status=active | ||
}} | }} | ||
Line 18: | Line 18: | ||
==== Motivation ==== | ==== Motivation ==== | ||
We have an **contact email** where people can send sensitive info. We dont want to transfer such info unsecurely nor have stored anywhere where can be leaked later. This email addres is actually an alias whose membership is changing overtime. Only actual final recipients (ie brmlab council members) should be able to decrypt such email. | We have an **contact email** where people can send sensitive info. We dont want to transfer such info unsecurely nor have stored anywhere where can be leaked later. This email addres is actually an alias whose membership is changing overtime. Only actual final recipients (ie brmlab council members) should be able to decrypt such email. | ||
+ | |||
+ | ==== Solutions ==== | ||
+ | |||
+ | === GnuPG email/ML gateway === | ||
+ | |||
+ | Explore existing solutions like [[https:// | ||
+ | |||
+ | === New idea === | ||
^ recipient | ^ recipient | ||
Line 23: | Line 31: | ||
| actual recipients | | actual recipients | ||
- | === Known problems === | + | == Architecture components == |
- | * __public subkey distribution__ on **email sender** site - since subkey is generated with one year validity (technically 12-15 months) an email clients needs to refresh to currently valid keyring state at least once a year. | + | |
- | * __private subkey distribution__ on **email recipients** site - each time new subkey generated (Usually related to the list of newly elected board members) this new subkey needs to be distributed to board members | + | |
- | * Afaik in GnuPG there is no way how to generate an decrypt only subkey (key without signing capability). Since we have an requirement to decrypt email content for the purpose of storing it in the mailing list archive an receiving email server needs to hold a private subkey currently used. The question whether processing server should also keep expired subkeys could be a matter of discussion. | + | |
- | + | ||
- | ==== Architecture components | + | |
- | === Email client | + | == Email client == |
An email client of the sender. Since we are expecting an heterogenous environment that consist of different email clients " | An email client of the sender. Since we are expecting an heterogenous environment that consist of different email clients " | ||
* GnuPG **encrypted** email - encrypted against currently valid subkey | * GnuPG **encrypted** email - encrypted against currently valid subkey | ||
* an **unencrypted** email - such email is not protected on its transfer | * an **unencrypted** email - such email is not protected on its transfer | ||
- | === Receiving email server | + | == Receiving email server == |
Email/SMTP server is receiving emails from email clients and encrypts them eventually (depending on the form of an email received). Following inputs are assumed: | Email/SMTP server is receiving emails from email clients and encrypts them eventually (depending on the form of an email received). Following inputs are assumed: | ||
* **unencrypted** email | * **unencrypted** email | ||
Line 56: | Line 59: | ||
Authentication and autorization to the data archived on the filesystem level are realized using operating system user rights assignment and SSH remote access capabilities. Also possible access to the raw data by the virtual infrastructure provider should not be forgotten. | Authentication and autorization to the data archived on the filesystem level are realized using operating system user rights assignment and SSH remote access capabilities. Also possible access to the raw data by the virtual infrastructure provider should not be forgotten. | ||
- | === Recipients | + | == Recipients == |
Recipient group consist of an organization board members or another small similarly defined user group. For the managing simplicity we didnt choose the way to reencrypt each incoming email to specific list of recipients instead of simply distribute private subkey to the recipients. | Recipient group consist of an organization board members or another small similarly defined user group. For the managing simplicity we didnt choose the way to reencrypt each incoming email to specific list of recipients instead of simply distribute private subkey to the recipients. | ||
Recipient always receives an mailing list processed emails in the form of GnuPG encrypted email and using private subkey to decrypt such email. | Recipient always receives an mailing list processed emails in the form of GnuPG encrypted email and using private subkey to decrypt such email. | ||
- | === Master keypair owners | + | As we know in our situation (brmlab council mailing list) consist of: |
+ | * council members | ||
+ | * brmlab members interested in council activities | ||
+ | |||
+ | == Master keypair owners == | ||
Master keypair is not used in a day-to-day operation. Its purpose is to be a source of trust in case new subkey is released. Limited number of persons (" | Master keypair is not used in a day-to-day operation. Its purpose is to be a source of trust in case new subkey is released. Limited number of persons (" | ||
- | ==== Solution | + | |
+ | == Known problems | ||
+ | * __public subkey distribution__ on **email sender** site - since subkey is generated with one year validity (technically 12-15 months) an email clients needs to refresh to currently valid keyring state at least once a year. | ||
+ | * __private subkey distribution__ on **email recipients** site - each time new subkey generated (Usually related to the list of newly elected board members) this new subkey needs to be distributed to board members | ||
+ | * Afaik in GnuPG there is no way how to generate an decrypt only subkey (key without signing capability). Since we have an requirement to decrypt email content for the purpose of storing it in the mailing list archive an receiving email server needs to hold a private subkey currently used. The question whether processing server should also keep expired subkeys could be a matter of discussion. | ||
+ | |||
+ | |||
+ | ==== Old idea ==== | ||
+ | < | ||
Sender encrypts an email against Brmlab public GPG key. Email is delivered to an brmlab SMTP server, reencrypted by **GPG-remailer** to an up-to-date list of recipients (that is changed more frequently than contact email) and resent to them. Only actual and specific members can decrypt such message with his/her own private key. | Sender encrypts an email against Brmlab public GPG key. Email is delivered to an brmlab SMTP server, reencrypted by **GPG-remailer** to an up-to-date list of recipients (that is changed more frequently than contact email) and resent to them. Only actual and specific members can decrypt such message with his/her own private key. | ||
project/secure_remailer/start.txt · Last modified: 2017/06/06 16:48 by ruza