Re: [Asrg] CRI Header

[Yakov Shafranovich <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg