On Mar 14, 2008, at 10:17 AM, Adam Roach wrote: >>> >> [JRE] Many phones do recognise P-Asserted-Identity and use that in >> preference to an unsigned From URI. It is difficult to find a >> solution >> that will not upset any existing deployed device, but we can at least >> try to make it work acceptably with a sizeable population. >> > > So we've gone from warning "don't implement internet-drafts" to "don't > implement RFCs"? It seems folly to pull the rug out from under > existing > user agents when we've already identified at least one approach that > seems to satisfy the keying requirement without breaking existing > deployed equipment or making assertions that can't be verified by the > asserter.
I think this is just another caveat on existing equipment. Some phones, if P-A-ID is present, will preferentially display it. Some will do this even in the presence of an Identity-signed From: field that contains conflicting information (inasmuch as they ignore Identity completely and prefer P-Asserted-Identity to From). This is simply something that happens. We have to analyze the situation from a backward-compatibility perspective. Proposal: Include a usage disclaimer parameter on the URI in the From: field of a request to which we apply RFC 4474 authentication service, resulting in an Identity header that signs the request (including the URI part of the From: field). Case 1: Somebody in the loop is RFC 2543 and not 3261 Result: Proposal breaks because RFC 2543 nodes may fail when proxies change From: fields. This doesn't bother me at all. Case 2: Receiver doesn't understand RFC 4474 or this proposal: Subcase 2a: Receiver prefers From: field Result: Contents of From: field are rendered. This MAY inform a knowledgeable user of the lack-of-trust, but probably won't. Subcase 2b: Receiver prefers P-A-ID Result: Contents of P-A-ID are rendered. So this results depends on how P-A-ID was populated, which is up to the implementation. Case 2: Receiver understands RFC 4474 but not this proposal: Result: Contents of From: field are rendered as verified. Depending on the rendering, this may either inform a knowledgeable user, or display as verified information that we know is not verified. Case 3: Receiver understands RFC 4474 and this proposal (and DTLS- SRTP) : Result: Contents of From: field are rendered as unverified. Media is encrypted. Media is verifiably bound to signaling. All is good. -- 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
