[Dev] Automatic secure email

[Elankath, Tarun (Cognizant)]

This is a multi-part message in MIME format.

------=_NextPartTM-000-8c863708-f97c-4189-a81c-070a285802e4
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi Andy,

Your article has been extremely interesting to read and so has been this
discussion.

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"...


Regards,
Tarun



-----Original Message-----
From: Andy Hertzfeld [mailto:andy@differnet.com]
Sent: Thursday, November 07, 2002 12:04 PM
To: Aaron Swartz
Cc: dev@osafoundation.org; design@osafoundation.org
Subject: Re: [Dev] Automatic secure email


Hi Aaron,

> Anyone can publish their public key to the Web simply by pasting it 
> into one of these forms:
>
> http://pgp.mit.edu/
> http://www.{us,ca,ch,dk,de,no,uk}.pgp.net/pgpnet/pks-commands.html
>
> There are many others. You end up with a URL like 
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x79F0DF4B

        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, 
indefinitely, though.

>
>> 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.

-- Andy



_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

------=_NextPartTM-000-8c863708-f97c-4189-a81c-070a285802e4
Content-Type: text/plain;
	name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_Disclaimer.txt"


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


------=_NextPartTM-000-8c863708-f97c-4189-a81c-070a285802e4--