[stir] Validating TN authority together with number portability

[Julio Martinez-Minguito <[e-mail]>]

Hi,


The current drafts for RFC4474bis and certificates describe how to validate that a telephone number is owned by the operator signing the calling Identity. A TNAuthorizationList may be included in the certificate listing the numbers the operator is authoritative for.

However, I see some issues handling this together with number portability which need to be clarified.
Subscribers will be ported in and out quite frequently, making the information in the certificates obsolete. To keep up the pace with the number portability, the operators certificates would have to be updated frequently. Should the certificates have short validity times? E.g. 1 week, or even shorter?

Instead of having the TN information in the certificate and need to update it constantly, it would be more appropriate to have a trusted server connected to the national Number Portability DB (to update the information) to which the verifiers can connect and retrieve the authority information. Each verifier could retrieve the TN lists for operators and refresh the list daily, without needing to re-issue operator certificates, so it would be updated with the latest portability.

About how to represent the TN lists, e.g. if an operator owns the range 555-xxxx, with the current definitions it will be easy to describe:
TelephoneNumberRange ::= SEQUENCE {
      start TelephoneNumber = 5550000,
      count INTEGER (2..MAX) = 10000
      }

Now, if number 555-6789 moves to another operator we have to represent with:
({start = 5550000, count = 6789}, {start = 5556790, count = 3210})

As more numbers are moved out from the range, this representation format will get messy and difficult to manage.

To handle NP it would be easier to keep the original range, and include a list of excluded numbers which have been ported out, e.g.:

TelephoneNumberRange ::= SEQUENCE {
      start TelephoneNumber,
      count INTEGER (2..MAX),

      excludedNumbers SEQUENCE SIZE (1..MAX) OF TNEntry
      }


Is this a feasible solution? Is it too late to handle now due to the current state?