Richard Shockey wrote:
>> I agree that the problem exists. But in the end for any signing based
>> on number to work there must be a tie to the legal notion of ownership of
>> e.164 numbers. There is no getting around that. Its just a matter of
>> whether there is *one* system for tying to ownership, or two.
>
> Well just as a small side bar here ... by International Treaty ...yes our
> friends in Geneva, no one "owns" phone numbers. The governance of E.164
> phone numbers are strictly nation state matters. So anything that touches
> the namespace gets to be vetted by each and every country. See the IAB-ITU
> agreements on e164.arpa for instance.
>
> You are starting from a fallacy aka "ownership" already and fast going
> downhill. "Right to usage" is even more a slippery slope...been there done
> that. :-)
I haven't been involved in the space like you have. I realize that
"ownership" iss probably too strong a word. Pick whatever word you like.
Some entity is entitled to have a phone associated with a particular
number, and other entities are not entitled to have phones associated
with that same number. Whatever you want to call that is ok with me.
When the feds show up with the warrant, what does the SP tell them? That
is what defines it.
In those places where public enum is supported, some entity is entitled
to give instructions on how it shall be populated for a given number.
What do you call that entity?
Thanks,
Paul
>> In this case it doesn't require that dns entries in the e164.ansi tree
>> be populated. Rather it requires that some CAs support the legal
>> framework for assigning certs, based on the same definitions of
>> ownership.
>>
>> It isn't essential that the certs be distributed to the end users
>> owning the numbers. A SP could act as an agent for the user in managing
> the
>> cert and doing the signing. (But an end user who wants to sign his own
>> requests should be able to get the cert.)
>
>
>
_______________________________________________
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
