> I Said: >> And asking the customer for the key on every call is clearly a >> non-starter as a real-world solution to any of this. > > and Dean responded: > Please explain the preceding.
So I will elaborate. The issue with answering is that there are several different assumptions that one might make about how this would work. I am unlikely to cover the cases other people may be thinking of. So, assume first that the behavior is that the system asks the client for the keys, and the client asks the user if it is acceptable to deliver the keys. As Dean observed, if you are going to do this and meet R24 (which is clearly mandatory for any meaningful LI), then any network that might ask for the key has to ask for it every time, whether it uses it or not. If the users actually had a choice, then asking them might (barely) make some sense. But if the users can say no, then they should be trained to always say no. And then we don't have an LI solution. So, if the user says no, when asked if the device can deliver the key, then the user will not be permitted to make the call on that network. Thus, the defined system behavior can be paraphrased as "Make it easy for the system to ask for the key, and train the users to say yes whenever they are asked for the key." As far as I am concerned, that is NOT a secure solution. That is a pretense of security. It would be more honest for such networks to simply refuse to permit encrypted media at any time. Yours, Joel PS: I don't know how the following complication further plays into it: What stops the handset from delivering a false key? I suppose we could define a solution where there is an interface for the system to ask for a key, and the system hands over whatever it feels like. The carriers can then try to ensure that their "approved handsets" hand over the real key? _______________________________________________ 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
