Hello list,
I have this proposal. I can re send it in PDF if you don't like the text
edition.
I know it's too early to send this kind of proposal, but please keep in
mind the idea that, if signature is required, use the existing business
relationships instead of making the Verisign mistake again.
------------------------------------
Email Certification Path Proposal.
Author: Alejandro G. Belluscio
IIGECI
Argentina
Sending Account (SA): refers to the Legal Entity or person identified by
a given user and password within an SMTP authorized users domain that
originates an email.
Recieving Account (RA): refers to the Legal Entity or person identified
by a given user and password within an SMTP authorized users domain that
recieves an email.
SMTP Manager (SM): The legal entity managing a SMTP server.
Unsolicited Mail Claims Account (UMCA): an email account set up by each
SMTP. Manager to exlusively recieve signed emails sent by a Sending
Account of his domain that are claimed to be Unsolicited Email. This
account should discard any email not signed by his own certificate or a
certificate directly signed by himself.
Unsolicited Mail (UM): I will not define unsolicited mail, because this
is a consensus definition. But I'm trying to make this proposal so
anyone in this system thinks that in good faith he's not really
bothering recipients when sending mail.
Offending Mail (OM): Mail that's percieved by the reciever as "not
wanted to be recieved". Note that this definition is flawed too, but its
not the core of the proposal.
Sender of Unsolicited Mail (SUM): Self explanatory given the
undefinition of UM
Unsolicited Mail Claim (UMC): A signal from a reciever of an email that
certain email was not solicited and clasifies it as "spam". Please note
that this is subject to change and open to discussions.
Objectives
-To have a certified sender in the sense of a legal entity .
-Keep the privacy of the sender and reciever when necesary.
-Minimize the cost of entity certification.
Description
1. Each SMTP has to enable SMTP-AUTH. This enables the server uniquely
identify the Sending Account sending such mail.
2. Using that information the header is then added a signature using a
certificate of the SM plus a code that let's said SM to uniquely
identify the Sending Account. This code should be chosen so as to be non
descriptive of said account for a third party, even if he recieves
multiple emails.
3. An UMCA belonging to the SM and one belonging to the direct signer if
his own certificate is added to the header signature.
4. (to discuss or optional) On a recieving SMTP if the email has a valid
signature path, it's signed by himself and given a code that let's the
SM uniquely identify the RA.
5. (from now on I'm over extending a bit) Should a user regard an email
as unsolicited he should:
a. If his MUA supports this system, the OM should be sent
(verbatrim?) as a UMC to both the SM's and it's immediate certificate
signer's UMCA.
b. If his MUA doesn't support this system, the RU should forward it
to a given account by his own SM that automates the point 5.a task.
Benefits
-This system allow a positive identification of the offending SA.
-It automates most of the task of identification of SUM while keeping a
certain degree of privacy to both SA and RA.
-It also minimizes the cost of certification authorities by using
existing business relationships.
-This system can be rolled with no intervention of the end users save
configuring SMTP-Auth (which many ISP force anyway). Some work on MUA
might be necessary but only to automate further the task.
-It significantly reduces the cost of processing UM by automating the
processing of emails that complies with this standard.
-It keeps the authority of ISPs intact.
-We don't create some artificial new authority.
-There's no reason fees should levied for the signature since it should
be just a simple more step in the setup of an account in an ISP,
backbone provider, etc.
-The incidence on existing protocols is nil.
-MTA should need a rewrite, but may use the signature infrastructure of
SSL, so the effort should not be too high.
Bad
-Increase in the size of every email by a fixed amount. So if email's
keep getting biggers this cost as a proportion decreases.
-MTA will need to be rewritten.
-The cost of resources for the SMTP. The ongoing trends of speed
increase and encryption acceleration in the mainstream CPU may offset
part of this cost in with time, but for high volume servers custom
hardware acceleration of the signature might be necessary.
-It's pure network economics. It might be very difficult to apply at
first since there's little benefit unless "everybody" is in the system.
-The absolute usefullness of the system can only be achieved with a
change in the MUA. Unless the system is so successful that the SM can
"reasonable" configure it's server to deny any non-signed message.
Rationale
The idea of sending the UMC back to the SM is to send a certain
"evidence" of the action and to allow the SM to keep a statistic
regarding any given SA and UM.
The idea of sending the UMC back to the SM's certificate's signer is to
allow him to keep statistics and a certain degree of control that the SM
is making his job. In a sence it's a tool to keep his own signature as
good.
Certification Authority Path.
Root Certificate Authorities
The upper certification authority should be the RIR or IANA. Since they
have actually make the effort to positively identify the organization to
whom they have given IP numbers, the cost of certifying it's true
identity it's already made. It also mreduces the number of CA to a small
stable number. They must provide certificates with the possibility of
making further signatures.
Second Level Certificate Authorities
The following level should be the backbone providers who sell bandwith
and connection services to ISP. Again, their customers are known and
providing a signature should be a minimum cost. They must provide
certificates with the possibility of making further signatures. For its
final clientes they should make an third level certificate and sign with
such certificate non signing certificate.
Third Level Certificate Authorities
The ISP should implement part of the SMTP protocol for the small clients
and may sign the certificate for well known, big customers. The
certificates thus signed should not be able sign further certificates.
Fourth Level Certificate Authorities.
Customers who want to have their own SMTP server should have them signed
by their respective ISP.
TODO:
Policy for revocationg signatures. When do we consider that some ISP
hasn't made his work?
The specifics of the PKI. Some of the PGP standard might be applied
here. My take is to use the SSL ceritfication part, without the
encryption.
Common registry of revocated Legal Entities. So known spammers can't
sign up an ISP that wants to be in this system.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg