I too think the straw man from Dan is an interesting idea. The alternative that I think Hadriel is suggesting (email style as a parameter of the E.164-based SIP URI) would probably not survive any changes of the E.164-based URI by intermediaries -part of the problem with E.164-based URIs in practice.
John > -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: 05 April 2008 19:03 > To: 'Hadriel Kaplan'; [email protected] > Cc: Elwell, John > Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs > > Hadriel Kaplan wrote: > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > > Behalf Of Dan Wing > > > > > > Here is a straw-man idea: > > > > > > On an outgoing request containing an e164-style URI in the From: > > > (or PAI, as you prefer), the domain additionally places the user's > > > email-style URI into a new header (let's call it > "email-identity"). > > > It determines the mapping between a user's E.164 URI and email URI > > > using a flat database (example: +14085551234 -> [EMAIL PROTECTED]). > > > > Interesting proposal. > > > > > This new header is signed along with everything else we like to > > > sign [choose RFC4474, draft-fischer-sip-e2e-sec-media-00.txt, or > > > draft-wing-sip-identity-media-02.txt, as you prefer]. > > > > You wouldn't be able to use 4474 as is, because it has no way > > to sign a new header, afaik. > > Right, RFC4474 is not extensible. > > > (though I'm all for a 4474bis ;) > > I know this is only a straw-man and too soon to get into the > > details, but I can't help myself, so I wonder why you > > wouldn't just put this email-style URI *inside* the From-URI > > as an escaped uri or user param. That way it avoids a new > > header and gets signed by 4474 as is, and really what you're > > saying is it is an alias property of the From-URI. > > That would look something like: > > From: Dan Wing <sip:[EMAIL PROTECTED];[EMAIL PROTECTED]> > > and the originating domain (cisco.com) would provide strong identity > over the entire URI, including the E.164 and the email-style portion > ([EMAIL PROTECTED]). > > I wanted to avoid signing the E.164 in the From, because we have not > yet resolved if we can do that in a meaningful way. > > > > This provides a backwards-compatible way to migrate to email-style > > > URIs, and gives us strong identity with those email-style URIs. > > > > And lets the UAS offer its user the ability to add both the > > e164 and email-forms into its contact address book. I'm not > > sure if that's good or bad, but it's a nice feature. > > Right, but that could also be another attack vector if the > E.164 is unsigned or only trustable hop-by-hop. > > -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
