Mikalai Birukou
2015-08-18 22:40:46 UTC
MailerId is one of the protocols developed in
https://github.com/3nsoft/3nweb-protocols
Raison d'etre for MailerId is to authenticate message senders and
recipients in ASMail (Authenticated Secure Mail), which will replace
today's SMTP email. Authentication (against spam and fishing) of senders
must be done in a non-tracking way, thus, naturally it does all signing
like BrowserID does it. Hooray! MailerId uses "best parts" of BrowserID.
To work in *any* client, MailerId must step away from browser-centric
login to Identity provider in a provisioning stage. MailerId uses a
login process based on public key cryptography. Public Key Login (PKL)
protocol describes this login process. There are several things to
mention about PKL:
1) Use of public crypto assures both sides (on top of SSL layer): client
is assured that it is talking to server that knows its public part of a
login key.
2) Protocols allows client may use only keys, which is usually more
secure option, than passwords.
3) PKL uses keys, but keys may be password generated, or be
password+second factor generated, or be key+second factor generated.
There is lots of flexibility in PKL's approach.
4) If there is MitM on PKL, instead of disclosure of target's password,
as it happens now, attack translates into offline attack on password, in
cases when key is generated from a password.
5) A by-product of PKL is an establishment of a mutual secret key
(session key). MailerId uses this session key to protect provisioning
stage against MitM of HTTPS.
3NWeb uses JWT (JSON Web Token) notation in a bit friendlier to app
developers way:
1) In keys' json, field "alg" is used for a *complete* description of an
encryption box-algorithm. No other fields should be needed crypto
parameters. For example, demo code (
https://github.com/3nsoft/3nweb-protocols ) uses NaCl from (
https://github.com/3nsoft/ecma-nacl/ ), and "alg" values for this
library are 'NaCl-sign-Ed25519' for signing, 'NaCl-box-CXSP' for public
key encryption, and 'NaCl-sbox-XSP' for symmetric keys.
2) In keys' json, field "use" is used for app's purposes, so that a key
cannot be reused by accident. For example, "mid-sign" is for user's
MailerId key. And, although, an app may have other signing keys that use
the same algorithm, different "use" field values will distinguish keys.
3) Signature and load that is signed are kept in "sig" and "load" fields
in SignedLoad json object. Concatenation with "." and turning whole
thing into string is replaced with json-stringifying of SignedLoad. At
the same time SignedLoad carries id of a key that did signing, its "alg".
As a whole, 3NWeb project aims at having mail, storage and other
functions done at a highest level of security and privacy, while still
being implementable even in browser environments, which is more
restrictive than a native approach. Therefore, all client code in demo
https://github.com/3nsoft/3nweb-protocols runs in a browser. This same
code will run in FirefoxOS. And this is were we say that security and
privacy can be affordable.
What do you think about MailerId and PKL? Should this become future
BrowserID, implemented (native crypto code) first in FirefoxOS and later
in browser?
https://github.com/3nsoft/3nweb-protocols
Raison d'etre for MailerId is to authenticate message senders and
recipients in ASMail (Authenticated Secure Mail), which will replace
today's SMTP email. Authentication (against spam and fishing) of senders
must be done in a non-tracking way, thus, naturally it does all signing
like BrowserID does it. Hooray! MailerId uses "best parts" of BrowserID.
To work in *any* client, MailerId must step away from browser-centric
login to Identity provider in a provisioning stage. MailerId uses a
login process based on public key cryptography. Public Key Login (PKL)
protocol describes this login process. There are several things to
mention about PKL:
1) Use of public crypto assures both sides (on top of SSL layer): client
is assured that it is talking to server that knows its public part of a
login key.
2) Protocols allows client may use only keys, which is usually more
secure option, than passwords.
3) PKL uses keys, but keys may be password generated, or be
password+second factor generated, or be key+second factor generated.
There is lots of flexibility in PKL's approach.
4) If there is MitM on PKL, instead of disclosure of target's password,
as it happens now, attack translates into offline attack on password, in
cases when key is generated from a password.
5) A by-product of PKL is an establishment of a mutual secret key
(session key). MailerId uses this session key to protect provisioning
stage against MitM of HTTPS.
3NWeb uses JWT (JSON Web Token) notation in a bit friendlier to app
developers way:
1) In keys' json, field "alg" is used for a *complete* description of an
encryption box-algorithm. No other fields should be needed crypto
parameters. For example, demo code (
https://github.com/3nsoft/3nweb-protocols ) uses NaCl from (
https://github.com/3nsoft/ecma-nacl/ ), and "alg" values for this
library are 'NaCl-sign-Ed25519' for signing, 'NaCl-box-CXSP' for public
key encryption, and 'NaCl-sbox-XSP' for symmetric keys.
2) In keys' json, field "use" is used for app's purposes, so that a key
cannot be reused by accident. For example, "mid-sign" is for user's
MailerId key. And, although, an app may have other signing keys that use
the same algorithm, different "use" field values will distinguish keys.
3) Signature and load that is signed are kept in "sig" and "load" fields
in SignedLoad json object. Concatenation with "." and turning whole
thing into string is replaced with json-stringifying of SignedLoad. At
the same time SignedLoad carries id of a key that did signing, its "alg".
As a whole, 3NWeb project aims at having mail, storage and other
functions done at a highest level of security and privacy, while still
being implementable even in browser environments, which is more
restrictive than a native approach. Therefore, all client code in demo
https://github.com/3nsoft/3nweb-protocols runs in a browser. This same
code will run in FirefoxOS. And this is were we say that security and
privacy can be affordable.
What do you think about MailerId and PKL? Should this become future
BrowserID, implemented (native crypto code) first in FirefoxOS and later
in browser?