The solution "appears" to be client side, however a bit of automation
can provide for a great deal of leverage as we move from the client
toward the "center" of the network.
In practical terms, if the client moves from job to job, they might take
their secrets with them since the secrets allow them to send messages to
their contacts. (If they maintain their ISP in the move and the ISP
provides facilities to support this mechanism then there may be no
change at all).
Supposing an individual moves entirely from one place to another (ISP,
job, everything), they would simply cary their secrets with them and
then broadcast their new secret (or the old one) with their new address
to all of their other group members. This would allow the group members
to send messages back to them. With some simple protocols this entire
process could be automated.
For example, the moving group member caries with them their collection
of secrets. The secrets allow them to send message to their peers in the
circle of trust. When the moving member reaches their location, they
broadcast their old secret and email address along with a request for
change/addition which includes their new secret and email address. Other
members in the group receiving this request (as authorized by the
correct use of the shared secret) can then update their address books
(or server provided services and directory systems) with the new data.
As a result they are now able to communicate with the moved member
without any problems and without intervention.
... This mechanism cannot be abused because broadcasting this request
only updates the members secrets so that they may, if they wish, send
messages to you. The automation does not provide a mechanism for a third
party to open access to the group... only a member of the group can do
that.... and, if that member abuses that privelege then it is easy for
the group to expell that member from the Circle Of Trust and silence
them...
In general this mechanism can be deployed in phases so that it can easly
support a mix of early adopters and eventually defacto standards for
automation...
It can start as a client side solution by convention only.
At the next level there may be automation in the MUA.
At the next level the provider may make facilities available at the MDA.
At the next level the provider may aggregate user policies for filtering
at the MTA (This is where real pay-offs start).
The users can effectively manage their own secrets because their groups
are small. A user who is a member of 5 groups would have 5 secrets. Only
members of the group need know the secret (excluding the provider who
would know for the purpose of applying filters).
If extended to subscription services, each subscriber record would have
a single additional field containing that user's secret - not much more
difficult than storing their email address and any other data they may
need.
This mechanism is only one part of a more comprehensive solution, but if
it were pushed to it's limits then the proliferation of secrets would
not be a problem because the workload is naturally distributed among the
users with each replicating and managing only those secrets they need. A
few simple protocols can coordinate any automation between these users
and the messages for that purpose could easily be transmitted in-band.
One way of looking at this is that the available computing and human
resource scales almost linearly with the complexity of the system. In
general you would have some number of secrets equal to or less than the
number of email addresses you correspond with because collections of
email addresses (a group) would normally be associated with a single
shared secret. This only changes when an email address belongs to more
than one group if for some reason you need to differentiate your secrets
for that user.
The collective system of individual nodes organizes the complexity
naturally as each node keeps track of it's own context within the whole.
(There are a number of advanced mechanisms that can also be applied
which allow for some third party authentication within a COT but I don't
want to stray into that and dilute the conversation.)
_M
-----Original Message-----
From: C. Wegrzyn [mailto:wegrzyn(_at_)garbagedump(_dot_)com]
Sent: Thursday, July 03, 2003 3:53 PM
To: Madscientist
Cc: asrg(_at_)ietf(_dot_)org
Subject: Re: [Asrg] 2. Problem Characterization - Defining
spam within consent paradigm
True. The problem is that without some kind of management scheme you
might just find yourself having too many little secrets all over the
place. And should you go from job to job or ISP to ISP how would this
work? Is this a client side solution?
Chuck
Madscientist wrote:
-----Original Message-----
From: C. Wegrzyn [mailto:wegrzyn(_at_)garbagedump(_dot_)com]
Seems like a lot of what you get with a cert. This is almost the
approach I took with the design I did. I can tell you it works
and works
well.
Chuck Wegrzyn
Thanks for that. The thing I feel most strongly about concerning this
type of "consent" and/or "identity" mechanism is that certification
mechanism should be open, decentralized, and entirely in the
control of
the end users. Unlike certs, which usually require some centralize
authority for a signature, simple shared secrets can be created and
destroyed entirely at the behest of the user groups involved and
require no cost beyond that effort.
(It is possible to have certs signed by some elected member of the
group, or to self sign, or to elect some local authority for
the local
COT, however the entire cert discussion tends to add unnecessary
complexity I think.)
_M
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg