I too think that the idea is interesting - modulo all the loose ends.
Paul
Elwell, John wrote:
> 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
>
_______________________________________________
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
