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

Reply via email to