RE: [Asrg] C/R Interworking Framework

[Yakov Shafranovich <[e-mail]>]

At 04:46 PM 6/15/2003 -0600, Art Pollard wrote:

>At 01:49 PM 6/15/2003 -0400, you wrote:
>>At 11:18 PM 6/14/2003 -0400, Eric D. Williams wrote:
>>
>>>On Monday, June 09, 2003 6:21 PM, Art Pollard [SMTP:[e-mail]] 
>>>wrote:
>>>8<...>8
>>> > ... The CR system would filter based in the digital signature rather
>>> > than the FROM address.
>>>
>>>A signature that signs what? or do you mean a 'hash' produced using a 
>>>'senders'
>>>private key?
>>
>>I think he meant a digital certificate issued by a third-part certificate 
>>authority, not a digital signature.
>
>Actually, I meant a digital signature. ;-)
>
>Given a digital signature, one can be assured that the person who the mail 
>says wrote the message actually wrote the message.  It will assist to 
>prevent spoofing of the sender's information (such as when spammers search 
>archives to figure out who knows who).

It also kills the concept of deniability - all emails sent via such systems 
cannot be later denied by the sender. This would cause problems just like 
any other PKI system with cases where private keys are stolen. It would 
also given a much bigger legal weight to email messages than today.

Also, will headers be signed as well?

>I envision when the whitelisting of an individual happens, their public 
>key would be kept on record.  The public key could be given in the header 
>of the message that passed the CR process.

Headers are limited in size to 998 characters (RFC 2822). Large keys, 
especially after base64 encoding or MIME could easily dwarf that limit. 
MIME headers would have to be used instead.

>Then if a new message comes in, the public key (again in the header) would 
>be looked up to see if it has been whitelisted.  If it is not in the 
>whitelist, a challenge would be sent.  If it is in the whitelist, then the 
>message would be checked to ensure that the key and the signature match. 
>If it passes then the message goes to the user.  If it does not pass, a 
>challenge would be sent.
>
>So, in a sense, the whitelisting would be based on the public key -- not 
>on the e-mail address or user name or something forgable.
>
>This avoids having a third party authority having to provide certificates 
>for one person or another.  People could generate their own key sets.  And 
>as long as they provided the same public/private keys to each account that 
>they used then their previous whitelistings would go with them.

This being the main advantage of such scheme - ability to switch email 
addresses without being re-whitelisted.

>You do not need somebody to provide a certificate since the odds of having 
>two people having the same public/private key pair are minimal and if 
>there were a collision, there isn't much that a spammer could do about 
>it.  And even if they could, it would only consist of spamming only a 
>handful of people (like 1-100) -- not the millions that they are used 
>to.  It just wouldn't be worth their time and effort.
>
>I don't think that certificates through a third party that guarantee that 
>someone is who they say they are are really worthwhile since all it takes 
>is for someone dishonest to start handing out falsified certificates.  Or 
>if a centralized certificate authorities were used, they would have a hard 
>time keeping up with applications.

Additionally, some systems such as PGP, do not use third party CAs.

>Instead, just let people generate their own public/private keys and don't 
>pay attention to whether they are who they say they are as the CR system 
>will weed out those who have malicious intent.

Correct. This scheme may very well fit within the general CRI protocol as 
an extension.


_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg