> > > Furthermore, trying to match sender identity as carried in > > > From to the TLS-level connection identity as carried in the > > > certificate does not work well in the the hop-by-hop model. > > > For instance, the sender's From may as well be [EMAIL PROTECTED], but > > > the last upstream proxy that opened up a connection to the > > > recipient could be some intermediary (proxy.com) not in the > > > a.com domain, thus making it impossible to enforce that the > > > From must match the identity of the last upstream proxy in the > > > certificate. > > > > Agreed. > > > > > Did you have some alternate or new thoughts on this to see if > > > we can hash out something that would still be in the context > > > of the domain-certs draft? As it stands, Scott and I are about > > > to submit a final post WGLC revision on it by next week. > > > > I don't think extending domain-cert's scope would be wise -- > > rather, I do think this is a separate problem. The separate > > problem is that with *some domains* you connect to (and do > > domain-certs validation with), you trust them to claim and > > use any old "From" they want -- because with those domains > > you trust them to have done some validation of their previous > > hop, who validated their previous hop, etc. This is how > > you would configure a SIP trunk with a service provider, for > > example. > > > > However, if you are communicating directly with another > > organization then you would not want to allow them to assert > > any identity they wished, because the only identity you expect > > them to send you requests with a From that had their own > > identity (@microsoft.com, @boeing.com, etc.) -- that is, > > the identity of their own employees. You do not expect them > > to assert the identity belonging to some other company. You > > would not extend the transitive trust to them. > [JRE] It depends. I ([EMAIL PROTECTED]) receive a call from > [EMAIL PROTECTED], and because I am working at home, the siemens.com proxy > forwards it to my home via a service provider. The service > provider now > needs to accept [EMAIL PROTECTED] (rather than [EMAIL PROTECTED]) as the > source of the call. At home I would expect to receive [EMAIL PROTECTED] as > caller ID.
So the title of the document would be "Validating SIP From Considered Harmful". After writing that document, do you feel the community would then see the need for designing a B2BUA-survivable identity mechanism?? -d _______________________________________________ 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
