Re: [stir] current draft charter - ENUM and databases

[Henning Schulzrinne <[e-mail]>]

On Jun 15, 2013, at 3:06 PM, Hadriel Kaplan wrote:

> 
> On Jun 13, 2013, at 9:12 PM, Henning Schulzrinne <[e-mail]> wrote:
> 
>> Also, I suspect there would be fewer concerns if the DNS-like database mainly referred to other databases, which can then be access-controlled as needed, and can evolve.
> 
> But that's just moving the problem around, isn't it?

Yes, in the spirit of "All problems in computer science can be solved by another level of indirection". My hunch is that directories/databases/DNS that try to enforce policy are likely to fail, but relatively policy-neutral ones have a better chance.


> 
> I mean ultimately some of us might want to actually implement the signing and verification into our systems.  If it uses public-key signatures, then we need a standardized protocol by which our systems can query for a certificate signed by some authority we trust for a given E.164 number.  If DNS tells us "go look over at FOO": then what standardized protocol does FOO use that we need to implement?

Wouldn't plain HTTPS do the trick, as in 4474?


> why should we trust it for this caller-id? and how does it avoid the privacy problems and ownership problems and so on?  How do you even know we can reach FOO, if it's not necessarily publicly reachable?
> 
> I mean all I've heard is this: 
> Step-1) Some magic happens somewhere, to enable the caller to generate a HTTP URL anyone can use**
> Step-2) You get the HTTP URL in SIP from the caller through some chain of providers
> Step-3) You send a GET request to above URL
> Step-4) Some more magic happens**
> Step-5) You get back a magic certificate
> Step-6) You trust the magic was real, and use the cert to verify
> Step-7) Ta-da! You've now verified the caller-id!
> Step-8) Profit.
> 
> **note: please contact the universal magician so we can make the magic stuff happen for you and everyone else.

I don't think it's quite *that* bad. What I've heard so far is some version of:

* Very small number of entities (1-10ish per country code) sign "public key X is entitled to use TN [range] A". The cert is conveyed in some proprietary fashion to the number holder, similar to how today's web CA's deliver certs to their customers. A single entity can have any number of public keys, if they want to obscure their number holdings or for operational reasons. Working group to-do: Define appropriate X.509 content for numbers.

* Small number of "convenience" database providers host certs, including possibly carriers (if they don't care about identifying themselves). The database providers offer scaling and access control. National policy decides what kind of access needs to be granted to whom (fees, non-discrimination, etc.).

* Certs are retrieved via the HTTPS URL that's included in 4474bis header. Clearly, the entity doing the signing has to know where to find the cert, but as long as the number of entities signing is small, this seems quite manageable.

* The validator knows trusted root CAs. Future work: A DANE-like mechanism to list those, e.g., based on prefixes (e.g., +1 might list the number administrator(s) in the US and other +1 countries). As long as the number of CAs for each country code prefix is very small (which seems likely, at least initially), there's no great need to have references for each TN, while still preventing the Nigerian NRA signing +1 numbers.

It might be interesting to see how much of EPP is applicable here.

As far as I can tell, assuming 4474bis header mods and the X.509 customs, you could build a system that allows interoperable validation. The only proprietary piece, initially, would be the cert delivery to the number holder.

Is that a bit less magic?

> 
>> Also, keeping scale in mind helps: In our case, the scale for "number-holding service providers" is currently a few thousand, not millions, so management solutions that don't scale to millions are acceptable to get started. The backend process today is pretty manual (faxes, web pages and proprietary APIs), so expectations are fairly low.
> 
> See, that matches up well with DNS too! The backend management/admin process is pretty manual afaict. ;)
> 
> -hadriel
> 
>