Hi Ed,
Things that are interesting that may not be in your charts:
Fx = Secure Message Exchange Negotiation
----------------------------------------
Ideally, if a correspondent's email address is known, it should be easy to start the exchange of secure messages with that correspondent. It should be possible to query the entity's email address for any information necessary to initiate exchange of secure message(s). Intent is to not require a single, world-readable directory of all potential email correspondents and their current email address(es), etc. -- the existence of which would likely have disastrous consequences.
F(x+1) = Secure Message Exchange Recipient Privacy
--------------------------------------------------
Conversely, it should be possible for each correspondent to exert their personally desired level of control over just who is able to access to his/her email address and, particularly, the corresponding security profile. Perhaps analagous to Caller-ID, the individual user (recipient) can determine which queries receive valid security information and which are handled in some other way. Intent is to allow desired message exchange but not be forced to spend time handling (mass quantities of) unwanted secure messages.
F(x+2) = Secure Message Exchange Blocking
-----------------------------------------
Ability to "undo" an earlier decision to engage in secure message exchange with a particular correspondent or group of correspondents. I want to "revoke" my credential specifically with respect to future use for communication with certain other correspondent(s).
Obvously, I don't have a specific solution in mind and have not tried to separate these capabilities cleanly. They'll all kind of run together at first. Also, I don't care whether public key, secret key, DH key exchange, x.509 certificates, or (any other crypto technology) is used in any solution.
The main point, at the outset, is to define a compellingly service that has sufficient benefits to drive the efforts necessary to achieve it's development (i.e., as opposed to allocating resources on other activities). All of us have been waiting for at least 10 years to start using secure email (i.e., as we know it today). A decade of collective experience strongly suggests there must be some new thinking before things will be able to move ahead.
Good Luck & Best Regards,
--dg
Things that are interesting that may not be in your charts:
Fx = Secure Message Exchange Negotiation
----------------------------------------
Ideally, if a correspondent's email address is known, it should be easy to start the exchange of secure messages with that correspondent. It should be possible to query the entity's email address for any information necessary to initiate exchange of secure message(s). Intent is to not require a single, world-readable directory of all potential email correspondents and their current email address(es), etc. -- the existence of which would likely have disastrous consequences.
F(x+1) = Secure Message Exchange Recipient Privacy
--------------------------------------------------
Conversely, it should be possible for each correspondent to exert their personally desired level of control over just who is able to access to his/her email address and, particularly, the corresponding security profile. Perhaps analagous to Caller-ID, the individual user (recipient) can determine which queries receive valid security information and which are handled in some other way. Intent is to allow desired message exchange but not be forced to spend time handling (mass quantities of) unwanted secure messages.
F(x+2) = Secure Message Exchange Blocking
-----------------------------------------
Ability to "undo" an earlier decision to engage in secure message exchange with a particular correspondent or group of correspondents. I want to "revoke" my credential specifically with respect to future use for communication with certain other correspondent(s).
Obvously, I don't have a specific solution in mind and have not tried to separate these capabilities cleanly. They'll all kind of run together at first. Also, I don't care whether public key, secret key, DH key exchange, x.509 certificates, or (any other crypto technology) is used in any solution.
The main point, at the outset, is to define a compellingly service that has sufficient benefits to drive the efforts necessary to achieve it's development (i.e., as opposed to allocating resources on other activities). All of us have been waiting for at least 10 years to start using secure email (i.e., as we know it today). A decade of collective experience strongly suggests there must be some new thinking before things will be able to move ahead.
Good Luck & Best Regards,
--dg
No comments:
Post a Comment