On Apr 4, 2008, at 2:50 PM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >> Elwell, John >> >> There seems to be some interest in adding some indicator to the URI >> or >> to the header field to warn of the limited guarantee of >> authenticity or >> the opposite (i.e.,lack of such an indicator would mean the >> guarantee is >> low, i.e., the identity has not been verified). > > I haven't thought about this since it was last on the list, and I > think I was a proponent of it at that time, but why were we thinking > this would ever be set? I mean if I'm a clid spoofer, why would I > ever want to add such a param?? Isn't it like a "spam=yes" flag > you're describing, and then expecting potential spammers to set it? > I've forgotten the train of thought which lead to this param as a > viable solution.
The Identity header essentially signs the From. It's traceable back to whoever made the signature. So, if you were an identity server, you could spoof any kind of caller ID you might want. But we'd know it was you doing it . . . What we're looking for is a way for an RFC 4474 identity server to say something about how strong it believes its assertion to be. Sure, it could lie, but then we wouldn't trust it in the future. It's much better if it volunteers the information to us that it doesn't REALLY know who the caller is, since it has only the caller-ID information to go from. If an identity server were to fully RFC 4474 "sign" a message rom a PSTN, it's even possible that the identity server operator could be held legally liable for inaccuracy in the asserted identity. In other words, if a caller-ID spoofer made a call through the example.com gateway, and the example.com identity server attaches an Identity header on to the resulting INVITE that asserts the spoofed telephone number identity, then someone injured (defrauded) by the caller could claim negligence on the part of the example.com identity server and sue for damages. This is why things like identity servers (and CAs) have statements of policy that describe their procedures and the strength of claim being made. Those published policies are legal contracts with the users of the certificates. It's part of why x.509 certs are so big and have so many things like subject-alt-names and extended key usage. SIP identity services need the same sorts of legal flexibility. Being able to sign a request on the basis of "I swear to you that it came through my gateway, but I don't know who it really came from, so I make no assertions about this identity other than that the request came through my gateway with the calling-party-ID information described herein" is really, really important. -- Dean _______________________________________________ Sip mailing list https://www.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
