[Dev] Automatic secure email
Elankath, Tarun (Cognizant)
ETarun at blr.cognizant.com
Thu Nov 7 00:01:11 PST 2002
Your article has been extremely interesting to read and so has been this
Some doubts (I apologize if they are naive)
1)I still don't see this prevents spammers from sending profile requests to
a large number of email addresses. Could you shed more light on the
"hash-cash" strings as you put it ? I mean couldn't all these numbers be
generated in the past and then the profile requests sent in one go ? Clients
would need to do more before sending profile responses back. I am not sure
that a "verification ping" as put forth by Aaron is the correct approach. We
may need do to a DNS check as well ?
2)Multiple profile associated with each email address is really interesting.
How are these profiles distinguished from each other ? Do we make some sort
of hash ?
3)The URL to get the public key is _not_ a good idea. There is no guarantee
that everybody has access to http. Many corporates block http during working
hours. Atleast it happens here in India :-)
4)What kind of problems will e-mail forwarding introduce in such a scheme
(if any) ?
5)I guess clients might end up having to support _both_ the "keys in header"
approach and the "round-trip approach"...
From: Andy Hertzfeld [mailto:andy at differnet.com]
Sent: Thursday, November 07, 2002 12:04 PM
To: Aaron Swartz
Cc: dev at osafoundation.org; design at osafoundation.org
Subject: Re: [Dev] Automatic secure email
> Anyone can publish their public key to the Web simply by pasting it
> into one of these forms:
> There are many others. You end up with a URL like
That's still too hard for many users to do. It needs to be
truly automatic if it's going to succeed, but perhaps Chandler could
register the keys automatically at key generation time. I'm not sure if
we can count on servers doing this on a large scale, for free,
>> There are multiple existing cryptographic algorithms and formats; it
>> would be nice to be able to support as many as we can, including ones
>> not yet defined.
> "While good formats allow you to select from a variety of options and
> extensions, there are times when this is not valuable. If there are,
> for example, two algorithms one can use to encrypt a message, all that
> means is that all encrypters are forced to be able to do both."
> - http://www.templetons.com/brad/cryptech.html
Well, there are multiple formats currently in use. It would be
great if everyone agreed on one, but I wouldn't count on it.
> Why would you want to do SOAP over email?
> MIME is currently designed to be fully extensible without requiring
> such a profile.
We eventually want to do SOAP over email so we can build
frameworks that use email for transactions and workflow type
applications, for example, buying a concert ticket or booking a plane
flight. But we can discuss that some other time.
MIME is extensible, that's sort of the problem - not all
clients support all MIME-types; hand-held clients are especially
spartan. We can do a better job if we know what types a client supports
when sending a message, so we can send them types they actually can use.
By the way, I don't necessarily think that it's bad to use the
"keys in header" approach you're advocating, instead of the "request a
profile" approach and I'm willing to go that way in Chandler if it makes
automatic secure email happen. I just think the other approach is
somewhat better, but I'm not even sure of that until we do more work and
try it out.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
-------------- next part --------------
This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly
prohibited and may be unlawful.
Visit us at http://www.cognizant.com
More information about the Dev