On Apr 4, 2008, at 11:15 PM, Hadriel Kaplan wrote: >> ... >> If you're a US business, and you sign a a request containing a >> telephone number, and it turns out you're wrong (not because you're >> doing it on purpose, but because you are incompetent) and I get taken >> in by a scammer as a result of your mistake, I can sue you for all >> the >> damages I receive. I might even win, and at the very least, I'm going >> to cost you a big chunk of money. > > Yes, and you mistook my premise I think - I was not arguing about > that for a US firm (heck, in the US you could sue even without a > signature ;) - I was arguing about it for a foreign one. Whether a > US-based identity issuer (e.g., Verisign) has that liability for > certs it gives out to foreign entities I don't know, IANAL, and > isn't germane to my argument (I think). >
Ok, I'll buy that. > >> But if you signed the request with a stipulation that you passed the >> request on, but that the identity came from the PSTN and is not >> something you have verified (and these things are true), then you are >> NOT liable, because there is no genenral expectation that PSTN caller >> ID is absolutely correct. > > Then everyone would set this source=unverified param, even those > that have very reasonable expectation of it being legit, and we > wouldn't get the semantic difference we're looking for. The legal premise is "best current practice" -- you can't be absolutely sure in any case, but if you're such a doofus that you do a full RFC 4474 signature on something that we all agree can't be verified, then you may need to get slapped awake. Unfortunately, the way RFC 4474 and DTLS Framework currently interact means that NOT using RFC 4474 on PSTN-sourced calls makes you almost as much of a doofus. So we either change need to change RFC 4474 (by making a signature "mean less" OR by allowing one to make a disclaimer on the signature), or we change DTLS-SRTP framework to make it nod depend on RFC 4474 for end-to-end communication of the signature. We do have two drafts (Wing, Fischer) that would accomplish this. > >> Given this, and in the absence a mechanism for making a disclaimer, >> you WOULD have to be a fool to slap an identity header on something >> that you didn't authenticate. > > Then I think anyone would have to be a fool to slap an identity > header on anything, including things they authenticated. SIP's > trust model simply isn't HTTP's, even with SIPS and TLS and all. It > isn't even really the same as email's, though certainly closer. Appropriate legal caution is required in all commercial practices. But blatant disregard for common sense will usually get you in trouble. -- 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
