At 09:43 AM 6/3/2003 -0400, Eric Dean wrote:
Trying to come up with the right place to shim in the CRI control headers.
It seems we can do the following:
1) Use SMTP headers: beyond the deployment issues, CRI is not limited to the
envelope and there are often many mail relays in the path that could remove
such headers. We do not want to restrict mail clients from implementing
CRI.
As I mentioned before, SMTP would be a good solution only for those cases
when two C/R systems are inter-operable and there is a need for the sender
to take the burden of storing the message. Otherwise, plain email should be
used so us humans can read the challenge message.
2) Use RFC 2822 headers: we could possibly introduce a new field altogether
or use an optional field as spec'd in 3.6.8
Using RFC 2822 headers would limit the amount of information since each
header is limited to 998 characters (as per section 2.1.1). Vernon Schryver
(https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg05168.html)
has already pointed out that MIME headers can store more information which
would be a factor in case some kind of PKI signatures are used..
Additionally, some C/R systems might want to combine several challenges
into one message and that would be awkward to do with RFC 2822 headers. On
the other hand, if such headers are used for single sender-single receiver
C/R headers are the simplest solution.
3) Use MIME headers (registered or private): though CRI has little relavancy
with MIME. Private headers can not become a standard. There isn't such a
limitation on 2822 3.6.8
Thoughts?
Some of the purposes of MIME as stated in RFC 2045 and look perfectly
suited for us:
"(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and"
In our case we can utilize MIME to create a multi-part message with one
part containing a human-readable challenge and other parts containing
machine-readable challenges (i.e. non-textual message bodies). The
advantages to using MIME is that:
1. We can include both human and machine requests in one messages, NOT
limited in size.
2. We can include PKI signatures, hashcash codes, etc.
3. We can include multiple challenges and responses in one message.
I think that all three approaches are good and they fulfill different
needs. I think all three should be used and we will allow C/R systems
to negotiate between themselves:
1. The basic CRI protocol should use RFC 2822 headers, with single
challenge per each sender. This allows for easier use with existing email
systems and non interoperable C/R systems. Such messages will have the
regular challenge message for humans in the message body with additional
information in the headers. Using custom MIME types can make email software
choke and leave the information unreadable to a human being.
2. IF a C/R system is used by the sender, then it can identify itself
either via ESMTP or an RFC 2822 header. Then the two systems can negotiate
on the use of RFC 2822 headers, MIME headers or plain SMTP. This would be
similar to the way HTTP clients negotiate with "Accept-Encoding" and
"Content-Encoding" methods. This would allow interoperable C/R systems to
use MIME and SMTP methods for cases like challenges to multiple senders,
custom PKI, burden of storage on sender, etc.
Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg