Re: IRIP version 4 (Part 2) - Trusted hosts

[Bruce_Kahn@xxxxxxxx]

Doug replied (in part):
>> >A trusted relationship between two IRIP servers means that one server
>> >can queue transactions for the other server and deliver them some time
>> >later. If IRIP server B trusts A, then A can queue requests for B. If A
>> >does not trust B then B cannot accumulate requests for A.
>>
>> Why cant there be a queue between non-trusted hosts?
>
>I think it could be a security issue as there would not
>be any way to trust who is asking for the data.

Not an answer.  If B can AUTHENTICATE to A and visa versa so each is able
to 'log in', there is still _no_ implication of trust.  Trust !=
Authenticatable.

If B is just an intermediate host between A and C then there is nothing to
preclude (or mandate really) the use of signed and/or encrypted data
between them such that B cannot see or tamper w/it.   Also, if there is
just 1 way trust then the entire concept of queueing outside firewalls on
intermediate hosts (ie: B) is easily broken.

Perhaps Im just a bit naive WRT trusted systems, etc so Id like to hear a
bit from Bob or Paul on this topic...

>> This happens for stuff like SMTP mail so what is wrong w/it here?
>
>Its not quite the same. In SMPT someone sent data to you and they
>can decide if it should be secured.
>
>With iRIP you ask for data and the replying side has no idea
>how important the data might be to someone.

Huh??  A sender does NOT decide the format my server saves incoming mail
into; thats my implementations decision!!   It _DOES_ however decide
encodings and security (ie: mulitpart/signed MUST be generated by the
sender, not the receiver!!).  This same concept applies here too.  If Bill
Gates wants to invite Ray Ozzie to a meeting, Bill decides if it should be
128 bit encrypted, etc, not Ray (or some intermediate host)!.

Still, the question about being able to queue requests for non-trusted
hosts still stands: Why not??

Bruce