At 8:32 AM +0000 11/9/07, Elwell, John wrote:
>If domain C intervenes only when a LI warrant exists for one of the
>users, I don't personally have a problem. But this violates R24, which
>some people seem to think is important.
And, as some people have pointed out, they may have to intervene
every time if they are to meet a legal demand that the LI not be
detectable by the end user.
>If domain C intervenes all the time (either by terminating encryption in
>domain C, so that user A and user B see the source of security keying
>material as domain C, or by demanding submission of the key to domain C
>before admitting the call), I think this is of real concern. It means
>businesses cannot have the security they need when, for various reasons,
>they are forced to go via a domain C.
>
>So I don't think we should do anything special towards meeting R24 at a
>domain C. Although not the IETF's job, those concerned should work with
>carriers and regulators to avoid situations where a domain C can prevent
>normal end-to-end security on calls not subject to an LI warrant.
>
>Concerning the engineering problem to be solved, there probably isn't
>one if we agree that R24 does not apply to a domain C.
>
I would personally be happy with that result. I think the engineering problem
for anyone who believes it *must* apply to C is a hard one: designing a system
which 1) allows C to intercept encrypted material 2) allows C to present
unencrypted material to the LI requestor 3) does not require C to ask for
the keys to every flow to hide the LI (to maintain the privacy of the flows
not subject to the LI) and 4) does not reveal C's action to A or B.
I am not sure that it admits of a solution that does not require a lot of
computational
power on the part of C (or, if the burden in 2 shifts to the LI requester, on
the part of
the LI requester)
regards,
Ted
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
