I'm a little confused by the need to "sign" phone numbers. I mean, whomever uses the number makes a call to or from it right? If the receiver of the call doesn't want to talk to whomever calls, don't they just hang up? This seems like a lot of extra work for little gain.
Thanks, FM -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henry Sinnreich Sent: Monday, February 18, 2008 9:26 AM To: Paul Kyzivat; Shockey, Richard Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers Paul, >My thought is that we already have an algorithmic mapping from an E.164 >phone number to a domain name, defined by enum. If the sender puts an >E.164 number in From, and can sign it with a cert for the enum mapped >domain name corresponding to that number, then that ought to be valid >proof of the validity of the sender. This seems indeed to be cutting the Gordian Knot! (http://en.wikipedia.org/wiki/Gordian_Knot) Should this not be a joint I-D with the ENUM WG, or have at least have some coordination? The exact mechanism to do this is certainly of interest to the ENUM folks. Henry -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: Monday, February 18, 2008 8:51 AM To: Jonathan Rosenberg Cc: IETF SIP List Subject: Re: [Sip] New I-D on RFC4474 and phone numbers Jonathan, I guess the time has come for this discussion, since John Ewell has also submitted a draft on this subject. I thought the problem was already well known, but perhaps not. IMO the main thing now is to figure out the *solution* to the problem! IMO a solution is to use a 4474-style approach, but where the certificate is tied to just the phone number, not to some arbitrary domain name. That of course would depend on a model where the "owner" of the phone number is the one who may obtain the certificate for that number. My thought is that we already have an algorithmic mapping from an E.164 phone number to a domain name, defined by enum. If the sender puts an E.164 number in From, and can sign it with a cert for the enum mapped domain name corresponding to that number, then that ought to be valid proof of the validity of the sender. In those places where public enum is in operation, I think there is already a legal mechanism in place to give the owner of record of a particular phone number control over the contents of the corresponding DNS entry. That should also be sufficient to allow a certificate authority to assign a cert to that same owner. Combine all that and you have a complete e2e identity model for phone numbers, based on public enum. And that can be true even if public enum isn't used to *route* the calls to that number. So it could be used for "unlisted" numbers. To use this approach the From header should contain either a TEL URI, or a sip/sips URI containing the enum-mapped domain name corresponding to the phone number. (I would rather see the TEL used for this - it is more user friendly.) Thanks, Paul Jonathan Rosenberg wrote: > I just submitted: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-concerns -00.txt > > This is basically a discussion on the security properties of rfc4474 > with phone numbers, and a comparison to rfc3325 in this case. Also a > discussion on what happens to dtls-srtp. > > Comments welcome. > > -Jonathan R. _______________________________________________ Sip mailing list http://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 http://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 http://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
