(1) Does the method provide end-to-end security or just client-to-mail server? (2) Does the method protect all of a user's email accounts or just his mail account associated with this service? - I.e. if the service name is secureemail.com is only liz@secureemail.com protected or are all my accts protected? (3) If an enrolled (liz@secureemail.com) sends an email to a non-enrolled, how can the non-enrolled view the email? - E.g. only via webmail? - E.g. what does it take for non-enrolled recipient to enroll? (4) What infrastructure required to provide above? and How does it work generally? (5) What parts of email are encrypted? And using what encryption algos/params? - just the body? - or also the RCPT To: MAIL From: ... (the so-called envelope) (6) Business model: how make $$$? ---------------------------------------------------------------------------------- Hypothetical case: secureemail.com What we know: (1) provides end-to-end security (2) user enters password, mail encrypted on user's machine before being xmitted (3) given (2), then either one of two things holds: (a) only the data portion of the email is encrypted; thus the envelope (who the mail is from, who the mail is destined to) is in the clear - which explains how the secureemail servers know how to route the message --> In this case, passive observers can learn that this sender is sending an email to this recipient or (b) the data portion of the email is encrypted using the recipient's public key; the envelope portion is encrypted using the public key of the secureemail.com servers --> In this case, depending upon how a non-enrolled recipient receives the mail, passive observers cannot learn that this sender is sending an email to this recipient (4) uses RSA 2048-bit encryption -- so probably (5) ------------------------- One possible architecture ------------------------- (1) Client signs up for secureemail.com account - entails downloading plugin - choosing password - obtaining a certificate (for myUname@secureemail.com) - client specifies who can send him emails (some list of email addresses which may or may not be @secureemail.com addresses) (2) Client sends email from secureemail account to a enrolled recipient - client clicks on "Send securely" and enters his password when prompted - secureemail.com looks up pubkey associated with recipient@secureemail.com; encrypts email with recipient's pub key -- the data portion of that email - sends email to recipient who receives it, decrypts it, ... + How is this different from PGP? Except that secureemail.com is supplanting role of "cert database/directory"? (3) Client sends email from secureemail.com account to non-enrolled recipient - client clicks on "Send securely" and enters his pwd when prompted - secureemail.com looks up target email address, doesn't have a cert/pub key for this recipient so creates one and stores it in its DB - uses recipient's pubkey to encrypt the message - sends encrypted email to recipient along with link to secureemail.com -- recipient will need to click on link to authenticate self to secureemail.com (using what credentials? Null credentials == ability to receive email at that address?) -- or sender creates auth credentials for recipient based on shared secret info (recipient's acct code??) - obtains privkey from secureemail.com - downloads extension - at addt'l cost, recipient can create secureemail.com acct? - then recipient able to receive and decrypt email from this sender as well as from any other sender@secureemail.com - alternatively, recipient could have NOT downloaded anything at all, but instead been sent an email with a webmail link... that lets recipient click on that link, confirms recipient can receive email at that address, creates webmail acct? so recipient can view email online (4) Mechanics of enrolled sender: - has plug in - user creates separate mail account for secureemail.com account, which uses secureemail POP3 and SMTP servers - - when user clicks "Send securely", only works if msg being sent with secureemail.com account - not necessarily: behavior of plug in is agnostic... - only message body is encrypted (not also the MAIL From, RCPT To values), so even if sender sending from me@aol.com, plug in will connect to secureemail servers, figure out whether have cert for intended recipient(s) and, if not, create one; encrypt the body of that message using recipient's pubkey; send message in normal way - So what does recipient get? I.e. what is format of message? -- plug in creates new email: - includes webmail link - so non-enrolled recipient can view email online - includes encrypted email as attachment - so if recipient is enrolled, can automatically open & decrypt mail - includes plugin as attachment? - so non-enrolled recipient can receive this email in his inbox even if he doesn't "sign up" -- installing plugin authenticates recipient, provides his private key to him -- so now recipient can open all email sent from secureemail.com clients to him -- but he can't generate encrypted messages to secureemail.com members unless he signs up for an account? - but if he has his own priv key and has certs for intended recipients, he can use his email client to encrypt an email using a pub key from one of those certs... without signing up for an account + but maybe he only obtains certs from senders IF he signs up? + but what if enrolled sender wants to sign encrypted email in order to authenticate himself to the recipient... then non-enrolled recipient must receive sender's cert in order to validate the signature... ------------ Big question ------------ (1) How to make it so that non-enrolled recipient is able to read mail from an enrolled sender with minimum fuss? But also in a way that prevents non-enrolled recipient from being able to obtain all benefits of enrollment without having to pay... - what exactly do we mean by enrollment anyway? (2) If non-enrolled recipient is able to decrypt and validate signature on email from an enrolled sender using the recipient's email client, what's to prevent that same recipient from subsequently generating email, encrypting/signing that email for an enrolled sender... - all without the non-enrolled recipient paying for anything... secureemail.com acct works to send/receive email to/from any other account liz@secureemail.com <----> liz@sbcglobal.net